티스토리 뷰

반응형

이번에는 Docker-Compose로 ELK(Elastic, Logstash, Kibana) 스택을 기반으로 하는 모니터링 서버를 구축하는 방법에 대해 정리해보도록 하겠습니다. 아래의 예제에서는 Docker와 Docker Compose가 사전에 설치되어있다고 가정하고 진행하도록 하겠습니다. 만약 Docker와 Docker Compose가 설치되어 있지 않다면 이 글을 참고해주세요.

 

 

 

1. Docker Compose로 ELK 구축


[ ELK 구축 ]

1. Docker Compose 설정 Clone

git clone https://github.com/MangKyu/Docker-ELK

 

위의 버전은 기존의 Docker-Compose에서 X-Pack 라이센스를 basic으로 변경해두었다. 추가로 username, password 변경이 필요하다면 진행하도록 하자.

 

 

2. Logstash 파이프라인 설정 추가

Logstash 파이프라인 설정은 logstash/pipeline/logstash.conf를 수정해주면 된다. Logstash 파이프라인 설정은 크게 다음의 3단계로 구성된다.

  • Input: 로그를 전달 받음
  • Filter: 전달받은 로그 메세지 가공
  • Output: 처리한 로그 전송

 

input {
       # FileBeat를 통해 로그 수신
       beats {
               port => 5000
               host => "0.0.0.0"
               ssl => false
       }

}

filter {
       # Grok형식으로 들어오는 로그를 가공하기 위한 필터
        grok {
                # 로그 안에 LOGLEVEL 패턴이 있을 경우 파싱하여 log_level이라는 필드로 추가
                match => [
                    "message", "\[%{LOGLEVEL:log_level}\]"
                ]
        }
}

output {
       # 처리한 로그를 Elastic 서버로 전송
       elasticsearch {
               # TODO 각자의 서버에 맞게 IP 변경
               hosts => "서버IP:9200"
               user => "elastic"
               password => "changeme"
               index => "logstash-%{+YYYY.MM.dd}"
       }
}

 

 

여기서 하나 주목해야 하는 부분은 filter 단계의 grok 부분이다. 예를 들어 다음과 같은 로그가 Filebeat로부터 들어온다고 하자.

2021-10-29 16:09:20 [DEBUG] [UserService] addUser ...

 

우리는 해당 로그로부터 Log Level을 파싱하여 관리한다면 모니터링에 많은 도움이 될 것이다. 그래서 메세지에서 해당 부분을 파싱하여 커스톰 필드로 추가해준 부분이 match 부분이다.

match => [
    "message", "\[%{LOGLEVEL:log_level}\]"
]

 

위에서 LOGLEVEL은 (INFO, DEBUG, WARN) 등을 포함하는 사전에 정의된 패턴이고, 매칭되는 값이 있을 경우 log_level이라는 이름의 필드로 해당 값을 추가하는 것을 의미한다. 그 외에도 거의 모든 패턴이 사전에 정의되어 있다. 위의 로그를 완벽히 파싱하려면 다음과 같은 파싱 패턴을 적용해주면 된다. 

%{YEAR:year}-%{DATA:month}-%{MONTHDAY:day} %{TIME:time} \[%{LOGLEVEL:log_level}\]%{GREEDYDATA:log_msg}

 

Grok 패턴의 파싱을 위한 테스트는 Grok Debugger에서 하면 상당히 편리하다.

 

 

3. Docker Compose 실행

docker-compose build && docker-compose up -d

 

기본적으로 각각의 ELK 컴포넌트는 아래와 같은 포트에서 동작한다.

  • Elasticsearch : 9200 / 9300
  • Logstash : 5000 / 9600
  • Kibana : 5601

 

 

그러므로 해당 서버의 IP:5601로 접속하면 다음과 같은 Kibana 화면을 확인할 수 있다.

 

 

