자체 배포 규칙 평가 및 알림

Google Cloud Managed Service for Prometheus는 Prometheus 호환 규칙 평가 및 알림을 지원합니다. 이 문서에서는 독립형 규칙 평가자 구성요소를 포함하여 자체 배포 규칙 평가를 설정하는 방법을 설명합니다.

전역 데이터 스토어에 대해 규칙 및 알림을 실행하려는 경우에만 이 안내를 따라야 합니다.

자체 배포 컬렉션 규칙 평가

Managed Service for Prometheus를 배포한 후에는 Prometheus 구성 파일의 rule_files 필드를 사용하여 각 배포된 인스턴스에서 로컬로 규칙을 계속 평가할 수 있습니다. 하지만 규칙의 최대 쿼리 시간은 서버가 로컬 데이터를 보유하는 시간으로 제한됩니다.

대부분의 규칙은 데이터의 마지막 몇 분 동안만 실행되므로, 각 로컬 서버에서 규칙을 실행하는 것이 적합한 전략인 경우가 많습니다. 이 경우 추가 설정이 필요하지 않습니다.

하지만 규칙의 모든 데이터가 특정 Prometheus 인스턴스에 함께 배치되지 않은 경우와 같이 일부 경우에는 전역 측정항목 백엔드에 대해 규칙을 평가하는 것이 유용합니다. 또한 이러한 경우 Managed Service for Prometheus가 규칙 평가자 구성요소도 제공합니다.

시작하기 전에

이 섹션에서는 이 문서에 설명된 태스크에 필요한 구성에 대해 설명합니다.

환경 구성

프로젝트 ID 또는 클러스터 이름을 반복해서 입력하지 않으려면 다음 구성을 수행합니다.

  • 다음과 같이 명령줄 도구를 구성합니다.

    • Google Cloud 프로젝트의 ID를 참조하도록 gcloud CLI를 구성합니다.

      gcloud config set project PROJECT_ID
      
    • 클러스터를 사용하도록 kubectl CLI를 구성합니다.

      kubectl config set-cluster CLUSTER_NAME
      

    이러한 도구에 대한 자세한 내용은 다음을 참조하세요.

네임스페이스 설정

예시 애플리케이션의 일부로 만드는 리소스에 대해 NAMESPACE_NAME Kubernetes 네임스페이스를 만듭니다.

kubectl create ns NAMESPACE_NAME

서비스 계정 사용자 인증 정보 확인

Kubernetes 클러스터에 워크로드 아이덴티티가 사용 설정되어 있으면 이 섹션을 건너뛸 수 있습니다.

GKE에서 실행될 때 Managed Service for Prometheus는 Compute Engine 기본 서비스 계정을 기반으로 환경에서 사용자 인증 정보를 자동으로 검색합니다. 기본적으로 기본 서비스 계정에는 필요한 권한 monitoring.metricWritermonitoring.viewer가 있습니다. 워크로드 아이덴티티를 사용하지 않고 이전에 기본 노드 서비스 계정에서 이러한 역할 중 하나를 삭제한 경우 계속하기 전에 누락된 권한을 다시 추가해야 합니다.

GKE에서 실행하지 않는 경우 명시적으로 사용자 인증 정보 제공을 참조하세요.

워크로드 아이덴티티에 대한 서비스 계정 구성

Kubernetes 클러스터에 워크로드 아이덴티티가 사용 설정되어 있지 않으면 이 섹션을 건너뛰어도 됩니다.

Managed Service for Prometheus는 Cloud Monitoring API를 사용하여 측정항목 데이터를 캡처합니다. 클러스터가 워크로드 아이덴티티를 사용하는 경우 Kubernetes 서비스 계정에 Monitoring API에 대한 권한을 부여할 수 있습니다. 이 섹션에서는 다음을 설명합니다.

서비스 계정 만들기 및 바인딩

이 단계는 Managed Service for Prometheus 문서의 여러 위치에 표시됩니다. 이미 이전 태스크를 수행하는 동안 이 단계를 수행했으면 이를 반복할 필요가 없습니다. 서비스 계정 승인으로 건너뛰세요.

다음 명령어 시퀀스는 gmp-test-sa 서비스 계정을 만들고 NAMESPACE_NAME 네임스페이스의 기본 Kubernetes 서비스 계정에 바인딩합니다.

gcloud config set project PROJECT_ID \
&&
gcloud iam service-accounts create gmp-test-sa \
&&
gcloud iam service-accounts add-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE_NAME/default]" \
  gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
&&
kubectl annotate serviceaccount \
  --namespace NAMESPACE_NAME \
  default \
  iam.gke.io/gcp-service-account=gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com

다른 GKE 네임스페이스 또는 서비스 계정을 사용하는 경우 적절하게 명령어를 조정합니다.

