관측 가능성 문제 해결

이 문서에서는 Google Distributed Cloud (GDC) 오프라인 어플라이언스에서 발생할 수 있는 배포 실패 및 운영 인시던트를 식별하는 방법을 설명하고, 로깅 및 모니터링 구성요소와 관련된 일반적인 문제를 해결하는 데 도움이 되도록 시스템에 표시되는 모든 알림에 대한 설명을 포함합니다.

관측 가능성 구성요소 식별

관측 가능성 플랫폼은 조직 인프라 클러스터의 obs-system 네임스페이스에 구성요소를 배포합니다.

인프라 운영자 (IO)의 Grafana 인스턴스는 조직 수준 측정항목에 대한 액세스를 제공하여 CPU 사용률, 스토리지 소비와 같은 인프라 구성요소를 모니터링합니다. 또한 운영 및 감사 로그에 대한 액세스 권한도 제공합니다. 또한 GDC 작동 가능 구성요소의 알림, 로그, 측정항목에 대한 액세스 권한을 제공합니다.

GDC 모니터링 및 로깅 스택은 관측 가능성 플랫폼의 일부로 오픈소스 솔루션을 사용합니다. 이러한 구성요소는 Kubernetes 포드, 베어 메탈 머신, 네트워크 스위치, 스토리지, 관리 서비스에서 로그와 측정항목을 수집합니다.

다음 표에는 관측 가능성 플랫폼을 통합하는 모든 구성요소에 대한 설명이 포함되어 있습니다.

구성요소 설명
Prometheus Prometheus는 측정항목을 수집 및 저장하고 알림을 평가하는 시계열 데이터베이스입니다. Prometheus는 장기 저장을 위해 조직 인프라 클러스터의 Cortex 인스턴스에 측정항목을 저장합니다. Prometheus는 라벨을 키-값 쌍으로 추가하고 Kubernetes 노드, 포드, 베어 메탈 머신, 네트워크 스위치, 스토리지 어플라이언스에서 측정항목을 수집합니다.
Alertmanager Alertmanager는 로그나 측정항목이 시스템 구성요소가 실패하거나 정상적으로 작동하지 않음을 나타낼 때 알림을 전송하는 사용자 정의 관리자 시스템입니다. Prometheus 알림 라우팅, 무음 처리, 집계를 관리합니다.
Loki Loki는 다양한 소스의 로그를 저장하고 집계하는 시계열 데이터베이스입니다. 효율적인 쿼리를 위해 로그를 색인화합니다.
Grafana Grafana는 Prometheus가 수집한 측정항목을 보고 해당 Loki 인스턴스에서 감사 및 작업 로그를 쿼리하는 사용자 인터페이스 (UI)를 제공합니다. UI를 사용하면 측정항목 및 알림의 대시보드를 시각화할 수 있습니다.
Fluent Bit Fluent Bit은 다양한 구성요소 또는 위치에서 로그를 가져와 Loki로 전송하는 프로세서입니다. 모든 클러스터의 모든 노드에서 실행됩니다.

배포 실패 식별

배포가 실행 중이고 정상 상태이면 구성요소가 READY 상태로 실행됩니다.

다음 단계를 따라 배포 실패를 식별하세요.

  1. 구성요소의 현재 상태를 확인합니다.

    kubectl get -n obs-system TYPE/COMPONENT

    다음을 바꿉니다.

    • TYPE: 구성요소 유형
    • COMPONENT: 구성요소 이름

    다음과 비슷한 출력이 표시됩니다.

    NAME       READY  AGE
COMPONENT  1/1    23h

    구성요소가 정상인 경우 출력의 READY 열에 N/N 값이 표시됩니다. READY 열에 값이 표시되지 않는다고 해서 반드시 실패를 나타내는 것은 아닙니다. 서비스에서 처리하는 데 시간이 더 필요할 수 있습니다.

  2. 각 구성요소의 포드를 확인합니다.

    kubectl get pods -n obs-system | awk 'NR==1 | /COMPONENT/'

    COMPONENT을 구성요소 이름으로 바꿉니다.

    다음과 비슷한 출력이 표시됩니다.

    NAME       READY  STATUS   RESTARTS  AGE
