에이전트 텔레메트리

에이전트 텔레메트리 (Agent Telemetry)

Consul 에이전트는 다양한 라이브러리와 하위 시스템의 성능에 대한 런타임 메트릭을 수집해요. 이 문서에서 텔레메트리 데이터를 검색하는 방법과 클러스터 건강 상태를 한눈에 파악하는 데 도움이 되는 주요 메트릭들을 설명할게요.

출처: 문서

본문

Consul 에이전트는 다양한 라이브러리와 하위 시스템의 성능에 대한 다양한 런타임 메트릭을 수집합니다. 이 메트릭들은 10초(10s) 간격으로 집계되며 구성 가능한 시간 동안 보관됩니다. 간격(interval) 은 데이터가 수집되고 집계되는 인스턴스 사이의 기간입니다.

텔레메트리가 외부 메트릭 저장소로 스트리밍될 때 간격은 해당 저장소의 플러시 간격으로 정의됩니다.

| 외부 저장소 (External Store) | 간격 (Interval - seconds) | | dogstatsd | 10s | | Prometheus | 60s | | statsd | 10s |

이 텔레메트리 정보를 사용해 Consul의 운영을 디버깅하고 관찰할 수 있습니다.

텔레메트리 데이터를 검색하려면 Consul 프로세스에 신호를 보냅니다:

  • Unix에서는 USR1을 보냅니다.
  • Windows에서는 BREAK를 보냅니다.

Consul이 신호를 받으면 현재 텔레메트리 정보를 에이전트의 stderr에 덤프합니다. 출력은 다음 예제와 유사합니다:

전형적인 텔레메트리 덤프 예제:

## ...
[G] 'consul.raft.applied_index': 291.000
[G] 'consul.state.connect_instances.dc1.ingress-gateway': 0.000
[G] 'consul.state.config_entries.dc1.file-system-certificate': 0.000
[G] 'consul.version.1.21.5.': 1.000
[G] 'consul.memberlist.node.instances.lan.left': 0.000
[G] 'consul.session_ttl.active': 0.000
[G] 'consul.runtime.total_gc_pause_ns': 12378333.000
[G] 'consul.autopilot.failure_tolerance': 0.000
[G] 'consul.state.config_entries.dc1.mesh': 0.000
[G] 'consul.runtime.num_goroutines': 335.000
[G] 'consul.raft.commitNumLogs': 1.000
[G] 'consul.state.connect_instances.dc1.terminating-gateway': 0.000
[G] 'consul.state.connect_instances.dc1.connect-proxy': 4.000
[G] 'consul.state.kv_entries.dc1': 0.000
[G] 'consul.state.config_entries.dc1.service-router': 0.000
[G] 'consul.state.config_entries.dc1.service-resolver': 0.000
[G] 'consul.state.config_entries.dc1.service-splitter': 0.000
[G] 'consul.runtime.free_count': 1809554.000
[G] 'consul.runtime.heap_objects': 150825.000
[G] 'consul.raft.leader.dispatchNumLogs': 1.000
[G] 'consul.server.isLeader': 1.000
[G] 'consul.state.services.dc1': 10.000
[G] 'consul.state.connect_instances.dc1.api-gateway': 1.000
[G] 'consul.state.config_entries.dc1.service-intentions': 4.000
[G] 'consul.state.config_entries.dc1.terminating-gateway': 0.000
[G] 'consul.runtime.sys_bytes': 67721480.000
## ...

텔레메트리 정보는 JSON 형식과 Prometheus 형식의 출력을 사용할 수 있는 메트릭 API 엔드포인트로도 검색할 수 있습니다.

기본적으로 모든 gauge 유형 메트릭 이름은 Consul 에이전트의 호스트 이름을 접두사로 사용합니다. 예를 들어 consul.<hostname>.server.isLeader입니다. 호스트 이름 접두사를 비활성화하려면 에이전트 구성에서 telemetry.disable_hostname=true를 설정합니다.

