Site icon GRIP.News

AWS, ElasticSearch Service 의 WebHook을 통한 분석 데이터 통보

grip.news

앞서 Fluentd 를 사용해 Amazon Elasticsearch Service (이하 AWS) 에 NGINX Access Log 전달 방법과 시각화에 대해 알아봤다. 현재 자사에서 NGINX 는 Reverse Proxy 개념 Apache Tomcat 과 연결되어 있다. NGINX 에서 수집된 Access Log 의 데이터를 AES가 분석해 문제가 발생한 경우 메신저로 알람을 받고자 한다. ‘명확한’ 장애가 발생한 경우 Zabbix 가 알림을 주지만, 시스템에치명적인 문제가 발생하지 않는 경우 Zabbix 가 감지할 수 없기 때문.

Fluentd 의 활용. ElasticSearch, Kibana 을 사용한 Nginx Log 수집

 

아키텍쳐

구성은 매우 간단하다. Tomcat 과 연결된 NGINX 는 Reverse Proxy로 동작하며 모든 사용자 트래픽을 처리하기 때문에 명확한 Access Log가 남는다. 또한 WAS 의 Log 를 돌려 받기 때문에, 커스터마이징 하기 애매한 Confluence/JiRA 의 로그를 저장하기에 적합하다. (물론, Tomcat 보다 NGINX 가 성능이 좋은점도 있고. log4j 를 건드리기도 애매하고..)

 

NGINX Access Log 설정

AES 가 분석하기 위해서는 잘 정리(규약)된 Access Log 가 필요하다. 현재 자사에서 사용중인 NGINX Access Log Format 은 다음과 같다. 이 데이터를 Fluentd 가 AES 로 보낸다.

log_format json escape=json '{"@time": "$time_iso8601",'
        '"@fields": { '
                '"host": "$remote_addr",'
                '"vhost": "$http_host",'
                '"status": "$status",'
                '"protocol": "$server_protocol",'
                '"method": "$request_method",'
                '"path": "$uri",'
                '"querystring": "$query_string",'
                '"req": "$request",'
                '"size": "$body_bytes_sent",'
                '"reqtime": "$request_time",'
                '"uprtime": "$upstream_response_time",'
                '"ua": "$http_user_agent",'
                '"forwardedfor": "$http_x_forwarded_for",'
                '"forwardedproto": "$http_x_forwarded_proto",'
                '"referrer": "$http_referer"}}';

 

Fluentd(td-agent) 설정

이번 포스트에서는 Fluentd 가 바로 AES 로 Access Log 를 전달한다. 때문에 특이점은 없다.

<source>
        @type config_expander
        <config>
                @type tail
                path "/var/log/nginx/access.log"
                pos_file "/var/log/nginx/access.log.pos"
                format json
                tag "wiki.nginx.access"
        </config>
</source>

<match wiki.**>
        type_name nginx
        @type "aws-elasticsearch-service"
        tag_key @log_name
        include_tag_key true
        logstash_format true
        flush_interval 10s
        buffer_type file
        buffer_path /var/log/td-agent/buffer/casted.nginx.access.buffer

        <endpoint>
                url {AES EndPoint}
                region            {Region}
                access_key_id     "{IAM Access Key}"
                secret_access_key "{IAM Secret Key}"
        </endpoint>
</match>

 

AES Log Discovery

JSON Format 으로 전달하기 때문에 데이터의 가시성은 매우 좋은편이다. 이중 모니터링 하고자 하는 데이터는 fields.status 값을 HTTP Response Code다. 200 인 경우 문제가 없지만, 4xx(404제외), 5xx 계열이 발생할 경우 서비스에 영향을 미처 품질 저하로 직결된다.

 

AES Alert 설정

AES 에서 취합, 분석된 데이터의 결과를 보낼 목적지를 선택하자. 자사는 Slack Alternative Messenger를 사용하고 있어 Custom WebHook/Slack 으로 사용해도 되고,  AWS SNS 등과 연결하면 연결된 Mobile/Email Service 를 사용할 수 있다.

 

