계획된 재시작 뒤 Prometheus 가 WAL 을 다 읽기 전에 startupProbe 에 걸려 재시작을 반복했고 지표가 빠졌다

증상

2024-04-15 12:32 에 계획된 Prometheus 변경을 적용한 뒤 Prometheus 를 쓸 수 없게 되었다. 팀은 prometheus 파드가 여러 번 재시작한 것을 보았다. 그동안 Cloud Platform 에는 모니터링이 없었고 지표가 빠졌다.

12:52 에 팀은 WAL 을 다시 읽는 도중에 재시작이 일어나 다시 읽기가 끝나지 못한다는 것을 알아냈다. WAL 은 Prometheus 가 디스크에 쓰는 선행 기록 로그이고, Prometheus 는 시작할 때 이것을 다시 읽는다. 12:57 에 계획된 변경을 되돌려 원인 후보에서 빼려 했지만 소용없었다. 13:46 에 로그를 살펴 startupProbe 실패 이벤트를 확인했다.

증상 ? 모니터링 중단프로브 실패

원인

촉발

계획된 변경으로 Prometheus 를 재시작했는데 그때 WAL 수가 평소보다 많아, WAL 다시 읽기가 startupProbe 기본 허용 시간인 15분 안에 끝나지 않았다.

감지

계획된 Prometheus 변경 뒤 팀이 prometheus 파드가 여러 번 재시작한 것을 보고 알았다. 처음 감지한 시각은 2024-04-15 12:32 였다.

조치

• startupProbe 허용 시간을 기본값 15분에서 30분으로 늘려 WAL 다시 읽기가 끝날 때까지 기다리게 했다.

후속 조치

• 팀은 계획된 Prometheus 재시작을 WAL 수가 적을 때 해서 재시작 시간을 줄이는 방안을 논의했다. 미확인
• Prometheus 의 기본 CPU 와 메모리 요청값을 최대 사용량에 맞춰 설정했다. 완료
• 운영 환경의 WAL 수를 재현하는 테스트 환경을 만든다. 미확인
• memory-snapshot-on-shutdown 과 auto-gomaxprocs 기능 플래그를 검토한다. 미확인
• WAL 파일을 다른 위치의 원격 저장소에 두는 방법을 검토한다. 미확인
• 운영과 같은 구성의 블루그린 Prometheus 를 만들어 운영에 적용하기 전에 변경을 시험하는 방안을 알아본다. 미확인
• Amazon Managed Prometheus 를 간단히 조사한다. 미확인

교훈

–

출처

• https://runbooks.cloud-platform.service.justice.gov.uk/incidents/2024-04-15-prometheus.html · runbook

관련 사례

• IL-0044 kube-prometheus-stack 업그레이드 뒤 Prometheus 가 WAL 재생 중 메모리를 50Gi 넘게 써서 시작할 때마다 OOMKilled 로 죽었다Saifeddine Rajhi · 2024

  같은 원인 · 공통 Prometheus

• IL-0016 네임스페이스와 규칙이 늘어 live 클러스터의 Prometheus 가 메모리 부족으로 OOMKilled 되며 플랫폼 모니터링이 끊겼다UK Ministry of Justice · 2023

  같은 원인 · 공통 Prometheus

• IL-0028 쿠버네티스에서 Temporal History 파드가 CPU 사용률이 60% 아래인데도 CPU 스로틀링을 받아 요청 지연이 불안정했다Temporal · 2023

  같은 원인 · 공통 Prometheus

• IL-0070 dask-gateway로 워커를 대량으로 띄우자 노드가 1분 만에 100대 늘었고, Prometheus가 메모리를 거의 다 쓰던 코어 노드에서 hub 파드를 비롯한 중요한 파드들이 축출되거나 재시작됐다2i2c · 2023

  같은 원인 · 공통 Prometheus

• IL-0176 시계열 급증으로 호스트 메모리가 바닥나자 oom_score_adj 999 를 받은 Prometheus 컨테이너가 커널 OOM Killer 에게 먼저 죽어 CrashLoopBackOff 에 빠졌다.LINE · 2020

  같은 원인 · 공통 Prometheus