또한 statsite 또는 statsd 서버로 Consul 텔레메트리를 보내 Graphite나 다른 메트릭 저장소에 집계·플러시할 수 있습니다. 이 옵션을 사용하려면 에이전트 구성에서 telemetry 매개변수 구성을 참조하세요.

Consul 팀이 유지 관리하는 Grafana 대시보드도 사용할 수 있습니다. 이 대시보드는 이러한 메트릭을 쉽게 시각화하도록 표시하는 데 도움이 되며 여러분만의 대시보드를 만드는 시작점으로 사용할 수 있습니다.

다음 문서와 튜토리얼은 텔레메트리 구성 과정의 추가 예제를 제공합니다:

주요 메트릭 (Key Metrics)

다음은 클러스터의 건강 상태를 한눈에 파악하는 데 도움이 되는 가장 중요한 메트릭 중 일부입니다. Consul이 방출하는 전체 메트릭 목록은 텔레메트리 참조 문서를 참조하세요.

트랜잭션 타이밍 (Transaction timing)

| 메트릭 이름 (Metric Name) | 설명 (Description) | 단위 (Unit) | 타입 (Type) | | consul.kvs.apply | KV 저장소 업데이트를 완료하는 데 걸리는 시간을 측정합니다. | ms | timer | | consul.txn.apply | 트랜잭션 작업을 적용하는 데 소요된 시간을 측정합니다. | ms | timer | | consul.raft.apply | 간격 동안 적용된 Raft 트랜잭션 수를 계산합니다. 이 메트릭은 리더에서만 보고됩니다. | raft transactions / interval | counter | | consul.raft.commitTime | 리더에서 Raft 로그에 새 항목을 커밋하는 데 걸리는 시간을 측정합니다. | ms | timer |

중요한 이유: 종합적으로 보면 이 메트릭들은 Consul 클러스터의 다양한 부분에서 쓰기 작업을 완료하는 데 걸리는 시간을 나타냅니다. 일반적으로 모두 상당히 일관적이며 몇 밀리초를 넘지 않아야 합니다. 타이밍 값 중 하나의 갑작스러운 변화는 Consul 서버의 예기치 않은 부하 또는 서버 자체의 문제 때문일 수 있습니다.

확인할 것: 이전 시간에 대한 기준선(baseline)에서 (이 메트릭 중 하나의) 편차가 50%를 초과하는지.

리더십 변경 (Leadership changes)

| 메트릭 이름 (Metric Name) | 설명 (Description) | 단위 (Unit) | 타입 (Type) | | consul.raft.leader.lastContact | 리더가 리더 임대를 확인할 때 팔로워 노드에 마지막으로 연락한 이후 경과된 시간을 측정합니다. | ms | timer | | consul.raft.state.candidate | Consul 서버가 선거를 시작할 때마다 증가합니다. | elections | counter | | consul.raft.state.leader | Consul 서버가 리더가 될 때마다 증가합니다. | leaders | counter | | consul.server.isLeader | 서버가 리더인지(1) 아닌지(0)를 추적합니다. | 1 or 0 | gauge |

중요한 이유: 일반적으로 Consul 클러스터는 안정적인 리더를 가져야 합니다. 잦은 선거나 리더십 변경이 있으면 Consul 서버 간 네트워크 문제나 Consul 서버 자체가 부하를 따라가지 못하는 것을 나타날 가능성이 높습니다.

확인할 것: 건강한 클러스터의 경우 lastContact가 200ms보다 낮고, leader > 0, candidate == 0인지 확인합니다. 이와 다른 편차는 리더십 깜빡임(flapping)를 나타낼 수 있습니다.

인증 기관 만료 (Certificate Authority expiration)

