: 자원 상황 파악, 요청 처리 속도, 량 등의 지표들을 수집하고 모니터링하는 것은 중요한 업무중 하나
: 3장에서 살펴본 프로메테우스나 X-Pack을 통해서 쉽고 편하게 모니터링할 수 있지만 이런 지표들을 어떻게 수집하는지
: 각각의 지표가 의미하는 것은 무엇인지 이해하는 것이 매우 중요
•
클러스터의 상태를 확인하는 방법
•
클러스터를 구성하는 노드들의 상태와 정보를 확인하는 방법
•
인덱스와 샤드의 상태와 정보를 확인하는 방법
•
성능 지표를 확인하는 방법
•
성능과 관련된 문제를 해결하는 방법
7.1 클러스터의 상태 확인하기
: ElasticSearch는 cat API를 통해서 클러스터의 상태, 노드의 상태, 샤드의 상태 등 다양한 정보를 확인할 수 있는 인터페이스를 제공
1.
curl -s http://localhost:9200/_cat/health
해당 명령어는 클러스터의 노드들 중 아무 노드에서나 호출하여 클러스터의 상태 정보를 확인할 수 있다.
다만 위의 명령어는 사람이 알아보기 힘들게 출력되므로 다양한 옵션을 사용하여 알아보기 편하게 할 수 있다.
2.
curl -s http://localhost:9200/_cat/health?v
v 옵션을 뒤에 추가해서 API를 호출, 1번의 명령어와 다르게 각 값에 대한 헤더를 포함
cat API는 format과 pretty 옵션을 통해 더 나은 가독성을 제공
3.
curl -s “http://localhost:9200/_cat/health?format=json&pretty”
[
{
"epoch": "1544448132", -- 1
"timestamp": "13:22:12", -- 2
"cluster" : "elasticsearch", -- 3
"status" : "green", -- 4
"node.total" : "13", -- 5
"node.data" : "10", -- 6
"shards" : "886", -- 7
"pri" : "443", -- 8
"relo" : "0", -- 9
"init" : "0", -- 10
"unassign" : "0", -- 11
"pending_tasks" : "0", -- 12
"max_task_wait_time" : "-", -- 13
"active_shards_precent" : "100.0%" -- 14
}
]
Java
복사
1.
API를 호출한 시간을 UNIX 시간 형태로 표현한 숫자
2.
API를 호출한 시간을 사람이 읽기 쉬운 형태로 표현한 값
3.
클러스터의 이름
4.
클러스터의 상태, 클러스터의 상태는 green, yellow, red 총 3개의 값
5.
클러스터를 구성하고 있는 전체 노드의 개수
6.
클러스터를 구성하고 있는 노드들 중 데이터 노드의 개수
7.
클러스터에 존재하는 전체 샤드의 개수, 모니터링해야 할 중요 지표
8.
클러스터에 존재하는 샤드들 중 프라이머리 샤드의 개수, 모니터링 필요
9.
클러스터에서 재배치되고 있는 샤드의 개수, 이값이 0이 아니라면 계속 샤드가 재배치되고 있는 것, 재배치되고 있는 샤드가 많다면 성능이 저하될 수 있음
10.
클러스터에서 초기화되고 있는 샤드의 개수
11.
클러스터에서 어느 노드에도 배치되지 않고 남아 있는 샤드의 개수, 이 값이 0이 아니라면 그만큼 수의 샤드가 배치되고 있지 않은 것
12.
클러스터의 유지 보수를 위한 작업 중 실행되지 못하고 큐에 쌓여있는 작업의 개수
13.
12에서 확인한 작업이 실행하기까지 소요된 최대 시간, 이 값이 클수록 작업이 정체되고 있는 것
14.
전체 샤드 중에서 정상적으로 동작하는 샤드의 비율
•
상탯값
값 | 의미 |
green | 모든 샤드가 정상적으로 동작하고 있는 상태 |
yellow | 모든 프라이머리 샤드는 정상적으로 동작하고 있으나 일부 혹은 모든 레플리카 샤드가 정상적으로 동작하고 있지 않은 상태 |
red | 일부 혹은 모든 프라이머리 샤드/레플리카 샤드가 정상적으로 동작하고 있지 않은 상태 |
: green과 yellow 상태에서는 프라이머리 샤드가 정상적으로 동작하고 있기 때문에 데이터의 유실은 발생하지 않는다.
: 다만 Yellow의 경우 일부 레플리카 샤드가 정상적으로 동작하지 않기 때문에 이후 레플리카 샤드가 없는 프라이머리 샤드에 문제가 생기면 상태가 red로 변경될 위험 존재
: red는 일부 인덱스들의 프라이머리 샤드가 배치되지 않은 상태이기 때문에 데이터의 유실이 발생할 수 있다.
7.2 노드의 상태와 정보 확인하기
: 노드들의 상태를 확인하는 cat API는 _cat/nodes
1.
curl -s http://localhost:9200/_cat/nodes?v
ip | heap.percent | ram.percent | cpu | load_1m | load_5m | load_15m | node.role | master | name |
노드의 IP 주소 | 힙 메모리 사용률 | 메모리 사용률 | CPU 사용률 | 1분 동안 평균 Load Average | 5분 동안 평균 Load Average | 15분 동안 평균 Load Average | 노드의 역할
d : data
m : master
i : ingest | 마스터 역할 표시 | 노드의 이름 |
7.3 인덱스의 상태와 정보 확인하기
: 인덱스의 상태도 green, yellow, red 세 개의 값으로 표현
: 인덱스의 상태를 확인하는 cat API는 _cat/indices
1.
curl -s http://localhost:9200/_cat/indices?v
health | status | index | uuid | pri | rep | docs.count | docs.delete | store.size | pri.store.size |
인덱스의 상태값 | 인덱스의 사용
여부
읽기/쓰기 기준
open : 사용가능
close : 불가능 | 인덱스의 이름 | 인덱스의 uuid | 인덱스를 구성하고 있는 프라이머리 샤드의 개수 | 인덱스의 replication 값, 1은 복제값이 1개, 0은 복제본 존재 x | 인덱스에 저장된 문서의 갯수 | 인덱스에서 삭제된 문서의 갯수 | 인덱스가 차지하고 있는 전체 용량 | 인덱스의 프라이머리 샤드가 차지하고 있는 전체 용량 |
클러스터의 상태 확인 → 인덱스의 상태 확인
: 클러스터의 상태가 red라고 해서 모든 인덱스가 유실될 가능성이 존재하는 것은 아니다.
: indicies를 조회하여 유실될 가능성이 있는 상태가 red인 인덱스들을 찾아내는 것이 중요하다.
: 만약 red 상태의 인덱스들이 이미 인덱싱이 끝난 과거의 로그들이라면 해당 인덱스의 샤드가 저장되어있는 데이터 노드의 복구를 통해 문서의 유실없이 복구 가능
7.4 샤드의 상태 확인하기
: 샤드의 상태를 확인하는 cat API는 _cat/shards
1.
curl -s http://localhost:9200/_cat/shards?v | more
index | shard | prirep | state | docs | store | ip | node |
인덱스의 이름 | 인덱스의 샤드 번호 | 프라이머리 샤드인지
레플리카 샤드인지 | 샤드의 상태
| 샤드에 저장된 문서의 수 | 샤드의 크기 | 샤드가 배치된 데이터 노드의 IP | 샤드가 배치된 데이터 노드의 노드 이름 |
값 | 의미 |
STARTED | 정상 상태 |
INITIALIZING | 샤드를 초기화하는 상태, 최초 배치 시, 혹은 샤드에 문제가 발생하여 새롭게 배치할 때의 상태 |
RELOADING | 샤드가 현재의 노드에서 다른 노드로 이동하고 있는 상태, 새로운 데이터 노드가 추가되거나 기존 데이터 노드에 문제가 생겨서 샤드가 새로운 노드에 배치되어야 할 때 |
UNASSIGNED | 샤드가 어느 노드에도 배치되지 않은 상태, 해당 샤드가 배치된 노드에 문제가 생기거나 클러스터의 라우팅 정책에 의해 배치되지 않은 상태 |
2.
curl -s http://localhost:9200/_cat/shards?v | grep UNASSIGNED
index | shard | prirep | state | unassigned.reason |
인덱스의 이름 | 인덱스의 샤드 번호 | 프라이머리 샤드인지, 레플리카 샤드인지 | 샤드의 상태
| Unassigned 상태가 된 이유 |
•
unassigned.reason
: 가장 흔한 경우는 INDEX_CREATED와 NODE_LEFT 두 가지로 INDEX_CREATED 인덱스가 생성된 후 샤드가 배치되지 않았음을 의미, 샤드를 특정 노드에만 배치되도록 강제하거나
특정 노드에 배치되지 않도록 강제했을 때 발생할 수 있음, NODE_LEFT는 샤드가 배치된 데이터 노드에서 문제가 생겨서 클러스터에서 제외되었을 때 발생하며 가장 흔하게 발생
클러스터의 상태가 red일 때 중요한 API, 클러스터의 상태가 red라면 먼저 인덱스의 상태를 확인하는 API를 통해 어떤 API가 red 상태인지 확인해야 함
이를 통해 문서의 유실이 발생하는 지 여부를 확인할 수 있
7.5 stats API로 지표 확인하기
: 클러스터와 노드의 각종 성능 지표를 확인하는 방법
1.
클러스터의 성능 지표
2.
노드의 성능 지표
7.6 성능 확인과 문제 해결
1.
색인 성능 살펴보기
2.
검색 성능 살펴보기
3.
GC 성능 살펴보기
