구성 동기화 모니터링

이 페이지에서는 구성 동기화 리소스를 모니터링하는 방법을 설명합니다.

RootSync 및 RepoSync API를 사용 설정하면, 구성 동기화는 OpenCensus를 사용하여 측정항목을 만들어 기록하고, OpenTelemetry를 만들어 측정항목을 PrometheusCloud Monitoring에 내보냅니다. 또한 OpenTelemety를 사용하여 측정항목을 커스텀 모니터링 시스템으로 내보낼 수 있습니다. 이 프로세스는 세 가지 리소스 모니터링 방법을 제공합니다.

  1. Cloud Monitoring
  2. 커스텀 모니터링 시스템
  3. Prometheus

RootSync 및 RepoSync API를 사용 설정하지 않으면 Prometheus로 리소스 모니터링만 가능합니다.

사용 가능한 OpenTelemetry 측정항목

RootSync 및 RepoSync API가 사용 설정되면 구성 동기화 및 리소스 그룹 컨트롤러가 다음 측정항목을 수집하여 OpenTelemetry에서 사용할 수 있도록 합니다. 태그 열에는 각 측정항목에 적용 가능한 모든 태그가 표시됩니다. 태그가 있는 측정항목은 태그 값의 각 조합에 대해 하나씩 여러 측정을 나타냅니다.

구성 동기화 측정항목

다음 측정항목은 Anthos Config Management 버전 1.10.1 이상에서 사용할 수 있습니다.

이름 유형 태그 설명
api_duration_seconds 분포 operation, status API 서버 호출의 지연 시간 분포
apply_duration_seconds 분포 status 적용자 리소스 동기화 이벤트의 지연 시간 분포
apply_operations_total 개수 operation, status 신뢰 소스에 리소스를 동기화하기 위해 수행된 총 작업 수
declared_resources 최종 값 reconciler Git에서 파싱된 선언된 리소스 수
internal_errors_total 개수 reconciler, source 구성 동기화로 트리거된 총 내부 오류 수
last_sync_timestamp 최종 값 reconciler Git에서의 최근 동기화의 타임스탬프
parser_duration_seconds 분포 조정자, 상태, 트리거, 소스 parse-apply-watch 루프의 지연 시간 분포입니다.
pipeline_error_observed 최종 값 name, reconciler, component RootSync 및 RepoSync 커스텀 리소스의 상태입니다. 값 1은 실패를 나타냅니다.
reconcile_duration_seconds 분포 status 조정자 관리자가 처리한 조정 이벤트의 지연 시간 분포입니다.
reconciler_errors 최종 값 조정자, 구성요소 RootSync 및 RepoSync 조정자의 오류 수
remediate_duration_seconds 분포 status 교정자 조정 이벤트의 지연 시간 분포
resource_conflicts_total 개수 reconciler 캐시된 리소스와 클러스터 리소스 사이의 불일치로부터 발생한 총 리소스 충돌 수
resource_fights_total 개수 reconciler 너무 자주 동기화되고 있는 리소스의 총 개수입니다. 0보다 큰 결과는 문제를 나타냅니다. 자세한 내용은 KNV2005: ResourceFightWarning을 참조하세요.
rendering_count_total 개수 reconciler 리소스에 대해 Kustomize 또는 Helm 차트 렌더링이 사용된 동기화 실행 횟수입니다.
skip_rendering_count_total 개수 reconciler 리소스에 대해 Kustomize 또는 Helm 차트 렌더링이 사용되지 않은 동기화 실행 횟수입니다.
resource_override_count_total 개수 조정자, 컨테이너, 리소스 리소스 패치에 지정된 리소스 재정의 수
git_sync_depth_override_count_total 개수 - spec.override.gitSyncDepth 재정의가 설정된 Root/RepoSync 객체 수입니다. Git 깊이를 사용하면 큰 저장소에서 동기화할 때 성능을 높일 수 있습니다.
no_ssl_verify_count_total 개수 - .spec.git.noSSLVerify 재정의가 설정된 Root/RepoSync 객체 수입니다.

리소스 그룹 컨트롤러 측정항목

