ELK stack 설치

ELK Stack은 Elasticsearch, Logstash, Kibana를 중심으로 로그를 수집, 저장, 검색, 시각화하는 구성입니다. 현재 Elastic Stack은 Beats, Elastic Agent, APM 등까지 포함해 더 넓게 운영되며, 설치할 때는 구성요소 버전 호환성과 보안 기본값을 먼저 확인해야 합니다.

기존 글은 CentOS 7과 Elastic 7.x 저장소를 기준으로 했지만, CentOS 7은 이미 운영 기준에서 주의가 필요한 레거시 OS입니다. 새 구축은 지원 중인 OS와 현재 Elastic 문서를 기준으로 진행합니다.

구성요소 역할

• Elasticsearch: 로그와 문서를 색인하고 검색합니다.
• Logstash: 입력, 필터, 출력 pipeline으로 로그를 변환합니다.
• Kibana: 검색, 대시보드, 관리 UI를 제공합니다.
• Beats/Elastic Agent: 서버와 애플리케이션에서 데이터를 수집해 전달합니다.

버전 호환

Elastic 공식 문서는 Stack 구성요소의 버전을 맞추라고 안내합니다. 예를 들어 Elasticsearch, Kibana, Logstash, Beats를 같은 major/minor 계열로 맞추는 것이 기본입니다. 업그레이드할 때도 지원되는 순서와 호환 matrix를 확인합니다.

설치 전 확인

uname -a
cat /etc/os-release
free -h
df -h
sysctl vm.max_map_count
ulimit -n

Elasticsearch는 메모리, 파일 descriptor, mmap count, 디스크 I/O 영향을 크게 받습니다. 작은 랩과 운영 클러스터의 요구사항은 다릅니다.

Elasticsearch 상태 확인

sudo systemctl status elasticsearch --no-pager
sudo journalctl -u elasticsearch -n 100 --no-pager
curl -k https://localhost:9200/
curl -k https://localhost:9200/_cluster/health?pretty

최근 Elastic Stack은 보안 기능이 기본 활성화되는 구성이 많습니다. 인증서, bootstrap password, enrollment token 등은 본문을 문서나 Git에 저장하지 않습니다.

Kibana 상태 확인

sudo systemctl status kibana --no-pager
sudo journalctl -u kibana -n 100 --no-pager
ss -lntp | grep 5601

Kibana를 0.0.0.0에 직접 열기 전에 reverse proxy, TLS, 인증, 접근 제어를 먼저 설계합니다.

Logstash pipeline 예시

input {
 file {
 path => "/var/log/messages"
 start_position => "beginning"
 }
}

filter {
 grok {
 match => { "message" => "%{SYSLOGTIMESTAMP:syslog_timestamp} %{SYSLOGHOST:host} %{GREEDYDATA:msg}" }
 }
}

output {
 elasticsearch {
 hosts => ["https://localhost:9200"]
 index => "linux-%{+YYYY.MM.dd}"
 }
}

Logstash 설정 검증

sudo /usr/share/logstash/bin/logstash --path.settings /etc/logstash -t
sudo systemctl restart logstash
sudo journalctl -u logstash -n 100 --no-pager

Filebeat 또는 Elastic Agent 수집

서버 로그 수집은 Logstash가 직접 파일을 읽는 방식보다 Filebeat나 Elastic Agent를 각 서버에 설치해 중앙으로 전달하는 구조가 운영에 더 적합한 경우가 많습니다.

sudo systemctl status filebeat --no-pager 2>/dev/null
sudo filebeat test config 2>/dev/null
sudo filebeat test output 2>/dev/null
sudo journalctl -u filebeat -n 100 --no-pager 2>/dev/null

수집 에이전트는 어떤 파일을 읽는지, multiline 로그를 어떻게 묶는지, 전송 실패 시 queue가 어떻게 동작하는지까지 확인해야 합니다.

Index와 보관 정책

curl -k https://localhost:9200/_cat/indices?v
curl -k https://localhost:9200/_cat/shards?v
curl -k https://localhost:9200/_ilm/policy?pretty

운영에서 가장 자주 발생하는 문제는 디스크 증가입니다. 일별 index만 만들고 삭제 정책이 없으면 금방 disk watermark에 걸릴 수 있습니다. ILM(Index Lifecycle Management)이나 별도 보관 정책으로 rollover, warm/cold, delete 기준을 정합니다.

보안 기본값

• Elasticsearch 9200 포트를 공인망에 직접 열지 않습니다.
• Kibana는 TLS와 인증 뒤에 둡니다.
• 수집 계정은 필요한 index 권한만 부여합니다.
• 로그에 password, token, session cookie가 들어오지 않게 애플리케이션에서 먼저 줄입니다.
• 운영 인증서와 enrollment token 실습은 문서/Slack/Git에 남기지 않습니다.

장애 점검

curl -k https://localhost:9200/_cluster/health?pretty
curl -k https://localhost:9200/_cat/nodes?v
curl -k https://localhost:9200/_cat/allocation?v
sudo journalctl -u elasticsearch -p warning -S -2h --no-pager
sudo journalctl -u kibana -p warning -S -2h --no-pager
sudo journalctl -u logstash -p warning -S -2h --no-pager

cluster health가 yellow이면 replica shard 미할당일 수 있고, red이면 primary shard 문제일 수 있습니다. 단일 노드 랩에서는 replica 설정 때문에 yellow가 나올 수 있지만, 운영 cluster에서는 shard allocation 이유를 확인해야 합니다.

백업과 복구

Elasticsearch 데이터 디렉터리를 파일 복사로 백업하는 방식은 안전하지 않습니다. 운영에서는 snapshot repository를 구성하고 snapshot/restore 절차를 테스트합니다. Kibana saved object, Logstash pipeline, agent policy도 함께 백업 범위에 넣습니다.

운영에서 중요한 것

• index lifecycle policy로 보관 기간과 rollover를 관리합니다.
• 로그 수집량을 산정하고 shard 수를 과도하게 만들지 않습니다.
• 민감정보가 로그로 들어오지 않게 애플리케이션과 pipeline에서 필터링합니다.
• 운영 Kibana는 반드시 인증과 TLS 뒤에 둡니다.
• cluster health, disk watermark, JVM heap, rejected thread pool 지표를 모니터링합니다.

공식 문서

• Elastic Stack
• Install Elasticsearch