실습 환경
- OS : Cent OS 7
- ELK Stack 버전 : 8.11
- JDK : 17.0.2
시스템 구조
0. 로그 파일 생성
여러개의 WAS가 동작 중인 상황이고 각 WAS 별로 별개의 로그 파일이 생성되어 파일 시스템에 저장되고 있는 상황을 가정합니다.
1. Filebeats
Filebeats를 활용하여 각각의 로그 파일에 접근하여 데이터 수집을 진행합니다.
multiline 설정을 통해 여러 줄의 로그 내용을 하나의 단위로 수집하도록 설정을 진행합니다.
주석처리된 exclude, include 속성을 활용하여 제외 키워드, 포함 키워드 또한 설정이 가능합니다.
2. Filebeats
Filebeats로부터 데이터를 받아 Elasticsearch 적재를 위한 데이터 가공, Elasticsearch 전달을 담당합니다.
input 영역에서는 beats를 통해 데이터 수신 설정
filter 영역에서는 데이터 가공 설정을 진행해야 하지만 현재는 별도 가공 없이 전달합니다.
output 영역에서는 전달해야할 elasticsearch 정보 및 index 정보를 설정합니다.
3. Elasticsearch
Logstash로부터 데이터를 받아 적재하고 인덱싱 처리를 진행합니다.
이렇게 전달받은 데이터는 /var/lib/elasticsearch 폴더 내에 인덱싱이 되어 저장됩니다.
4. Kibana
데이터 적재 현황을 파악할 수 있는 Kibana Discover 페이지 입니다.
데이터 적재를 위해 WAS에 접속하여 강제로 로그를 생성한 후에 다시 Discover 페이지에 접속합니다.
설정한 기간 내에 몇 건의 데이터가 조회되었는지 카운트와 간단한 차트를 제공하며
아래 테이블에서 Field별로 확인 또한 가능합니다.
5. Alert (MS Teams)
Alert 목표는 각 운영 상황마다 다르겠지만
이번 실습에서는 간단하게 5분 이내에 5회 이상 'ERROR'라는 키워드가 포함된 로그 데이터가 적재되면 지정한 Webhook(MS Teams)을 통해 알림하는 것을 목표로 합니다.
Connector 설정을 통해 알림을 보낼 대상을 설정하며
2번째 사진의 Webhook URL에 MS Teams에서 제공받은 Webhook URL을 설정합니다.
Elastic Search는 루씬기반의 검색엔진이므로 조회를 위해서는 KQL 또는 Lucene 으로 쿼리를 작성해야 합니다.
단순 쿼리로 message 필드의 값 중 'ERROR'라는 키워드가 5분동안 5회 이상 노출되었을 때를 규칙으로 설정합니다.
현재는 message (로그 메세지) 속성만 사용해서 쿼리를 작성했지만
다른 속성들도 AND/OR로 작성이 가능합니다.
규칙 작성 후에 위에서 설정한 Connector를 연결합니다.
WAS에서 강제로 익셉션을 발생시킨 후 Teams를 보면 KIBANA에서 전달한 Alert가 수신됩니다.
간단한 오류 메세지가 담겨있으며 위에서 알 수 있듯 해당 메세지 또한 활용 가능한 변수들을 조합하여 커스터마이징이 가능합니다.
Link의 값으로 접속하면 해당 내용의 Discover 페이지로 이동합니다.
TODO
이로써 간단한 로그 분석 및 알림 전송 시스템은 실습이 끝났습니다.
나아가서 아래 항목 또한 고려할 필요가 있습니다.
Elastic Search 서버 분리
Elasticsearch가 비교적 많은 메모리와 저장공간을 차지하며 별도로 Log Rotate를 하지 않는 이상 지속적으로 용량을 차지하기 때문에 적합한 리소스를 갖는 별도의 서버 구축이 필요합니다.
저장한 데이터는 정기적으로 다른 저장소에 전달하는 기능 또한 고려할 수 있습니다.
모니터링 대상 및 규칙 세분화
실제 운영 환경에 맞는 모니터링 대상 및 알림을 보내는 규칙의 구체화가 필요합니다.
Kibana 커스터마이징
현재는 정말 필요한 기능만 사용했지만 Kibana 는 다양한 기능을 갖고있는 강력한 도구이기 때문에 운영 상황에 맞는 Visualise/Dashboard활용, 알림, 외부 시스템 연동에 대한 고민이 필요합니다.