리소스 그룹 컨트롤러는 관리형 리소스를 추적하고 개별 리소스가 준비 또는 조정되었는지 확인하는 구성 동기화의 구성요소입니다. 다음 측정항목은 Anthos Config Management 버전 1.10 이상에서 사용할 수 있습니다.

이름 유형 태그 설명
reconcile_duration_seconds 분포 stallreason ResourceGroup CR을 조정하는 데 걸린 시간의 분포
resource_group_total 최종 값 ResourceGroup CR의 현재 개수
resource_count_total 합계 클러스터의 모든 ResourceGroup CR에서 추적하는 총 리소스 수
resource_count 최종 값 resourcegroup ResourceGroup으로 추적된 총 리소스 수
ready_resource_count_total 합계 클러스터의 모든 ResourceGroup CR에서 준비된 총 리소스 수
ready_resource_count 최종 값 resourcegroup ResourceGroup의 준비된 총 리소스 수
resource_ns_count 최종 값 resourcegorup ResourceGroup의 리소스에 사용된 네임스페이스의 수
cluster_scoped_resource_count 최종 값 resourcegroup ResourceGroup의 클러스터 범위 지정된 리소스 수
crd_count 최종 값 resourcegroup ResourceGroup의 CRD 수
kcc_resource_count_total 합계 클러스터에 있는 모든 ResourceGroup CR에 대한 Config Connector 리소스 총 수
kcc_resource_count 게이지 resourcegroup ResourceGroup의 총 KCC 리소스 수
pipeline_error_observed 최종 값 name, reconciler, component RootSync 및 RepoSync 커스텀 리소스의 상태입니다. 값 1은 실패를 나타냅니다.

구성 동기화 측정항목 태그

측정항목 태그는 측정항목 데이터를 집계하는 데 사용될 수 있습니다. Monitoring 콘솔의 그룹화 기준 드롭다운 목록에서 선택할 수 있습니다.

커스텀 태그

위의 표 태그 열에 있는 각 메트릭에 대해 커스텀 태그가 나열됩니다.

이름 설명
operation 만들기, 패치, 업데이트, 삭제 수행된 작업 유형
status 성공, 오류 작업 실행 상태
reconciler rootsync, reposync 조정자 유형
source 파서, 차이, 조정자 내부 오류의 소스
trigger 재시도, watchUpdate, managementConflict, 다시 동기화, 다시 가져오기 조정 이벤트 트리거
name 조정자 이름 조정자 이름
component 파싱, 소스, 동기화, 렌더링, 준비 현재 조정 중인 구성요소/단계 이름
container 조정자, git-sync 컨테이너 이름
resource cpu, 메모리 리소스 유형

리소스 태그

구성 동기화 커스텀 모니터링 측정항목은 다음 태그와 함께 제공되는 K8s_Pod 리소스 유형을 사용합니다.

이름 설명
project 프로젝트 ID
cluster_name 클러스터 이름
location 클러스터의 위치/영역
namespace_name 측정항목을 내보낸 네임스페이스의 이름
pod_name 측정항목을 내보낸 포드의 이름

pipeline_error_observed 측정항목 이해

pipeline_error_observed 측정항목은 동기화되지 않았거나 원하는 상태로 조정되지 않은 리소스를 포함하는 RepoSync 또는 RootSync CR을 빠르게 식별할 수 있게 해주는 측정항목입니다. 이 측정항목은 Anthos Config Management 버전 1.10 이상에서 사용할 수 있습니다.

  • RootSync 또는 RepoSync의 동기화 성공에 대해 모든 구성요소(rendering, source, sync, readiness)를 포함하는 측정항목은 값 0으로 관측됩니다.

    값이 0으로 관측된 모든 구성요소가 있는 pipeline_error_observed 측정항목의 스크린샷

  • 최신 커밋으로 자동 렌더링이 실패하면 구성요소가 rendering인 측정항목이 값 1로 관측됩니다.

  • 최신 커밋을 체크아웃할 때 오류가 발생하거나 최신 커밋에 잘못된 구성이 포함된 경우 구성요소 source가 포함된 측정항목이 값 1로 관측됩니다.

  • 어떤 리소스가 클러스터에 적용되지 않으면 구성요소 sync가 포함된 측정항목이 값 1로 관측됩니다.

  • 리소스가 적용되었지만 원하는 상태에 도달하지 못하면 readiness 구성요소가 있는 측정항목이 값 1로 관측됩니다. 예를 들어 배포가 클러스터에 적용되지만 해당 포드가 성공적으로 생성되지 않습니다.

