Google Cloud Managed Service for Prometheus는 Prometheus 호환 규칙 평가 및 알림을 지원합니다. 이 문서에서는 관리 규칙 평가를 설정하는 방법을 설명합니다.
규칙 평가
Managed Service for Prometheus는 전역 Prometheus 백엔드의 컨텍스트에서 규칙을 안전하게 작성할 수 있게 해주어 대규모 조직의 다른 사용자 데이터와 혼용되지 않도록 방지하는 규칙 평가자 구성요소를 제공합니다. 이 구성요소는 Kubernetes 클러스터에서 실행될 때 관리 컬렉션의 일부로 자동으로 배포됩니다.
Managed Service for Prometheus 측정항목과 Cloud Monitoring 측정항목 모두에 대한 규칙 및 알림을 작성할 수 있습니다. Cloud Monitoring 측정항목에 대한 규칙을 작성할 때는 GlobalRules 리소스를 사용해야 합니다.
규칙
관리 규칙-평가자는 규칙 리소스를 사용하여 기록 및 알림 규칙을 구성합니다. 다음은 예시 규칙 리소스입니다.
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.12.0/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 리소스를 사용하여 측정항목 범위 내의 모든 프로젝트에서 Managed Service for 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 리소스를 통해 명시적으로 제공되어야 합니다.
컨텍스트를 대상 프로젝트에 설정합니다.
gcloud config set project PROJECT_ID
서비스 계정을 만듭니다.
gcloud iam service-accounts create gmp-test-sa
서비스 계정에 필요한 권한을 부여합니다.
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
서비스 계정에 대해 키를 만들고 다운로드합니다.
gcloud iam service-accounts keys create gmp-test-sa-key.json \ --iam-account=gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com
키 파일을 GKE 클러스터 외의 클러스터에 보안 비밀로 추가합니다.
kubectl -n gmp-public create secret generic gmp-test-sa \ --from-file=key.json=gmp-test-sa-key.json
수정을 위해 OperatorConfig 리소스를 엽니다.
kubectl -n gmp-public edit operatorconfig config
굵게 표시된 텍스트를 리소스에 추가합니다.
apiVersion: monitoring.googleapis.com/v1 kind: OperatorConfig metadata: namespace: gmp-public name: config rules: credentials: name: gmp-test-sa key: key.json또한 관리형 컬렉션이 작동하도록 이러한 사용자 인증 정보를collection섹션에 추가해야 합니다.파일을 저장하고 편집기를 닫습니다. 변경사항이 적용되고 포드가 다시 생성된 후 제공된 서비스 계정을 사용하여 측정항목 백엔드에 대해 인증을 시작합니다.
규칙 평가 확장
규칙 평가자는 리소스 요청과 한도가 고정된 단일 복제본 배포로 실행됩니다. 많은 수의 규칙을 평가할 때 OOMKilled되는 경우와 같은 워크로드 중단이 발생할 수 있습니다. 이 문제를 완화하기 위해
VerticalPodAutoscaler를 배포하여 배포를 수직 확장할 수 있습니다. 먼저 Kubernetes 클러스터에 수직형 포드 자동 확장이 사용 설정되어 있는지 확인합니다. 그런 다음 다음과 같은VerticalPodAutoscaler리소스를 적용합니다.apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: rule-evaluator namespace: gmp-system spec: resourcePolicy: containerPolicies: - containerName: evaluator controlledResources: - memory maxAllowed: memory: 4Gi minAllowed: memory: 16Mi mode: Auto targetRef: apiVersion: apps/v1 kind: Deployment name: rule-evaluator updatePolicy: updateMode: Auto자동 확장 처리 상태를 확인하여 자동 확장 처리가 작동하는지 확인할 수 있습니다.
kubectl get vpa --namespace gmp-system rule-evaluator
자동 확장 처리가 작동하면 'PROVIDED' 열에서 워크로드의 리소스 권장사항을 계산했다고 보고합니다.
NAME MODE CPU MEM PROVIDED AGE rule-evaluator Auto 2m 11534336 True 30m
구성 압축
규칙 리소스가 많으면 ConfigMap 공간이 부족할 수 있습니다. 이 문제를 해결하려면 OperatorConfig 리소스에서
gzip압축을 사용 설정합니다.apiVersion: monitoring.googleapis.com/v1 kind: OperatorConfig metadata: namespace: gmp-public name: config features: config: compression: gzipAlertmanager 구성
OperatorConfig 리소스를 사용하여 Prometheus Alertmanager로 알림을 전송하도록 관리 규칙 평가자를 구성합니다. 자체 배포되는 Alertmanager 외에도 자동으로 배포되는 관리형 Alertmanager로 알림을 전송할 수 있습니다.
관리형 Alertmanager
Prometheus용 관리형 서비스는 규칙 평가자가 자동으로 알림을 전달하도록 구성되는 Alertmanager의 관리형 인스턴스를 배포합니다. 기본적으로 이 구성은 Alertmanager 구성 파일이 포함된 특별하게 명명된 Kubernetes 보안 비밀로 설정됩니다.
배포된 Alertmanager 인스턴스에 대해 보고를 사용 설정하고 구성하려면 다음을 수행합니다.
Alertmanager 설정이 포함된 로컬 구성 파일을 만듭니다(샘플 구성 템플릿 참조).
touch alertmanager.yaml
원하는 Alertmanager 설정을 사용하여 파일을 업데이트하고
gmp-public네임스페이스에alertmanager보안 비밀을 만듭니다.kubectl create secret generic alertmanager \ -n gmp-public \ --from-file=alertmanager.yaml
잠시 후 Prometheus용 관리형 서비스가 새 구성 보안 비밀을 선택하고 해당 설정을 사용해서 관리형 Alertmanager를 사용 설정합니다.
구성 보안 비밀 이름 맞춤설정
관리형 Alertmanager는 구성 로드를 위해 커스텀 보안 비밀 이름을 지원합니다. 이 기능은 구성 보안 비밀이 여러 개 있고 Alertmanager 인스턴스를 해당 구성으로 전환하려는 경우에 유용합니다. 예를 들어 긴급 대기 교대 근무조 순환에 따라 알림 채널을 변경하거나 새로운 알림 경로를 테스트하도록 실험적인 Alertmanager 구성에서 스왑을 수행해야 할 수 있습니다.
OperatorConfig 리소스를 사용하여 기본값이 아닌 보안 비밀 이름을 지정하려면 다음을 수행합니다.
로컬 Alertmanager 구성 파일에서 보안 비밀을 만듭니다.
kubectl create secret generic SECRET_NAME \ -n gmp-public \ --from-file=FILE_NAME
수정을 위해 OperatorConfig 리소스를 엽니다.
kubectl -n gmp-public edit operatorconfig config
관리형 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 구성을 수정하면 됩니다.
외부 URL 맞춤설정
알림이 해당 알림 UI에 콜백 링크를 제공할 수 있도록 관리형 Alertmanager의 외부 URL을 구성할 수 있습니다. 이는 업스트림 Prometheus Alertmanager의
--web.external-url플래그를 사용하는 것과 같습니다.apiVersion: monitoring.googleapis.com/v1 kind: OperatorConfig metadata: namespace: gmp-public name: config managedAlertmanager: externalURL: EXTERNAL_URL
자체 배포되는 Alertmanager
자체 배포되는 Alertmanager의 규칙 평가자를 구성하려면 다음을 수행합니다.
수정을 위해 OperatorConfig 리소스를 엽니다.
kubectl -n gmp-public edit operatorconfig config
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 구성 섹션에서는 필요한 경우 승인 구성 옵션을 제공합니다.