| 메트릭 이름 (Metric Name) | 설명 (Description) | 단위 (Unit) | 타입 (Type) | | consul.mesh.active_root_ca.expiry | 서비스 메시 루트 인증서가 만료되기까지의 초. 매 시간 업데이트됩니다. | seconds | gauge | | consul.mesh.active_signing_ca.expiry | 서비스 메시 서명 인증서가 만료되기까지의 초. 매 시간 업데이트됩니다. | seconds | gauge | | consul.agent.tls.cert.expiry | 에이전트 TLS 인증서가 만료되기까지의 초. 매 시간 업데이트됩니다. | seconds | gauge |

중요한 이유: Consul 서비스 메시는 서비스를 식별·연결하는 데 사용되는 모든 인증서에 서명할 CA가 필요합니다. 인증서가 만료되어 무효가 되면 메시 네트워크는 작동을 중단합니다. Consul은 루트 CA를 자동으로 회전하지 않으므로 특히 루트 CA 모니터링이 중요합니다. TLS 인증서 메트릭은 서버의 에이전트가 클러스터의 다른 에이전트와 연결하는 데 사용하는 인증서를 모니터링합니다.

확인할 것: 루트 CA는 수동 또는 외부 자동화로 루트 CA를 회전할 때임을 알리는 만료 임박 여부를 모니터링해야 합니다. Consul은 서명(중간) 인증서를 자동으로 회전해야 하지만 회전을 모니터링할 것을 권장합니다. 인증서가 회전하지 않으면 서버 에이전트 로그에서 CA 시스템 관련 메시지를 확인하세요. 에이전트 TLS 인증서의 회전 처리는 구성에 따라 다릅니다.

Autopilot

| 메트릭 이름 (Metric Name) | 설명 (Description) | 단위 (Unit) | 타입 (Type) | | consul.autopilot.healthy | 로컬 서버 클러스터의 전반적 건강 상태를 추적합니다. 모든 서버가 정상이면 1, 하나 이상이 비정상이면 0. | health state | gauge |

중요한 이유: Autopilot은 단순한 부울 값으로 클러스터의 전반적 건강 상태를 노출할 수 있습니다.

확인할 것: healthy가 0이면 경고합니다. 비정상 클러스터의 다른 지표는 다음과 같습니다:

  • 높은 consul.raft.commitTime. 이는 에이전트가 수행하는 상태 저장소 변경 속도를 반영할 수 있습니다. 이 숫자가 상승하면 서버가 호스트의 리소스 저하로 인한 문제를 겪고 있을 수 있습니다.
  • 리더십 변경 메트릭 - 권장 값과의 편차를 확인합니다. 이는 실패한 리더십 선거 또는 깜빡이는 노드를 나타낼 수 있습니다.

메모리 사용량 (Memory usage)

| 메트릭 이름 (Metric Name) | 설명 (Description) | 단위 (Unit) | 타입 (Type) | | consul.runtime.alloc_bytes | Consul 프로세스가 할당한 바이트 수를 측정합니다. | bytes | gauge | | consul.runtime.sys_bytes | OS에서 얻은 총 메모리 바이트 수를 측정합니다. | bytes | gauge |

중요한 이유: Consul은 모든 데이터를 메모리에 보관합니다. Consul이 사용 가능한 모든 메모리를 소비하면 충돌합니다.

확인할 것: consul.runtime.sys_bytes가 총 사용 가능한 시스템 메모리의 90%를 초과하는지.

참고

이 메트릭은 Go의 런타임 패키지 MemStats를 사용해 계산됩니다. 이는 top에서 수집한 정보를 사용하는 것과는 다른 출력을 갖습니다. 자세한 내용은 GH-4734를 참조하세요.

가비지 컬렉션 (Garbage collection)

| 메트릭 이름 (Metric Name) | 설명 (Description) | 단위 (Unit) | 타입 (Type) | | consul.runtime.total_gc_pause_ns | 프로세스 시작 이후 가비지 컬렉션 일시 중지에 소요된 누적 나노초. | ns | gauge |

