受管理的規則評估和警示

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_idclusternamespace 範圍內。舉例來說,上述資源中的 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.15.3/examples/rules.yaml

幾分鐘後,系統就會提供 job:up:sum 指標。 快訊 AlwaysFiring 也會開始觸發。如要瞭解如何將快訊傳送至 Alertmanager,請參閱「Alertmanager 設定」一文。

ClusterRulesGlobalRules 資源提供的介面與 Rules 資源相同,但會將規則套用至更廣泛的範圍。ClusterRules 會使用 project_idcluster 標籤選取資料,而 GlobalRules 會選取查詢指標範圍內的所有資料,且不會限制標籤。

如需所有 Managed Service for Prometheus 自訂資源的參考說明文件,請參閱 prometheus-engine/doc/api reference

將 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 系統指標發出快訊時,也必須使用 GlobalRule。

如果規則未保留 project_idlocation 標籤,系統會預設為叢集的值。

如果是 Managed Service for Prometheus 指標,建議您只在少數情況下使用 GlobalRules,也就是警報可能需要同時跨所有叢集的資料時。如要取得個別部署作業的指標,請使用 Rules 或 ClusterRules 資源,確保評估作業不會納入非預期資料,並提高可靠性。除非規則的目的是要匯總這些標籤,否則強烈建議在規則評估結果中保留 clusternamespace 標籤,否則查詢效能可能會下降,且您可能會遇到基數限制。強烈建議不要移除這兩個標籤。

多專案和全域規則評估

在 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 資源類型,自動建立及管理規則、ClusterRules 和 GlobalRules 資源,這兩種資源類型都可讓您指定任意自訂資源。

如要瞭解如何搭配使用 Google Cloud 與 Terraform,請參閱「Terraform with Google Cloud」。

明確提供憑證

在 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. 儲存檔案並關閉編輯器。套用變更後,系統會重新建立 Pod,並開始使用指定的服務帳戶向指標後端進行驗證。

    評估資源調度規則

    規則評估工具會以單一副本部署的形式執行,並具有固定的資源要求和限制。評估大量規則時,您可能會發現工作負載發生中斷情形,例如 OOMKilled。為解決這個問題,您可以部署 VerticalPodAutoscaler,垂直調度 Deployment 的資源。首先,請確認 Kubernetes 叢集已啟用垂直自動調度 Pod 資源功能。然後套用 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: gzip
    

    Alertmanager 設定

    您可以使用 OperatorConfig 資源,設定受管理規則評估工具將快訊傳送至 Prometheus Alertmanager。除了自行部署的 Alertmanager,您也可以將快訊傳送至自動部署的受管理 Alertmanager。

    Managed Alertmanager

    Managed Service for Prometheus 會部署 Alertmanager 的代管執行個體,並自動設定規則評估工具,將快訊轉送至該執行個體。根據預設,這項設定會使用含有 Alertmanager 設定檔的特定名稱 Kubernetes Secret 設定。

    如要啟用及設定向已部署的 Alertmanager 執行個體回報,請按照下列步驟操作:

    1. 建立包含 Alertmanager 設定的本機設定檔 (請參閱設定範本):

      touch alertmanager.yaml
      
    2. 使用所需的 Alertmanager 設定更新檔案,並在 gmp-public 命名空間中建立名為 alertmanager 的 Secret:

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

    過一會兒,Managed Service for Prometheus 就會擷取新的設定密鑰,並啟用代管 Alertmanager 和您的設定。

    自訂設定密鑰名稱

    受管理 Alertmanager 也支援自訂 Secret 名稱,用於載入設定。如果您有多個設定密鑰,且希望 Alertmanager 執行個體在對應的設定之間切換,這項功能就非常實用。舉例來說,您可能會想根據輪值班表變更警報通知管道,或是想換入實驗性 Alertmanager 設定,測試新的警報路徑。

    如要使用 OperatorConfig 資源指定非預設的 Secret 名稱,請按照下列步驟操作:

    1. 從本機 Alertmanager 設定檔建立 Secret:

      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 設定,可以更新先前建立的 Secret,編輯這個 Alertmanager 的設定。

    自訂外部網址

    您可以設定受管理 Alertmanager 的外部網址,讓快訊通知提供回呼連結至快訊 UI。這相當於使用上游 Prometheus Alertmanager 的 --web.external-url 旗標。

    apiVersion: monitoring.googleapis.com/v1
    kind: OperatorConfig
    metadata:
      namespace: gmp-public
      name: config
    managedAlertmanager:
      externalURL: EXTERNAL_URL
    

    自行部署的 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 位於與規則評估工具不同的叢集中,您可能需要設定 Endpoints 資源。舉例來說,如果 OperatorConfig 指出 Alertmanager 端點位於 Endpoints 物件 ns=alertmanager/name=alertmanager,您可以手動或以程式輔助方式建立這個物件,並從其他叢集填入可連線的 IP。如有需要,您可以在「AlertmanagerEndpoints」設定專區中設定授權選項。

    閒置時節省資源

    如果未設定任何規則、ClusterRules 或 GlobalRules 資源,GKE 會將規則評估工具和 Alertmanager 部署作業縮減為零,為未使用受管理規則或快訊的客戶節省叢集資源。套用新的規則資源時,這些部署作業會自動擴大。您可以套用不執行任何動作的規則資源,強制擴大這些資源。