효과적인 문제 해결을 위한 일반적인 Elasticsearch 로그 분석

Elasticsearch는 강력한 분산 검색 및 분석 엔진이지만, 그 복잡성으로 인해 문제가 발생했을 때 근본 원인을 진단하기 어려울 수 있습니다. 효과적인 문제 해결을 위한 가장 중요한 도구는 Elasticsearch 로그 파일입니다. 이 로그는 시스템의 운영 일지 역할을 하며, 성공적인 시작 시퀀스 및 정기적인 클러스터 유지 관리부터 메모리 회로 차단기 트립 또는 샤드 할당 실패와 같은 중요한 오류까지 모든 것을 기록합니다.

이러한 로그를 읽고 해석하는 기술을 숙달하는 것은 건강하고 성능이 우수한 클러스터를 유지하는 데 필수적입니다. 이 가이드는 Elasticsearch 로그 구조를 이해하고, 중요한 메시지를 식별하며, 로그 분석을 사용하여 클러스터 상태 문제, 리소스 제약 및 성능 병목 현상을 포함한 일반적인 운영 문제를 신속하게 찾아내고 해결하는 포괄적인 접근 방식을 제공합니다.

1. Elasticsearch 로그 구조 이해하기

Elasticsearch는 로깅을 위해 Apache Log4j 2 프레임워크를 사용합니다. 기본적으로 로그는 파일에 기록되며, 기계 판독을 용이하게 하기 위해 JSON 형식으로 저장되는 경우가 많지만, 구성에 따라 일반 텍스트도 흔하게 사용됩니다.

기본 로그 위치

주요 로그 파일은 설치 방식(예: RPM/DEB 패키지, Docker 또는 ZIP 파일)에 따라 일반적으로 다음 위치에서 찾을 수 있습니다.

설치 유형	일반적인 로그 경로
RPM/DEB (Linux)	`/var/log/elasticsearch/`
Docker	컨테이너 표준 출력 (stdout/stderr)
ZIP/Tarball	`$ES_HOME/logs/`

로그 항목의 구성 요소

각 로그 항목은 특히 JSON 형식에서 컨텍스트에 중요한 몇 가지 핵심 필드를 포함합니다:

@timestamp: 이벤트 발생 시각.
level: 이벤트의 심각도 (예: INFO, WARN, ERROR).
component: 메시지를 생성한 특정 Elasticsearch 클래스 또는 서비스 (예: o.e.c.c.ClusterService, o.e.n.Node). 이는 책임 있는 서브시스템을 좁히는 데 도움이 됩니다.
cluster.uuid: 로그가 속한 클러스터를 식별합니다.
node.name: 로그를 생성한 노드를 식별합니다.
message: 이벤트에 대한 설명.

{
  "@timestamp": "2024-01-15T10:30:00.123Z",
  "level": "WARN",
  "component": "o.e.c.r.a.DiskThresholdMonitor",
  "cluster.uuid": "abcde12345",
  "node.name": "es-node-01",
  "message": "high disk watermark [90%] exceeded on [es-node-01]"
}

2. 로그 레벨을 이용한 문제 해결 우선순위 지정

level 필드를 해석하는 것은 문제의 우선순위를 정하는 가장 빠른 방법입니다. 일반적으로 WARN 및 ERROR 메시지에 먼저 집중하도록 로그를 필터링해야 합니다.

레벨	설명	조치 우선순위
ERROR	서비스 중단 또는 데이터 손실로 이어지는 치명적인 오류 (예: 노드 종료, 주요 샤드 실패).	즉시 조치
WARN	모니터링이 필요한 잠재적 문제 또는 상태 (예: 사용 중단된 설정, 낮은 디스크 공간, 임계치에 근접한 회로 차단기).	높음
INFO	일반적인 운영 메시지 (예: 노드 시작, 인덱스 생성, 샤드 할당 완료).	낮음/모니터링
DEBUG/TRACE	심층 진단 또는 개발 중에만 사용되는 매우 상세한 로깅.	해당 없음 (적극적인 디버깅 중이 아닌 경우)

