꼬반 Blog

일단 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를 보면 부지런히 해당 쿼리를 수행하고 있음을 알게 되었다. 그래서 이후는 쿼리를 수행시키고

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

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

웹 서버를 운영하다 보면 서버의 로그를 수집하고 모니터링을 하는 부분이 매우 중요해진다.

그런데 로그를 살펴보면 각종 검색엔진의 crawler로 인해 로그가 고통받는걸 볼 수 있다.

(어디가든 bot 이 문제야! ㅠㅠ)

그래서 이 bot 들의 로그를 남기지 않기 위해서는 다음과 같이 설정하여 주면 된다.

참조 : https://bjornjohansen.no/exclude-requests-from-nginx-access-log

map $http_user_agent $log_ua {

    ~Pingdom 0;
    ~Googlebot 0;
    ~Baiduspider 0;

    default 1;
}

server {
       
    […]

    access_log /var/log/nginx/access.log main if=$log_ua;

}

user_agent 에 특정 문자열을 포함한 경우는 로그를 남기지 않게 설정할 수 있다.

이 설정을 응용하여 특정 ip 나 특정 refferer 에서 로그를 남기지 않게 설정할 수 있다.

위 설정 도입 후 모니터링 솔루션에서 수집되는 로그수가 많이 감소하였다.

일반적으로 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 파일을 단일로 고정시키면 위와같은 문제 없이 수집을 정상적으로 할 수 있다.