Cloud Monitoring으로 리소스 모니터링

구성 동기화가 기본 서비스 계정이 있는 Google Cloud 환경 내에서 실행되는 경우 구성 동기화가 측정항목을 Cloud Monitoring으로 자동으로 내보냅니다.

워크로드 아이덴티티가 사용 설정되어 있으면 다음 단계를 완료하세요.

  1. 네임스페이스 config-management-monitoring의 Kubernetes ServiceAccount default를 측정항목 작성자 역할이 있는 Google 서비스 계정에 바인딩합니다.

    gcloud iam service-accounts add-iam-policy-binding \
        --role roles/iam.workloadIdentityUser \
        --member "serviceAccount:PROJECT_ID.svc.id.goog[config-management-monitoring/default]" \
        GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
    

    다음을 바꿉니다.

    • PROJECT_ID: 프로젝트 ID
    • GSA_NAME: 측정항목 작성자 역할이 있는 Google 서비스 계정

    이 작업에는 프로젝트에 대한 iam.serviceAccounts.setIamPolicy 권한이 필요합니다.

  2. Google 서비스 계정의 이메일 주소를 사용하여 Kubernetes ServiceAccount에 주석을 추가하세요.

    kubectl annotate serviceaccount \
        --namespace config-management-monitoring \
        default \
        iam.gke.io/gcp-service-account=GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
    

이러한 측정항목을 확인하는 방법에 대한 예시는 다음 디버깅 절차 예시 섹션 및 Cloud Monitoring의 OpenCensus 측정항목 문서를 참조하세요.

Cloud Monitoring 디버깅 절차 예시

다음 Cloud Monitoring 예시는 RootSync 및 RepoSync API를 사용할 때 구성 동기화와 관련된 문제를 검색하고 진단하기 위해 OpenCensus 측정항목을 사용하기 위한 몇 가지 패턴을 보여줍니다.

측정항목 형식

Cloud Monitoring에서 측정항목은 다음 형식을 갖습니다. custom.googleapis.com/opencensus/config_sync/METRIC.

이 측정항목 이름은 다음 구성요소로 구성됩니다.

  • custom.googleapis.com: 모든 커스텀 측정항목에 이 프리픽스가 포함됩니다.
  • opencensus: 이 프리픽스는 구성 동기화에 OpenCensus 라이브러리가 사용되기 때문에 추가됩니다.
  • config_sync/: 구성 동기화가 Cloud Monitoring에 내보내는 측정항목에 이 프리픽스가 포함됩니다.
  • METRIC: 쿼리하려는 측정항목의 이름입니다.

조정자로 측정항목 쿼리

RootSync 및 RepoSync 객체는 클러스터에서 구성 동기화의 작동 방법에 대한 유용한 정보를 제공하는 고급 측정항목으로 계측됩니다. 거의 모든 측정항목에 조정자 이름이 태그로 지정되므로, 오류가 발생했는지 확인하고 이에 대한 알림을 Cloud Monitoring에서 설정할 수 있습니다.

조정자는 배포로 배포되는 pod입니다. Git 저장소의 매니페스트를 클러스터에 동기화합니다. RootSync 객체를 만들 때 구성 동기화는 root-reconciler라는 조정자를 만듭니다. RepoSync 객체를 만들 때 구성 동기화는 ns-reconciler-NAMESPACE라는 조정자를 만듭니다. 여기서 NAMESPACE는 RepoSync 객체를 만든 네임스페이스입니다.

다음 다이어그램은 조정자 pod의 작동 방식을 보여줍니다.

조정자 흐름