서비스 계정 승인

관련 권한 그룹이 역할에 수집되고 주 구성원(이 예시에서는 Google Cloud 서비스 계정)에 역할을 부여합니다. Monitoring 역할에 대한 자세한 내용은 액세스 제어를 참조하세요.

다음 명령어는 Google Cloud 서비스 계정 gmp-test-sa에 측정항목 데이터 읽기 및 쓰기에 필요한 Monitoring API 역할을 부여합니다.

이미 이전 태스크를 수행하는 동안 Google Cloud 서비스 계정에 특정 역할을 부여한 경우 이를 다시 수행할 필요가 없습니다.

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/monitoring.viewer \
&& \
gcloud projects add-iam-policy-binding PROJECT_ID\
  --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/monitoring.metricWriter

워크로드 아이덴티티 구성 디버그

워크로드 아이덴티티 작동에 문제가 있으면 워크로드 아이덴티티 설정 확인워크로드 아이덴티티 문제 해결 가이드 문서를 참조하세요.

워크로드 아이덴티티를 구성할 때 오타 및 부분 복사-붙여넣기가 가장 일반적인 오류 소스이므로 이 안내의 코드 샘플에 삽입된 수정 가능한 변수 및 클릭 가능한 복사-붙여넣기 아이콘을 사용하는 것이 좋습니다.

프로덕션 환경의 워크로드 아이덴티티

이 문서에 설명된 예시에서는 Google Cloud 서비스 계정을 기본 Kubernetes 서비스 계정에 바인딩하고 Google Cloud 서비스 계정에 Monitoring API를 사용하기 위해 필요한 모든 권한을 부여합니다.

프로덕션 환경에서는 각 구성요소에 대해 서비스 계정이 있고, 각각 최소 권한이 포함된 세분화된 방법을 사용해야 할 수 있습니다. 워크로드 아이덴티티 관리를 위한 서비스 계정 구성에 대한 자세한 내용은 워크로드 아이덴티티 사용을 참조하세요.

독립형 규칙 평가자 배포

Managed Service for Prometheus 규칙 평가자는 Managed Service for Prometheus HTTP API에 대해 Prometheus 알림 및 기록 규칙을 평가하고 결과를 다시 Monarch에 기록합니다. Prometheus과 동일한 구성 파일 형식 및 규칙 파일 형식이 사용됩니다. 플래그도 대부분 동일합니다.

  1. 알림 및 기록 규칙을 평가하도록 사전 구성된 규칙 평가자의 예시 배포를 만듭니다.

    kubectl apply -n NAMESPACE_NAME -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.8.2/manifests/rule-evaluator.yaml
    
  2. 규칙 평가자의 포드가 성공적으로 배포되었는지 확인합니다.

    kubectl -n NAMESPACE_NAME get pod
    

    배포가 성공했으면 출력이 다음과 비슷하게 표시됩니다.

    NAME                              READY   STATUS    RESTARTS   AGE
    ...
    rule-evaluator-64475b696c-95z29   2/2     Running   0          1m
    

규칙 평가자가 성공적으로 배포되었는지 확인한 후 다음을 수행하도록 설치된 매니페스트를 조정할 수 있습니다.

  • 커스텀 규칙 파일을 추가합니다.
  • 구성 파일의 alertmanager_config 필드를 사용하여 자체 배포된 Prometheus Alertmanager로 알림을 전송하도록 규칙 평가자를 구성합니다.

Alertmanager가 규칙 평가자와 다른 클러스터에 있는 경우 엔드포인트 리소스를 설정해야 할 수 있습니다. 예를 들어 OperatorConfig가 Alertmanager 엔드포인트를 엔드포인트 객체 ns=alertmanager/name=alertmanager에서 찾을 수 있도록 지정하는 경우 이 객체를 수동으로 또는 프로그래매틱 방식으로 직접 생성하고 다른 클러스터에서 연결할 수 있는 IP로 채울 수 있습니다.

명시적으로 사용자 인증 정보 제공

