꼬반 Blog

오랜만에 MySQL Log를 분석하기 위해 구축해둔 ELK Cluster를 올렸다. 그러자 es01, es02, es03, es04 는 정상적으로 실행이 되었으나 kibana가 다음과 같은 error와 함께 실행되지 않았다.

검색을 통해 아래 사이트에서 해결방법을 확인하였고 조치하기 위하여 kibana.yml 파일을 별도로 생성후 kibana만 다시 실행 시켜준 뒤 아래와 같이 조치하였다.

https://discuss.elastic.co/t/forbidden-12-index-read-only-allow-delete-api/110282 

https://dev-yeon.tistory.com/12

이후 정상적으로 동작하는것을 확인하였다.

일단 Elasticsearch는 버전업이 무지하게 빠르다. 무시무시하다. 

개발자님들에게 X키를 눌러 JOY를...

그런 환경이므로 elk를 docker를 활용하여 올린다. 

docker의 환경설정을 수정하여 docker 볼륨 위치도 변경해놓고 2개 클러스터 512m 램으로 

기본 사용하여 mysql의 general 로그를 파싱하여 넣기로 했다.

일단 직접하려고 하루정도 golang으로 삽질하다가 검색 고고싱 아래 사이트들에서 도움을 받았다.

- *<https://pad.yohdah.com/285/mysql-general-query-log-and-logstash>

- <https://qbox.io/blog/mysql-logs-elasticsearch-logstash-kibana>

- <https://qbox.io/blog/ship-mysql-logs-elasticsearch-filebeat>

- *<https://github.com/cj203/logstash-mysql-general-log-filter/blob/master/pipeline.conf>

특히 별표가 있는 사이트가 도움이 되었는데 일단 버전이 다른 부분은 좀더 수정하였다.

첫번째 pad 사이트의 아래 부분의 파이선 스크립트로 general 로그를 전처리를 수행하고 

이후 logstash 로 파싱하여 elastic으로 input해주었는데 중간에 filter 부분에 multiline { }

은 현재 사용하는 7.1.1 버전에서는 codec => multiline { } 으로 바꿔 사용하여 주고

filter 부분이 아닌 input 쪽에 넣어주어 