예를 들어 Cloud Monitoring을 사용할 때 조정자 이름으로 필터링하려면 다음 태스크를 완료합니다.

  1. Google Cloud Console에서 Monitoring으로 이동합니다.

    모니터링으로 이동

  2. Monitoring 탐색 창에서 측정항목 탐색기를 클릭합니다.

  3. 측정항목 선택 드롭다운 목록에서 custom.googleapis.com/opencensus/config_sync/reconciler_errors를 추가합니다.

  4. 필터 드롭다운 목록에서 root_reconciler를 선택합니다. 필터 필드 상자가 나타납니다.

  5. 필터 필드 상자의 첫 번째 필드에서 =을 선택하고 두 번째 필드에서 root-reconciler를 선택합니다.

  6. 적용을 클릭합니다.

이제 RootSync 객체에 대한 측정항목을 확인할 수 있습니다.

특정 데이터 유형으로 필터링하는 방법에 대한 상세 설명은 데이터 필터링을 참조하세요.

구성요소 및 상태별 구성 동기화 작업 쿼리

RootSync 및 RepoSync API를 사용 설정한 경우 Git 저장소에서 가져오기 및 소싱과 클러스터로의 동기화는 조정자에 의해 처리됩니다. reconciler_errors 측정항목에 구성요소별로 라벨이 지정되므로 오류가 발생한 위치를 확인할 수 있습니다.

예를 들어 Cloud Monitoring을 사용할 때 구성요소로 필터링하려면 다음 태스크를 완료합니다.

  1. Google Cloud Console에서 Monitoring으로 이동합니다.

    모니터링으로 이동

  2. Monitoring 탐색 창에서 측정항목 탐색기를 클릭합니다.

  3. 측정항목 선택 드롭다운 목록에서 custom.googleapis.com/opencensus/config_sync/reconciler_errors를 추가합니다.

  4. 필터 드롭다운 목록에서 구성요소를 선택합니다. 필터 필드 상자가 나타납니다.

  5. 필터 필드 상자의 첫 번째 필드에서 =을 선택하고 두 번째 필드에서 source를 선택합니다.

  6. 적용을 클릭합니다.

이제 조정자에 대해 Git 저장소에서 소싱할 때 발생한 오류를 확인할 수 있습니다.

다음 측정항목을 쿼리하고 status 태그로 필터링하여 소스 및 동기화 프로세스 자체에 대해 측정항목을 확인할 수도 있습니다.

custom.googleapis.com/opencensus/config_sync/parser_duration_seconds
custom.googleapis.com/opencensus/config_sync/apply_duration_seconds
custom.googleapis.com/opencensus/config_sync/remediate_duration_seconds

커스텀 OpenTelemetry 내보내기 구성

측정항목을 다른 모니터링 시스템으로 전송하려면 OpenTelemetry 구성을 수정할 수 있습니다. 지원되는 모니터링 시스템 목록은 OpenTelemetry Collector 내보내기 도구OpenTelemetry Collector-Contrib 내보내기 도구를 참조하세요.

OpenTelemetry 모니터링 리소스는 별도의 config-management-monitoring 네임스페이스에서 관리됩니다. 구성 동기화에 사용하도록 커스텀 OpenTelemetry를 구성하려면 해당 config-management-monitoring 네임스페이스에서 otel-collector-custom 이름으로 ConfigMap을 만들어야 합니다. ConfigMap은 otel-collector-config.yaml 키를 포함해야 하고, 값은 커스텀 OpenTelemetry Collector 구성의 파일 콘텐츠여야 합니다. 구성 옵션에 대한 상세 설명은 OpenTelemetry Collector 구성 문서를 참조하세요.

다음 ConfigMap은 커스텀 로깅 내보내기 도구를 사용한 ConfigMap 예시입니다.

# otel-collector-custom-cm.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: otel-collector-custom
  namespace: config-management-monitoring
  labels:
    app: opentelemetry
    component: otel-collector
data:
  otel-collector-config.yaml: |
    receivers:
      opencensus:
    exporters:
      logging:
        logLevel: debug
    processors:
      batch:
    extensions:
      health_check:
    service:
      extensions: [health_check]
      pipelines:
        metrics:
          receivers: [opencensus]
          processors: [batch]
          exporters: [logging]

