꼬반 Blog

회사에서 웹 서버의 로그 수집 및 분석을 위해 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 연동 확인

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

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

회사에서는 다양한 방식으로 모니터링을 하고 있다. 

일단 기본적으로 Nagios로 전반적인 서비스와 하드웨어 등을 모니터링 하고 있고

외부 모니터링 도구로 whatap.io 로 서버와 중요 url 5개(무료 제한) 를 모니터링 하고 있다.

각 서버 로그는 telegraf - influxdb - grafana / filebeat - elastic - kibana 로 이중화 하여

수집 및 모니터링을 하고 있다.

그럼에도 불구하고 안정적인 서비스를 위한 모니터링에는 끝이 없다.

그래서 이번에 Slack-Bot 을 활용하여 웹 서비스를 간편하게 체크할 수 있도록 해보았다.

먼저 개발은 다음과 같은 환경으로 진행하였다.

1. 웹 서비스 40개의 status code 와 응답시간을 체크 -> Golang 으로 개발

2. Node.js 로 Slack-Bot 개발 및 세팅

3. Slack 에서 정해진 키워드를 받으면 Bot 에서 1번에서 개발한 프로그램을 실행하여 결과를 

   메신져로 전송

아래는 결과물이다.

먼저 1번 항목의 경우 Golang 으로 작성한 이유는 Golang을 써보고 싶었고...

Golang에서 지원하는 고루틴이 매우 좋은 성능을 나타내기 때문이다. 

모바일 Slack App 에서도 동일하게 동작함을 확인하였고, 이로써 모니터링 도구가 하나더 추가되었다.

(모..모니터링 지옥이라능!)

수, 목, 금 3일동안 프로토타입은 나왔으니 앞으로 좀 가다듬으서 더 쓸만한 Bot을 만들어봐야겠다.

추신1. 이상 항목 1은 현재 내부에서만 접근가능하게 되어 있어서 나오는 항목으로 실제론 이상이 있지 않습니다?

추신 2. 아래 몇몇 서비스가 3초 이상으로 시간이 많이 걸리는데 올해 정리할 예정..

          (X키를 눌러 조의를 표하십시오.)

추신 3. 개발과 Bot 을 윈도우 환경에서 돌렸는데 생각보다 꽤 환경이 쾌적해서 놀랐..

          (Visual Studio Code - Golang - Node.js / VSC 에 각 Plugin 들을 설치하고 사용하니

           해당 프로그램 하나 켜놓고 다 작업하고 터미널도 바로 열리고 아주 맘에 들었습니다~)

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

그런데 로그를 살펴보면 각종 검색엔진의 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 파일을 단일로 고정시키면 위와같은 문제 없이 수집을 정상적으로 할 수 있다.

회사에서 관리하는 웹 서비스가 약 40개 가량 되다보니 모니터링이나 관리가 필요하여

어제, 오늘 간단하게 만들어보았습니다.

물론 해당 서버들에는 nagios 나 whatap, whatsup 등으로 모니터링을 하고 있고

서비스가 다운되면 메일로 알림이 오긴 하지만

아무래도 한눈에 지금 사이트들이 다 정상인지 아닌지 확인하기는 좀 어려운 부분이 있는건 사실입니다.

그래서 다음과 같은 요구 사항을 가지고 만들었습니다.

1. 모니터링 도메인의 추가/삭제 가능

2. 해당 도메인의 현재 상태 (response 응답 코드) 확인 가능 (대시보드에 접속했을때 동작)

3. 해당 사이트에 메인 페이지 스크린샷 저장 가능

일단은 위 요구사항을 기본으로 다음과 같이 작성하였습니다.

URL 부분은 가려두었습니다. 액션부분은 아직 미정인 부분입니다.

메인에 접속하면 모니터링 대상 도메인을 불러와 상태를 확인하고 해당 스크린샷을 찍어서 테이블로 뿌려줍니다.

ui는 bootstrap / nodejs, express, pageres 가 주 모듈이고, DB는 사용하지 않습니다.

개선 사항으로는

1. 스크린샷에서 확인되는 것 처럼 NO가 정렬되지 않고 노출되는 부분에 대한 수정

2. 스크린샷이 현재 시점으로 저장되는데 날짜와 시간을 파일명에 추가하여 이력관리가 가능하도록 할 것

3. 액션 추가 (왼쪽 메뉴의 관리, 이력 포함)

정도가 있습니다. 추후 수정하겠죠.. 아마...

주요 소스는 아래와 같습니다.

index.js - router

router.get('/', function(req, res) {
    fs.readFile('../url.list', 'utf8', function (err, data) {
        var array_url = data.split("\n");
        res.header("Access-Control-Allow-Origin" , "*");
        res.render('index', { result: array_url });
    });
});

