elastic search 트러블 슈팅(로그 적재)

해당 게시글은 로그 적재용으로 es를 사용할때의 문제점과 해결방식을 정리했습니다.

 

로그의 경우 검색속도보다는 적재에 포커스를 맞춰서 시스템을 구축하게 되므로 그에 맞는 트러블 슈팅방식을 정리합니다.

1. es의 컴퓨팅 리소스가 부족할때

(1). 에러로그

es의 컴퓨팅 리소스가 부족할때 es가 뱉는 에러는 아래와 같습니다.

Error received from Elasticsearch cluster. 429 Too Many Requests /my-index/my-type/_bulk

Request to ES cluster timed out. 
Ensure that the cluster has sufficient capacity for the current workload.

{"type":"es_rejected_execution_exception",
"reason":"rejected execution of org.elasticsearch.common.util.concurrent.TimedRunnable@1e05c960 on 
EWMATrackingEsThreadPoolExecutor[name = R_DYVUy/write, queue capacity = 1000, 
task execution EWMA = 118.9ms, 
org.elasticsearch.common.util.concurrent.EWMATrackingEsThreadPoolExecutor@5ab715eb[Running, pool size =16, 
active threads = 16, queued tasks = 1140, completed tasks = 11728030]]"} 
Domain ARN: arn:aws:es:ap-northeast-2:xxxxxxxxx:domain/xxx

요청이 너무 많아 es가 wirte 트래픽을 견디지 못한다는 에러입니다.

(2). 해결방법1

특정시간에만 일시적으로 write가 튀는거라면 es로 write 요청을 보낸 클라이언트가 해당에러에 retry를 할수있도록 큐 등의 아키텍처를 구축합니다.

 

(3). 해결방법2

Error received from Elasticsearch cluster. 429 Too Many Requests /my-index/my-type/_bulk

해당 에러는 requqest 숫자 자체가 많은 경우입니다.

es로 보낼때 bulk api를 통해 더 많은 양을 쌓아서 보내도록 조치하여 request 숫자 자체를 줄여서 해결합니다.

(4). 해결방법3

retry로 커버하지 못한다면 es의 스케일링을 고려해봅니다.

추가비용이 발생하는 부분이므로 최후의 방법으로 사용하시면 됩니다.
es의 네트워크, cpu, jvm write queue, node 등의 메트릭을 확인한 후 스케일링이 정답이라는 확신이 생기면 그때 스케일링 합니다. (디스크 공간이 부족해도 순간적으로 cpu가 튈수있으니 주의합니다)

 

 

2. 저장공간이 부족할 때

kibana 좌측 사이드바에서 index 관리 정책을 설정할 수 있습니다.
여기서 오래된 인덱스를 삭제하도록 정책을 설정하면 부족한 storage 공간을 확보할 수 있습니다.

elastic search 클러스터는 전체 클러스터의 디스크가 넉넉한 상황이라도 하나의 데이터노드의 디스크가 부족하면 에러를 뱉을 수 있습니다.

샤드가 한번 배치됐다면 노드의 공간이 부족하다고 자동으로 재배치 해주지 않으므로 샤드의 크기를 30~50GiB로 일정하게 맞춰주는것도 중요합니다(data stream기능을 이용해도 됩니다)

 

엘라스틱 서치 샤드와 레플리카에 대한 게시글입니다.

[elastic search] 엘라스틱 서치 shard와 replica

 

3. es mapping error

(1). 에러로그 및 원인

es에 데이터를 넣다보면 mapper_parsing_exception 을 발견할 수 있습니다.
object(key value pair)가 매핑되있는곳에 string이 왔다던가 등의 에러입니다.

{
    "type":"mapper_parsing_exception",
    "reason":"failed to parse field [xx] of type [text] in document with id xx",
    "caused_by":{"type":"illegal_state_exception","reason":"Can't get text on a START_OBJECT at 1:378"}
}

(2). 해결방법

[ 포맷팅 변경 ]

애플리케이션에서 포맷팅을 변경해주거나 (log4j, logback 등의 설정)

로그전송 파이프라인에서 하나의 key에 object와 string이 혼용되지 않도록 직접 잡아줘서 해결할 수 있습니다.

 

[ es 매핑 방식 변경 ]

elastic search는 key value 의 json을 저장 후, 쉽게 검색하고 kibana를 통해 시각화할수 있는 솔루션입니다.

 

로그센터를 구축할때는 매일매일 index를 변경하는경우가 일반적이므로(my-index-2022-08-17등으로 인덱스가 바뀐다고 가정)
index template을 만들어 해결합니다
template을 생성하게 되면 template의 패턴과 일치하는 index가 생성될 때 적용되게 됩니다.

PUT _template/my-template
{
  “index_patterns”: “my-index-*“,
  “mappings”: {
     “some_type”: {
       “dynamic”: false,
      “properties” : {
        “@timestamp” : {
          “type” : “date”
        }
        // 필드 추가가 필요할시 추가 기입
      }
    }
  }
}

위의 예시는 모든 로그에 @timestamp필드가 있다는 가정입니다.(원하는 필드만 매핑)
인덱스 템플릿을 만들때 dynamic mapping을 false로 적용하게 되면 자동매핑이 되지 않아 모든필드에 어떤 데이터타입이 오든 저장이 가능합니다. 

 

mapping error는 피해갈 수 있으나 인덱스 템플릿에 매핑시켜주지 않은 데이터는 검색이 힘듭니다.

검색에 필요한 필드를 추가하게 된다면 검색을 정상적으로 이용할수 있게 됩니다.

(새로운 template이 적용됐다면 kibana index pattern을 refresh를 해준 후 정상적으로 검색할 수 있습니다.)