COMPONENT  1/1    Running  0         23h

    READY 열에 N/N 값이 표시되고, STATUS 열에 Running 값이 표시되고, RESTARTS 수가 2 값을 초과하지 않는지 확인합니다.

    다시 시작 횟수가 많으면 다음과 같은 증상이 나타납니다.

    • 포드가 실패하고 Kubernetes가 포드를 다시 시작합니다.
    • STATUS 열에는 CrashLoopBackoff 값이 표시됩니다.

    실패 상태를 해결하려면 포드의 로그를 확인하세요.

    포드가 PENDING 상태인 경우 이 상태는 다음 증상 중 하나 이상을 나타냅니다.

    • 포드가 필요한 컨테이너를 다운로드하기 위해 네트워크 액세스를 기다리고 있습니다.
    • 구성 문제로 인해 포드가 시작되지 않습니다. 예를 들어 포드에 필요한 Secret 값이 누락되었습니다.
    • Kubernetes 클러스터에 포드를 예약할 리소스가 부족합니다. 이는 클러스터에서 많은 애플리케이션이 실행되는 경우 발생합니다.

  3. PENDING 상태의 원인을 확인합니다.

    kubectl describe -n obs-system pod/POD_NAME

    POD_NAME을 PENDING 상태를 표시하는 포드의 이름으로 바꿉니다.

    출력에 포드에 대한 자세한 정보가 표시됩니다.

  4. 출력의 Events 섹션으로 이동하여 포드의 최근 이벤트를 나열하는 표와 PENDING 상태의 원인에 관한 요약을 확인합니다.

    다음 출력은 Grafana StatefulSet 객체의 샘플 Events 섹션을 보여줍니다.

    Events:
  Type    Reason            Age                From                    Message
  ----    ------            ----               ----                    -------
  Normal  SuccessfulCreate  13s (x3 over 12d)  statefulset-controller  create Pod grafana-0 in StatefulSet grafana successful

    포드 또는 다른 리소스에 장시간 이벤트가 없으면 다음 출력이 표시됩니다.

      Events:         <none>

관측 가능성 로깅 스택이 실행 중인지 확인

다음 단계를 따라 로깅 스택이 실행 중인지 확인합니다.

  1. 모든 Loki 인스턴스 또는 포드에 Istio 사이드카가 삽입되어 있는지 확인합니다. 이름이 anthos-audit-logs-forwarder-SUFFIX 및 anthos-log-forwarder-SUFFIX인 모든 Fluent Bit 포드에 Istio 사이드카가 삽입되어 있는지 확인합니다.

  2. 조직 인프라 클러스터에서 모든 Loki 인스턴스가 오류 없이 실행되고 있는지 확인합니다.

  3. anthos-audit-logs-forwarder 및 anthos-log-forwarder DaemonSet 객체의 상태를 확인하여 모든 인스턴스가 모든 노드에서 오류 없이 실행되는지 확인합니다.

  4. 모든 클러스터에서 지난 5분 동안 kube-apiserver-SUFFIX 컨테이너의 운영 로그와 Kubernetes API 서버의 감사 로그를 가져오는지 확인합니다. 이렇게 하려면 Grafana 인스턴스에서 다음 쿼리를 실행하세요.

    • 운영 로그: sum (count_over_time({service_name="apiserver"} [5m])) by (cluster, fluentbit_pod)
    • 감사 로그: sum (count_over_time({cluster=~".+"} [5m])) by (cluster, node)

    조직 인프라 클러스터의 모든 컨트롤 플레인 노드에 대해 0이 아닌 값을 가져와야 합니다.