모든 커스텀 구성은 opencensus 수신기 및 metrics 파이프라인을 정의해야 합니다. 나머지 필드는 선택적이고 구성 가능하지만, 예시와 같이 batch 프로세서 및 상태 확인 확장 프로그램을 포함하는 것이 좋습니다.

ConfigMap을 만든 후 kubectl을 사용하여 리소스를 만듭니다.

kubectl apply -f otel-collector-custom-cm.yaml

OpenTelemetry Collector 배포는 이 ConfigMap을 선택하고 자동으로 재시작되어 커스텀 구성을 적용합니다.

Prometheus로 리소스 모니터링

구성 동기화는 Prometheus를 사용하여 프로세스와 관련된 측정항목을 수집하고 표시합니다.

Prometheus에서 커스텀 측정항목을 가져오도록 Cloud Monitoring을 구성할 수도 있습니다. 그러면 Prometheus와 Monitoring 모두에서 커스텀 측정항목을 확인할 수 있습니다. 자세한 내용은 Prometheus 사용을 참조하세요.

측정항목 스크래핑

모든 Prometheus 측정항목을 포트 8675에서 스크랩할 수 있습니다. 측정항목을 스크랩하기 전에 다음 두 가지 방법 중 하나로 Prometheus용 클러스터를 구성해야 합니다.

  • Prometheus 문서를 따라 스크랩용 클러스터를 구성합니다. 또는

  • Prometheus Operator를 다음 매니페스트와 함께 사용합니다. 그러면 모든 Anthos Config Management 측정항목이 10초마다 스크랩됩니다.

    1. 매니페스트 파일을 저장할 임시 디렉터리를 만듭니다.

      mkdir acm-monitor
      cd acm-monitor
      
    2. curl 명령어를 사용하여 CoreOS 저장소에서 Prometheus Operator 매니페스트를 다운로드합니다.

      curl -o bundle.yaml https://raw.githubusercontent.com/coreos/prometheus-operator/master/bundle.yaml
      

      이 매니페스트는 권장되지 않는 default 네임스페이스를 사용하도록 구성됩니다. 다음 단계에서는 대신 monitoring 네임스페이스를 사용하도록 구성을 수정합니다. 다른 네임스페이스를 사용하려면 네임스페이스를 나머지 단계에서 표시되는 monitoring으로 대체합니다.

    3. 파일을 만들어 위 번들에 있는 ClusterRoleBinding의 네임스페이스를 업데이트합니다.

      # patch-crb.yaml
      apiVersion: rbac.authorization.k8s.io/v1
      kind: ClusterRoleBinding
      metadata:
        name: prometheus-operator
      subjects:
      - kind: ServiceAccount
        name: prometheus-operator
        namespace: monitoring # we are patching from default namespace
      
    4. 패치를 적용하고 매니페스트에서 다른 리소스의 네임스페이스를 수정하는 kustomization.yaml 파일을 만듭니다.

      # kustomization.yaml
      resources:
      - bundle.yaml
      
      namespace: monitoring
      
      patchesStrategicMerge:
      - patch-crb.yaml
      
    5. monitoring 네임스페이스가 없으면 만듭니다. 네임스페이스에 다른 이름을 사용할 수 있지만 이 경우 이전 단계의 YAML 매니페스트에서 namespace 값도 변경합니다.

      kubectl create namespace monitoring
      
    6. 다음 명령어를 사용하여 Kustomize 매니페스트를 적용합니다.

      kubectl apply -k .
      
      until kubectl get customresourcedefinitions servicemonitors.monitoring.coreos.com ; \
      do date; sleep 1; echo ""; done

      두 번째 명령어는 클러스터에서 CRD를 사용할 수 있을 때까지 차단됩니다.

    7. Anthos Config Management에서 측정항목을 스크랩하는 Prometheus 서버를 구성하는 데 필요한 리소스의 매니페스트를 만듭니다.

      # acm.yaml
      apiVersion: v1
      kind: ServiceAccount
      metadata:
        name: prometheus-acm
        namespace: monitoring
      ---
      apiVersion: rbac.authorization.k8s.io/v1
      kind: ClusterRole
      metadata:
        name: prometheus-acm
      rules:
      - apiGroups: [""]
        resources:
        - nodes
        - services
        - endpoints
        - pods
        verbs: ["get", "list", "watch"]
      - apiGroups: [""]
        resources:
        - configmaps
        verbs: ["get"]
      - nonResourceURLs: ["/metrics"]
        verbs: ["get"]
      ---
      apiVersion: rbac.authorization.k8s.io/v1
      kind: ClusterRoleBinding
      metadata:
        name: prometheus-acm
      roleRef:
        apiGroup: rbac.authorization.k8s.io
        kind: ClusterRole
        name: prometheus-acm
      subjects:
      - kind: ServiceAccount
        name: prometheus-acm
        namespace: monitoring
      ---
      apiVersion: monitoring.coreos.com/v1
      kind: Prometheus
      metadata:
        name: acm
        namespace: monitoring
        labels:
          prometheus: acm
      spec:
        replicas: 2
        serviceAccountName: prometheus-acm
        serviceMonitorSelector:
          matchLabels:
            prometheus: config-management
        podMonitorSelector:
          matchLabels:
            prometheus: config-management
        alerting:
          alertmanagers:
          - namespace: default
            name: alertmanager
            port: web
        resources:
          requests:
            memory: 400Mi
      ---
      apiVersion: v1
      kind: Service
      metadata:
        name: prometheus-acm
        namespace: monitoring
        labels:
          prometheus: acm
      spec:
        type: NodePort
        ports:
        - name: web
          nodePort: 31900
          port: 9190
          protocol: TCP
          targetPort: web
        selector:
          app: prometheus
          prometheus: acm
      ---
      apiVersion: monitoring.coreos.com/v1
      kind: ServiceMonitor
      metadata:
        name: acm-service
        namespace: monitoring
        labels:
          prometheus: config-management
      spec:
        selector:
          matchLabels:
            monitored: "true"
        namespaceSelector:
          matchNames:
          # If you are using RootSync and RepoSync APIs, change
          # config-management-system to config-management-monitoring
          - config-management-system
        endpoints:
        - port: metrics
          interval: 10s
      ---
      
    8. 다음 명령어를 사용하여 매니페스트를 적용합니다.

      kubectl apply -f acm.yaml
      
      until kubectl rollout status statefulset/prometheus-acm -n monitoring; \
      do sleep 1; done
      

      두 번째 명령어는 pod가 실행될 때까지 차단됩니다.

    9. Prometheus 서버의 웹 포트를 로컬 머신에 전달하여 설치를 확인할 수 있습니다.

      kubectl -n monitoring port-forward svc/prometheus-acm 9190
      

      이제 http://localhost:9190에서 Prometheus 웹 UI에 액세스할 수 있습니다.

    10. 임시 디렉터리를 삭제합니다.

      cd ..
      rm -rf acm-monitor
      

