Incident Library
  • 원인
  • 구성 요소
  • 증상
  • 기여 요인
  • 사례

사례6건

6건 중 3~6번째

  1. 증상

    2023-11-01 10:15 에 Pingdom 이 Prometheus - live healthcheck 가 DOWN 이라며 PagerDuty 로 높은 우선순위 알림을 보냈다. 팀은 알림을 확인하고 Prometheus 서버 상태를 살폈다.

    원인
    구성 요소
    기여 요인
    –
    감지

    Pingdom 의 Prometheus - live healthcheck 가 DOWN 이 되면서 PagerDuty 높은 우선순위 알림이 울렸다. 몇 분 사이에 같은 알림이 세 번 울리자 팀은 장애를 선언했다.

    조치
    • Prometheus 가 재시작하지 않도록 readiness probe 타임아웃을 3초에서 6초로 늘렸다.
    후속 조치
    • 이런 실패를 더 일찍 찾아내도록 점검을 더 꼼꼼히 할 방법을 찾는다.
    • 데이터베이스로 들어가는 데이터 수집의 양이 너무 많거나 시간이 너무 오래 걸리는지 조사한다.
    • 일부 쿼리가 Prometheus 에 부담을 줘서 Prometheus 가 readiness probe 에 응답하지 못하는지 조사한다.
    • Prometheus 에 상태 검사를 보내는 다른 서비스가 재시작을 일으키는지 조사한다.
    • 정기 velero 백업이 EBS 읽기와 쓰기를 방해해 재시작을 일으키는지 조사한다.
  2. 증상

    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. 증상

    2023-07-25 14:05 PagerDuty 로 Pingdom 의 고우선순위 경보가 왔다. Prometheus - live 헬스 체크가 DOWN 이었다. 팀이 Prometheus 서버를 확인하니 규칙 평가 오류가 나 있었고 서버는 Exit code 137 로 종료돼 있었다.

    촉발

    네임스페이스와 Prometheus 규칙 수가 늘어 Prometheus 서버가 쓰는 메모리가 늘었고, 기존 인스턴스 크기로는 Prometheus 를 계속 띄울 수 없었다.

    원인
    구성 요소
    기여 요인
    감지

    14:05 Pingdom 이 Prometheus - live 헬스 체크가 DOWN 인 것을 감지해 PagerDuty 로 고우선순위 경보를 보냈다. 장애 선언은 15:21 에 했다.

    조치
    • 14:22 모니터링 노드를 드레인해 Prometheus 를 다른 모니터링 노드로 옮겼다.
    • 15:31 노드 인스턴스 크기를 CPU 와 메모리가 두 배인 r6i.4xlarge 로 바꿨다.
    • 15:50 Prometheus 컨테이너의 메모리 limit 을 100Gi 로 올렸다.
    • 16:18 Prometheus 컨테이너 limit 을 CPU 12코어, 메모리 110Gi 로 바꿨다.
    후속 조치
    • 노드 메모리 사용량을 감시하고, 파드 하나가 노드 메모리 대부분을 쓰는 상황을 잡아내는 경보를 추가한다. 이 일은 이슈 #4538 에서 다룬다.
  4. 증상

    팀은 2020년 9월 21일 18:27 에 처음 장애를 알아챘다. Cloud Platform 에서 돌아가는 서비스 일부에 사용자가 접속하지 못했다.

    촉발

    테스트 클러스터를 지우려고 삭제 스크립트를 실행했는데, kube 컨텍스트가 잘못 잡혀 있어 스크립트가 운영 클러스터 live-1 을 대상으로 돌았다.

    원인
    구성 요소
    기여 요인
    감지

    팀은 18:27 에 처음 장애를 알아챘고, 13분 뒤인 18:40 에 장애를 선언했다.

    조치
    • 기본 인그레스 컨트롤러를 먼저 되살리고, 인그레스 컨트롤러가 의존하는 external-dns 와 kiam 도 함께 되살렸다.
    • Route53 TXT 레코드의 잘못된 owner 값을 고쳐 external-dns 가 Formbuilder 레코드를 새 NLB 로 바꾸게 했다.
    • 남은 구성 요소는 대상을 지정한 apply 로 되살렸다.
    • apply 파이프라인을 돌려 환경 저장소에 있는 인증서, ServiceMonitor, Prometheus 규칙을 모두 다시 만들었다.
내 클러스터에도 있는지 확인하기

이 6건에서 가장 많이 나오는 구성 요소: Prometheus, 텔레메트리 에이전트. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.

원인별3

용량 한계4건

  1. IL-0042 OpenSearch 디스크가 가득 찬 동안 fluent-bit 가 로그를 처리하지 못해 Elasticsearch 와 OpenSearch 에 애플리케이션 로그가 들어오지 않았다.
  2. IL-0046 계획된 재시작 뒤 Prometheus 가 WAL 을 다 읽기 전에 startupProbe 에 걸려 재시작을 반복했고 지표가 빠졌다
  3. IL-0043 새 버전 fluent-bit에서 청크를 버리는 방식이 바뀌어 Kibana의 애플리케이션 로그에 긴 공백이 생겼다
  4. IL-0016 네임스페이스와 규칙이 늘어 live 클러스터의 Prometheus 가 메모리 부족으로 OOMKilled 되며 플랫폼 모니터링이 끊겼다

unknown1건

구성 요소
기여 요인
–
  1. IL-0045 live 클러스터의 Prometheus 가 readiness probe 실패로 여러 번 재시작해 Cloud Platform 모니터링이 끊기고 메트릭이 빠졌다

운영 실수1건

  1. IL-0089 테스트 클러스터 삭제 스크립트가 운영 클러스터 live-1 을 대상으로 실행돼 인그레스 컨트롤러, 모니터링, 인증서 구성 요소가 지워지고 사용자 서비스에 접속할 수 없게 됐다.