관측 가능성 모니터링 스택이 실행 중인지 확인

다음 단계를 따라 모니터링 스택이 실행 중인지 확인합니다.

  1. Grafana 인스턴스가 조직 인프라 클러스터에서 실행되고 있는지 확인합니다. grafana-0 포드는 다음 네임스페이스에서 오류 없이 실행되어야 합니다.

    • obs-system
    • infra-obs-obs-system
    • platform-obs-obs-system

  2. 모든 모니터링 구성요소가 Istio 서비스 메시지에 있는지 확인합니다. 배포 실패 식별 섹션의 단계를 따릅니다. 다음 포드 각각의 READY 열에 모든 컨테이너가 준비된 것으로 표시되어야 합니다. 예를 들어 값이 3/3이면 세 개의 컨테이너 중 세 개가 준비되었음을 의미합니다. 또한 포드에 istio-proxy 컨테이너가 있어야 합니다. 포드가 이러한 조건을 충족하지 않으면 포드를 다시 시작합니다.

    포드 이름 준비된 컨테이너 수
    cortex- 2/2
    cortex-etcd-0 2/2
    cortex-proxy-server- 2/2
    cortex-tenant- 2/2
    meta-blackbox-exporter- 2/2
    meta-grafana-0 3/3
    meta-grafana-proxy-server- 2/2
    meta-prometheus-0 4/4
    cortex-alertmanager- 2/2
    cortex-compactor- 2/2
    cortex-distributor- 2/2
    cortex-etcd-0 2/2
    cortex-ingester- 2/2
    cortex-querier- 2/2
    cortex-query-frontend- 2/2
    cortex-query-scheduler- 2/2
    cortex-ruler- 2/2
    cortex-store-gateway- 2/2
    cortex-tenant- 2/2
    grafana-proxy-server- 2/2
    meta-blackbox-exporter- 2/2
    meta-grafana-0 3/3
    meta-grafana-proxy-server-* 2/2
    meta-prometheus-0 4/4

  3. Cortex가 오류 없이 실행되는지 확인합니다.

관측 가능성 로그 가져오기

다음 표에는 관측 가능성 플랫폼에서 배포하는 각 구성요소의 로그를 가져오기 위해 실행해야 하는 명령어가 포함되어 있습니다.

구성요소 로그 가져오기 명령어
grafana kubectl logs -n obs-system statefulset/grafana
anthos-prometheus-k8s kubectl logs -n obs-system statefulset/anthos-prometheus-k8s
alertmanager kubectl logs -n obs-system statefulset/alertmanager
ops-logs-loki-io kubectl logs -n obs-system statefulset/ops-logs-loki-io
ops-logs-loki-io-read kubectl logs -n obs-system statefulset/ops-logs-loki-io-read
ops-logs-loki-all kubectl logs -n obs-system statefulset/ops-logs-loki-all
ops-logs-loki-all-read kubectl logs -n obs-system statefulset/ops-logs-loki-all-read
audit-logs-loki-io kubectl logs -n obs-system statefulset/audit-logs-loki-io
audit-logs-loki-io-read kubectl logs -n obs-system statefulset/audit-logs-loki-io-read
audit-logs-loki-pa kubectl logs -n obs-system statefulset/audit-logs-loki-pa
audit-logs-loki-pa-read kubectl logs -n obs-system statefulset/audit-logs-loki-pa-read
audit-logs-loki-all kubectl logs -n obs-system statefulset/audit-logs-loki-all
audit-logs-loki-all-read kubectl logs -n obs-system statefulset/audit-logs-loki-all-read
anthos-log-forwarder kubectl logs -n obs-system daemonset/anthos-log-forwarder
anthos-audit-logs-forwarder kubectl logs -n obs-system daemonset/anthos-audit-logs-forwarder
oplogs-forwarder kubectl logs -n obs-system daemonset/oplogs-forwarder
logmon-operator kubectl logs -n obs-system deployment/logmon-operator