사용 가능한 Prometheus 측정항목

구성 동기화는 다음과 같은 측정항목을 수집하여 Prometheus에 제공합니다. 라벨 열에는 각 측정항목에 적용 가능한 모든 라벨이 표시됩니다. 라벨이 없는 측정항목은 시간이 지남에 따라 단일 측정을 나타내는 반면 라벨이 있는 측정항목은 라벨 값의 각 조합에 대해 하나씩 여러 측정을 나타냅니다.

이 테이블이 동기화되지 않으면 Prometheus 사용자 인터페이스의 프리픽스로 측정항목을 필터링할 수 있으며 모든 해당 측정항목은 gkeconfig_ 프리픽스로 시작합니다.

이름 유형 라벨 설명
gkeconfig_importer_cycle_duration_seconds_bucket 히스토그램 status 임포터가 구성을 클러스터로 가져 오려고 시도한 주기 수(각 주기 동안 버킷으로 분배)
gkeconfig_importer_cycle_duration_seconds_count 히스토그램 status 임포터가 구성을 클러스터로 가져 오려고 시도한 주기 수(지속 시간 무시)
gkeconfig_importer_cycle_duration_seconds_sum 히스토그램 status 임포터가 구성을 클러스터로 가져 오려고 시도한 모든 주기 지속 시간의 합계
gkeconfig_importer_namespace_configs 게이지 현재 상태의 네임스페이스 구성 수
gkeconfig_monitor_errors 게이지 component 구성 저장소에서 오류가 발생한 구성 요소별로 그룹화된 오류 수
gkeconfig_monitor_configs 게이지 state 동기화 상태별로 그룹화된 구성(클러스터 및 네임스페이스) 수
gkeconfig_monitor_last_import_timestamp 게이지 최근 가져오기의 타임스탬프입니다.
gkeconfig_monitor_last_sync_timestamp 게이지 최근 동기화의 타임스탬프입니다.
gkeconfig_monitor_sync_latency_seconds_bucket 히스토그램 가져온 동기화로 가져오기 측정 수(두 항목 사이의 대기 시간에 따라 버킷에 분산됨)
gkeconfig_monitor_sync_latency_seconds_count 히스토그램 가져온 동기화로 가져오기 측정 수(둘 사이의 지연 시간 무시)
gkeconfig_monitor_sync_latency_seconds_sum 히스토그램 가져온 모든 가져오기 동기 측정의 지연 시간 합계
gkeconfig_syncer_api_duration_seconds_bucket 히스토그램 operation, type, status 동기화 프로그램이 API 서버에 대해 수행한 호출 수(각 호출 기간에 따라 버킷으로 분배)
gkeconfig_syncer_api_duration_seconds_count 히스토그램 operation, type, status 임포터가 API 서버에 호출한 횟수(지속 시간 무시)
gkeconfig_syncer_api_duration_seconds_sum 히스토그램 operation, type, status 동기화 프로그램이 API 서버에 대해 수행한 모든 호출 지속 시간의 합계
gkeconfig_syncer_controller_restarts_total 카운터 source 네임스페이스 및 클러스터 구성 컨트롤러에 대한 총 재시작 횟수
gkeconfig_syncer_operations_total 카운터 operation, type, status 리소스를 구성에 동기화하기 위해 수행된 총 작업 수
gkeconfig_syncer_reconcile_duration_seconds_bucket 히스토그램 type, status 동기화 프로그램에서 처리한 조정 이벤트 수(기간별로 버킷으로 분배)
gkeconfig_syncer_reconcile_duration_seconds_count 히스토그램 type, status 동기화 프로그램에서 처리한 조정 이벤트 수(지속 시간 무시)
gkeconfig_syncer_reconcile_duration_seconds_sum 히스토그램 type, status 동기화 프로그램에서 처리한 모든 조정 이벤트 기간의 합계
gkeconfig_syncer_reconcile_event_timestamps 게이지 type 동기화 조정 이벤트가 발생했을 때의 타임스탬프