중요한 이유: GC 일시 중지는 "스톱-더-월드(stop-the-world)" 이벤트로, GC가 완료될 때까지 모든 런타임 스레드가 차단됨을 의미합니다. 일반적으로 이러한 일시 중지는 몇 나노초만 지속됩니다. 하지만 메모리 사용량이 높으면 Go 런타임이 너무 자주 GC하여 Consul이 느려지기 시작할 수 있습니다.

확인할 것: total_gc_pause_ns가 초당 2초/분을 초과하면 경고하고, 5초/분을 초과하면 심각(중요) 상태로 처리합니다.

참고

total_gc_pause_ns는 누적 카운터이므로 비율(예: GC/분)을 계산하려면 InfluxDB의 non_negative_difference() 같은 함수를 적용해야 합니다.

네트워크 활동 - RPC 수 (Network activity - RPC count)

| 메트릭 이름 (Metric Name) | 설명 (Description) | 단위 (Unit) | 타입 (Type) | | consul.client.rpc | Consul 에이전트가 Consul 서버에 RPC 요청을 할 때마다 증가합니다. | requests | counter | | consul.client.rpc.exceeded | Consul 에이전트가 Consul 서버에 RPC 요청할 때 해당 에이전트의 limits 구성으로 속도 제한될 때마다 증가합니다. | requests | counter | | consul.client.rpc.failed | Consul 에이전트가 Consul 서버에 RPC 요청하고 실패할 때마다 증가합니다. | requests | counter |

중요한 이유: 이 측정값은 요청이 속도 제한될 만큼 높아질 때를 포함해 Consul 에이전트에서 발생하는 현재 부하를 나타냅니다. 특히 consul.client.rpc.exceeded에서 온 높은 RPC 수는 요청이 속도 제한되고 있음을 의미하며 잘못 구성된 Consul 에이전트를 암시할 수 있습니다.

확인할 것: consul.client.rpc 메트릭의 갑작스러운 큰 변화(기준선 대비 50% 이상 편차). consul.client.rpc.exceeded 또는 consul.client.rpc.failed 수가 0보다 큰 경우. 이는 에이전트가 속도 제한되거나 Consul 서버에 RPC 요청을 실패함을 의미합니다.

Raft 스레드 포화 (Raft thread saturation)

| 메트릭 이름 (Metric Name) | 설명 (Description) | 단위 (Unit) | 타입 (Type) | | consul.raft.thread.main.saturation | 메인 Raft 고루틴이 바빠서 새 작업을 수용할 수 없는 시간 비율의 대략적 측정값. | percentage | sample | | consul.raft.thread.fsm.saturation | Raft FSM 고루틴이 바빠서 새 작업을 수용할 수 없는 시간 비율의 대략적 측정값. | percentage | sample |

중요한 이유: 이 측정값은 Consul 서버가 추가 쓰기 부하를 수용할 수 있는 용량이 얼마인지에 대한 유용한 대리 지표입니다. Raft 고루틴의 높은 포화는 시스템의 나머지 부분에 지연 시간 상승을 가져오고 클러스터 불안정을 유발할 수 있습니다.

확인할 것: 일반적으로 서버의 정상 상태 포화는 50% 미만이어야 합니다.

참고

이 메트릭들은 대략적이며, 매우 높은 부하에서는 서버가 사용할 수 있는 여유 용량(headroom)이 얼마인지에 대한 완벽하고 세밀한 보기를 제공하지 않습니다. 초기 경고 신호로 취급하세요.

Raft 복제 용량 문제 (Raft replication capacity issues)

| 메트릭 이름 (Metric Name) | 설명 (Description) | 단위 (Unit) | 타입 (Type) | | consul.raft.fsm.lastRestoreDuration | 마지막 FSM 복원(디스크 또는 리더에서)이 걸린 시간을 측정합니다. | ms | gauge | | consul.raft.leader.oldestLogAge | 리더의 로그 저장소에서 가장 오래된 로그가 얼마나 오래되었는지 측정합니다. | ms | gauge | | consul.raft.rpc.installSnapshot | raft 리더가 다운 후 따라잡거나 방금 클러스터에 조인한 팔로워에게 스냅샷을 설치하는 데 걸리는 시간을 측정합니다. | ms | timer |