구성요소의 이전 인스턴스 로그를 보려면 각 명령어 끝에 -p 플래그를 추가합니다. -p 플래그를 추가하면 현재 실행 중인 인스턴스 대신 이전 실패한 인스턴스의 로그를 검토할 수 있습니다.

구성 보기

관측 가능성 스택은 Kubernetes API 커스텀 리소스를 사용하여 모니터링 및 로깅 파이프라인을 구성합니다.

LoggingPipeline 커스텀 리소스는 조직 인프라 클러스터에 배포되고 Loki 인스턴스를 구성합니다.

다음 명령어는 로깅 파이프라인에서 실행할 수 있는 작업을 보여줍니다.

  • 로깅 파이프라인 배포의 현재 구성을 확인합니다.

    kubectl get loggingpipeline -n obs-system default -o yaml

  • 로깅 파이프라인 배포의 구성을 변경합니다.

    kubectl edit loggingpipeline -n obs-system default

GDC는 logmon-operator라는 로깅 및 모니터링 연산자를 사용하여 Prometheus 및 Fluent Bit와 같은 관측 가능성 구성요소의 배포를 관리합니다. logmon-operator 구성요소의 API는 logmon 커스텀 리소스 정의입니다. logmon 커스텀 리소스 정의는 logmon-operator에 배포의 관측 가능성을 구성하는 방법을 알려줍니다. 이 맞춤 리소스 정의에는 측정항목을 저장할 볼륨, Alertmanager의 알림 규칙, 측정항목을 수집할 Prometheus 구성, 대시보드의 Grafana 구성의 속성이 포함됩니다.

다음 명령어는 logmon 커스텀 리소스 정의에서 실행할 수 있는 작업을 보여줍니다.

  • 관측 가능성 배포의 현재 구성을 확인합니다.

    kubectl get logmon -n obs-system logmon-default -o yaml

  • 관측 가능성 배포의 구성을 변경합니다.

    kubectl edit logmon -n obs-system logmon-default

명령어를 실행한 출력은 추가 구성을 위해 여러 Kubernetes ConfigMap 객체를 참조할 수 있습니다. 예를 들어 이름으로 logmon 커스텀 리소스 정의에서 참조되는 별도의 ConfigMap 객체에서 Alertmanager 규칙을 구성할 수 있습니다. gpc-alertmanager-config이라는 logmon 커스텀 리소스 정의를 통해 Alertmanager 구성을 변경하고 볼 수 있습니다.

Alertmanager 구성을 보려면 다음을 실행합니다.

kubectl get configmap -n obs-system gpc-alertmanager-config -o yaml

일반적인 문제

이 섹션에는 관측 가능성 플랫폼을 배포할 때 발생할 수 있는 일반적인 문제가 포함되어 있습니다.

Grafana에 액세스할 수 없음

기본적으로 Grafana는 Kubernetes 클러스터 외부의 머신에 노출되지 않습니다. 조직 인프라 클러스터 외부에서 Grafana 인터페이스에 일시적으로 액세스하려면 Service를 localhost로 포트 전달하면 됩니다. Service을 포트 전달하려면 다음을 실행합니다.

kubectl port-forward -n gpc-system service/grafana 33000\:3000

웹브라우저에서 http://localhost:33000로 이동하여 배포의 Grafana 대시보드를 확인합니다. 프로세스를 종료하려면 Control+C 키를 누릅니다.

Grafana가 느리게 실행됨

Grafana가 느리게 실행되는 경우 다음을 나타냅니다.

  • Prometheus 또는 Loki에 대한 쿼리가 과도한 데이터를 반환합니다.
  • 쿼리에서 단일 그래프에 표시하기에 적합하지 않은 데이터를 반환합니다.

