관리형 규칙 평가 및 알림

Google Cloud Managed Service for Prometheus는 Prometheus 호환 규칙 평가 및 알림을 지원합니다. 이 문서에서는 관리 규칙 평가를 설정하는 방법을 설명합니다.

규칙 평가

Managed Service for Prometheus는 전역 Prometheus 백엔드의 컨텍스트에서 규칙을 안전하게 작성할 수 있게 해주어 대규모 조직의 다른 사용자 데이터와 혼용되지 않도록 방지하는 규칙 평가자 구성요소를 제공합니다. 이 구성요소는 Kubernetes 클러스터에서 실행될 때 관리 컬렉션의 일부로 자동으로 배포됩니다.

Managed Service for Prometheus 측정항목과 Cloud Monitoring 측정항목 모두에 대한 규칙 및 알림을 작성할 수 있습니다. Cloud Monitoring 측정항목의 규칙을 작성할 때 GlobalRules 리소스를 사용해야 합니다.

참고: PromQL 쿼리 및 Prometheus 알림 규칙을 기반으로 Cloud Monitoring 알림 정책을 만들 수 있습니다. 자세한 내용은 PromQL을 사용한 알림 정책을 참조하세요.

규칙

관리 규칙-평가자는 규칙 리소스를 사용하여 기록 및 알림 규칙을 구성합니다. 다음은 예시 규칙 리소스입니다.

apiVersion: monitoring.googleapis.com/v1
kind: Rules
metadata:
  namespace: NAMESPACE_NAME
  name: example-rules
spec:
  groups:
  - name: example
    interval: 30s
    rules:
    - record: job:up:sum
      expr: sum without(instance) (up)
    - alert: AlwaysFiring
      expr: vector(1)

.spec.groups 요소의 형식은 업스트림 Prometheus rule_group 배열과 동일합니다. Rules에 정의된 알림 및 기록 규칙은 리소스의 project_id, cluster, namespace로 범위가 지정됩니다. 예를 들어 위 리소스의 job:up:sum 규칙은 sum without(instance) (up{project_id="test-project", cluster="test-cluster", namespace="NAMESPACE_NAME"})를 효과적으로 쿼리합니다. 이렇게 하면 알림 또는 기록 규칙이 사고로 인해 알 수 없는 애플리케이션의 측정항목을 평가하지 않도록 보장합니다.

예시 규칙을 클러스터에 적용하려면 다음 명령어를 실행합니다.

kubectl apply -n NAMESPACE_NAME -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.8.2/examples/rules.yaml

몇 분 후 job:up:sum 측정항목이 사용 가능해집니다. AlwaysFiring 알림도 실행이 시작됩니다. Alertmanager로 알림을 전송하는 방법에 대한 자세한 내용은 Alertmanager 구성을 참조하세요.

ClusterRules 및 GlobalRules 리소스는 Rules 리소스와 동일한 인터페이스를 제공하지만 규칙을 보다 광범위한 범위에 적용합니다. ClusterRules는 project_id 및 cluster 라벨을 사용하여 데이터를 선택하고 GlobalRules는 라벨을 제한하지 않고 쿼리된 측정항목 범위의 모든 데이터를 선택합니다.

모든 Managed Service for Prometheus 커스텀 리소스에 대한 참조 문서는 prometheus-engine/doc/api 참조를 확인하세요.

Prometheus 규칙을 규칙으로 변환

규칙 리소스는 관리 규칙 평가에 기존 규칙을 사용하기 위해 매끄러운 마이그레이션 경로를 제공하도록 호환 가능한 인터페이스를 Prometheus 규칙에 제공합니다. 규칙 리소스에 기존 규칙을 포함할 수 있습니다. 예를 들어 다음은 Prometheus 규칙입니다.

groups:
- name: example
  interval: 30s
  rules:
  - record: job:up:sum
    expr: sum without(instance) (up)
  - alert: AlwaysFiring
    expr: vector(1)

굵게 표시된 원래 Prometheus 규칙과 함께 다음 규칙 리소스가 표시됩니다.

apiVersion: monitoring.googleapis.com/v1
kind: Rules
metadata:
  namespace: NAMESPACE_NAME
  name: example-rules
spec:
  groups:
  - name: example
    interval: 30s
    rules:
    - record: job:up:sum
      expr: sum without(instance) (up)
    - alert: AlwaysFiring
      expr: vector(1)

ClusterRules

ClusterRules 리소스를 사용하여 특정 클러스터의 모든 네임스페이스에서 Managed Service for Prometheus로 전송되는 모든 시계열을 평가할 수 있는 기록 및 알림 규칙을 구성할 수 있습니다. 사양은 Rules와 동일합니다. 이전 예시 Prometheus 규칙은 다음 ClusterRules 리소스가 됩니다.

apiVersion: monitoring.googleapis.com/v1
kind: ClusterRules
metadata:
  name: example-clusterrules
spec:
  groups:
  - name: example
    interval: 30s
    rules:
    - record: job:up:sum
      expr: sum without(instance) (up)
    - alert: AlwaysFiring
      expr: vector(1)