중요한 이유: 이 메트릭들은 운영자가 서버의 raft 복제 건강 상태와 용량을 모니터링할 수 있게 해 줍니다. Consul이 많은 양의 데이터와 높은 쓰기 처리량을 처리할 때 클러스터가 다음 상태에 들어갈 수 있습니다:

  • 쓰기 처리량이 초당 500 커밋 이상이고 지속적
  • 리더가 매분 정도마다 큰 스냅샷을 작성
  • 스냅샷이 충분히 커서 재시작 시 디스크에서 복원하거나 팔로워가 뒤처지면 리더에서 복원하는 데 상당한 시간이 걸림
  • 사용 가능한 디스크 IO로 리더가 팔로워가 디스크에서 복원하는 것보다 더 빨리 스냅샷을 작성할 수 있음

이러한 조건에서 재시작 후 팔로워는 리더가 새 스냅샷을 작성하고 로그를 잘라내는 것보다 디스크나 리더에서 복원하는 데 시간이 더 걸리므로 복제를 따라잡고 다시 투표자가 되지 못할 수 있습니다.

서버는 스냅샷이 더 최신이더라도 raft_trailing_logs(기본값 10240) 로그 항목을 보관합니다. 초당 500 커밋을 처리하는 리더에서 이는 약 20초 분량의 로그일 뿐입니다. 리더가 20초 미만으로 스냅샷을 작성하고 로그를 잘라낼 수 있다면, 스냅샷 직후에는 리더에 약 20초 분량의 "최근" 로그만 있고, 60초마다 스냅샷을 작성하고 로그를 자른다고 가정하면 약 80초 분량을 넘지 않습니다.

이 상태에서 팔로워는 스냅샷을 메모리에 복원하고 80초 이내에 복제를 재개할 수 있어야 합니다. 그렇지 않으면 쓰기 속도가 줄어들 때까지 클러스터에 다시 조인하지 못할 수 있습니다. 20초 이상 걸리면 재시작 타이밍이 운이 좋지 않아 서버에서 스냅샷을 한 번 이상 다시 다운로드해야 할 가능성이 있습니다. 50초 이상 걸리면 따라잡기보다 실패할 가능성이 더 높고, 리더가 로그를 자르기 직전에 복원을 완료할 때까지 한동안 비투표자로 남게 됩니다.

최악의 경우 팔로워는 지속적으로 리더에서 스냅샷을 다운로드하며, 이는 복원될 때쯤이면 항상 너무 오래된 것입니다. 이로 인해 리더가 큰 스냅샷을 반복적으로 전송하는 부담이 추가되고 클러스터의 내결함성과 서빙 용량도 줄어들 수 있습니다.

Consul 1.5.3부터 raft_trailing_logs를 구성할 수 있게 되었습니다. 이를 늘리면 리더가 더 많은 로그를 보관하여 팔로워가 복원하고 따라잡을 시간을 더 줄 수 있습니다. 단점은 잠재적으로 더 느린 append이며 결국 쓰기 처리량과 지연 시간에 부정적인 영향을 줄 수 있으므로 임의로 높게 설정하는 것은 권장하지 않습니다.

Consul 1.10.0부터 raft_trailing_logs는 이제 consul reload 또는 SIGHUP으로 재로드할 수 있어 운영자가 리더를 재시작하거나 리더십을 잃지 않고 증가시킬 수 있으며 클러스터를 정상적으로 복구할 수 있습니다.

이 메트릭들을 모니터링하면 이 상태를 피하거나 진단하는 데 도움이 됩니다.

확인할 것:

consul.raft.leader.oldestLogAge는 리더가 스냅샷을 찍을 때까지 시간에 따라 선형적으로 증가하는 톱니파 모양이어야 하며, 가장 오래된 로그가 잘려나가면서 아래로 점프합니다. 그 선의 최저점은 스냅샷 복원 시간보다 충분히 높아야 합니다(2배 이상).

