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

사례4건

4건 중 1~4번째

  1. 증상

    14:27 에 사용자가 #ask-cloud-platform 채널로 Kibana 에 13:45 부터 로그가 들어오지 않는다고 알려 왔다.

    촉발

    OpenSearch 의 디스크 공간이 바닥나 인덱스 쓰기가 막혔다.

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

    원문은 처음 감지된 시각을 12:10 으로 적었다. 이때 cp-live-app-logs 에서 ClusterIndexWritesBlocked 경보가 시작됐다. 팀이 실제로 문제를 알게 된 것은 14:27 에 사용자가 #ask-cloud-platform 채널로 Kibana 에 13:45 부터 로그가 들어오지 않는다고 알려 왔을 때였다.

    조치
    • 14:59 에 fluent-bit 컨테이너를 모두 rollout restart 했다. 로그가 잠깐 일부 흘렀지만 같은 오류가 다시 났다.
    • OpenSearch 디스크 공간을 8000 에서 12000 으로 늘렸다.
    • 근본 원인을 조사하는 동안 임시 조치로 fluent-bit 가 OpenSearch 로 로그를 보내지 않게 설정했다.
    후속 조치
    • OpenSearch 와 Elasticsearch 의 인덱스 날짜 문제를 살핀다.
    • Elasticsearch 와 OpenSearch 에 우선순위 높은 경보를 만든다.
    • OpenSearch 를 live 로깅에 다시 넣는다.
    • fluent-bit 의 “failed to flush chunk” 오류를 조사한다.
  2. 증상

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

    촉발

    계획된 변경으로 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 를 간단히 조사한다.
  3. 증상

    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다.
    • 로그가 로깅 클러스터로 실제로 전송되는지 확인하는 통합 테스트를 추가한다.
  4. 증상

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

원인별1