일반 상태 점검을 위한 핵심 메트릭
일반 상태 점검을 위한 핵심 메트릭 (Key metrics for common health checks)
이 문서는 Vault 모니터링에서 자주 쓰는 패턴을 다룹니다. 실행 중인 Vault 클러스터에 대한 운영·사용량 통찰을 확보하면 성능을 이해하고, 선제적인 사고 대응을 돕고, 비즈니스 워크로드와 사용 사례를 파악할 수 있으므로 중요합니다.
이 문서는 다섯 개의 메트릭 섹션(core, usage, storage backend, audit, resource)으로 구성되며, 추가로 복제(Replication) 메트릭을 다룹니다. Core 메트릭은 Vault 클러스터의 상태를 보장하기 위해 모니터링해야 할 기본적인 내부 메트릭입니다. Usage 메트릭 섹션은 Vault의 활성·과거 클라이언트를 세는 데 도움이 되는 메트릭을 다룹니다. Storage backend 섹션은 Vault 클러스터가 사용하는 스토리지 인프라를 이해하고 스토리지가 의도대로 동작하는지 확인하기 위해 모니터링해야 할 메트릭을 강조합니다. Audit 메트릭은 규정 준수 요구사항을 충족하도록 모니터링을 구성하게 해 줍니다. Resource 메트릭은 CPU, 네트워킹 등 Vault가 호스트에서 사용하는 리소스를 모니터링하게 해 줍니다. Replication 섹션은 Vault가 의도대로 데이터를 복제하고 있는지 확인하는 데 쓸 수 있는 메트릭을 다룹니다.
출처: 문서
본문
Core 메트릭
서버가 리더 역할을 맡는다
메트릭:
Vault.core.leadership_lost
vault.core.leadership_setup_failed
배경:
이 다이어그램은 3개의 가용 영역(AZ)에 분산된 5개 노드를 가진 고가용성(HA) Vault 클러스터를 보여줍니다. Vault의 Integrated Storage는 합의 프로토콜을 사용해 클러스터 노드 간 일관성을 제공합니다. 리더(활성) 노드는 새 로그 엔트리를 받아들이고, 이를 팔로워(대기) 노드로 복제하며, 엔트리를 언제 커밋할지 관리합니다. Integrated Storage는 일관성을 위해 합의 프로토콜을 사용하므로, 리더를 잃으면 투표 노드들이 새 리더를 선출합니다. 자세한 내용은 Integrated storage 문서를 참조하세요.
팁
Vault를 Integrated Storage로 운영하면 Raft 리더십 변경에 대한 추가 메트릭이 자동으로 제공됩니다.
알림:
vault.core.leadership_lost 메트릭은 서버가 리더 자리를 잃기 전까지 그 자리를 유지한 시간을 측정합니다. 이 메트릭 값이 지속적으로 낮으면 리더십 교체가 잦다는 뜻으로, 클러스터 내부의 불안정 가능성을 시사합니다.
반면 vault.core.leadership_setup_failed 메트릭의 급증은 대기(standby) 서버가 필요할 때 리더 역할을 맡는 데 실패했음을 나타냅니다. 이런 실패는 즉시 조사하고, 리더 선출 락(lock) 획득과 관련된 문제도 확인하세요. 이 메트릭들은 중요한 알림이며 보안·신뢰성 위험을 시사할 수 있습니다. 예를 들어 Vault와 스토리지 백엔드 사이 통신 문제가 있거나, 더 넓은 장애로 인해 여러 Vault 서버가 실패할 수 있습니다. 이 메트릭들을 모니터링하고 분석하면 근본 문제를 파악·해결해 Vault 클러스터의 안정성과 보안을 보장할 수 있습니다.
애플리케이션의 대기 시간이 길어진다
메트릭:
vault.core.handle_login_request
vault.core.handle_request
배경:
Vault는 Kubernetes, Active Directory, Okta 같은 신뢰할 수 있는 소스를 사용해 시크릿에 접근을 허용하기 전에 클라이언트(사용자 또는 서비스)의 신원을 검증할 수 있습니다. 클라이언트는 vault login 명령이나 API를 통해 로그인 요청을 보내 인증해야 합니다. 인증에 성공하면 Vault는 클라이언트에게 토큰을 부여하며, 이 토큰은 클라이언트 머신에 로컬로 저장되고 이후 요청을 승인하는 데 사용됩니다. 클라이언트가 만료되지 않은 유효한 토큰을 제시하는 한, Vault는 그 클라이언트를 인증된 것으로 인식합니다.
알림:
vault.core.handle_login_request 메트릭은 평균을 내면 Vault가 클라이언트 로그인 요청에 얼마나 빠르게 응답하는지 측정합니다. 이 메트릭이 크게 늘었는데 발급된 토큰 수(vault.token.creation)는 크게 늘지 않았다면, 원인을 즉시 조사하는 것이 중요합니다.
클라이언트가 Vault에 요청을 보내면 일반적으로 신원을 검증하고 필요한 권한을 얻기 위해 인증 과정을 거쳐야 합니다. 이 인증 과정은 사용자 이름·비밀번호나 API 토큰 같은 클라이언트 자격 증명을 검증하고, 클라이언트가 적절한 접근 권한을 갖고 있는지 확인하는 것을 포함합니다.
Vault의 인증 과정이 느리면 Vault가 클라이언트 자격 증명을 검증하고 요청을 승인하는 데 더 오래 걸립니다. 이런 인증 지연은 Vault의 클라이언트 요청 응답 시간에 직접 영향을 줍니다.
또한 서버 워크로드를 측정하는 vault.core.handle_request 메트릭도 모니터링해야 합니다. 이 메트릭은 증가하는 트래픽을 수용하기 위해 클러스터를 확장해야 하는지 판단하는 데 도움이 됩니다. 반면 처리량(throughput)이 갑자기 떨어지면 Vault와 클라이언트 사이의 연결 문제를 나타낼 수 있으므로 추가 조사가 필요합니다.
감사 설정이 어렵거나 커스텀 플러그인 백엔드 마운트에 문제가 생긴다
메트릭:
vault.core.post_unseal
배경:
Vault 서버는 seal(봉인) 또는 unseal(봉인 해제) 두 상태 중 하나입니다. 보안을 보장하기 위해 Vault는 스토리지 백엔드를 신뢰하지 않고 데이터를 암호화된 형태로 저장합니다. Vault가 시작된 후, 데이터를 복호화하는 데 필요한 해독 키를 읽기 위한 평문 루트 키를 얻으려면 unseal 과정을 거쳐야 합니다. unseal 후 Vault는 요청에 응답하기 시작하기 전에 서버를 올바르게 설정하기 위한 다양한 post-unseal 작업을 수행합니다.
알림:
vault.core.post_unseal 메트릭의 갑작스러운 증가를 발견하면, 감사 오류나 커스텀 플러그인 백엔드 마운트 오류처럼 post-unseal 과정에서 서버의 가용성에 영향을 주는 문제가 있을 수 있습니다. 문제를 진단하려면 Vault 서버의 로그를 참조하세요.
Usage 메트릭
과도한 토큰 생성이 Vault 성능에 영향을 준다
메트릭:
vault.token.creation
배경:
인증된 모든 Vault 요청에는 유효한 클라이언트 토큰이 필요합니다. 토큰은 특정 경로에 대해 클라이언트(사용자 또는 시스템)가 가진 기능을 결정하는 정책에 연결됩니다. Vault는 서비스 토큰(service token), 배치 토큰(batch token), 복구 토큰(recovery token) 세 가지 유형의 토큰을 발급합니다.
서비스 토큰은 사용자가 일반적으로 "일반" Vault 토큰이라고 생각하는 것입니다. 갱신, 폐기, 하위 토큰 생성 등 모든 기능을 지원합니다. 그만큼 생성·추적에 무겁습니다.
배치 토큰은 클라이언트에 대한 최소한의 정보만 담고 있는 암호화된 이진 대형 객체(blob)입니다. Vault는 서비스 토큰은 영속하지만 배치 토큰은 영속하지 않습니다. 서비스 토큰을 저장하는 데 필요한 공간은 인증 방법에 따라 달라집니다. 따라서 서비스 토큰이 대량이면 메모리 부족(out-of-memory) 문제로 이어질 수 있습니다.
복구 토큰은 복구 모드에서 Vault를 운영할 때만 사용됩니다.
알림
생성된 토큰 수(vault.token.creation)와 로그인 요청 빈도(vault.core.handle_login_request, 전체 합계로 계산)를 모니터링하면 시스템의 전체 워크로드를 파악할 수 있습니다. 서버리스 워크로드처럼 수많은 단기 실행 프로세스를 운영하는 시나리오라면, 수백·수천 개의 함수가 동시에 시크릿을 생성·요청하는 상황이 발생할 수 있습니다. 이 경우 두 메트릭 모두에서 상관된 급증을 관찰하게 됩니다.
일시적 워크로드를 다룰 때는 배치 토큰을 사용해 클러스터 성능을 높이는 것이 좋습니다. Vault는 배치 토큰을 생성할 때 클라이언트의 모든 정보를 암호화해 클라이언트에 제공합니다. 클라이언트가 이 토큰을 사용하면 Vault는 저장된 메타데이터를 복호화해 요청을 처리합니다. 서비스 토큰과 달리 배치 토큰은 클라이언트 정보를 보유하지 않거나 클러스터 간 복제되지 않습니다. 이 특성 덕분에 스토리지 백엔드의 부담이 줄어들고 클러스터 성능이 향상됩니다.
배치 토큰에 대해 더 알아보려면 배치 토큰 튜토리얼을 참조하세요.
임대 수명주기가 Vault에 예상치 못한 트래픽 급증을 일으킨다
메트릭:
vault.expire.num_leases
배경:
Vault는 동적 시크릿이나 서비스 토큰을 생성할 때 임대(lease)를 만듭니다. 이 임대에는 시크릿·토큰의 TTL(time to live) 값, 확장·갱신 가능 여부 같은 필수 정보가 담깁니다. Vault는 임대를 스토리지 백엔드에 저장합니다. Vault가 TTL에 도달하기 전에 임대를 갱신하지 않으면 임대가 만료·무효화되어 해당 시크릿·토큰이 폐기됩니다.
알림
Vault 서버의 활성 임대 수(vault.expire.num_leases)를 모니터링하면 서버의 활동 수준을 파악하는 데 유용한 통찰을 얻을 수 있습니다. 임대 수가 늘면 애플리케이션으로 가는 트래픽이 많아졌다는 뜻입니다. 동시에 임대 수가 갑자기 줄면 들어오는 트래픽을 처리할 만큼 동적 시크릿에 빠르게 접근하지 못하는 문제를 나타낼 수 있습니다.
보안과 성능을 위해 임대의 TTL은 가능한 한 짧게 설정하는 것을 권합니다. 여기에는 두 가지 주된 이유가 있습니다. 첫째, TTL이 짧을수록 잠재적 공격의 영향을 줄입니다. 둘째, 임대가 무한정 누적되어 스토리지 백엔드의 과도한 공간을 소비하는 것을 막아줍니다. TTL을 명시하지 않으면 임대는 기본적으로 32일로 설정됩니다. 그런데 부하가 갑자기 급증해 이 긴 기본 TTL을 가진 임대가 대량 생성되면 스토리지 백엔드가 최대 용량에 빠르게 도달해 다운돼 가용성이 사라질 수 있습니다.
사용 사례에 따라 토큰·시크릿이 전체 32일이 아니라 몇 분·몇 시간만 필요할 수도 있습니다. 적절한 TTL을 설정하면 새 시크릿·토큰을 저장할 스토리지 공간을 확보할 수 있습니다. Vault Enterprise의 경우 임대 수 쿼터를 설정해 특정 임계값 아래로 생성되는 임대 수를 제한할 수 있습니다. 임계값에 도달하면 기존 임대가 만료·폐기될 때까지 Vault는 새 임대 생성을 제한합니다. 이렇게 하면 전체 임대 수를 관리하고 과도한 리소스 사용을 막을 수 있습니다.
리소스 쿼터로 Vault 보호하기 튜토리얼에서 임대 수 쿼터를 설정하는 방법을 배워보세요.
또는 Vault 에이전트 캐싱을 활용해 임대 수명주기 관리를 Vault Agent에 위임할 수 있습니다.
참고
임대의 수명주기는 만료 관리자(expiration manager)가 관리하며, 임대에 연결된 TTL 값에 도달하면 임대를 폐기합니다. 백엔드 잘못된 구성, 네트워크 연결 문제, 대상 시스템의 지속적 실패 등으로 철회 불가능한(irrevocable) 임대가 생길 수 있습니다. 이런 임대는 vault.expire.num_irrevocable_leases 메트릭으로 추적됩니다. 이 메트릭은 값이 오르면 조사가 필요한 운영·보안 위험을 나타낼 수 있으므로 모니터링하는 것이 중요합니다. 철회 불가능한 임대를 식별·해결하는 방법은 철회 불가능한 임대 문제 해결 튜토리얼을 참조하세요.
클라이언트 토큰을 갱신·폐기하는 평균 시간을 파악한다
메트릭:
vault.expire.renew-token
vault.expire.revoke
배경:
Vault는 토큰의 TTL이 만료되면 토큰이 부여한 시크릿에 대한 접근을 자동으로 폐기합니다. 보안 침해 가능성이 있는 징후가 있으면 토큰을 수동으로 폐기할 수도 있습니다. 토큰이 더 이상 유효하지 않으면(만료 또는 폐기) 클라이언트는 Vault가 관리하는 시크릿에 접근할 수 없게 됩니다. 따라서 클라이언트는 토큰이 만료되기 전에 갱신하거나 새 토큰을 요청해야 합니다.
알림
폐기(vault.expire.revoke)와 갱신(vault.expire.renew-token) 작업이 제때 완료되는지 모니터링하는 것은 시크릿의 유효성·접근성을 보장하는 데 중요합니다. 일부 장기 실행 애플리케이션은 새 토큰을 받는 대신 토큰을 갱신해야 할 수 있습니다. 이런 경우 토큰을 갱신하는 데 걸리는 시간이 애플리케이션의 시크릿 접근에 영향을 줄 수 있습니다. 또한 폐기 작업 완료 시간을 추적하면 시크릿에 대한 승인되지 않은 접근을 감지하는 데 도움이 됩니다. 접근을 얻은 공격자가 시스템에 침투해 피해를 줄 수 있기 때문입니다. 폐기 과정에 큰 지연이 발견되면 폐기를 방해한 백엔드 문제가 없는지 서버 로그를 조사하세요.
스토리지 백엔드 메트릭
Vault 스토리지 백엔드의 성능 문제를 감지한다
메트릭:
vault.<STORAGE>.get
vault.<STORAGE>.put
vault.<STORAGE>.list
vault.<STORAGE>.delete
배경:
스토리지 백엔드의 성능은 Vault 전체 성능에 영향을 주므로, 이상 징후를 감지·대응할 수 있도록 스토리지 백엔드 성능을 모니터링하는 것이 중요합니다. 백엔드 모니터링을 통해 스토리지 인프라가 최적으로 동작하는지 확인할 수 있습니다. 성능 추적을 통해 백엔드 작업에 대한 자세한 정보와 통찰을 수집하고, 개선·최적화가 필요한 영역을 식별할 수 있습니다.
알림
Vault가 항목을 검색(vault.<STORAGE>.get), 저장(vault.<STORAGE>.put), 나열(vault.<STORAGE>.list), 삭제(vault.<STORAGE>.delete)하는 백엔드 접근에 더 오래 걸리면, Vault 클라이언트가 스토리지 제한 때문에 지연을 겪고 있을 수 있습니다. 이 문제를 해결하려면 Vault의 스토리지 백엔드 접근이 느려질 때 팀에 자동으로 알리는 알림을 설정할 수 있습니다. 그러면 지연 증가가 애플리케이션 사용자 경험에 부정적인 영향을 주기 전에 I/O 성능이 더 좋은 디스크로 업그레이드하는 등 조치를 취할 수 있습니다.
Integrated Storage를 사용한다면 다음 리소스가 추가 지침을 제공합니다.
Audit 메트릭
막힌 감사 디바이스 (Blocked audit devices)
메트릭:
vault.audit.log_request_failure
vault.audit.log_response_failure
배경:
감사 디바이스는 Vault의 요청·응답에 대한 포괄적인 감사 로그를 기록해 규정 준수 요구사항을 충족하는 데 핵심적인 역할을 합니다. 운영 배포에서는 클러스터와 관련된 모든 들어오는 요청과 나가는 응답을 추적할 수 있도록 Vault 클러스터에 감사 디바이스가 하나 이상 활성화되어 있어야 합니다. 감사 디바이스 하나에만 의존하는데 문제(예: 네트워크 연결 손실, 권한 문제)가 발생하면 Vault가 응답하지 않게 되어 요청 처리를 멈출 수 있습니다. 감사 디바이스를 하나 이상 추가로 활성화하는 것은 Vault의 중단 없는 기능과 응답성을 보장하는 데 필수적입니다.
알림
원활한 운영을 위해 감사 로그 요청 실패(vault.audit.log_request_failure)와 응답 실패(vault.audit.log_response_failure)의 비정상적인 증가를 모니터링하는 것이 중요합니다. 이런 실패는 디바이스 막힘을 나타낼 수 있습니다. 이런 문제가 발생하면 감사 로그를 검토해 문제가 있는 디바이스를 식별하고 근본 문제에 대한 추가 단서를 얻을 수 있습니다.
Vault가 감사 로그를 syslog에 쓸 수 없으면 아래 예시와 같은 오류 로그를 생성합니다.
2020-10-20T12:34:56.290Z [ERROR] audit: backend failed to log response: backend=syslog/ error="write unixgram @->/test/log: write: message too long"
2020-10-20T12:34:56.291Z [ERROR] core: failed to audit response: request_path=sys/mounts
error="1 error occurred:
* no audit backend succeeded in logging the response
실패한 로그 응답마다 audit 모듈과 core 모듈에서 한 쌍의 오류가 발생할 것으로 예상해야 합니다. "write: message too long" 메시지가 포함된 오류 메시지를 받으면, Vault가 syslog 감사 디바이스에 쓰려는 엔트리가 syslog 호스트의 소켓 전송 버퍼 크기를 초과한다는 뜻입니다. 이런 경우 Active Directory나 LDAP 그룹의 방대한 목록처럼 큰 로그 엔트리를 생성하는 원인을 조사해야 합니다.
추가 지침은 막힌 감사 디바이스 튜토리얼을 참조하세요.
Resource 메트릭
런타임 메트릭 (Runtime metrics)
메트릭:
vault.runtime.num_goroutines
vault.runtime.heap_objects
배경:
Vault 런타임의 기본적인 부분은 goroutines입니다. goroutines는 Go 런타임이 관리하는 경량 스레드로, Vault 내부의 많은 함수가 런타임의 일부로 생성합니다.
Vault 설치 환경의 상태에 대한 정확한 기준선(baseline)과 알림 임계값을 만들기 위해 런타임의 핵심 메트릭을 모니터링하는 것을 권합니다.
알림:
추적할 두 가지 핵심 알림 메트릭은 vault.runtime.num_goroutines와 vault.runtime.heap_objects입니다.
vault.runtime.num_goroutines의 갑작스러운 증가는 시스템 로드에 영향을 주는 무언가가 있어 조사가 필요함을 나타낼 수 있습니다.vault.runtime.heap_objects의 변화는 메모리 압박을 나타낼 수 있습니다.
vault.runtime.heap_objects에 대한 정확한 기준선과 알림 임계값을 갖추면 잠재적인 성능 문제가 실제 문제가 되기 전에 식별하는 데 도움이 됩니다.
가비지 컬렉션으로 나타나는 Vault 메모리 문제
메트릭:
vault.runtime.sys_bytes
vault.runtime.gc_pause_ns
배경:
Go 런타임의 가비지 컬렉션은 모든 작업을 일시적으로 중단시킵니다. 이런 중단은 보통 짧지만, 메모리 사용량이 높으면 가비지 컬렉션이 더 자주 발생합니다. 이런 가비지 컬렉션 빈도 증가는 Vault 성능에 지연을 일으킬 수 있습니다.
알림
Vault의 메모리 사용량(호스트의 전체 사용 가능 메모리 비율로 표현)과 가비지 컬렉션 중단 시간(vault.runtime.gc_pause_ns로 측정) 사이의 관계를 분석하면 리소스 제한에 대한 유용한 통찰을 얻고 컴퓨팅 리소스를 효과적으로 할당하는 데 도움이 됩니다.
예를 들어 vault.runtime.sys_bytes가 호스트의 사용 가능한 메모리의 90%를 초과하면 성능 저하를 막기 위해 메모리를 추가하는 것이 좋습니다. 또한 GC 중단 시간이 분당 5초를 초과하면 알림이 트리거되도록 설정해야 합니다. 이 알림은 즉시 알려줘 문제를 신속히 해결할 수 있게 해 줍니다.
CPU I/O 대기 시간 (CPU I/O wait time)
배경:
Vault는 인스턴스·노드를 추가해 수평 확장하지만, 확장성에는 여전히 실질적인 한계가 있습니다. I/O 작업에 대한 과도한 CPU 대기 시간은 시스템이 확장 한계에 도달하거나 특정 리소스를 과도하게 사용하고 있음을 나타낼 수 있습니다. 관리자는 이 메트릭을 추적해 시스템의 확장성을 평가하고, I/O 작업 최적화나 추가 리소스 확보처럼 시스템이 성장할 때 성능을 유지하기 위한 적절한 조치를 취할 수 있습니다.
알림
최적의 성능을 위해 I/O 대기 시간을 10% 미만으로 유지하는 것을 권합니다. 대기 시간이 지나치게 길어지면 클라이언트가 Vault의 요청 응답을 기다리는 동안 지연을 겪고 있다는 뜻입니다. 이 지연은 Vault에 의존하는 애플리케이션의 성능에 부정적인 영향을 줄 수 있습니다. 이런 상황에서는 리소스가 워크로드를 처리하도록 제대로 구성되었는지, 요청이 모든 CPU에 고르게 분산되는지 평가해야 합니다. 이 단계들은 잠재적인 성능 문제를 해결하고 Vault와 그 의존 애플리케이션의 원활한 운영을 보장하는 데 도움이 됩니다.
네트워크 처리량을 임계값 안에 유지한다
배경:
Vault 클러스터의 네트워크 처리량을 모니터링하면 워크로드를 가늠할 수 있습니다. 들어오거나 나가는 트래픽이 갑자기 줄면 Vault와 클라이언트·의존성 사이의 통신 문제를 나타낼 수 있습니다. 반대로 네트워크 활동이 예상치 못하게 급증하면 서비스 거부(DoS) 공격의 징후일 수 있습니다. 이런 네트워크 패턴을 파악하면 잠재적인 문제나 보안 위협을 식별하는 데 유용한 통찰을 얻을 수 있습니다.
알림
Vault 1.5부터는 Vault의 전반적인 안정성·상태를 보장하기 위해 속도 제한 쿼터(rate limit quota)를 설정할 수 있습니다. 서버가 이 임계값에 도달하면 Vault는 새 클라이언트 요청을 거부하고 HTTP 429 오류(구체적으로 "Too Many Requests")로 응답합니다. 거부된 요청은 감사 로그에 기록되며 "error: request path kv/app/test: rate limit quota exceeded." 같은 메시지가 표시됩니다. 정상적인 요청을 차단하고 애플리케이션을 느려지게 하지 않도록 속도 쿼터에 적절한 한도를 고르는 것이 중요합니다. 이러한 위반 빈도를 모니터링하고 한도를 조정하려면 속도 제한 쿼터를 위반할 때마다 증가하는 quota.rate\_limit.violation 메트릭을 주시하면 됩니다.
Vault의 속도 제한 쿼터를 설정하는 방법은 리소스 쿼터로 Vault 보호하기 튜토리얼을 참조하세요.
복제 메트릭
Write-Ahead 로그 모니터링으로 스토리지 백엔드 메모리를 확보한다
메트릭:
vault.wal_flushready
vault.wal.persistWALs
배경:
높은 성능을 유지하기 위해 Vault는 주기적으로 오래된 Write-Ahead 로그(WAL)를 제거해 스토리지 백엔드의 메모리를 확보하는 가비지 컬렉터를 사용합니다. 그런데 예상치 못한 트래픽 급증이 발생하면 WAL이 빠르게 누적되어 스토리지 백엔드에 부담이 가중될 수 있습니다. 이런 급증은 같은 스토리지 백엔드에 의존하는 Vault의 다른 프로세스에 부정적인 영향을 줄 수 있습니다. 따라서 복제가 스토리지 백엔드 성능에 미치는 영향을 평가하는 것이 중요합니다. 이를 통해 복제 과정이 시스템의 전체 성능에 어떻게 영향을 주는지 더 잘 이해할 수 있습니다.
알림
vault.wal_flushready와 vault.wal.persistWALs 두 메트릭을 추적하는 것을 권합니다. 첫 번째 메트릭은 준비된 WAL을 영속 큐(persist queue)로 플러시하는 데 걸리는 시간을, 두 번째 메트릭은 WAL을 스토리지 백엔드에 영속화하는 데 걸리는 시간을 측정합니다.
효율적인 성능을 위해 vault.wal_flushready 메트릭이 500밀리초를 초과하거나 vault.wal.persistWALs 메트릭이 1,000밀리초를 넘으면 알림이 트리거되도록 설정하시길 권합니다. 이 알림들은 백프레셔(backpressure)가 스토리지 백엔드를 느리게 하고 있음을 나타내는 지표입니다.
이 알림 중 하나라도 트리거되면 증가한 워크로드를 수용하도록 스토리지 백엔드 확장을 고려해 보세요. 확장은 부담을 줄이고 최적의 성능을 유지하는 데 도움이 됩니다.
Vault Enterprise 복제 상태 점검
메트릭:
vault.replication.wal.last_wal
배경:
Vault의 Write-Ahead 로그(WAL)는 내구성 있는 데이터 저장·복구 메커니즘입니다. WAL은 Vault가 변경 사항을 기본 스토리지 백엔드에 영속화하기 전에 Vault 데이터 저장소에 대한 모든 변경 사항을 기록하는 로그 파일입니다. WAL은 시스템 실패·크래시가 발생해도 신뢰성의 추가 계층을 제공하고 데이터 무결성을 보장합니다.
알림
Performance Replication 또는 Disaster Recovery Replication이 구성된 Vault Enterprise 배포 환경에서는 데이터가 기본 클러스터에서 보조 클러스터로 복제되는지 모니터링해야 합니다. 기본·보조 클러스터가 동기화를 잃고 있는지 감지하려면 두 클러스터의 마지막 WAL 인덱스를 비교하면 됩니다. 이들 사이의 차이를 감지하는 것이 중요합니다. 보조 클러스터가 기본 클러스터보다 크게 뒤처져 있고 기본 클러스터를 사용할 수 없게 되면 Vault에 대한 모든 요청이 오래된 데이터를 반환하기 때문입니다. 따라서 WAL에서 누락된 값이 발견되면 다음을 포함한 잠재적 원인을 조사하는 것이 필수적입니다.
- 기본·보조 클러스터 간 네트워크 문제: 네트워크 연결 문제는 클러스터 간 데이터 복제를 방해할 수 있습니다.
- 기본·보조 시스템의 리소스 제한: 기본·보조 클러스터가 리소스 제약을 겪고 있으면 데이터를 효과적으로 복제하는 능력에 영향을 줄 수 있습니다.
- 특정 키 문제: 때로는 Vault 내의 특정 키와 관련된 문제일 수 있습니다. 이런 문제를 식별하려면 Vault의 운영·스토리지 로그를 검토하면 동기화 격차를 일으키는 문제 키에 대한 자세한 정보를 얻을 수 있습니다.
자세한 내용은 Vault 복제 모니터링 튜토리얼을 참조하세요.
쓰기 과부하 보호 모니터링
메트릭:
vault.wal.write_controller.reject_fraction
배경:
적응형 쓰기 과부하 보호(adaptive write overload protection) 기능은 쓰기 부하가 높은 기간 동안 클러스터 안정성을 유지하는 데 도움을 줍니다. 쓰기 요청이 스토리지 백엔드가 처리할 수 있는 속도보다 빨리 도착하면 WAL이 빠르게 누적되어 스토리지 백엔드를 압도하고 전체 클러스터 성능을 저하시킬 수 있습니다. 쓰기 컨트롤러는 WAL 축적을 모니터링하고, 과부하 상태를 방지하기 위해 필요할 때 들어오는 쓰기 요청의 일부를 자동으로 거부합니다.
알림:
vault.wal.write_controller.reject_fraction 메트릭은 클러스터 안정성을 유지하기 위해 거부되는 쓰기 요청의 추정 비율을 나타내는 0과 1 사이의 게이지 값입니다.
지속적인 0이 아닌 값은 쓰기 부하 압박을 나타내므로 reject fraction 메트릭을 모니터링해 용량 문제를 감지하는 것을 권합니다. 부하 압박을 계속 다뤄야 한다면 워크로드 패턴을 조사하고, 스토리지 백엔드 성능을 확인하거나 인프라를 확장해야 할 수 있습니다. 자세한 내용은 적응형 과부하 보호 문서를 참조하세요.