팔로워에서 스냅샷을 복원하는 방법은 두 가지입니다: 시작 시 디스크에서, 또는 installSnapshot RPC 동안 리더에게서. 리더는 팔로워가 새것이고 상태가 없거나, 상태가 너무 오래되어 리더 로그를 따라잡을 수 없을 때만 installSnapshot RPC를 보냅니다.

consul.raft.fsm.lastRestoreDuration은 두 소스 중 하나에서 복원하는 데 걸린 시간을 마지막으로 보여줍니다. 대부분의 경우 이 기간은 서버가 시작되었을 때 시작됩니다. 이는 항상 마지막 복원 기간을 표시하는 gauge입니다(Consul v1.10.0 이상). 얼마나 오래 전이든 관계없이 말입니다.

consul.raft.rpc.installSnapshot은 리더가 팔로워에 새 스냅샷을 설치할 때 리더 관점의 타이밍 정보입니다. 데이터 전송에 소요된 시간과 팔로워가 복원하는 시간을 모두 포함합니다. 이러한 이벤트는 일반적으로 드물기 때문에 Prometheus에서 max_over_time와 같은 큰 범위로 마지막으로 관찰된 값을 그래프로 표시해야 할 수 있습니다. 복원 부분은 lastRestoreDuration에도 반영되지만, 팔로워가 항상 안전하게 따라잡을 수 있도록 로그가 스냅샷 전달을 포함한 전체 작업을 커버할 수 있어야 하므로 이것을 관찰하는 것도 유용합니다.

consul.raft.leader.oldestLogAge를 여기의 다른 두 메트릭과 같은 축에 그래프로 표시하면 현재 쓰기 속도에서 리더가 보관하고 있는 한도의 위험할 정도로 가까운 복원 시간을 한눈에 볼 수 있습니다.

서버가 자주 재시작되지 않으면 마지막 복원 이후 스냅샷이 크게 커졌을 수 있으므로 마지막 복원 시간이 에이전트를 지금 재시작할 때의 결과를 반영하지 않을 수 있다는 점에 유의하세요.

라이선스 만료 (License expiration) - Enterprise

| 메트릭 이름 (Metric Name) | 설명 (Description) | 단위 (Unit) | 타입 (Type) | | consul.system.licenseExpiration | Consul Enterprise 라이선스가 만료되기까지의 시간(시간). | hours | gauge |

중요한 이유: 이 측정값은 Consul Enterprise 라이선스가 만료되기까지 남은 시간을 나타냅니다. 라이선스가 만료되면 일부 Consul Enterprise 기능이 작동을 중단합니다. 예를 들어 라이선스 만료 후에는 기본이 아닌 네임스페이스의 리소스를 생성하거나 수정할 수 없으며, 네임스페이스된 리소스의 읽기는 여전히 작동하지만 네임스페이스 정의 자체를 관리할 수도 없습니다.

확인할 것: 기능 저하를 방지하기 위해 라이선스가 만료되지 않도록 이 메트릭을 모니터링해야 합니다.

WAL 로그스토어 성능 (WAL logstore performance)

WAL LogStore는 이전 Consul 버전에서 백엔드로 사용된 BoltDB를 대체했습니다. 자세한 내용은 영구 데이터 백엔드 아키텍처를 참조하세요.