서비스 메시로 생성된 것과 같이 수평형 측정항목에서만 ClusterRules 리소스를 사용하는 것이 좋습니다. 개별 배포의 측정항목에 대해서는 평가에 의도치 않은 데이터가 포함되지 않도록 규칙 리소스를 사용합니다.

GlobalRules

GlobalRules 리소스를 사용하여 측정항목 범위 내의 모든 프로젝트에서 Prometheus용 관리형 서비스에 전송되는 모든 시계열을 평가할 수 있는 레코딩 및 알림 규칙을 구성할 수 있습니다. 사양은 Rules와 동일합니다. 이전 예시 Prometheus 규칙은 다음 GlobalRules 리소스가 됩니다.

apiVersion: monitoring.googleapis.com/v1
kind: GlobalRules
metadata:
  name: example-globalrules
spec:
  groups:
  - name: example
    interval: 30s
    rules:
    - record: job:up:sum
      expr: sum without(instance) (up)
    - alert: AlwaysFiring
      expr: vector(1)

Cloud Monitoring 측정항목은 네임스페이스 또는 클러스터로 범위가 지정되지 않으므로 Cloud Monitoring 측정항목에 대한 규칙 또는 알림을 작성할 때는 GlobalRules 리소스를 사용해야 합니다. Google Kubernetes Engine 시스템 측정항목에 대한 알림을 받을 때도 GlobalRules를 사용해야 합니다.

규칙에 project_id 또는 location 라벨이 없으면 기본값은 클러스터 값입니다.

Prometheus용 관리형 서비스 측정항목의 경우 드물지만 알림이 모든 클러스터의 데이터를 동시에 필요로 하는 사용 사례에서만 GlobalRules를 사용하는 것이 좋습니다. 개별 배포의 측정항목의 경우 규칙 또는 ClusterRules 리소스를 사용하여 안정성을 높이고 평가에 의도치 않은 데이터가 포함되지 않도록 합니다. 규칙의 목적을 해당 라벨을 집계하는 것이 아니라면 규칙 평가 결과에서 cluster 및 namespace 라벨을 보존하는 것이 좋습니다. 그렇지 않으면 쿼리 성능이 저하되고 카디널리티 제한이 발생할 수 있습니다. 두 라벨을 모두 제거하지 않는 것이 좋습니다.

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

Google Kubernetes Engine에 배포될 때 규칙 평가자는 규칙 평가자가 자동으로 감지하는 클러스터와 연결된 Google Cloud 프로젝트를 사용합니다. 여러 프로젝트에 걸쳐 있는 규칙을 평가하려면 GlobalRules 리소스를 실행하는 규칙 평가자를 구성하여 다중 프로젝트 측정항목 범위로 프로젝트를 사용해야 합니다. 여기에는 두 가지 방법이 있습니다.

• 다중 프로젝트 측정항목 범위가 있는 프로젝트에 GlobalRules 리소스를 배치합니다.
• 다중 프로젝트 측정항목 범위가 있는 프로젝트를 사용하려면 OperatorConfig 내의 queryProjectID 필드를 설정합니다.

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

측정항목 범위에 모든 프로젝트가 포함된 경우 규칙이 전역적으로 평가됩니다. 자세한 내용은 측정항목 범위를 참조하세요.

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

GlobalRules 리소스를 사용하면 PromQL을 통해 Google Cloud 시스템 측정항목에 대한 알림을 보낼 수 있습니다. 유효한 쿼리를 만드는 방법은 Cloud Monitoring 측정항목용 PromQL을 참조하세요.

Terraform을 사용하여 규칙 및 알림 구성

임의 커스텀 리소스를 지정할 수 있는 kubernetes_manifest Terraform 리소스 유형이나 kubectl_manifest Terraform 리소스 유형을 사용하여 규칙, ClusterRule, GlobalRule 리소스를 자동으로 만들고 관리할 수 있습니다.

Terraform과 함께 Google Cloud를 사용하는 방법에 대한 일반적인 내용은 Google Cloud에서 Terraform을 참조하세요.

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

GKE에서 실행할 경우 규칙 평가자가 노드의 서비스 계정을 기반으로 환경에서 사용자 인증 정보를 자동으로 검색합니다. 비GKE Kubernetes 클러스터에서 사용자 인증 정보는 gmp-public 네임스페이스에서 OperatorConfig 리소스를 통해 명시적으로 제공되어야 합니다.

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 gmp-public create secret generic gmp-test-sa \
     --from-file=key.json=gmp-test-sa-key.json
   