Grafana 내에서 속도가 느린 문제를 해결하려면 맞춤 Grafana 대시보드의 쿼리를 확인하세요. 쿼리에서 단일 그래프에 표시하기에 적절한 것보다 많은 데이터를 반환하는 경우 대시보드 성능을 개선하기 위해 표시되는 데이터 양을 줄이는 것이 좋습니다.

Grafana 대시보드에 측정항목 또는 로그가 표시되지 않음

Grafana에 측정항목이나 로그가 표시되지 않는 경우 다음과 같은 이유가 있을 수 있습니다.

  • Grafana 데이터 소스가 올바르게 설정되지 않았습니다.
  • 시스템에 모니터링 또는 로깅 데이터 소스에 대한 연결 문제가 있습니다.
  • 시스템에서 측정항목이나 로그를 수집하지 않습니다.

로그와 측정항목을 보려면 다음 단계를 따르세요.

  1. Grafana 사용자 인터페이스에서 대시보드 설정을 클릭합니다.
  2. 데이터 소스를 선택합니다.
  3. 데이터 소스 페이지에 다음 소스가 표시되는지 확인합니다.
이름 조직 URL
Audit Logs All http://audit-logs-loki-io-read.obs-system.svc:3100
Operational Logs Root http://ops-logs-loki-io-read.obs-system.svc:3100
Operational Logs Org http://ops-logs-loki-all-read.obs-system.svc:3100
prometheus http://anthos-prometheus-k8s.obs-system.svc:9090

이러한 데이터 소스가 누락되면 관측 가능성 스택이 Grafana를 올바르게 구성하지 못한 것입니다.

데이터 소스를 올바르게 구성했지만 데이터가 표시되지 않으면 Prometheus 또는 Loki에 제공되는 측정항목 또는 로그를 수집하는 Service 객체에 문제가 있을 수 있습니다.

Prometheus는 측정항목을 수집할 때 풀 모델을 따라 주기적으로 Service 객체에 측정항목을 쿼리하고 찾은 값을 저장합니다. Prometheus가 측정항목 수집을 위해 Service 객체를 검색하려면 다음이 충족되어야 합니다.

  • Service 객체의 모든 포드에는 'monitoring.gke.io/scrape: "true"' 주석이 달려 있습니다.

  • Prometheus 측정항목 형식은 HTTP를 통해 포드 측정항목을 노출합니다. 기본적으로 Prometheus는 엔드포인트 http://POD_NAME:80/metrics에서 이러한 측정항목을 찾습니다. 필요한 경우 주석을 통해 포트, 엔드포인트, 스키마를 재정의할 수 있습니다.

Fluent Bit는 로그를 수집하며 Kubernetes 클러스터의 모든 노드에서 실행됩니다. Fluent Bit은 장기 저장을 위해 Loki로 로그를 전송합니다.

Grafana에 로그가 없으면 다음 해결 방법을 시도해 보세요.

  • Loki 인스턴스의 로그를 확인하여 오류 없이 실행되는지 확인합니다.

  • Loki 인스턴스가 제대로 실행되는데 로그가 표시되지 않으면 Fluent Bit의 로그를 확인하여 서비스가 예상대로 작동하는지 확인합니다. 로그를 가져오는 방법을 검토하려면 모니터링 가능성 로그 가져오기를 참고하세요.

Alertmanager에서 알림을 열지 않음

Alertmanager에서 알림을 열지 못하는 경우 다음 단계를 따르세요.

  1. gpc-system 네임스페이스 내의 configMap 객체에서 logmon: system_metrics 라벨이 있는지 확인합니다.
  2. configMap 데이터 섹션에 alertmanager.yml이라는 키가 포함되어 있는지 확인합니다. alertmanager.yml 키의 값은 유효한 Alertmanager 구성 파일에 포함된 알림 규칙이어야 합니다.

  3. gpc-system 네임스페이스에 있는 logmon-default이라는 logmon 커스텀 리소스 정의에 configMap 객체에 대한 참조가 포함되어 있는지 확인합니다. logmon-default 맞춤 리소스 정의에는 다음 예와 같이 configMap 객체의 이름이 포함되어야 합니다.

    apiVersion: addons.gke.io/v1