| 메트릭 이름 (Metric Name) | 설명 (Description) | 단위 (Unit) | 타입 (Type) | | consul.raft.wal.head_truncations | 헤드에서 잘라낸 로그 항목 수를 계산하며, 이는 가장 오래된 항목을 나타냅니다. 시간 경과에 따른 변화율을 그래프로 표시하면 개별 truncate 호출을 스파이크로 관찰할 수 있습니다. | log entries | counter | | consul.raft.wal.last_segment_age_seconds | 세그먼트를 회전할 때마다 설정되며, 해당 세그먼트 파일이 처음 생성된 시점과 봉인(sealed)된 시점 사이의 초 수를 나타냅니다. 이는 쓰기가 디스크를 얼마나 빨리 채우는지에 대한 대략적 추정치를 제공합니다. | seconds | gauge | | consul.raft.wal.log_appends | StoreLog(s) 호출 수를 계산합니다. 추가된 엔트리 배치 수입니다. | batches of entries | counter | | consul.raft.wal.log_entries_read | get_log 호출 수를 계산합니다. | entries | counter | | consul.raft.wal.log_entries_written | 작성된 엔트리 수를 계산합니다. | entries | counter | | consul.raft.wal.log_entry_bytes_read | 디코딩 전에 세그먼트에서 읽은 로그 엔트리 바이트를 계산합니다. 헤더와 인덱스 엔트리, 그리고 버퍼에 맞지 않는 큰 항목에 대한 가능한 2차 읽기를 포함하므로 실제 디스크 읽기 바이트가 더 높을 수 있습니다. | entries | counter | | consul.raft.wal.log_entry_bytes_written | Codec으로 인코딩한 후의 로그 엔트리 바이트를 계산합니다. 헤더와 인덱스 엔트리를 포함하므로 실제 디스크에 기록된 바이트가 약간 더 높을 수 있습니다. | entries | counter | | consul.raft.wal.segment_rotations | 새 세그먼트 파일로 이동하는 횟수를 계산합니다. | segments | counter | | consul.raft.wal.stable_gets | StableStore.Get 또는 GetUint64 호출 수를 계산합니다. | calls | counter | | consul.raft.wal.stable_sets | StableStore.Set 또는 SetUint64 호출 수를 계산합니다. | calls | counter | | consul.raft.wal.tail_truncations | 헤드에서 잘라낸 로그 항목 수를 계산하며, 이는 가장 새 항목을 나타냅니다. 시간 경과에 따른 변화율을 그래프로 표시하면 개별 truncate 호출을 스파이크로 볼 수 있습니다. | log entries | counter |

요구 사항:

  • Consul 1.20.0+

중요한 이유: consul.raft.wal.last_segment_age_seconds는 쓰기가 디스크를 얼마나 빨리 채우는지에 대한 직접적인 지표입니다.

확인할 것: 주로 살펴볼 것은 consul.raft.wal.last_segment_age_seconds 시간의 증가입니다. 이 정보를 consul.raft.commitTime, consul.raft.rpc.installSnapshot, consul.raft.leader.dispatchLog 값과 결합하면 로그스토어 성능에 대한 개요를 얻을 수 있습니다.

Bolt DB 성능 (Bolt DB performance)

| 메트릭 이름 (Metric Name) | 설명 (Description) | 단위 (Unit) | 타입 (Type) | | consul.raft.boltdb.freelistBytes | freelist 메타데이터를 인코딩하는 데 필요한 바이트 수를 나타냅니다. raft_logstore.boltdb.no_freelist_sync가 false로 설정된 경우 이 메타데이터 바이트는 각 커밋된 로그에 대해 디스크에도 기록되어야 합니다. | bytes | gauge | | consul.raft.boltdb.logsPerBatch | db에 배치당 기록되는 로그 수를 측정합니다. | logs | sample | | consul.raft.boltdb.storeLogs | db에 로그를 기록하는 데 소요된 시간을 측정합니다. | ms | timer | | consul.raft.boltdb.writeCapacity | 초당 기록할 수 있는 로그 수 측면의 이론적 쓰기 용량. 각 샘플은 향후 배치 로그 쓰기 작업이 이와 유사하다면 용량이 어떨지 출력합니다. 이 유사성은 4가지를 포함합니다: 배치 크기, 바이트 크기, 디스크 성능, boltdb 성능. 이 중 어느 것도 정적이지 않고 이 메트릭의 개별 샘플이 다를 가능성이 높지만, 더 큰 시간 창에 걸쳐 이 메트릭을 집계하면 이 BoltDB 저장소가 어떻게 수행할 수 있는지에 대한 괜찮은 그림을 제공해야 합니다. | logs/second | sample |

