728x90

엔지니어에게 로그는 물과 같습니다.
무슨 일이 일어나더라도 충분한 로그가 있으면 해결할 수 있기 때문입니다. 
다양한 환경에서 Proxy로 활용되는 엔진엑스에서도 마찬가지입니다.
문제는 로그가 너무 많은 경우 인스턴스 운용이 어려울 수 있다는 것이죠. 


원칙#1, 로그는 일단 끄고 시작하자

이게 무슨말이냐구요?
로그를 왜 끄고 시작하냐구요?
네, 로그를 끄고 시작하는 것을 권장합니다.

엔진엑스 구성 파일은 복잡합니다. 
여러개의 분리된 파일을 include 로 쓰는 것이 기본 구성이고
디폴트 구성 자체가 이렇게 되어 있다보니 
대부분 nginx.conf 에서 /conf.d/*.conf 로 이어지는 구성을
채택하고 사용하고 계실 겁니다.

권고 드리는 기본 구성은 nginx.conf 에서 access_log를 끄고
location 지시자 등 필요한 경우에 access_log를 활성화하는 방식입니다. 

// nginx.conf

http {
    ...
    log_format  main  '$remote_addr - $remote_user [$time_local] "$scheme" "$request" '
                      '$status $upstream_status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for" "$http_host" "$upstream_addr"';

    access_log off;
    ...
    ...
    include /etc/nginx/conf.d/*.conf;
}

위 설정은 nginx 기본 설정 파일인 nginx.conf의 예입니다. 
http 서빙을 위해 http 블록이 들어가 있고 
로그 형식을 지정하는 log_format과 access_log 지시자가 있습니다. 

access_log 는 기본적으로 활성화 되어 있기 때문에
off 를 지정하여 http 요청에 대해 기본적으로 로깅을 하지 않도록 구성했습니다. 
패키지 저장소에서 nginx를 설치했기 때문에 /etc/nginx/에 필요한 파일들이 위치해 있고 
conf.d 경로 아래의 conf 확장자를 가진 파일들을 include 하고 있습니다.

 

원칙#2, 로그는 필요한 경우에만 켜자

로깅을 껐으면 이제는 필요한 부분에서 로깅을 켜야 합니다. 
보통은 location 블록을 활용해 업스트림 서버를 구분하거나 
필요한 프록시 기능을 구현하고 계실겁니다. 
다음의 설정은 location 블록 내에서 로깅을 활성화하는 예시입니다. 

// /conf.d/default.conf

server {
    ...
    location = /no-log-path {
        ...
        ## 여러 설정들 ##
        ...
    }

    location = /admin {
        ...
        access_log /var/log/nginx/admin.access.log  main;
        ...
    }
}

이렇게 구성하면 /no-log-path 경로로 들어오는 요청들은
앞서 http 블록에서 지정한 access_log off 에 따라 로깅을 하지 않습니다. 
대신 중요한 경로인 /admin 으로 들어오는 요청들은 
앞서 지정한 main 로그 형식에 따라 지정된 경로에 로그를 남기게 됩니다. 

 

원칙#3, 필요한 경우 샘플링해서 로그를 남기자

이렇게 필요한 경우에만 로그를 남기도록 구성했더라도 
요청량이 너무 많은 경우에는 제한적으로 로그를 남길 필요가 있습니다. 
엔진엑스의 access_log 지시자는 if 구문을 이용해 조건부로 활성화 할 수 있습니다.
위의 예제를 조금 수정해 보겠습니다. 

// /conf.d/default.conf

split_clients $remote_addr $is_need_to_logged {
    5%    1;
    *     0;
}

server {
    ...
    location = /no-log-path {
        ...
        ## 여러 설정들 ##
        ...
    }

    location = /admin {
        ...
        access_log /var/log/nginx/admin.access.log  main if=$is_need_to_logged;
        ...
    }
}

split_clients 지시자를 이용해 사용자 IP중 5%에 대해서
$is_need_to_logged 라는 변수 값을 1로 지정하도록 했습니다. 
1은 true의 의미를 갖는다는 것을 활용해 access_log 지시자의 if 구문에 활용했습니다. 
이렇게 구성한 설정의 흐름을 정리하면 다음과 같습니다.

  1. 엔진엑스 서버로 http 요청이 들어오면 일단 로그를 비활성화 한다
  2. /admin 경로로 들어오는 요청은 main 형식으로 /var/log/nginx/admin.access.log 파일에 로그를 기록한다
  3. 다만, 요청 사용자 IP기준으로 5%의 사용자에 대해서만 로그를 남긴다

로그는 중요합니다. 
하지만 로그는 가장 큰 부담중 하나입니다.
적절한 규모로 로그를 관리하는 것이
편안한 취침의 지름길입니다.

엔진엑스의 다양한 활용에 대해 알고싶다면
제가 번역한 <엔진엑스 쿡북>을 읽어보시는 건 어떨까요? :-)

 

 

NGINX 쿡북 - 예스24

애플리케이션의 성능, 신뢰성, 보안을 책임지는만능 웹 서버 소프트웨어 엔진엑스 제대로 활용하기엔진엑스 설치 및 사용법부터 다양한 모듈과 실전 운영 팁까지 다룬다. 엔진엑스라는 애플리

www.yes24.com

 

 

본 포스팅은 제휴 마케팅을 통해
소정의 수수료를 지급받는 링크를 포함하고 있습니다

728x90
728x90

 

제작년에 출간했던 <NGINX 쿡북>의 개정판 번역서 작업을 완료했습니다!
지난주부터 여러 서점에 배포되기 시작했고
온라인 서점에서도 쉽게 구입하실 수 있습니다. 

초판 번역은 참 버거웠는데, 개정판 작업은 의외로 빠르게 끝낼 수 있었습니다.
리버스 프록시의 대표주자이자 k8s ingress controller의 대표주자인 NGINX!
아직 익숙하지 않다면 <NGINX 쿡북> 개정판으로 NGINX를 정복해 보는건 어떨까요!?

 

NGINX 쿡북 - YES24

애플리케이션의 성능, 신뢰성, 보안을 책임지는만능 웹 서버 소프트웨어 엔진엑스 제대로 활용하기엔진엑스 설치 및 사용법부터 다양한 모듈과 실전 운영 팁까지 다룬다. 엔진엑스라는 애플리

www.yes24.com

 

본 포스팅은 본인 책에 대한 판매 링크를 포함하고 있습니다. 
판매를 통해 소소한 수수료를 지급받을 수 있습니다!

 

728x90
728x90

Grafana 8.x 이상 버전에서는 웹 소켓을 이용하여 업데이트 되는 데이터를 패치해 옵니다.
이전에는 별도의 HTTP Request를 이용했지만, 이제는 웹 소켓을 이용해 
매번 연결을 보내는 오버헤드를 줄이려는 의도라고 생각합니다. 
Grafana 에서는 이 기능을 Grafana Live라 부릅니다. 

 

Grafana Live

Grafana Live overview Grafana Live is a real-time messaging engine introduced in Grafana v8.0. With Grafana Live, you can push event data to a frontend as soon as an event occurs. This could be notifications about dashboard changes, new frames for rendered

grafana.com

Grafana 인스턴스가 직접 엔드포인트를 제공하면 웹 소켓 이용에 특별한 문제가 없으나
여러가지 이유로 앞단에 NGINX 등을 통한 리버스 프락시를 구현해 두었다면
웹 소켓 연결이 제대로 맺어지지 않는 문제가 있습니다.

물론 Grafana 의 동작 자체는 문제가 없고 브라우저 개발자 도구/콘솔상에 
보기 싫은 빨간색 에러가 잔뜩 찍히는 불편함이 있습니다.

보기 싫은 에러들... ㅜㅜ

 


방법#1. Grafana Live 기능을 꺼버리자!

가장 쉬운 방법은 Grafana Live 기능을 꺼버리는 방법입니다. 
다만 이 방법은 Grafana Live 문서에서 이야기 하고 있는 기술의 장점을 버리는 선택이 됩니다. 
그렇지만 굳이 필요 없다면 기능을 꺼버리는 것이 여러모로 더 나은 선택일 수도 있습니다.

Grafana 설정 파일인 grafana.ini 혹은 custom.ini 에 
[live] 섹션을 찾아 max_connections 값을 0으로 설정하면 기능을 끌 수 있습니다. 

 

방법#2. 리버스 프락시에 웹 소켓 설정을 추가하자!

조금 더 적극적인 사용자이고 새로운 기술들을 활용해 보고 싶다면?
구성해 둔 리버스 프락시의 설정을 업데이트하여 웹 소켓을 잘 소화하도록 수정할 수 있습니다. 
여기에서는 가장 널리 사용되는 nginx를 리버스 프락시로 사용한 경우입니다. 

웹 소켓은 hop-by-hop, 즉 클라이언트와 nginx, 그리고 nginx와 Grafana 사이의 연결을 별도로 취급합니다. 
클라이언트가 Grafana와 웹 소켓을 통한 데이터 교환을 하기 위해서는 
nginx가 웹 소켓과 관련하여 일종의 터널링을 해주어야 합니다. 
마치 nginx가 없는 것처럼 클라이언트와 Grafana 사이를 연결해 주어야 하는 것입니다. 

http {
    map $http_upgrade $connection_upgrade {
        default upgrade;
        '' close;
    }

    upstream grafana {
        server 127.0.0.1:3000;
    }

    server {
        listen 8000;

        location / {
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;
            proxy_set_header Host $http_host;
            proxy_pass http://grafana;
        }
    }
}

사용자 환경에 따라 nginx 설정 파일을 쪼개서 쓸 수도 있기 때문에 
공식 문서에서 가이드 하고 있는 예제 설정을 가져왔습니다. 

웹 소켓은 Upgrade 헤더를 이용하여 웹 소켓 사용이 가능한지를 체크하고 
문제가 없는 경우에만 커넥션을 맺고 데이터를 흘리는 구조입니다.

설정의 내용은 클라이언트와 nginx 간에 Upgrade 헤더 값에 따라 
변수($connection_upgrade) 값을 지정하고 
이 값을 Grafana로 요청을 보낼때 사용하는 방식입니다. 

마지막의 location 블록을 보면 클라이언트가 보낸
Upgrade 헤더 값($http_upgrade)을 Upgrade 요청 헤더에 지정하고 
map 블록으로 지정한 $connection_upgrade 변수 값을 
Connection 헤더에 담아 Grafana로 보내는 것을 확인할 수 있습니다. 

이렇게 설정하고 nginx config을 리로드 하면 에러가 깔끔하게 사라집니다!

깔끔합니다! 101 응답도 잘 내려왔네요!


nginx 기준으로 위와 같은 형태로 구성하는 것은 1.13.x 이후 버전부터 가능합니다. 
혹시나 예상대로 잘 동작하지 않으면 nginx의 버전을 살펴보기 바랍니다!

꾸준히 판매되고 있는 저의 번역서 NGINX 쿡북!
아직 구매하지 않았다면 아래 링크로 고고씽~ 구매 달려주시기 바랍니다!

 

NGINX 쿡북 - YES24

빠르고 안전한 웹 서비스를 위한 NGINX 레시피엔진엑스는 널리 사용되는 웹 서버용 오픈 소스 소프트웨어다. 가볍고 확장 가능하며 요청을 동시에 처리할 수 있어 트래픽이 높을 때에도 성능이

www.yes24.com

 

본 포스팅은 제휴 마케팅을 통해 
소정의 수수료를 지급 받을 수 있습니다. 

728x90

+ Recent posts