kind: Logmon
spec:
  system_metrics:
    outputs:
      default_prometheus:
        deployment:
          components:
            alertmanager:
              alertmanagerConfigurationConfigmaps:
                - alerts-config

    예의 alerts-config 값은 configMap 객체의 이름입니다.

Alertmanager가 구성된 알림 채널로 알림을 전송하지 않음

구성 오류로 인해 Alertmanager가 Grafana 인스턴스에서 알림을 생성하더라도 Slack과 같은 알림 채널로 구성된 외부 소프트웨어에서 알림을 수신하지 못할 수 있습니다.

외부 소프트웨어에서 알림을 받으려면 다음 단계를 따르세요.

  1. Alertmanager 구성 파일의 값이 올바르게 형식이 지정되었는지 확인합니다. Alertmanager가 알림을 트리거하면 외부 소프트웨어의 웹훅을 쿼리합니다.

  2. 외부 소프트웨어에 연결되는 웹훅 URL이 올바른지 확인합니다. URL이 올바른 경우 소프트웨어가 웹훅을 수락하도록 구성되어 있는지 확인하세요. 외부 서비스 API에 액세스하기 위해 API 키를 생성해야 할 수도 있고, 현재 API 키가 만료되어 새로고침해야 할 수도 있습니다.

  3. 외부 서비스가 GDC 오프라인 어플라이언스 배포 외부에 있는 경우 조직 인프라 클러스터에 이그레스 규칙이 구성되어 있는지 확인합니다. 이 구성을 사용하면 Alertmanager가 내부 Kubernetes 네트워크 외부의 서비스에 요청을 보낼 수 있습니다. 이그레스 규칙을 확인하지 않으면 Alertmanager가 외부 소프트웨어를 찾을 수 없습니다.

프로젝트 범위 워크로드의 측정항목을 볼 수 없음

다음 단계를 따라 해결 방법을 적용하고 워크로드에서 측정항목을 가져오세요.

  1. MonitoringTarget 커스텀 리소스의 상태가 Ready인지 확인합니다.
  2. 워크로드를 스크랩하려면 워크로드 포드 사양의 MonitoringTarget에 지정된 모든 타겟 정보를 선언해야 합니다. 예를 들어 포트 8080에서 측정항목을 사용할 수 있다고 선언하는 경우 워크로드 포드는 포트 8080이 열려 있다고 Kubernetes에 선언해야 합니다. 그렇지 않으면 Prometheus가 워크로드를 무시합니다.
  3. Prometheus는 여러 샤드를 실행하므로 모든 Prometheus 포드가 포드를 스크랩하지는 않습니다. 각 Prometheus 포드의 이름에서 샤드 번호를 확인할 수 있습니다. 예를 들어 primary-prometheus-shard0-replica0-0는 샤드 0에 속합니다. 각 Prometheus 샤드에서 스크래핑하려는 포드를 확인합니다.
    1. obs-system 네임스페이스에서 Prometheus의 primary-prometheus-shardSHARD_NUMBER-replica0-0 포트를 포트 전달하여 Prometheus UI에 액세스합니다. 새 샤드를 확인할 때마다 포드 이름의 SHARD_NUMBER을 증가하는 숫자로 바꿉니다.
    2. 웹브라우저에서 Prometheus UI로 이동하여 다음 단계를 따르세요.
      1. 상태 > 대상을 클릭합니다.
      2. 스크랩하려는 포드가 목록에 있는지 확인합니다. 그렇지 않으면 다음 샤드를 확인합니다. 확인할 샤드가 더 이상 없으면 Prometheus가 샤드를 검색할 수 있는 정보가 충분한지 다시 확인합니다.
    3. obs-system 네임스페이스에서 Prometheus 로그의 primary-prometheus-shardSHARD_NUMBER-replica0-0 포드에 오류가 있는지 확인합니다.
  4. obs-system 네임스페이스에서 cortex-tenant 포드 로그 오류를 확인합니다.