Prometheus 디버깅 절차 예시

다음 예시는 Prometheus 측정항목, 객체 상태 필드, 객체 주석을 사용하여 구성 동기화와 관련된 문제를 감지하고 진단하는 몇 가지 패턴을 보여줍니다. 이러한 예시는 문제를 발견한 상위 수준 모니터링에서 시작한 다음 점진적으로 상세 검색을 통해 문제의 근본 원인을 파악하는 방법을 보여줍니다.

상태별 구성 쿼리

monitor 프로세스는 클러스터에서 구성 동기화가 작동하는 방식에 대한 전반적인 정보를 제공하는 높은 수준의 측정항목을 제공합니다. 오류가 발생했는지 여부를 알 수 있으며 경고를 설정할 수도 있습니다.

gkeconfig_monitor_errors

조정자로 측정항목 쿼리

구성 동기화 RootSync 및 RepoSync API를 사용하는 경우 RootSync 및 RepoSync 객체를 모니터링할 수 있습니다. RootSync 및 RepoSync 객체는 구성 동기화가 클러스터에서 작동하는 방식에 대한 유용한 정보를 제공하는 상위 수준 측정항목으로 계측됩니다. 거의 모든 측정항목에 조정자 이름이 태그로 지정되므로 오류가 발생했는지 확인하고 이에 대한 알림을 Prometheus에서 설정할 수 있습니다.