요구 사항:

  • Consul 1.11.0+

중요한 이유: consul.raft.boltdb.storeLogs 메트릭은 Consul 서버의 디스크 쓰기 성능에 대한 직접적인 지표입니다. 디스크에 문제가 있거나 Bolt DB와 관련된 성능 저하가 있으면 이 메트릭이 문제와 잠재적 원인을 보여줍니다.

확인할 것: 주로 살펴볼 것은 consul.raft.boltdb.storeLogs 시간의 증가입니다. 그 값은 Consul 내 쓰기 작업 처리량의 상한을 직접 결정합니다.

Consul에서 각 쓰기 작업은 커밋할 단일 Raft 로그로 바뀝니다. Raft는 이 로그들을 처리해 Bolt DB에 배치로 저장합니다. Bolt DB 내 로그 저장을 호출할 때마다 걸린 시간과 배치에 포함된 로그 수를 측정합니다. 이런 방식으로 로그를 기록하는 것은 직렬화되므로 후속 로그 저장 작업은 이전 작업이 완료된 후에만 시작될 수 있습니다. 매초 수행할 수 있는 최대 로그 저장 작업 수는 consul.raft.boltdb.writeCapacity 메트릭으로 나타납니다. 로그 저장 작업이 느려지면 각 작업의 배치 크기가 증가하여 쓰기 용량이 즉시 감소하지 않을 수 있습니다. 그러나 허용되는 최대 배치 크기는 64 로그입니다. 따라서 logsPerBatch 메트릭이 64에 가깝고 storeLogs 메트릭이 각 배치를 디스크에 기록하는 시간이 증가하면 쓰기 지연 시간이 증가하고 다른 오류가 발생할 가능성이 높습니다.

이를 유발할 수 있는 잠재적 문제는 여러 가지가 있습니다. 종종 문제는 기본 디스크의 성능일 수 있습니다. 때로는 Bolt DB 동작으로 인해 발생할 수 있습니다. Bolt DB는 raft.db 파일 내의 여유 공간을 추적합니다. 데이터를 할당해야 할 때 파일을 더 확장하기 전에 기존 여유 공간을 먼저 사용합니다. 기본적으로 Bolt DB는 모든 로그 저장 작업에 대해 DB 내 여유 페이지에 대한 메타데이터가 포함된 데이터 구조를 디스크에 기록합니다. 따라서 DB 내 여유 공간이 정상 상태를 넘어 크게 증가하면(예: 기록이 크게 급증한 후 쓰기 속도가 느려진 경우) Bolt DB는 각 로그 저장 작업에 대해 많은 양의 추가 데이터를 디스크에 기록할 수 있습니다. 이는 기본 디스크가 따라잡기 어려울 만큼 디스크 쓰기 처리량을 급격히 증가시킬 가능성이 있습니다. 이 상황을 감지하려면 consul.raft.boltdb.freelistBytes 메트릭을 확인할 수 있습니다. 이 메트릭은 로그 데이터 자체를 넘어 각 로그 저장 작업에 대해 기록되는 추가 바이트 수의 카운트입니다. 실제 문제의 명확한 지표는 아니지만 이 메트릭은 consul.raft.boltdb.storeLogs 메트릭이 높은 이유를 진단하는 데 사용할 수 있습니다.

Bolt DB 로그 저장 성능이 문제가 되고 free list 관리로 인해 발생한다면 서버 구성에서 raft_logstore.boltdb.no_freelist_sync를 true로 설정하면 디스크 IO와 로그 저장 작업 시간을 줄이는 데 도움이 될 수 있습니다. 단, free list 동기화를 비활성화하면 이미 채워진 free list 구조를 로드하는 대신 여유 공간에 대해 raft.db 파일을 스캔해야 하므로 서버 시작 시간이 증가합니다.

더 알아보기 (Learn more)