사례3건

3건 중 1~3번째

1. IL-0110 Grafana Agent 파드가 메모리를 많이 쓰던 노드에 Hangfire 파드가 함께 올라가 시스템 OOM 으로 CrashLoopBackOff 를 반복했고, 노드가 응답을 멈추고 NotReady 가 됐다.

   DFDS2024

   증상

   2024-03-13 10:01 UTC 에 쿠버네티스 노드 하나가 NotReady 상태가 됐다. 그때 노드에 잡힌 requests 는 CPU 78%, 메모리 82% 였다. 10:03 에 Slack 으로 알림이 왔고, 10:05 에 알림을 보고 조사를 시작했다.

   노드 NotReady컨테이너 재시작 반복OOMKilled모니터링 중단

   촉발

   Hangfire 로 작업을 실행하는 개발 컨테이너가 Grafana Agent 가 메모리를 많이 쓰고 있던 노드에 배치됐고, 작업이 OOM 으로 실패하며 CrashLoopBackOff 를 반복했다.

   원인

   용량 한계

   구성 요소

   텔레메트리 에이전트컨테이너 메모리 한도애플리케이션 데이터베이스

   기여 요인

   과도한 영향 범위리소스 요청과 한도 미설정수동 조치 악화모니터링 사각지대

   감지

   10:03 UTC 에 Slack 으로 알림이 왔고, 10:05 에 알림을 확인하고 조사를 시작했다. 두 번째 노드는 15:03 에 Slack 알림이 왔고 15:09 에 확인했다. 탐지까지 걸린 시간은 4분이었다.

   조치

   • 10:22 에 EC2 인스턴스를 비정상으로 표시해 새 노드를 띄웠다.
   • 10:30 에 NotReady 노드를 cordon 하고 강제로 drain 했고, 10:36 에 그 EC2 인스턴스를 종료했다.
   • 13:02 에 네임스페이스에서 LimitRange 를 지우고 Grafana Agent 파드를 재시작했다.
   • 14시대에 문제의 개발 컨테이너를 0개로 줄였고, 몇 분 뒤 EC2 네트워크 트래픽이 정상으로 돌아왔다.
   • 두 번째 NotReady 뒤 15:15 에 개발 컨테이너를 다시 0개로 줄였고, 15:18 에 새 노드가 추가됐다.
   • 15:19 에 개발 컨테이너를 맡은 팀에 메일을 보냈고, 15:52 에 그 팀이 문제를 확인하고 수정 중이라고 답했다.

   후속 조치

   • grafana-agent 를 모니터링 노드 그룹으로 옮긴다.
   • 클러스터 전체 대역폭이 정해 둔 기준에 닿으면 알림을 보낸다.
   • grafana-agent Helm 차트에 메모리 한도를 걸 수 있는지 조사한다.
   • grafana-agent 의 메모리 사용량을 조사한다.
   • grafana-agent 에 PVC 를 써야 하는지 Grafana 지원팀에 묻는다.
   • 보존 기간을 제한한 채 노드 로그를 Loki 로 보내는 방안을 검토한다.
   • 쿠버네티스 노드 문제를 조사할 때 확인할 자주 쓰는 지표와 로그 쿼리를 위키 페이지로 만든다.

   교훈

   포스트모템에서 나온 후속 조치를 끝까지 챙겨야 한다. CloudWatch 에서 어떤 지표가 쓸모 있는지가 팀에 제대로 공유되지 않아 진단과 조사가 어려웠다.

   사례 보기