대시보드가 생성되지 않음

다음 단계를 따라 해결 방법을 적용하고 대시보드가 생성되지 않는 이유를 알아보세요.

  1. Dashboard 커스텀 리소스의 상태를 검토하여 오류가 있는지 확인합니다. 맞춤 리소스에는 Ready 상태가 있어야 합니다.
  2. 올바른 Grafana 인스턴스를 확인하고 있는지 확인합니다. 예를 들어 my-namespace라는 프로젝트 네임스페이스에 대시보드를 배포한 경우 대시보드는 https://GDCH_URL/my-namespace/grafana 엔드포인트의 Grafana 인스턴스에 있어야 합니다.
  3. gpc-system 네임스페이스에서 fleet-admin-controller의 로그를 확인합니다. 로그에서 대시보드 이름을 검색하여 대시보드와 관련된 오류를 찾습니다. 오류가 발견되면 configMap 객체의 JSON 파일 형식이 잘못된 것이므로 수정해야 합니다.
  4. PROJECT_NAME-obs-system 네임스페이스에서 Grafana 로그를 확인하여 오류가 있는지 확인합니다. 대시보드는 Grafana REST API를 쿼리하므로 대시보드를 만들려면 Grafana가 작동해야 합니다.

알림이 열리지 않음

다음 단계를 따라 해결 방법을 적용하고 알림이 열리지 않는 이유를 확인하세요.

  1. Cortex와 Loki가 모두 버킷 스토리지 모드인지 확인합니다. 백엔드가 버킷 스토리지를 지원하지 않으면 규칙이 작동하지 않습니다.
  2. MonitoringRule 및 LoggingRule 커스텀 리소스의 상태가 Ready인지 확인합니다.
  3. 다음 알림 조건을 확인하세요.
    • PromQL 및 LogQL 표현식: 사용 중인 모든 함수를 알림 규칙 만들기 문서와 비교하여 규칙이 원하는 대로 구성되어 있는지 확인합니다. 표현식이 true 또는 false 값을 반환하는지 확인합니다.
    • 기간: 커스텀 리소스의 for 필드는 조건이 참이어야 하는 기간을 정의합니다. interval 필드는 조건을 평가하는 빈도를 정의합니다. 이러한 필드의 값을 서로 비교하여 조건이 논리적인지 확인합니다.
  4. Grafana UI에서 알림 페이지를 사용하여 알림이 열려 있는지 확인합니다.
  5. Grafana에 알림이 열려 있다고 표시되면 알림 채널을 확인하고 Alertmanager가 알림을 생성하기 위해 알림 채널에 연락할 수 있는지 확인합니다.

예상 로그를 사용할 수 없음

구성요소의 운영 로그가 표시되지 않으면 다음 단계를 따르세요.

  1. 구성요소가 실행되고 로그를 생성하는지 확인합니다.
  2. 구성요소 로그를 기본 기능으로 수집해야 하는지 확인합니다. 그렇지 않은 경우 유효한 사양과 Ready 상태로 LoggingTarget 커스텀 리소스가 배포되어 있는지 확인합니다.

구성요소의 감사 로그가 표시되지 않으면 다음 단계를 따르세요.

  1. 구성요소가 파일에 로그를 쓰는 경우 파일이 /var/log/audit/SERVICE_NAME/NAMESPACE/ACCESS_LEVEL/audit.log 경로의 노드 파일 시스템에 실제로 있는지 확인합니다.
  2. 동일한 노드의 anthos-audit-logs-forwarder-SUFFIX 포드에 오류가 없는지 확인합니다.
  3. 구성요소가 syslog 엔드포인트를 사용하여 로그를 수신하는 경우 유효한 사양과 Ready 상태로 배포된 AuditLoggingTarget 커스텀 리소스가 있는지 확인합니다.

