DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브 DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브

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

Elasticsearch 로그 분석을 사용하여 클러스터 상태, 디스크, 메모리, 샤드 복구 및 느린 쿼리 문제를 더 빠르게 진단하세요.

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

Elasticsearch 로그 분석은 일반적으로 적색 클러스터, 실패한 인덱싱 요청 또는 느린 검색 불만을 설명하는 가장 빠른 방법입니다. 클러스터에 여러 노드가 있는 경우 로그는 어떤 노드에서 첫 번째 실패가 발생했는지, 어떤 구성 요소가 반응했는지, 문제가 디스크, 메모리, 검색, 보안 또는 샤드 복구인지 알려줍니다.

이 가이드는 노이즈를 쫓지 않고 Elasticsearch 로그를 읽는 방법을 보여줍니다. 로그가 일반적으로 있는 위치, 중요한 필드, 일반적인 실패 메시지의 의미, 그리고 메인 서버 로그에서 느린 로그 또는 할당 API로 전환해야 하는 시점을 배우게 됩니다.

Elasticsearch 로그 구조 이해

Elasticsearch는 Log4j 2를 로깅에 사용합니다. 패키지 설치는 일반적으로 /var/log/elasticsearch/ 아래에 로그 파일을 씁니다. 컨테이너화된 배포는 종종 표준 출력으로 로그를 보내며, 컨테이너 런타임 또는 로깅 에이전트가 수집합니다. 버전과 log4j2.properties에 따라 일반 텍스트 로그, JSON 로그 또는 둘 다를 볼 수 있습니다.

설치 유형 일반적인 로그 경로
RPM/DEB Linux 패키지 /var/log/elasticsearch/
Docker 컨테이너 표준 출력
ZIP 또는 tarball $ES_HOME/logs/

일반적인 파일에는 메인 서버 로그, 지원 중단 로그, 느린 로그, 그리고 보안 감사가 활성화된 경우 감사 로그가 포함됩니다.

JSON 로그 항목에는 일반적으로 다음과 같은 필드가 포함됩니다.

  • @timestamp: 이벤트가 발생한 시간.
  • level: 심각도. 예: INFO, WARN, 또는 ERROR.
  • component: 메시지를 기록한 Elasticsearch 클래스 또는 하위 시스템.
  • 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]"
}

로그 레벨별 메시지 우선순위 지정

먼저 WARN 및 ERROR로 필터링한 다음 동일한 타임스탬프 주변으로 검색 범위를 넓히세요. 첫 번째 ERROR 이전의 라인이 최종 스택 추적보다 원인을 더 잘 설명하는 경우가 많습니다.

레벨 일반적인 의미 첫 번째 조치
ERROR 요청, 샤드, 노드 또는 하위 시스템이 실패했습니다. 즉시 조사하십시오.
WARN Elasticsearch가 위험한 상태를 감지했습니다. 중단이 발생하기 전에 확인하십시오.
INFO 정상적인 수명 주기 활동. 경고 및 오류에 대한 컨텍스트로 사용하십시오.
DEBUG / TRACE 심층 진단 세부 정보. 필요할 때만 잠시 활성화하십시오.

프로덕션 노드를 DEBUG 또는 TRACE로 두지 마십시오. 자세한 로깅은 디스크를 빠르게 소모하고 피할 수 있는 오버헤드를 추가할 수 있습니다.

일반적인 로그 패턴 문제 해결

Elasticsearch 로그는 하나의 깔끔한 문장으로 "근본 원인은 X입니다"라고 말하는 경우가 거의 없습니다. 패턴을 찾으십시오: 첫 번째 경고, 구성 요소 이름, 영향을 받은 인덱스 또는 샤드, 그리고 뒤따르는 반복 메시지.

부트스트랩 검사 실패

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]

호스트 설정을 수정하고, 노드를 다시 시작하고, 시작 로그가 노드가 클러스터에 조인하는 지점에 도달하는지 확인하십시오.

네트워크 바인딩 및 검색 실패

노드가 시작되었지만 클러스터에 조인하지 못하는 경우 BindException, master not discovered, discovery 및 cluster.initial_master_nodes를 검색하십시오. BindException은 일반적으로 주소 또는 포트 충돌을 나타냅니다. 검색 메시지는 종종 잘못된 시드 호스트, 차단된 전송 포트 9300, 일치하지 않는 클러스터 이름 또는 노드가 서로를 신뢰하지 못하게 하는 보안 설정을 가리킵니다.

서킷 브레이커 예외

서킷 브레이커는 너무 많은 메모리를 사용할 요청을 중지합니다. 실패한 요청은 오류를 반환하지만 노드는 계속 작동해야 합니다.