2. IL-0043 새 버전 fluent-bit에서 청크를 버리는 방식이 바뀌어 Kibana의 애플리케이션 로그에 긴 공백이 생겼다

   UK Ministry of Justice2023

   증상

   2023년 8월 4일 09:14에 사용자들이 Kibana 로그에 긴 공백이 있다고 #ask-cloud-platform 채널에 알렸다.

   모니터링 중단

   촉발

   새 버전 fluent-bit에서 청크를 버리는 방식이 바뀌었다.

   원인

   용량 한계

   구성 요소

   텔레메트리 에이전트

   기여 요인

   한계 경보 부재모니터링 사각지대

   감지

   사용자들이 #ask-cloud-platform 채널에 알려 와서 알았다. 처음 알려진 시각은 2023년 8월 4일 09:14이고, 장애 선언은 10:09였다.

   조치

   • 메모리 버퍼가 넘칠 때 파일 시스템에 쓰도록 하는 수정을 넣어 Live 환경에 배포했다.
   • 로그를 더 작은 청크로 나눠 내보내도록 바꿨다.

   후속 조치

   • 로깅 클러스터에서 나오는 알림을 #lower-priority-alerts 채널로 보낸다. 이슈 번호는 #4704다.
   • 로그가 로깅 클러스터로 실제로 전송되는지 확인하는 통합 테스트를 추가한다.

   사례 보기
3. IL-0041 fluent-bit 이 오류 없이 멈춰 운영 노드 한 대의 애플리케이션 로그가 Elasticsearch 로 전혀 가지 않았다.

   PrometheusKube2020

   증상

   화요일 아침 개발자가 운영 환경 로그 일부가 빠져 있다고 알려 왔다. 이상하게도 빠진 로그는 노드 한 대에서 나온 것뿐이었다.

   모니터링 중단

   원인

   소프트웨어 결함

   구성 요소

   텔레메트리 에이전트Elasticsearch 와 OpenSearch

   기여 요인

   모니터링 사각지대미패치 알려진 버그

   감지

   운영 환경 로그 일부가 빠져 있다는 개발자의 메시지로 알았다. fluent-bit 의 Prometheus 지표는 오류를 보이지 않고 값만 멈춰 있어서 모니터링은 이 상황을 잡지 못했다. 지표가 늘지 않는 것도 이슈 #1935 로 보고된 다른 버그였다.

   조치

   • Elasticsearch 스레드 큐 오류를 보고 Elasticsearch 가상 머신에 CPU 를 늘렸다. 오류는 사라졌지만 로그 누락의 원인은 아니었다.
   • 노드 어피니티로 Fluentd 를 놓고 안티 어피니티로 fluent-bit 을 빼는 방식으로, 노드 하나씩 Fluentd 를 배포했다.
   • 오래된 로그가 한꺼번에 밀려 버퍼가 넘치지 않도록 Fluentd 의 flush_thread_count 를 1로 줄이고 flush_interval 을 5초로 늘렸다.
   • Fluentd 의 Position DB 기능을 켜서 이미 보낸 데이터를 건너뛰게 했다.

   후속 조치

   • Fluentd 의 Prometheus 연동으로 모니터링 패키지를 만든다. 5분 동안 보낸 바이트 비율에 낮과 밤 기준을 따로 두는 알림이나, 로그를 계속 남기고 Elasticsearch 에 들어왔는지 확인하는 블랙박스 점검을 적용한다.

   교훈

   오픈소스 소프트웨어가 어떻게 망가질지는 미리 알 수 없고, 때로는 다른 도구로 빨리 갈아탈 수 있어야 한다. 로그 전송 에이전트는 오류 지표만으로 감시할 수 없다. 이번처럼 지표가 오류 없이 멈추면 아무것도 잡히지 않는다. fluentbit_output_proc_bytes_total 의 5분 비율처럼 전송량에 알림을 걸 수 있다. 트래픽은 밤에 줄고 낮에 늘어 기준값 하나로는 맞지 않으므로, 낮과 밤 기준을 따로 둔다. 테스트 로그를 계속 남기고 Elasticsearch 에 들어왔는지 확인하는 블랙박스 점검도 방법이다. 다만 이런 알림이 울려도 그 자리에서 할 수 있는 조치가 마땅치 않다.

   사례 보기

원인별2