6. 수정을 위해 OperatorConfig 리소스를 엽니다.

   kubectl -n gmp-public edit operatorconfig config
   

   1. 굵게 표시된 텍스트를 리소스에 추가합니다.

      apiVersion: monitoring.googleapis.com/v1
      kind: OperatorConfig
      metadata:
        namespace: gmp-public
        name: config
      rules:
        credentials:
          name: gmp-test-sa
          key: key.json
      

      또한 관리형 컬렉션이 작동하도록 이러한 사용자 인증 정보를 collection 섹션에 추가해야 합니다.

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

   Alertmanager 구성

   OperatorConfig 리소스를 사용하여 Prometheus Alertmanager로 알림을 전송하도록 관리 규칙 평가자를 구성합니다. 자체 배포되는 Alertmanager 외에도 자동으로 배포되는 관리형 Alertmanager로 알림을 전송할 수 있습니다.

   관리형 Alertmanager

   미리보기

   이 기능에는 서비스별 약관의 일반 서비스 약관 섹션에 있는 'GA 이전 제공 서비스 약관'이 적용됩니다. GA 이전 기능은 '있는 그대로' 제공되며 지원이 제한될 수 있습니다. 자세한 내용은 출시 단계 설명을 참조하세요.

   Prometheus용 관리형 서비스는 규칙 평가자가 자동으로 알림을 전달하도록 구성되는 Alertmanager의 관리형 인스턴스를 배포합니다. 기본적으로 이 구성은 Alertmanager 구성 파일이 포함된 특별하게 명명된 Kubernetes 보안 비밀로 설정됩니다.

   배포된 Alertmanager 인스턴스에 대해 보고를 사용 설정하고 구성하려면 다음을 수행합니다.

   1. Alertmanager 설정을 포함하는 로컬 구성 파일을 만듭니다(샘플 구성 템플릿 참조).

      touch alertmanager.yaml
      

   2. 원하는 Alertmanager 설정을 사용하여 파일을 업데이트하고 gmp-public 네임스페이스에 alertmanager라는 보안 비밀을 만듭니다.

      kubectl create secret generic alertmanager \
        -n gmp-public \
        --from-file=alertmanager.yaml
      

   잠시 후 Prometheus용 관리형 서비스가 새 구성 보안 비밀을 선택하고 해당 설정을 사용해서 관리형 Alertmanager를 사용 설정합니다.

   구성 보안 비밀 이름 맞춤설정

   관리형 Alertmanager는 구성 로드를 위해 커스텀 보안 비밀 이름을 지원합니다. 이 기능은 구성 보안 비밀이 여러 개 있고 Alertmanager 인스턴스를 해당 구성으로 전환하려는 경우에 유용합니다. 예를 들어 긴급 대기 교대 근무조 순환에 따라 알림 채널을 변경하거나 새로운 알림 경로를 테스트하도록 실험적인 Alertmanager 구성에서 스왑을 수행해야 할 수 있습니다.

   OperatorConfig 리소스를 사용하여 기본값이 아닌 보안 비밀 이름을 지정하려면 다음을 수행합니다.

   1. 로컬 Alertmanager 구성 파일에서 보안 비밀을 만듭니다.

      kubectl create secret generic SECRET_NAME \
        -n gmp-public \
        --from-file=FILE_NAME
      

   2. 수정을 위해 OperatorConfig 리소스를 엽니다.

      kubectl -n gmp-public edit operatorconfig config
      

   3. 관리형 Alertmanager 보고를 사용 설정하려면 다음 굵은 텍스트로 표시된 대로 managedAlertmanager 섹션을 수정하여 리소스를 수정합니다.

      apiVersion: monitoring.googleapis.com/v1
      kind: OperatorConfig
      metadata:
        namespace: gmp-public
        name: config
      managedAlertmanager:
        configSecret:
          name: SECRET_NAME
          key: FILE_NAME
      

   Alertmanager 구성을 변경해야 할 경우 이전에 만든 보안 비밀을 업데이트하여 이 Alertmanager의 구성을 수정할 수 있습니다.

   자체 배포되는 Alertmanager

   자체 배포되는 Alertmanager의 규칙 평가자를 구성하려면 다음을 수행합니다.

   1. 수정을 위해 OperatorConfig 리소스를 엽니다.

      kubectl -n gmp-public edit operatorconfig config
      

   2. Alertmanager 서비스로 알림을 전송하도록 리소스를 구성합니다.

      apiVersion: monitoring.googleapis.com/v1
      kind: OperatorConfig
      metadata:
        namespace: gmp-public
        name: config
      rules:
        alerting:
          alertmanagers:
          - name: SERVICE_NAME
            namespace: SERVICE_NAMESPACE
            port: PORT_NAME
      

   Alertmanager가 규칙 평가자와 다른 클러스터에 있는 경우 엔드포인트 리소스를 설정해야 할 수도 있습니다. 예를 들어 OperatorConfig가 Alertmanager 엔드포인트를 엔드포인트 객체 ns=alertmanager/name=alertmanager에서 찾을 수 있다고 표시되는 경우 이 객체를 수동으로 또는 프로그래매틱 방식으로 직접 생성하고 다른 클러스터에서 연결할 수 있는 IP로 채울 수 있습니다. AlertmanagerEndpoints 구성 섹션은 필요한 경우 승인 구성에 대한 옵션을 제공합니다.