router.get('/load', function(req, res) {
    fs.readFile('../url.list', 'utf8', function (err, data) {
        var array_url = data.split("\n");
        res.header("Access-Control-Allow-Origin" , "*");
        res.send(array_url);
    });
});

router.post('/check', function(req, res) {
    var body = req.body;
    //console.log(body.t_url);
    check.checkUrlStatus(body.t_url, function(result) {
        //console.log(result);
        res.header("Access-Control-Allow-Origin" , "*");
        res.send(result+" : "+body.cnt);
    });
});

checkUrl.js

/**
 * Created by ggoban on 16. 1. 4.
 */
var http = require('http'),
    url = require('url'),
    Pageres = require('pageres');
    require('events').EventEmitter.defaultMaxListeners = Infinity;

exports.checkUrlStatus = function (Url, callback) {
        var options = {
            method: 'GET',
            host: url.parse(Url).host,
            port: 80,
            path: url.parse(Url).pathname
        };

        var pageres = new Pageres({delay: 2})
            .src(Url, ['1024x768'])
            .dest(__dirname+'/public/screenshot');
        pageres.run(function (err) {
            if (err) {
                throw err;
                console.log(err);
            }
            console.log('done');
        });

        http.get(options, function (res) {
            //console.log(options);
            //console.log(res.statusCode);
            callback(options.host+options.path+" : "+res.statusCode);
        }).on('error', function(e) {
            //console.log(options);
            //console.log(e.message);
            callback(options.host+options.path+" : "+ e.message);
        });

}

위 버전은 현재 standalone 버전으로 작성해두었고 원래 진행하고 있는 satm쪽으로 모듈을 추가할 예정입니다.

월, 화 이틀동안 급조하느라 소스가 매우 허접합니다. ㅠ _ㅠ 혹시나 해당 포스팅을 보시게 되면 가감없이

수정할 부분이나 부족한 부분에 대해 지적해주시면 매우 감사하겠습니다.

사용하는 서버의 수량이 적다면 모르지만 서버가 한대, 두대가 늘어나면 늘어날수록 관리는 점점 어려워진다.

게다가 OS도 각기 다르고 어플리케이션에 DB에 보안문제까지 생각하면

관리만 하더라도 어지간한 중노동이다.

그래서 다양한 모니터링도구들이 존재하지만 사용하기 썩 좋은 것은 드문것이 사실이다.

우리 회사에서는 그래서 최근에 what's up / nagios / elk 등으로 시스템을 구축했는데

해당 솔루션들이 설치와 설정이  그리만만하지 않다.

그러던중 와탭 (whatap) 서비스를 알게됬다.

무료로(기본 Basic 상품 - 24시간만 데이터 장) 간편하게 서버 모니터링을 할수 있다. 설치도 설정도 매우 쉽다!

일단 https://www.whatap.io/ko.html 사이트에서 가입을 하고 로그인을 하면

다음과 같은 대시보드에서 모니터링 서버를 추가할 수 있다.

지원하는 운영체제는 Windows / Linux 지원하고 있으며 거의 대부분의 버전을 지원하지만 너무 오래된 버전은

지원하지 않는다. (Fedora 8에서 설치가 되지 않았음. 다만 동일버전대의 커널인 CentOS 5에서는 설치가 됨.)

윈도우는 설치파일을 받아 실행 후 라이선스를 등록하기만 하면 되고

리눅스도 리포지토리 추가 후 yum / apt-get 으로 설치 후 실행하면 된다. 

실행은 설정스크립트를 그대로 커맨드 라인에 입력하면 자동으로 라이선스 입력 후 에이전트가 동작된다.

그러면 서버 목록과 대시 보드를 통해 서버의 상태를 모니터링 할 수 있는데

무료 치고는 성능이 매우 훌륭하다.

기본적인 서버상태는 물론이고 각 서버를 선택해서 상세내역으로 들어가면

cpu / memory / 프로세스 / 디스크 / 트래픽 / 알림 / 로그 등을

확인할 수 있고 각 프로세스의 상세 상태도 보여준다.

거기다가 모바일 앱도 존재한다!

모바일 앱을 설치하고 사용자 계정으로 로그인하면 모바일 기기에서도

언제나 서버 상태를 모니터링 할 수 있다.

무료로 이정도의 서비스라면 매우매우 훌륭하다!

다만 아직 부족한 부분들이 조금 남아 있지만 빠르게 개선해나고 있고, 더욱 좋아질 거라는 것을 

기술 블로그를 둘러보고 확신할 수 있었다.

회사 서버들을 무료로 사용하여 보고 괜찮다면 유료 서비스 도입을 한번 고려해봐야 겠다.