CircuitBreakingException 또는 Data too large를 검색하십시오:

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

일반적인 원인으로는 대규모 집계, 너무 많은 필드를 반환하는 요청, 대량 벌크 인덱싱 또는 텍스트 필드에 로드된 fielddata가 있습니다. 요청 패턴을 식별한 다음 요청 크기를 줄이거나, 매핑을 수정하거나, 용량을 추가하십시오.

가비지 컬렉션 경고

기본 Elasticsearch 로그는 긴 JVM 가비지 컬렉션 일시 중지를 보고할 수 있습니다. gc, JvmGcMonitorService 및 overhead를 검색하십시오. 부하 급증 중 몇 가지 경고는 정상일 수 있습니다. 반복되는 경고와 검색 지연 시간 증가가 함께 나타나면 일반적으로 힙에 압력이 가해지고 있음을 의미합니다.

샤드 복구 및 손상

샤드 할당에 실패하거나 노드가 잘못된 로컬 샤드 복사본을 감지하면 Elasticsearch는 인덱스와 샤드 번호를 기록합니다.

shard failed, failed shard, failed to recover 또는 영향을 받은 인덱스 이름을 검색하십시오:

[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

메시지가 손상을 언급하는 경우 파일을 수동으로 삭제하지 마십시오. 로그를 보존하고, 유효한 복제본이 있는지 확인하고, 데이터 경로를 직접 편집하는 대신 Elasticsearch 복구 도구 및 API를 사용하십시오.

디스크 워터마크

Elasticsearch는 노드가 디스크 워터마크를 초과할 때 샤드 할당 동작을 변경합니다. DiskThresholdMonitor, low disk watermark, high disk watermark 또는 flood-stage disk watermark를 검색하십시오. 기본값은 버전 및 구성에 따라 다를 수 있으므로 조치를 취하기 전에 클러스터 설정을 확인하십시오:

GET /_cluster/settings?include_defaults=true&filter_path=**.disk.watermark*

플러드 스테이지 이벤트 후 인덱스가 읽기 전용이 되면 먼저 디스크 공간을 확보하십시오. 그런 다음 노드가 워터마크 아래로 안전하게 내려간 후에만 블록을 제거하십시오:

PUT /my-index/_settings
{
  "index.blocks.read_only_allow_delete": null
}

성능 문제에 느린 로그 사용

느린 검색 또는 인덱싱 작업의 경우 메인 서버 로그는 종종 너무 광범위합니다. 느린 로그는 구성된 임계값을 초과하는 작업을 추적합니다. 인덱스 설정 API를 사용하여 인덱스별로 구성하십시오.

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"
}

느린 로그는 구성된 경우 인덱스, 샤드, 경과 시간 및 요청 소스를 보여줍니다. 이를 사용하여 반복되는 고비용 쿼리, 광범위한 날짜 범위, 와일드카드가 많은 검색 및 효율적인 집계를 위해 매핑되지 않은 필드에 대한 집계를 찾으십시오.

실용적인 검토 워크플로

사용자가 볼 수 있는 증상부터 시작하여 거꾸로 작업하십시오:

  1. 클러스터 상태 및 영향을 받은 인덱스를 확인하십시오.
  2. 인시던트 시간 전후의 WARN 및 ERROR 로그를 검색하십시오.
  3. node.name 및 cluster.uuid를 사용하여 노드 간 로그를 비교하십시오.
  4. 최종 예외뿐만 아니라 첫 번째 반복 경고를 따르십시오.
  5. 다음으로 대상 API를 사용하십시오: 할당되지 않은 샤드에 대한 할당 설명, 느린 요청에 대한 느린 로그, 리소스 압력에 대한 노드 통계.

예를 들어, Kibana가 빨간색 인덱스를 표시하면 먼저 할당되지 않은 샤드를 찾은 다음 해당 인덱스 및 샤드 번호에 대한 로그를 검색하십시오. 로그가 디스크 워터마크를 언급하면 다시 라우팅하기 전에 디스크 압력을 해결하십시오. 노드 누락을 언급하면 위험한 할당 명령을 고려하기 전에 해당 노드를 복구하거나 스냅샷에서 복원하십시오.

결론

모든 Elasticsearch 인시던트는 가장 큰 최종 스택 추적이 아닌 첫 번째 관련 경고 또는 오류를 찾는 것으로 시작하십시오. 노드, 검색, 디스크, 메모리 및 샤드 실패에는 메인 로그를 사용하십시오. 클러스터는 정상이지만 특정 검색 또는 인덱싱 워크로드가 느린 경우 느린 로그를 사용하십시오.