input {
  file {
    codec => multiline {
      pattern => "^%{NUMBER}\s+%{NOTSPACE}"
      negate => "true"
      what => "previous"
    }

  ...

}

처럼 설정해준다.

그럼 path에 지정한 log파일을 파싱해서 input 하는데 대상 로그 사이즈는 2016년10월부터 현재까지 약 80G

로그 파일이고 전처리는 오래 걸리지 않았으나 elk로 전체 data를 입력하는데는 약 5일정도 걸린것 같다...

그리고 중간에 elk memory heap 이 부족하여 error가 났고 docker-composer 를 수정하여

각 node의 메모리를 4G로 / 전체 클러스터를 마스터1 / 노드 3으로 수정하여 이후 문제없이 모두 입력을 받았다.

그리고 이후 입력된 값을 확인하는 중에 사용한 grok 패턴은 connect command 에만 접속한 db, 유저, client 정보가 나오고 나머지엔 나오지 않아 다른 레코드들의 field 를 업데이트 해주어야 했다.

이는 update_by_query 를 통해 수행하였는데 

- <https://www.roseindia.net/elasticsearch/elasticsearch-update-by-query-add-field.shtml>

- <https://stackoverflow.com/questions/44725905/how-to-update-a-string-field-with-elasticsearch-update-by-query>

- <https://stackoverflow.com/questions/44725905/how-to-update-a-string-field-with-elasticsearch-update-by-query>

- <https://discuss.elastic.co/t/is-there-any-way-to-update-multiple-fields-by-update-by-query/70644/1>

- <https://discuss.elastic.co/t/add-field-to-existing-document-by-query/68874/1>

다음 사이트들의 도움을 받았고 kibana console 에서 

POST /mysql-xxxx-xx-xx/_update_by_query
{
  "script": {
    "inline": "ctx._source.mysql_database=\"\";ctx._source.mysql_connect_user=\"\";ctx._source.mysql_connect_host=\"\"",
    "lang": "painless"
  },
  "query": {
    "match": {
      "command": "Query"
    }
  }
}

특정일에 대한 인덱스에 대해 테스트 후 동작하는 것을 확인하고 mysql-* 로 전체 인덱스에로 쿼리를 수행했다.

그리고 kibana에서 request timeout 으로 정상 수행 결과가 나오지 않는 것을 보고는 날짜별/월별/일별 등 다양한 

방법으로 테스트 하였는데 월별 정도로 돌릴때 타임아웃없이 수행된것을 보고 실제 레코드를 확인해보면

필드가 반영이 안되어 있는 등 여러 이슈를 발견하여 해결하기 위해 다양하게 체크를 했는데

결과적으로는 에러가 아니라 실질적으로 해당 쿼리를 수행하고 kibana에서의 대기시간에 return이 없어서

timeout이 난 것뿐 이고 

CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O           PIDS
002b90c4fc50        es04                229.43%             4.831GiB / 62.65GiB   7.71%               456GB / 159GB       50.1GB / 531GB      215
3052fb09ca6a        es01                268.17%             5.363GiB / 62.65GiB   8.56%               1.05TB / 955GB      65.5GB / 597GB      259
73ee3a3d2f17        es03                227.66%             4.868GiB / 62.65GiB   7.77%               442GB / 635GB       49.6GB / 589GB      222
d81350bd7053        kibana              0.55%               174.1MiB / 62.65GiB   0.27%               19.5GB / 1.58GB     437MB / 102kB       14
5b36619c88b5        es02                261.03%             4.857GiB / 62.65GiB   7.75%               499GB / 212GB       61.8GB / 584GB      229

도커 컨테이너의 resoure를 보면 부지런히 해당 쿼리를 수행하고 있음을 알게 되었다. 그래서 이후는 쿼리를 수행시키고

리소스 사용률이 없어질때까지 기다리기..

이후 원하는데로 필드가 추가된 것을 볼수 있었다. 

회사에서 웹 서버의 로그 수집 및 분석을 위해 2015년 말 부터 ELK Stack과 TICK+Grafana Stack으로

웹 서버 및 주요 서버, 서비스의 로그 수집 및 대시보드를 통한 모니터링을 활용해 왔다.

다만 ELK는 당시에는 버전이 낮았고 성능이나 사용적인 부분에서 InfluxDB 보다 불편함을 느껴

지금까지 주로 TICK을 사용해왔다.

ELK는 1.X에서 2.X로, 그리고 5.X로 마이그레이션을 하며 사용은 했었지만 제대로 활용하진 않았다.

얼마전 Elastic Tour 2017 Seoul 에 참석하여 6.X ELK를 보니 다시 한번 제대로 사용해보자는 생각이 들어

처음부터 새로 구축하기로 하였다. 

이 글은 간단한 설치 및 구성과 logstash, filebeat 를 통한 로그 수집, 필터 처리, kibana를 통한

대시보드 작성을 진행과정에 따라 적어보고자 한다.

1.  ELK Stack 설치

1.1. 설치 버전 : 6.1.1

1.2. 준비 사항 : Docker CE 17.12 / docker-compose 1.18 / Golang 1.5 이상

1.3. 쉽게 사용하기 위해 Docker, Docker-compose 를 통해 elk-cluster 를 구축하려면 다음과 같이 docker-compose.yml 파일을

     사용하여 클러스터를 올린다. 몇몇 세부 옵션들은 yml 파일을 수정하여 사용한다.

version: '2.2'

services:

  elasticsearch1:

    image: docker.elastic.co/elasticsearch/elasticsearch:6.1.1

    container_name: elasticsearch1

    environment:

      - cluster.name=kobic-elk-docker-cluster

      - bootstrap.memory_lock=true

      - "ES_JAVA_OPTS=-Xms4096m -Xmx4096m"

    ulimits:

      memlock:

        soft: -1

        hard: -1

    volumes:

      - esdata1:/usr/share/elasticsearch/data

    ports:

      - 9200:9200

    networks:

      - esnet

  elasticsearch2:

    image: docker.elastic.co/elasticsearch/elasticsearch:6.1.1

    container_name: elasticsearch2

    environment:

      - cluster.name=kobic-elk-docker-cluster

      - bootstrap.memory_lock=true

      - "ES_JAVA_OPTS=-Xms2048m -Xmx2048m"

      - "discovery.zen.ping.unicast.hosts=elasticsearch1"

    ulimits:

      memlock:

        soft: -1

        hard: -1

    volumes:

      - esdata2:/usr/share/elasticsearch/data

    networks:

      - esnet

  kibana:

    image: docker.elastic.co/kibana/kibana:6.1.1

    container_name: kibana

    environment:

      SERVER_NAME: kibana.kobic.re.kr

      ELASTICSEARCH_URL: http://localhost:9200

    ports:

      - 5601:5601

    networks:

      - esnet

  logstash:

    image: docker.elastic.co/logstash/logstash:6.1.1

    container_name: logstash

    environment:

      XPACK_MONITORING_ELASTICSEARCH_URL: http://localhost:9200

    ports:

      - 5044:5044

    networks:

      - esnet

    depends_on: ['elasticsearch1']

volumes:

  esdata1:

    driver: local

  esdata2:

    driver: local

networks:

  esnet:

위 파일이 위치한 곳에서 docker-compose up 명령어를 통해 서비스를 올리면 해당 이미지들을 pulling 하고 기다리면

각 컨테이너가 실행이 된다. 그후 브라우저에서 localhost:5601 로 접속하면 kibana에 접속할수 있고 모니터링 탭을 통하여

각 elk node, kibana, logstash 의 상태를 확인할 수 있다.

회사에서 사용하고 있는 웹 서비스의 구성은 간단하게 다음과 같다.

Nginx (리버스 프록시 서버) --- WAS (각 어플리케이션 서버) --- 백엔드 (DB, 스토리지 등)

여기서 유저는 가장 상단의 Nginx 서버에만 접근이 가능하다. 이러한 구성은 

기본적으로 보안이나 관리 등에 용이하다.

그리고 각 서버들의 상태 모니터링 및 로그 수집을 위해 2가지 시스템을 혼용하여 사용하는데

ELK 와 TICK 이 바로 그것이다.

ELK는 Elasticsearch, Logstash, Kibana 를 지칭하는데 과거 버전에서 5.x 버전으로 

업그레이드를 하면서 이 로그 수집방식이 Logstash-forward 대신에 beat 로 대체 되었다.

그래서 각 단말에 beat가 서버의 로그를 수집하여 Elasticsearch 로 보내고 저장되며 Kibana를 통해

모니터링 및 대시보드를 통한 Visualize 가 가능하다.

Elasticsearch 와 Kibana 는 Docker와 Docker-composer 를 통해 관리된다. 

TICK 은 Telegraf, Influxdb, Chronograf, Kapacitor를 의미하며 각각 수집, 시계열DB, 모니터링 및 관리, 알람

의 기능을 가지고 있다.

그리고 이 데이터들은 Grafana 라는 Visualize platform 에서 활용이 가능하다.

이번에 한 작업은 다음의 목적을 가지고 진행되었다.

1. 특정 사이트의 접속 로그에 대한 모니터링이 필요

2. 접속 지역에 대한 확인이 가능할 것.

3. Nginx access log 에는 기본 apache log + agent, response time 이 붙은 custom log 이며 접속자의 IP가

   확인이 된다. 이 IP를 IP조회 사이트에서 조회하여 지역이 확인이 가능하나 불편하다.

4. Dashboard 를 통해 바로 확인할 방법이 필요.

그래서 위의 목적을 달성하기 위해 다음과 같은 작업을 진행 하였다.

1. 기존 리버스 프록시 서버인 Nginx 서버에 GeoIP Module 연동

  1.1. nginx-module-geoip 를 설치

  1.2. 설정 파일에 load module 후 테스트 -> 로드 X (버전 문제 nginx geoip version 1013003 

        instead of 1013000, 즉 현재 nginx 는 1.13.0 버전 이고 모듈은 1.13.3 버전

  1.2. 기존 사용하던 1.13.0 버전을 1.13.3 버전으로 재컴파일 (rpm, yum 버전 등 build 버전은 사용하지 않음

        http2 지원등을 위해 직접 소스 컴파일, 라이브 서버에 적용 전 VM에 테스트 후 진행)

  1.3. 1.13.3 버전 설치 후 모듈 연동 테스트 -> 성공

  1.4. access log 형식에 geoip_city, geoip_region, geoip_country_code, geoip_country_code2 추가 후 확인 완료

2. Telegraf 수집 형식 변경

  2.1. 기존 logparse 에 grok matching 을 위해 필드 추가 적용 (country_code 는 2개 추가한 이유가 하나는 tag로

       지정하기 위함.)

  2.2. influxdb 에서 수집된 field, tag 에 반영 확인

3. Grafana 연동

  3.1. Grafana World Map Plugin 설치

  3.2. https://github.com/grafana/worldmap-panel / https://github.com/grafana/worldmap-panel/issues/30

       참고하여 설정 진행

  3.3. World-Map 연동 확인

총평. 진행된 내용만 간략히 적었지만 사실 각 작업간에 많은 시행착오가 있었다. 물논 그런 시행착오가 없을 순

       없다. 각 작업 내용은 다시 한번 정리해서 추후 포스팅 해야겠다.

일반적으로 Tomcat을 사용하여 Virtual Host 설정을 하게되면

해당 Virtual Host 의 access log 를 Tomcat의 org.apache.catalina.AccessLog 를 사용하게 된다.

이때 기본 옵션의 상태로 저장되는 log 의 형태는

prefix + timestamp + suffix 형태가 된다.

이때 중간에 들어가는 timestamp 로 인해 일반적인 다른 로그 프레임워크와는 결과값이 다르게 된다.

A : service.access.log / service.access.log-YYYYMMD(D-1)

Tomcat default : service.access.YYYYMMDD.log / service.access.YYYYMMD(D-1).log

위와 같은 차이가 발생한다.

이 부분에 있어 A와 같은 형식으로 로그를 저장하는 방식으로 변경하는 방법은 아래와 같다.

참조 : http://tomcat.apache.org/tomcat-7.0-doc/config/valve.html

<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
               prefix="service.access" suffix=".log" renameOnRotate="true"
               pattern='%h %l %u %t "%r" %s %b "%{Referer}i" "%{User-agent}i" "%v" %T' />

중간에 renameOnRotate 옵션을 true 로 설정하고 톰캣을 재시동하게 되면

A와 같은 타입으로 로그가 저장되게 된다.

여기서 A와 같은 타입으로 변경하는 이유는 다음과 같다.

오픈소스 로스 수집기를 활용하여 웹 서버의 로그를 수집하여 모니터링 솔루션을 구축하는데

다음과 같은 문제를 발견하였다.

logstash, telegraf 에 수집할 log file 형식을 지정해주는데 Tomcat 처럼 현재 날짜를 포함하는

로그를 위해 로그패턴을 날짜를 포함하거나 혹은 **.log 와 같이 해당 디렉토리내 전체 파일에 대해

수집 설정을 해준다. 그러나 날짜가 변경되어 새로 생성되는 로그 파일의 경우 에이전트가 재시작되어야만

새로 생성되는 로그파일을 정상적으로 추적하게 되는 문제가 발생한다.

따라서 access log 파일을 단일로 고정시키면 위와같은 문제 없이 수집을 정상적으로 할 수 있다.