GKE에서 실행할 경우 규칙 평가자가 노드의 서비스 계정 또는 워크로드 아이덴티티 설정을 기준으로 환경에서 사용자 인증 정보를 자동으로 검색합니다. 비GKE Kubernetes 클러스터에서는 플래그 또는 GOOGLE_APPLICATION_CREDENTIALS 환경 변수를 사용하여 규칙 평가자에 사용자 인증 정보를 명시적으로 제공해야 합니다.

  1. 컨텍스트를 대상 프로젝트에 설정합니다.

    gcloud config set project PROJECT_ID
    
  2. 서비스 계정을 만듭니다.

    gcloud iam service-accounts create gmp-test-sa
    

    이 단계에서는 워크로드 아이덴티티 안내에 따라 이미 생성되었을 수 있는 서비스 계정을 만듭니다.

  3. 서비스 계정에 필요한 권한을 부여합니다.

    gcloud projects add-iam-policy-binding PROJECT_ID \
      --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
      --role=roles/monitoring.viewer \
    && \
    gcloud projects add-iam-policy-binding PROJECT_ID\
      --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
      --role=roles/monitoring.metricWriter
    

  4. 서비스 계정에 대해 키를 만들고 다운로드합니다.

    gcloud iam service-accounts keys create gmp-test-sa-key.json \
      --iam-account=gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com
    
  5. 키 파일을 GKE 클러스터 외의 클러스터에 보안 비밀로 추가합니다.

    kubectl -n NAMESPACE_NAME create secret generic gmp-test-sa \
      --from-file=key.json=gmp-test-sa-key.json
    

  6. 수정을 위해 규칙-평가자 배포 리소스를 엽니다.

    kubectl -n NAMESPACE_NAME edit deploy rule-evaluator
    
    1. 굵게 표시된 텍스트를 리소스에 추가합니다.

      apiVersion: apps/v1
      kind: Deployment
      metadata:
        namespace: NAMESPACE_NAME
        name: rule-evaluator
      spec:
        template
          containers:
          - name: evaluator
            args:
            - --query.credentials-file=/gmp/key.json
            - --export.credentials-file=/gmp/key.json
      ...
            volumeMounts:
            - name: gmp-sa
              mountPath: /gmp
              readOnly: true
      ...
          volumes:
          - name: gmp-sa
            secret:
              secretName: gmp-test-sa
      ...
      

    2. 파일을 저장하고 편집기를 닫습니다. 변경사항이 적용되고 포드가 다시 생성된 후 제공된 서비스 계정을 사용하여 측정항목 백엔드에 대해 인증을 시작합니다.

    또는 이 예시에 설정된 플래그를 사용하는 대신 GOOGLE_APPLICATION_CREDENTIALS 환경 변수를 사용하여 키-파일 경로를 설정할 수 있습니다.

    다중 프로젝트 및 전역 규칙 평가

    여러 프로젝트 및 리전에 대해 평가되는 인스턴스에서 실행하는 대신 각 Google Cloud 프로젝트 및 리전에서 규칙 평가자의 하나의 인스턴스를 실행하는 것이 좋습니다. 그러나 시나리오가 필요한 시나리오에는 다중 프로젝트 규칙 평가가 지원됩니다.

    Google Kubernetes Engine에 배포된 경우 규칙 평가자가 자동으로 감지되는 클러스터와 연결된 Google Cloud 프로젝트를 사용합니다. 여러 프로젝트에 걸쳐진 규칙을 평가하려면 --query.project-id 플래그를 사용하여 다중 프로젝트 측정항목 범위로 프로젝트를 지정하여 쿼리된 프로젝트를 재정의할 수 있습니다. 측정항목 범위에 모든 프로젝트가 포함된 경우 규칙이 전역적으로 평가됩니다. 자세한 내용은 측정항목 범위를 참조하세요.

    또한 서비스 계정이 범위 지정 프로젝트에서 읽고 측정항목 범위의 모든 모니터링되는 프로젝트에 쓸 수 있도록 규칙 평가자에서 사용되는 서비스 계정의 권한을 업데이트해야 합니다.

    규칙을 작성할 때 라벨 보존

    평가자가 Managed Service for Prometheus에 다시 기록하는 데이터의 경우 평가자는 Managed Service for Prometheus 서버 바이너리와 동일한 --export.* 플래그 및 external_labels 기반 구성을 지원합니다. project_id, location, cluster, namespace 라벨이 집계 수준에 맞게 적절하게 보존되도록 규칙을 작성하는 것이 좋습니다. 그러지 않으면 쿼리 성능이 저하되고 카디널리티 제한이 발생할 수 있습니다.

    project_id 또는 location 라벨은 필수입니다. 이러한 라벨이 없으면 규칙 평가 결과의 값이 규칙 평가자의 구성에 따라 설정됩니다. 누락된 cluster 또는 namespace 라벨에는 값이 제공되지 않습니다.

    고가용성 배포

    규칙 평가자는 Prometheus 서버에 대해 설명된 것과 동일한 방법에 따라 가용성이 높은 설정으로 실행될 수 있습니다.

    Cloud Monitoring 측정항목을 사용하여 알림

    PromQL을 사용하여 Google Cloud 시스템 측정항목에서 알리도록 규칙 평가자를 구성할 수 있습니다. 유효한 쿼리를 만드는 방법은 Cloud Monitoring 측정항목용 PromQL을 참조하세요.