그리고 Kibana에서 로그를 확인하기 위해서는 먼저 축적되는 로그가 있고, 해당 로그를 기반으로 설정을 해주어야 하는데, 먼저 로그를 받아 저장하기 위해 Filebeat 설치를 해주도록 하자.

 

 

 

 

2. Filebeat 설치 및 ELK로 로그 전송


[ ELK 구축 ]

1. Elastic Repository 추가

sudo vi /etc/yum.repos.d/elastic.repo

# elastic.repo에 아래의 내용 추가
[elastic-7.x]
name=Elastic repository for 7.x packages
baseurl=https://artifacts.elastic.co/packages/7.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1
autorefresh=1
type=rpm-md

 

2. Filebeat 설치

sudo yum install -y filebeat

 

3. Filebeat 설정

sudo rm /etc/filebeat/filebeat.yml
sudo vi /etc/filebeat/filebeat.yml

# /etc/filebeat/filebeat.yml에 아래의 내용 추가
filebeat.inputs:
- type: log
  enabled: true

  paths:
    # 각자의 경로에 맞게 수정 ex) /home/mangkyu/logs/tomcat/mangkyu-elk/*.log
    - /home/로그경로...
    
  # custom fields가 필요한 경우 추가
  fields:
    env: "real"
    project: "openapi"

  # multiline 설정
  multiline.pattern: ^[0-9]{4}-[0-9]{2}-[0-9]{2}[[:space:]][0-9]{2}:[0-9]{2}:[0-9]{2}[[:space:]]\[
  multiline.negate: true
  multiline.match: after

setup.kibana:
  # 각자의 서버 주소:5601로 설정
  host: "서버주소:5601"

output.logstash:
  enabled: true
  # 각자의 서버 주소:5000로 설정
  hosts: ["서버주소:5000"]

 

 

위의 Filebeat 설정에서 몇가지 살펴볼 부분이 있다.

먼저 fields 부분인데, fields 하위에는 custom한 값들을 추가로 넘겨줄 수 있다. 위의 예시에서는 현재 로그를 전송하려는 서버의 환경 정보와 프로젝트 명을 추가하여 전달하도록 하였다. 그 결과 아래와 같이 fields.env와 fields.project 필드가 추가된 것을 확인할 수 있다.

 

그 다음에 살펴볼 부분은 multiline 부분이다.

위의 로그에서 v2, restUri... 로 시작하는 부분은 위의 2021-11-16 ... RestApiBO와 하나의 로그로 보이는데, 로그 출력 시에 \n으로 개행 처리가 되어 있어 별도의 로그로 전송된 것으로 보인다. 우리는 2021-11-16 10:59:07 [ 과 같은 패턴을 구분자로 하여 여러 라인의 메세지를 1개의 메세지로 인식하도록 처리해야 한다. 이에 대한 pattern을 분석해보니 다음과 같다.

 

숫자4개-숫자2개-숫자2개 숫자2개:숫자2개:숫자2개 [

 

그래서 이러한 패턴을 multiline.pattern으로 추가하고, multiline.negate는 true, multiline.match는 after로 주면 되며 이는 같은 패턴이 나올때까지 이전 로그에 붙인다는 것을 의미한다.

# 숫자4개-숫자2개-숫자2개
multiline.pattern: ^[0-9]{4}-[0-9]{2}-[0-9]{2}[[:space:]][0-9]{2}:[0-9]{2}:[0-9]{2}[[:space:]]\[
multiline.negate: true
multiline.match: after

 

위와 같이 multiline 패턴을 적용하면 로그가 다음과 같이 쌓이게 된다.

 

4. 연결 테스트

  • 설정 정보 테스트: sudo filebeat test config
  • 연결 테스트: sudo filebeat test output

 

5. Filebeat 시작 및 종료

  • 시작: sudo systemctl start filebeat
  • 종료: sudo systemctl stop filebeat
  • 재시작: sudo systemctl restart filebeat

없을 경우 sudo /etc/init.d/filebeat start로 처리하도록 하자.

 

 

그러면 이제 Filebeat에서 전송된 로그는 Logstash가 받아 가공하여 Elastic으로 넘기는 작업까지 끝났다. 마지막으로 Kibana에서 Elasitc에 저장된 로그를 확인하도록 설정해보도록 하자.

 

 

 

3. Kibana 설정 및 모니터링


[ Kibana 설정 ]

 

1. Index Patterns설정

 

먼저 홈 화면에서 왼쪽의 햄버거 버튼을 클릭하고 Stack Management로 이동한다.

 

그러면 새로운 화면이 보이는데 거기서 Index Patterns를 클릭하고, Create index pattern을 누른다.

(Elastic으로 전송된 로그가 있어야 Create index pattern 버튼이 보인다.)

 

그러면 우리가 Logstash Output 설정에서 작성한 elk로 시작하는 인덱스 패턴의 형태로 로그가 작성된 것이 보인다. 

다음과 같이 logstash*로 인덱스 패턴을 추가해주도록 하자.

 

 

그러면 이제 모니터링 화면(Discover)에서 로그를 확인할 수 있다.

 

 

[ 로그 모니터링 ]

1. Discover로 이동

 

2. 로그 확인

그러면 위와 같이 로그가 정상적으로 쌓이는 것이 보인다. 참고로 위에 로그 내용이 이상한 것은 데이터 보안을 위해 편집을 해서 그런 부분이므로 이해를 부탁드리겠습니다. 그 외에도 데이터를 검색하기 위한 시간 범위 설정이나 필터링 등을 할 수 있으므로 유용하게 이용하도록 하자.

 

 

 

하지만 이렇게 데이터를 계속 쌓게 되면 저장 공간이 가득 차게 되고 쿼리속도가 느려지는 등의 문제가 발생할 수 있다. ElasticSearch(엘라스틱 서치)는 이러한 문제를 해결하기 위해 인덱스의 라이프사이클을 설정하는 Index Lifecycle Management 기능을 제공하고 있는데, 다음 포스팅에서 자세히 알아보도록 하자.

 

 

 

 

 

관련 포스팅

  1. Linux 서버에 Docker와 Docker Compose 설치 및 Docker 명령어 - (1/3)
  2. Docker Compose로 ELK 모니터링 서버 구축 및 Filebeat로 로그 전송 - (2/3)
  3. 엘라스틱 서치의 인덱스 라이프사이클 정책(ElasticSearch Index Lifecycle Policy)  설정하기 - (3/3)

 

 

 

 

반응형
댓글
댓글쓰기 폼
  • 소프 글 참고해서 처음으로 ELK 구축 완료했네요 감사합니다!
    근데 테스트한 서버의 사양이 안좋은건지 가동중에도 CPU가 아주 가끔 튀네요;;
    ELK를 한서버에 구축하면 사양이 아주 좋은 서버 아니면 1대씩 분리해서 구축하는게 좋을까요?

    실무에서는 어떻게 쓰는지 궁금합니다..

    2022.04.30 14:51 신고
  • 망나니개발자 오 소프님 오랜만입니다! ELK를 구축하셨군요 축하드립니다ㅎㅎㅎ
    ELK가 처리해야 하는 양에 따라 다를 것 같은데요~ 요청이 많다면 Elastic과 Logstash는 여러 서버를 띄워야 할 것 같고, Kibana는 1대로 충분할 것 같습니다! 반면에 요청이 많지 않고 간단히 빠르게 구축해야 하는 경우라면 위처럼 DockerCompose로 구성하는 것이 좋을 것 같네요:)
    CPU가 튀었을 시점에 혹시 실제로 로그 요청이 많았는지 확인해보시는 것도 좋을 것 같습니다! 아니라면 Logstash의 CPU Usage가 튀는 이슈도 있는데, 해당 내용 찾아보시는 것도 좋을 것 같습니다!
    2022.05.01 02:47 신고
반응형
공지사항
Total
2,491,267
Today
304
Yesterday
5,743
TAG
more
«   2022/05   »
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        
글 보관함