애플리케이션 지표

다음 지표를 모니터링하여 상태를 OpenSearch 분석하십시오.

클러스터 상태
파편 수
GC 모니터링

참고: 본 절에서 언급된 임계값, 구성 및 심각도 수준은 최적의 성능을 위해 권장하는 IBMOpenSearch 지침입니다. 운영 요구 사항에 따라 이러한 임계값을 수정하거나 조치를 정의할 수 있습니다.

스레드 덤프 및 힙 덤프 생성 방법에 대한 자세한 내용은 문제 해결: 모니터링을 참조하십시오 OpenSearch.

지표가 초과된 임계값을 반환하는 경우, 언급된 심각도를 고려하고 문제를 식별 및 디버깅하기 위해 권장되는 가능한 조치를 수행하십시오. 추가 지원이 필요하시면 IBM 문의해 주십시오.

OpenSearch 클러스터 상태

클러스터의 최적 건강 상태와 성능을 보장하기 위해 OpenSearch, 정기적으로 클러스터 OpenSearch 상태를 모니터링하는 것이 권장됩니다.

표 1. OpenSearch 클러스터 상태 세부 정보
명령	설명
`curl -X GET http://localhost:9240/_cluster/health?pretty`	이 명령어는 클러스터 상태를 OpenSearch 확인합니다.
`$.status`	이 JSON 경로 표현식은 응답에서 클러스터 상태 정보를 가져옵니다.
`$.number_of_nodes`	이 JSON 경로 표현식은 응답에서 클러스터의 노드 수를 가져옵니다.

헬스 체크 요청의 응답 JSON에는 응답에 상태 필드가 표시됩니다. 상태는, yellow 또는 green 값을 가질 red수 있습니다. 클러스터 상태는 다음 색상 코드에 따라 표시됩니다:

표 2. 클러스터 상태
상태	설명
`green`	클러스터가 정상 상태임을 나타냅니다. 클러스터가 대량의 데이터를 OpenSearch 처리할 때는 클러스터 상태를 표시하는 데 시간이 다소 소요됩니다.
`yellow`	클러스터가 정상 상태가 아님을 나타냅니다. 원인을 파악하고 시정하십시오. 이 시간 동안, 사용 가능한 인덱스에 OpenSearch 대한 요청을 처리합니다. 할당되지 않은 샤드가 있는 경우, 해당 샤드를 식별하고 할당되지 않은 원인을 확인한 후 문제를 해결하십시오. 다음 명령어를 실행하여 할당되지 않은 샤드 목록을 가져옵니다. `curl -X GET “http://localhost:9240/_cat/ shards?h=index,shard,primaryOrReplica,state,docs,store,ip,node,segments.count,unassigned.at,unassigned.details,unassigned.for,unassigned.reason,help,s=index&v”` 특정 샤드의 할당되지 않은 이유를 확인하려면 다음 명령을 실행하십시오. `curl -X GET "http://localhost:9240/_cluster/allocation/ explain" -d ‘{ "index" :"index name","primary" : "true\|false","shard": "shardnumber"}’reason,help,s=index&v”`
`red`	노드가 다운되었거나 연결할 수 OpenSearch 없거나 OpenSearch 마스터가 발견되지 않음을 나타냅니다. 노드 수가 구성된 OpenSearch 노드 수와 일치하지 않을 경우, 클러스터에 가입하지 않은 노드를 식별하고 해당 노드가 클러스터에 가입하지 못한 근본 원인을 파악하십시오. 근본 원인에 따라 시스템이 OpenSearch 다운되었는지 확인하십시오. 연결이 OpenSearch 끊어지고 접근할 수 없는 경우, 연결 상태를 확인하십시오.

예시 HTTP 응답은 다음과 같습니다:


{
"cluster_name": "apidatastore_cluster",
"status": "green",
"timed_out": false,
"number_of_nodes": 3,
"number_of_data_nodes": 3,
"active_primary_shards": 101,
"active_shards": 202,
"relocating_shards": 0,
"initializing_shards": 0,
"unassigned_shards": 0,
"delayed_unassigned_shards": 0,
"number_of_pending_tasks": 0,
"number_of_in_flight_fetch": 0,
"task_max_waiting_in_queue_millis": 0,
"active_shards_percent_as_number": 100.0
}

전체 클러스터 상태는 모든 OpenSearch 노드가 예상대로 작동하므로 green 정상입니다.

파편 수

노드에 샤드를 적절히 할당하기 위해 샤드 수를 정기적으로 모니터링하는 것이 좋습니다.

표 3. 샤드 세부사항
명령	설명
`curl -X GET "http://localhost:9240/_cluster/health?pretty"`	이 명령어는. OpenSearch 에 있는 샤드 수를 가져옵니다. 응답에서 받은 활성 샤드 총 수가 `heap space * nodes * 20` 카운트를 초과하면, 노드의 OpenSearch 힙 공간을 늘리거나 새 OpenSearch 노드를 추가하십시오. OpenSearch GB당 최대 20개의 활성 샤드를 건강한 것으로 간주합니다. 활성 샤드의 총 개수를 유지하려면 다음 작업 중 하나를 수행하십시오: 노드 theOpenSearch 확장. 노드를 OpenSearch 확장할 수 없는 경우, 최후의 수단으로 힙 크기를 늘리십시오. 힙 공간은 시스템 메모리(RAM)의 절반을 초과해서는 안 됩니다. 예를 들어, 시스템 메모리가 16GB인 경우. OpenSearch NET에 할당할 수 있는 최대 용량은 8GB입니다. 힙 공간을 늘리려면, 에 위치한 jvm.options 파일에서 Xmx2g 및 Xms2g`InstallDir`\config 매개변수를 수정하십시오.

가비지 컬렉션(GC) 모니터링

GC 메트릭은 GC 실행 시간을 초 단위로 제공합니다. 5분마다 GC 실행 시간을 확인해야 합니다. 평균 GC 실행 시간은 1초를 초과해서는 안 됩니다.

표 4. GC 메트릭 세부 정보
메트릭	설명
오픈서치_JVM_가비지_컬렉션_초_합계 오픈서치_JVM_가비지_콜렉션_초_카운트	두 메트릭의 비율은 GC 실행 시간을 나타냅니다. 상수가 1 초를 초과할 경우, 가비지 컬렉션(GC) 실행 시간이 길어짐을 의미하며 이는 요청 처리를 OpenSearch 지연시킵니다. 로그를 수집하고 API 인덱스와 트랜잭션 인덱스의 매핑을 확보해야 합니다.