조정자는 Git 저장소의 매니페스트를 클러스터에 동기화하는 Pod입니다. RootSync 객체를 만들 때 구성 동기화는 root-reconciler라는 조정자를 만듭니다. RepoSync 객체를 만들 때 구성 동기화는 ns-reconciler-NAMESPACE라는 조정자를 만듭니다. 여기서 NAMESPACE는 RepoSync 객체를 만든 네임스페이스입니다.

Prometheus에서 조정자에 다음 필터를 사용할 수 있습니다.

# Querying Root reconciler
config_sync_reconciler_errors{root_reconciler="root-reconciler"}

# Querying Namespace reconciler for a namespace called retail
config_sync_reconciler_errors{ns_reconciler_retail="ns-reconciler-retail"}

nomos status를 사용하여 오류 표시

Prometheus 측정항목을 사용하여 클러스터의 구성 동기화 상태를 모니터링하는 것 외에 명령줄에서 모든 클러스터의 오류를 출력하는 nomos status 명령어를 사용할 수도 있습니다.

상태별 가져오기 및 동기화 작업 쿼리

구성 동기화는 2단계 프로세스를 사용하여 저장소의 구성을 클러스터에 적용합니다. gkeconfig_monitor_errors 측정항목에 구성요소별로 라벨이 지정되므로 오류가 발생한 위치를 확인할 수 있습니다.

gkeconfig_monitor_errors{component="importer"}
gkeconfig_monitor_errors{component="syncer"}

또한 importer 및 syncer 프로세스 자체의 측정항목을 확인할 수도 있습니다.

gkeconfig_importer_cycle_duration_seconds_count{status="error"}
gkeconfig_syncer_reconcile_duration_seconds_count{status="error"}

RootSync 및 RepoSync API를 사용 설정한 경우 Git 저장소에서 가져오기 및 소싱과 클러스터로의 동기화는 조정자에 의해 처리됩니다. reconciler_errors 측정항목에 구성요소별로 라벨이 지정되므로 오류가 발생한 위치를 확인할 수 있습니다.

Prometheus에서 다음 쿼리를 사용할 수 있습니다.

# Check for errors that occurred when sourcing configs from the Git repository.
config_sync_reconciler_errors{component="source"}

# Check for errors that occurred when syncing configs to the cluster.
config_sync_reconciler_errors{component="sync"}

소스 및 동기화 프로세스 자체의 측정항목도 확인할 수 있습니다.

config_sync_parse_duration_seconds{status="error"}
config_sync_apply_duration_seconds{status="error"}
config_sync_remediate_duration_seconds{status="error"}

구성 객체 상태 확인

구성 동기화는 ClusterConfig와 NamespaceConfig, 두 가지 커스텀 Kubernetes 객체를 정의합니다. 이러한 객체는 구성에 마지막으로 적용된 변경과 발생한 오류에 대한 정보가 포함된 상태 필드를 정의합니다. 예를 들어 shipping-dev 네임스페이스에 오류가 있으면 해당 NamespaceConfig의 상태를 확인할 수 있습니다.

kubectl get namespaceconfig shipping-dev -o yaml

객체의 token 주석 확인

구성 동기화를 통해 관리형 Kubernetes 객체가 마지막으로 업데이트된 시기를 알고자 할 수 있습니다. 각 관리형 객체에는 최종 수정 시 Git 커밋의 해시와 수정 사항이 포함된 구성의 경로가 주석으로 지정됩니다.

kubectl get clusterrolebinding namespace-readers
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
    configmanagement.gke.io/source-path: cluster/namespace-reader-clusterrolebinding.yaml
    configmanagement.gke.io/token: bbb6a1e2f3db692b17201da028daff0d38797771
  name: namespace-readers
...

자세한 내용은 라벨 및 주석을 참조하세요.

다음 단계