모범 사례: DEBUG 또는 TRACE로 로깅을 설정한 프로덕션 클러스터를 실행하지 마십시오. 이는 디스크 공간을 빠르게 소모하고 성능 오버헤드를 유발할 수 있습니다.

3. 로그를 통한 일반적인 시나리오 문제 해결

Elasticsearch 로그는 다양한 유형의 오류에 대한 직접적인 지표를 제공합니다. 다음은 여러 시나리오에서 주의해야 할 중요한 로그 패턴입니다.

3.1. 클러스터 시작 및 상태 문제

노드가 클러스터에 참여하지 못하거나 클러스터가 빨간색/노란색 상태로 유지되는 경우, 시작 시퀀스 중에 생성된 로그를 확인하십시오.

A. 부트스트랩 검사 실패

Elasticsearch는 시작 시 필수 부트스트랩 검사(예: 충분한 메모리, 파일 디스크립터 및 가상 메모리 확인)를 수행합니다. 이러한 검사가 실패하면 노드는 즉시 종료됩니다.

로그 패턴: bootstrap checks failed 메시지를 찾으십시오.

[2024-01-15T10:00:00,123][ERROR][o.e.b.BootstrapCheck$Bootstrap] [es-node-01] bootstrap checks failed
[2024-01-15T10:00:00,124][ERROR][o.e.b.BootstrapCheck$Bootstrap] [es-node-01] max file descriptors [4096] for elasticsearch process is too low, increase to at least [65536]

B. 네트워크 바인딩 및 디스커버리 실패

노드가 필요한 포트에 바인딩할 수 없거나 다른 클러스터 구성원을 찾을 수 없는 문제.

로그 패턴: BindException 또는 Discovery failure를 찾으십시오.

3.2. 리소스 관리 (메모리 및 JVM)

메모리 관련 문제는 종종 간헐적인 성능 저하 또는 노드 불안정으로 나타납니다. 로그는 JVM 상태를 추적하는 데 중요합니다.

A. 회로 차단기 예외

회로 차단기는 구성된 메모리 제한을 초과하는 작업을 중지하여 리소스 소진을 방지합니다. 트립되면 작업은 빠르게 실패하지만, 노드는 안정적으로 유지됩니다.

로그 패턴: CircuitBreakerException 또는 Data too large를 검색하십시오.

[2024-01-15T11:45:20,500][WARN][o.e.c.c.CircuitBreakerService] [es-node-02] \nCircuitBreakingException: [parent] Data too large, data for [<transport_request>] would be [123456789b], which is larger than the limit of [100.0/500mb]

B. JVM 가비지 컬렉션 (GC) 문제

자세한 GC 로그는 종종 별도로 존재하지만, 주 Elasticsearch 로그는 때때로 높은 GC 활동 또는 긴 GC 일시 중지(stop-the-world 이벤트)를 보고합니다.

로그 패턴: GC 참조, 특히 긴 일시 중지에 대한 WARN 또는 ERROR 메시지가 나타나는 경우 이를 찾으십시오.

3.3. 인덱싱 및 샤딩 실패

인덱싱 실패 또는 손상된 데이터는 종종 샤드 실패 이벤트를 트리거합니다.

A. 샤드 할당 및 실패

샤드가 할당에 실패하거나 노드가 로컬 샤드 복사본에서 손상 문제를 감지하면 로그에 기록됩니다.

로그 패턴: shard failed 또는 failed to recovery를 검색하십시오.

[2024-01-15T12:05:10,999][ERROR][o.e.i.e.Engine] [es-node-03] [my_index][2] fatal error in engine loop
java.io.IOException: Corrupt index files, checksum mismatch

B. 디스크 워터마크

Elasticsearch는 디스크 공간을 모니터링하고 특정 워터마크에 도달하면 쓰기를 방지하여 인덱싱 실패를 유발할 수 있습니다.

로그 패턴: 85% (low) 또는 90% (high) 사용량을 나타내는 DiskThresholdMonitor 경고를 찾으십시오.