설정에는 크게 주의해야 할 요소가 없다.

 

AES Alert Monitors

목적지에 보낼 모니터링 데이터를추려낸다. 간단한 설정과 쿼리문 작성이 필요하다.

 

주기는 경우에 따라 다르지만, 아래는 테스트로 ‘1분’으로 지정되어 있으며, 실제로는 15분 주기로 데이터를 수집해 알림을 보내고 있다. 마지막으로, ‘Define using extraction query’ 를 선택해 모니터링 조건을 Query 로 작성하자.

 

Query문 작성 예제는 ElasticSearch 의 페이지를 참고할 것을 추천하며, 다음 예제는 fields.status 값이 404 인 경우 알람을 발생시키게끔 정의되어 있다. 참고로 404는 테스트 데이터이며, 실제로는 사용하지 않고 있다.

아래 JSON을 잘 살펴보면, range 영역이 있는데, 15분 주기로 동작 하고 있기 때문에 이 범위 안에 있는 데이터만 검사할 것을 명시하고 있다. default_field 에 모니터링할 기본 필드명과 query 에는 어떤 값을 찾을 것인지 명시하고 있다. 만약 404가 아니라 401, 402를 찾는다면 401 OR 402 이런 형식으로 작성하자.

{
    "size": 0,
    "query": {
        "bool": {
            "must": [
                {
                    "query_string": {
                        "query": "404",
                        "default_field": "@fields.status",
                        "fields": [],
                        "type": "best_fields",
                        "default_operator": "or",
                        "max_determinized_states": 10000,
                        "enable_position_increments": true,
                        "fuzziness": "AUTO",
                        "fuzzy_prefix_length": 0,
                        "fuzzy_max_expansions": 50,
                        "phrase_slop": 0,
                        "analyze_wildcard": true,
                        "escape": false,
                        "auto_generate_synonyms_phrase_query": true,
                        "fuzzy_transpositions": true,
                        "boost": 1
                    }
                },
                {
                    "range": {
                        "@time": {
                            "from": "now-15m",
                            "to": "now",
                            "include_lower": true,
                            "include_upper": true,
                            "format": "epoch_millis",
                            "boost": 1
                        }
                    }
                }
            ],
            "adjust_pure_negative": true,
            "boost": 1
        }
    }
}

 

Trigger 작성

모니터링 조건에 부합되는 결과를 찾았을 때 동작시킬 트리거를 작성하자. 일반적으로 모니터링 조건을 입력하고 저장하면 바로 트리거를 선택하는 화면으로 넘어간다. 자. 앞서 우리는 Destinations 를 먼저 선택했다. 그 이유는 Trigger 에서 Destination을 지정 해야 하기 때문이었다.

 

일정 수 이상의 데이터가 발생했을 경우 알람을 받는다. 기본값은 0이다.

 

명칭과을 정의하고 Destination name 을 지정하면 Test 가 가능하다. 여기서 주의해야 할 것은 두가지.

  1. ‘한글(또는 기타 2바이트 문자)’는 지원하지 않는다. 이는 AES 의 Kibana 한정이다.
  2. 시간 데이터는 UTC 기준이다.

 

그리고 모니터링 자료는 목록으로 확인하거나, 대쉬보드에서 확인할 수 있다. 물론, 모니터링 및 트리거 데이터는 History 쪽이 보기 더 편하다.

 

 

결론

필요한 데이터를 Query 로 좀더 자세히 만들어 운영한다면, Zabbix, What’s Up 도구등에서 얻지 못한 정보를 취득 및 알람을 받을 수 있다. 최근 AES 에 VPC Flowlogs까지 추가 되었기 때문에 접근성이 좋아져 활용 성이 더 커지 상황이다. 한글 및 일부 Plug-in 에 대한 아쉬움이 남지만, 이런 환경 구축 및 사용을 십분 투자로 충분히 가능한 것이 클라우드의 매리트 아니겠는가. 😀

Exit mobile version