Elasticsearch

[Elasticsearch] maximum shards open error

ssh9308 2023. 12. 27. 11:58
반응형

현재 회사에서 Elasticsearch를 운영하고 있다.

 

Elasticsearch는 매일 monitoring-es ~라는 인덱스를 자동으로 인덱싱 한다.

 

해당 인덱스는 X-Pack 모니터링 기능이 활성화되어 있을 때 자동으로 생성되며,

 

클러스터의 성능, 상태 및 메트릭에 대한 상세 정보를 포함한다.

 

보통 monitoring-es 인덱스는 아래와 같은 정보를 저장해 준다.

 

 

1) 클러스터 상태 정보

 

클러스터의 건강 상태, 노드 수, 인덱스 수, 샤드 수 등 클러스터 전반에 대한 상태 정보.

 


2) 노드 메트릭

 

각 노드의 CPU 사용량, 메모리 사용량, 디스크 I/O 통계, JVM 통계(가비지 컬렉션, 힙 메모리 사용량 등),

네트워크 사용량 등 노드별 성능지표.

 


3) 인덱스 메트릭

 

각 인덱스의 샤드 할당 상태, 문서 수, 저장 공간 사용량, 인덱싱 및 검색 작업에 대한 성능 지표.

 


4) 샤드 메트릭

 

각 샤드의 상태, 문서 수, 저장 공간 사용량 등 샤드별 상세 정보.

 

5) 시스템 메트릭

 

운영 시스템에 대한 정보, 시스템 부하, 프로세스가 실행 중인 시간 등입니다.

 


6) Elasticsearch 로그 및 오류

 

클러스터, 노드, 인덱스에 관한 로그 메시지와 오류 메시지.

 

 

 

현재 회사에서는 운영 중인 elasticsearch cluster에서. monitoring~ 인덱스를 수집하여

 

특정 metric에 문제가 생길 경우 (예를 들어 disk 사용률이 임계치 이상으로 올라갈 때)

 

Telegram Bot을 통하여 알람을 보내주고 있다.

 

 

그런데 오늘 아침 출근할 때 아래와 같은 에러가 계속 울리는 것이 아니겠는가?

 

처음에는 단순히 탐지오류이거나, 인덱스 생성시점에 체크를 한 것이라

 

인덱스가 없다고 알람이 온 줄 알았다.

 

 

하지만, 위의 에러는 계속 지속되었고, 원인을 파악해 보기로 했다.

 

Kibana Dev Tool로 아래와 같은 명령어를 쿼리 했다.

 

GET /.monitoring-es-7-2023.12.27/_search

 

하지만, 아래와 같은 에러메시지만 리턴될 뿐이었다.

{
  "error" : {
    "root_cause" : [
      {
        "type" : "index_not_found_exception",
        "reason" : "no such index [.monitoring-es-7-2023.12.27]",
        "resource.type" : "index_or_alias",
        "resource.id" : ".monitoring-es-7-2023.12.27",
        "index_uuid" : "_na_",
        "index" : ".monitoring-es-7-2023.12.287"
      }
    ],
    "type" : "index_not_found_exception",
    "reason" : "no such index [.monitoring-es-7-2023.12.27]",
    "resource.type" : "index_or_alias",
    "resource.id" : ".monitoring-es-7-2023.12.27",
    "index_uuid" : "_na_",
    "index" : ".monitoring-es-7-2023.12.27"
  },
  "status" : 404
}

 

 

운영하고 있는 Elasticsearch cluster는 utc 기준으로 인덱싱 되고 있으며,

 

한국시간 기준으로 오전 9시에 새로운 monitoring 인덱스가 인덱싱 되는 게 맞는데

 

monitoring 인덱스가 생성되지 않고 있던 것이다.

 

 

더 자세한 원인 파악을 위해서

 

해당 서버에 직접 접근하여 로그를 살펴보기로 했다.

 

 

원인은 maximum normal shard open 에러였다.

 

해당 에러는 데이터 노드에서 사용할 수 있는 샤드가 최대치에 도달해서

 

더 이상 샤드를 할당할 수 없고, 그로 인해 새로운 인덱스를 인덱싱 하지 못하여 발생하는 오류이다.

 

 

해당 문제가 발생한 elasticsearch cluster 구조는 아래와 같다.

 

현재 해당 클러스터는 master/ingest 역할을 하는 노드 3개와

 

데이터 노드 3개로 구성되어 있다.

 

로그파일에 써져 있는 오류중에 유심히 봐야 할 것은

 

"cluster currently has [3000]/[3000]" 해당 부분이다.

 

Elasticsearch에서 샤드는 데이터를 저장하고 검색 쿼리를 처리하는 역할을 하는 데이터 노드에만 할당된다.

 

각 노드당 최대의 샤드개수를 뜻하는 시스템 필드인 "cluster.max_shards_per_node"는

 

기본적으로 1000의 값을 갖는다.

 

즉, 3개의 데이터 노드가 있으므로, 할당가능한 샤드의 최대치는 3000인데,

 

새로운 인덱스를 구성하려고 샤딩을 해주려다 보니 더 이상 할당 가능한 샤드가 없어서 문제가 생긴 것이다.

 

이 문제를 해결하기 위해서 kibana dev로 접근하여 아래와 같은 명령어를 쿼리 했다.

 

PUT /_cluster/settings
{
  "persistent": {
    "cluster.max_shards_per_node": 4000
  }
}

 

위의 쿼리는 각 노드의 허용가능한 최대샤드를 1000 -> 4000으로 늘려주는 것이다.

 

즉 데이터 노드가 3개 이므로 총 할당가능한 샤드는 12,000 개가 된다.

 

해당 옵션이 작 적용되었는지 확인하려면 아래와 같은 명령어를 쿼리 할 수 있다.

GET /_cluster/settings

 

 

 

그럼 샤드가 다시 재 할당되어 인덱스가 생성되고 있는지 확인해 보자.

 

kibana에서도 확인 가능하지만 서버에 직접 접근해서 총샤드의 개수를 뽑아보겠다.

 

curl -s -XGET "http://{아이디}:{비밀번호}@{아이피주소}:{포트번호}/_cat/shards" | wc -l

 

 

정상적으로 4개의 샤드가 더 할당된 모습을 볼 수 있다.

 

반응형