4. 슬로우 로그를 이용한 성능 튜닝

성능 분석, 특히 느린 쿼리 또는 인덱싱 작업의 경우 주 클러스터 로그만으로는 불충분한 경우가 많습니다. Elasticsearch는 특수 슬로우 로그를 활용합니다.

슬로우 로그는 사전 정의된 시간 임계값을 초과하는 작업을 추적합니다. 이는 elasticsearch.yml에서 정적으로 또는 Indices Settings API를 통해 동적으로 명시적으로 구성해야 합니다.

동적 슬로우 로그 임계값 구성

인덱싱 및 검색 단계에 대해 다른 임계값을 설정할 수 있습니다. 다음 예는 특정 인덱스의 검색 쿼리에 대해 1초의 WARN 임계값을 설정합니다.

PUT /my_index/_settings
{
  "index.search.slowlog.threshold.query.warn": "1s",
  "index.search.slowlog.threshold.query.info": "500ms",
  "index.indexing.slowlog.threshold.index.warn": "1s"
}

슬로우 로그 항목 해석

슬로우 로그는 특정 인덱스/샤드, 소요 시간 및 쿼리 내용 자체를 포함하여 쿼리 실행에 대한 자세한 정보를 제공합니다. 이를 통해 사용자는 비효율적인 쿼리 또는 복잡한 집계를 정확히 찾아낼 수 있습니다.

주요 확인 지표:

took: 작업에 소요된 총 시간.
source: 쿼리 또는 인덱스 작업의 전체 텍스트.
id: 검색 컨텍스트 ID.

5. 로그 분석 모범 사례

효과적인 문제 해결은 단순히 어디를 봐야 할지 아는 것 이상으로, 체계적인 접근 방식을 필요로 합니다.

A. 로그 중앙 집중화

분산 환경에서는 수십 개의 노드에서 로그를 수동으로 살펴보는 것은 비실용적입니다. Logstash, Filebeat 또는 전문 로깅 서비스와 같은 중앙 집중식 로깅 도구를 사용하여 로그를 단일 Elasticsearch 인덱스(종종 '로깅 클러스터'라고 함)로 집계하십시오. 이를 통해 모든 노드에서 동시에 이벤트를 검색, 필터링 및 상관 관계를 파악할 수 있습니다.

B. 노드 간 이벤트 상관 관계 분석

@timestamp 및 cluster.uuid 필드를 사용하여 관련 이벤트를 찾으십시오. node-A에서 샤드 실패가 발생하면 해당 노드에 ERROR로 기록될 수 있지만, node-B에서 실행 중인 클러스터 관리자는 샤드 재할당 시도에 대해 INFO 또는 WARN을 기록할 것입니다.

C. 반복되는 패턴 주시

동일한 경고 또는 오류 메시지가 빠르게 반복되는 경우('로그 폭풍'), 이는 사용 불가능한 포트에 반복적으로 바인딩하려는 프로세스 또는 지속적인 과부하로 인한 연속적인 회로 차단기 트립과 같이 지속적이고 리소스 집약적인 실패 루프를 나타내는 경우가 많습니다. 이러한 패턴은 즉각적인 조사를 요구합니다.

D. WARN 메시지를 무시하지 마십시오

경고는 종종 미래의 치명적인 오류에 대한 초기 지표 역할을 합니다. 예를 들어, 사용 중단된 설정 또는 낮은 메모리 사용량에 대한 반복적인 WARN 메시지는 ERROR 수준의 중단으로 확대되기 전에 사전에 해결해야 합니다.

결론

Elasticsearch 로그는 클러스터 불안정 또는 성능 저하의 근본 원인을 진단하고 증상적인 수정 이상으로 나아가는 데 필요한 필수적인 컨텍스트를 제공하는 귀중한 리소스입니다. 표준 로그 구조를 이해하고, 심각도에 따라 메시지의 우선순위를 지정하며, 성능 튜닝을 위해 슬로우 로그를 특별히 활용함으로써 관리자는 다운타임을 크게 줄이고 강력한 클러스터 상태를 유지할 수 있습니다.