사전 정의된 알림 규칙 식별

이 섹션에는 시스템 장애를 알리기 위해 관측 가능성 구성요소에 있는 사전 정의된 알림 규칙에 관한 정보가 포함되어 있습니다.

Loki의 사전 정의된 알림 규칙

다음 표에는 감사 로깅 실패를 위해 Loki에 사전 설치된 알림 규칙이 나와 있습니다.

감사 로깅 실패를 위한 Loki의 사전 설치된 알림 규칙
이름 유형 설명
FluentBitAuditLoggingWriteFailure 심각 Fluent Bit이 지난 5분 동안 감사 로그를 전달하지 못했습니다.
LokiAuditLoggingWriteFailure 심각 Loki가 감사 로그를 백엔드 스토리지에 쓸 수 없습니다.

이러한 알림이 하나 이상 표시되면 시스템에서 하나 이상의 감사 기록을 손실한 것입니다.

Prometheus의 사전 정의된 알림 규칙

다음 표에는 Kubernetes 구성요소용 Prometheus에 사전 설치된 알림 규칙이 나와 있습니다.

Prometheus에 사전 설치된 알림 규칙
이름 유형 설명
KubeAPIDown 심각 Kube API가 Prometheus 대상 검색에서 15분 동안 사라졌습니다.
KubeClientErrors 경고 Kubernetes API 서버 클라이언트의 오류 비율이 15분 동안 0.01을 초과했습니다.
KubeClientErrors 심각 Kubernetes API 서버 클라이언트의 오류 비율이 15분 동안 0.1을 초과했습니다.
KubePodCrashLooping 경고 포드가 15분 이상 비정상 종료되는 루프 상태입니다.
KubePodNotReady 경고 포드가 15분 이상 준비되지 않은 상태입니다.
KubePersistentVolumeFillingUp 심각 클레임된 PersistentVolume 객체의 무료 바이트가 0.03 미만입니다.
KubePersistentVolumeFillingUp 경고 클레임된 PersistentVolume 객체의 무료 바이트가 0.15 미만입니다.
KubePersistentVolumeErrors 심각 영구 볼륨이 5분 동안 Failed 또는 Pending 단계에 있습니다.
KubeNodeNotReady 경고 노드가 15분 이상 준비되지 않았습니다.
KubeNodeCPUUsageHigh 심각 노드의 CPU 사용량이 80%를 초과합니다.
KubeNodeMemoryUsageHigh 심각 노드의 메모리 사용량이 80%를 초과합니다.
NodeFilesystemSpaceFillingUp 경고 노드의 파일 시스템 사용량이 60%를 초과합니다.
NodeFilesystemSpaceFillingUp 심각 노드의 파일 시스템 사용량이 85%를 초과합니다.
CertManagerCertExpirySoon 경고 인증서가 21일 후 만료됩니다.
CertManagerCertNotReady 심각 10분 후 트래픽을 처리하는 데 사용할 인증서가 준비되지 않았습니다.
CertManagerHittingRateLimits 심각 5분 동안 인증서를 생성하거나 갱신할 때 비율 제한에 도달했습니다.
DeploymentNotReady 심각 조직 인프라 클러스터의 배포가 15분 이상 준비되지 않은 상태입니다.
StatefulSetNotReady 심각 조직 인프라 클러스터의 StatefulSet 객체가 15분 이상 준비되지 않은 상태입니다.
AuditLogsForwarderDown 심각 anthos-audit-logs-forwarder DaemonSet이 15분 이상 다운되었습니다.
AuditLogsLokiDown 심각 audit-logs-loki 스테이트풀(Stateful) 세트가 15분 이상 준비되지 않은 상태입니다.