開始使用自行部署的集合

本文說明如何設定 Google Cloud Managed Service for Prometheus，並自行部署收集作業。範例應用程式會部署至 Kubernetes 叢集，並由 Prometheus 伺服器監控，後者會將收集到的指標儲存在 Monarch 中。

本文將說明如何執行下列操作：

  • 設定環境和指令列工具。
  • 為啟用 Workload Identity Federation for GKE 的叢集設定服務帳戶。
  • 在 Kubernetes 上執行 Prometheus 二進位檔。
  • 控管要將哪些指標擷取至 Managed Service for Prometheus。
  • 將 Managed Service for Prometheus 與 prometheus-operator 設定整合。
  • 手動編譯及執行 Prometheus 二進位檔。

使用自行部署的資料收集機制時，您可以照常管理 Prometheus 安裝作業。唯一差異在於，您執行的是 Managed Service for Prometheus 的替代二進位檔 gke.gcr.io/prometheus-engine/prometheus:v2.53.5-gmp.1-gke.2，而非上游 Prometheus 二進位檔。

插入式二進位檔提供額外的設定選項，可使用 --export.* 標記。詳情請參閱 --help 選項的輸出內容。本文將說明最重要的選項。

Managed Service for Prometheus 不支援從同盟伺服器或用做遠端寫入接收器的伺服器匯出指標。您可以透過篩選器和本機匯總，複製所有聯盟伺服器功能，包括在將資料傳送至 Monarch 前匯總資料，以減少擷取量。

將資料串流至 Managed Service for Prometheus 會耗用額外資源。如果您自行部署收集器，建議將 CPU 和記憶體限制提高 5 倍，並根據實際用量調整。

如要進一步瞭解代管和自行部署的資料收集機制，請參閱「Managed Service for Prometheus 資料收集」。

事前準備

本節說明執行本文所述工作所需的設定。

設定專案和工具

如要使用 Google Cloud Managed Service for Prometheus，您需要下列資源：

  • Google Cloud 專案已啟用 Cloud Monitoring API。

    • 如果沒有 Google Cloud 專案，請執行下列步驟：

      1. 前往 Google Cloud 控制台的「New Project」(新專案)：

        建立新專案

      2. 在「Project Name」欄位中輸入專案名稱，然後按一下「Create」。

      3. 前往「帳單」：

        前往「帳單」頁面

      4. 如果尚未在頁面頂端選取您剛建立的專案，請立即選取。

      5. 系統會提示您選擇現有的付款資料或是建立新的付款資料。

      新專案預設會啟用 Monitoring API。

    • 如果您已有 Google Cloud 專案，請確認已啟用 Monitoring API：

      1. 前往Google Cloud 控制台的 Monitoring API 程式庫頁面：

        前往「媒體庫」頁面

      2. 選取專案。

      3. 如果程式庫頁面顯示「管理」按鈕，表示 Monitoring API 已啟用。如果看到「啟用」按鈕，表示 API 尚未啟用，請點選「啟用」按鈕啟用。

  • Kubernetes 叢集。如果沒有 Kubernetes 叢集，請按照 GKE 快速入門導覽課程中的操作說明進行。

您還需要下列指令列工具：

  • gcloud
  • kubectl

gcloud 和 kubectl 工具是 Google Cloud CLI 的一部分。如要瞭解如何安裝這些元件，請參閱「管理 Google Cloud CLI 元件」。如要查看已安裝的 gcloud CLI 元件，請執行下列指令：

gcloud components list

設定環境

為避免重複輸入專案 ID 或叢集名稱，請執行下列設定：

  • 請依下列方式設定指令列工具：

    • 將 gcloud CLI 設為參照Google Cloud 專案的 ID：

      gcloud config set project PROJECT_ID

    • 如果是在 GKE 上執行，請使用 gcloud CLI 設定叢集：

      gcloud container clusters get-credentials CLUSTER_NAME --location LOCATION --project PROJECT_ID

    • 否則，請使用 kubectl CLI 設定叢集：

      kubectl config set-cluster CLUSTER_NAME

    如要進一步瞭解這些工具，請參閱下列說明：

設定命名空間

建立 NAMESPACE_NAME Kubernetes 命名空間，用於存放您在範例應用程式中建立的資源。使用這份文件設定 Prometheus 範例時，建議使用命名空間名稱 gmp-test。

執行下列指令來建立命名空間：

kubectl create ns NAMESPACE_NAME

驗證服務帳戶憑證

如果 Kubernetes 叢集已啟用 Workload Identity Federation for GKE，則可以略過本節。

在 GKE 上執行時，Managed Service for Prometheus 會根據 Compute Engine 預設服務帳戶，自動從環境中擷取憑證。預設服務帳戶具備必要權限。如果您沒有為 GKE 使用 Workload Identity Federation，且先前已從預設節點服務帳戶移除 monitoring.metricWriter 和 monitoring.viewer 角色授權，則必須重新新增這些缺少的角色，才能繼續操作。

為 Workload Identity Federation for GKE 設定服務帳戶

如果 Kubernetes 叢集未啟用 Workload Identity Federation for GKE，可以略過本節。

Managed Service for Prometheus 會使用 Cloud Monitoring API 擷取指標資料。如果叢集使用 GKE 適用的工作負載身分聯盟，您必須授予 Kubernetes 服務帳戶 Monitoring API 的權限。本節說明下列事項：

建立及繫結服務帳戶

Managed Service for Prometheus 文件中有多處提到這個步驟。如果您已在先前的作業中執行這個步驟，就不需要重複執行。直接跳到「授權服務帳戶」。

首先，請建立服務帳戶 (如果尚未建立)：

gcloud config set project PROJECT_ID \
&&
gcloud iam service-accounts create gmp-test-sa

然後使用下列指令序列，將 gmp-test-sa 服務帳戶繫結至 NAMESPACE_NAME 命名空間中的預設 Kubernetes 服務帳戶：

gcloud config set project PROJECT_ID \
&&
gcloud iam service-accounts add-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --condition=None \
  --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 」所需的 Monitoring API 角色授予「gmp-test-sa」，以便寫入指標資料。

如果您已在先前的作業中授予 Google Cloud 服務帳戶 特定角色，就不必再次執行這項操作。

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

偵錯 Workload Identity Federation for GKE 設定

如果無法順利使用 Workload Identity Federation for GKE，請參閱驗證 Workload Identity Federation for GKE 設定的說明文件，以及 Workload Identity Federation for GKE 疑難排解指南。

為 GKE 設定 Workload Identity Federation 時，最常見的錯誤來源是錯別字和部分複製貼上，因此我們強烈建議使用這些操作說明中程式碼範例內建的可編輯變數和可點選的複製貼上圖示。

實際工作環境中的 Workload Identity Federation for GKE

本文所述範例會將 Google Cloud 服務帳戶繫結至預設 Kubernetes 服務帳戶，並授予 Google Cloud服務帳戶使用 Monitoring API 的所有必要權限。

在正式環境中，您可能需要採取更精細的方法，為每個元件使用服務帳戶，並盡量減少權限。如要進一步瞭解如何設定服務帳戶來管理工作負載身分，請參閱「使用 Workload Identity Federation for GKE」。

設定自行部署的收集功能

本節說明如何設定及執行使用自行部署收集作業的範例應用程式。

部署範例應用程式

範例應用程式會在 metrics 通訊埠發布 example_requests_total 計數器指標和 example_random_numbers 直方圖指標 (以及其他指標)。應用程式的資訊清單定義了三個副本。

執行下列指令來部署範例應用程式：

kubectl -n NAMESPACE_NAME apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.17.2/examples/example-app.yaml

執行替代的 Prometheus 二進位檔

如要擷取範例應用程式發布的指標資料，請部署 Google 分支版本的 Prometheus 伺服器，並設定該伺服器，以抓取工作負載的指標和自身的指標端點。

  1. 如要部署分叉伺服器，請執行下列指令：

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

    這個部署的 Prometheus 伺服器是上游 Prometheus 二進位檔的精簡分支版本。這個伺服器的運作方式與標準 Prometheus 伺服器相同，但也會將資料擷取至 Managed Service for Prometheus。

    上述資訊清單提供基本工作範例，可將資料傳送至全球資料儲存庫 Monarch。不會永久儲存資料的本機副本。如要瞭解這個預先定義的設定如何運作，以及如何擴充設定，請參閱開放原始碼 Prometheus 設定說明文件。

    預先建構的映像檔僅適用於 Linux 節點。如要擷取在 Windows 節點上執行的目標，請在 Linux 節點上部署伺服器，並將其設定為擷取 Windows 節點上的端點，或自行建構 Windows 的二進位檔。

  2. 確認 Prometheus 伺服器和範例應用程式的 Pod 已成功部署：

    kubectl -n NAMESPACE_NAME get pod

    如果部署成功，您應該會看到類似以下的輸出內容：

    NAME                            READY   STATUS    RESTARTS   AGE
prom-example-84c6f547f5-fglbr   1/1     Running   0          5m
prom-example-84c6f547f5-jnjp4   1/1     Running   0          5m
prom-example-84c6f547f5-sqdww   1/1     Running   0          5m
prometheus-test-0               2/2     Running   1          3m

如果您在 GKE 執行上述作業，還能執行以下操作：

如果您在 GKE 以外的環境中執行作業，則需要建立服務帳戶並授權寫入指標資料，詳情請參閱下一節。

明確提供憑證

在 GKE 上執行時，收集 Prometheus 伺服器會根據節點的服務帳戶或 Workload Identity Federation for GKE 設定，自動從環境中擷取憑證。在非 GKE Kubernetes 叢集中，必須使用旗標或 GOOGLE_APPLICATION_CREDENTIALS 環境變數，明確提供收集 Prometheus 伺服器的憑證。

  1. 將環境設為目標專案：

    gcloud config set project PROJECT_ID

  2. 建立服務帳戶：

    gcloud iam service-accounts create gmp-test-sa

    這個步驟會建立服務帳戶，您可能已在 Workload Identity Federation for GKE 指示中建立該帳戶。

  3. 將必要權限授予服務帳戶：

    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. 開啟 Prometheus StatefulSet 資源進行編輯：

    kubectl -n NAMESPACE_NAME edit statefulset prometheus-test

    1. 將粗體顯示的文字新增至資源：

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

    2. 儲存檔案並關閉編輯器。變更套用後，系統會重新建立 Pod，並開始使用指定的服務帳戶向指標後端進行驗證。

    或者，您也可以使用 GOOGLE_APPLICATION_CREDENTIALS 環境變數設定金鑰檔案路徑，而不使用本範例中設定的旗標。

    自行部署的收集器適用的其他主題

    本節將說明如何執行下列操作：

    • 篩選要匯出至代管服務的資料。
    • 轉換現有的部署設定。
    • 在高可用性模式下執行 Prometheus 二進位檔。
    • 建構並執行替代 Prometheus 二進位檔。
    • 在 Google Cloud外部執行 Managed Service for Prometheus。

    篩選匯出的指標

    如果收集的資料量很多，您可能需要避免部分時間序列傳送至 Managed Service for Prometheus，藉此降低成本。

    您可以在 Prometheus 抓取設定中使用一般指標重新標籤設定。您可以使用重新標籤設定，依據擷取時的標籤比對結果捨棄指標。

    有時您可能想在本機擷取資料，但不想匯出至 Managed Service for Prometheus。如要篩選匯出的指標，可以使用 --export.match 標記。

    這個標記會指定一或多個 PromQL 序列選取器，且可多次使用。如果時間序列符合至少一個旗標中的所有選取器，就會匯出至 Managed Service for Prometheus；也就是說，判斷資格時，單一旗標中的條件會以 AND 運算子連結，不同旗標中的條件則會以 OR 運算子連結。以下範例使用了兩個旗標執行個體：

    ./prometheus \
  --export.match='{job="prometheus"}' \
  --export.match='{__name__=~"job:.+"}' \
  ...

    這項變更會導致系統只匯出「prometheus」工作指標，以及依工作層級彙整的記錄規則所產生的指標 (前提是遵循命名最佳做法)。其他所有序列的樣本則會遭到篩除。根據預設，系統不會指定任何選取器，且會匯出所有時間序列。

    --export.match 旗標的語意與 Prometheus 聯盟的 match[] 參數相同。因此，您可以將聯盟設定遷移至 Managed Service for Prometheus，方法是直接將聯盟伺服器的選取器做為旗標，用於聯盟 Prometheus 伺服器抓取的 Prometheus 伺服器。系統不支援將指標從同盟伺服器匯出至代管服務。

    如要在篩選器中納入 histogram 類型的指標，請務必指定 _count、_sum 和 _bucket 指標。您也可以使用萬用字元比對器，例如選取器 {__name__=~"histogram_metric_.+"}。

    如果您使用 prometheus-operator 程式庫，請使用容器的 EXTRA_ARGS 環境變數設定任何 --export.match 旗標。詳情請參閱「搭配 prometheus-operator 使用」。

    您可以將篩選器標記與本機執行的記錄規則合併，在將資料傳送至 Monarch 前「匯總」資料，藉此降低基數和費用。詳情請參閱「費用控管和歸因」。

    Cloud Monitoring 的「指標管理」頁面提供相關資訊，協助您控管可計費指標的支出金額，同時不影響可觀測性。「指標管理」頁面會回報下列資訊：

    • 以位元和樣本為準的帳單，以及指標網域和個別指標的擷取量。
    • 指標的標籤和基數相關資料。
    • 每個指標的讀取次數。
    • 警告政策和自訂資訊主頁中的指標使用情形。
    • 指標寫入錯誤率。

    您也可以使用「指標管理」頁面排除不必要的指標，藉此省下擷取這些指標的費用。如要進一步瞭解「指標管理」頁面，請參閱「查看及管理指標用量」。

    搭配 prometheus-operator 使用

    Managed Service for Prometheus Prometheus 二進位檔也可搭配 prometheus-operator 管理的現有 GKE Prometheus 部署項目使用。

    如要使用代管服務的二進位檔，請替換 Prometheus 資源中的映像檔規格：

      apiVersion: monitoring.coreos.com/v1
  kind: Prometheus
  metadata:
    name: NAMESPACE_NAME
    namespace: gmp-system
  spec:
    image: gke.gcr.io/prometheus-engine/prometheus:v2.53.5-gmp.1-gke.2
    ...
    replicas: 1
    serviceAccountName: default
    version: v2.35.0
    ...

    如果您位於 Workload Identity Federation for GKE 叢集，且資源中的命名空間或服務帳戶不同，請針對額外的命名空間和 Kubernetes 服務帳戶配對，重複Workload Identity Federation for GKE 指示。

    在非 GKE Kubernetes 叢集上執行時，您需要手動提供憑證。如要提供憑證，請按照下列步驟操作：

    1. 如「明確提供憑證」一文所述，以密碼形式新增適當的服務帳戶金鑰檔案。

    2. 修改 Prometheus 資源，加入以粗體顯示的文字：

        apiVersion: monitoring.coreos.com/v1
  kind: Prometheus
  metadata:
    namespace: NAMESPACE_NAME
    name: example
  spec:
    ...
    secrets:
    - gmp-test-sa
    containers:
    - name: prometheus
      env:
      - name: GOOGLE_APPLICATION_CREDENTIALS
        value: /gmp/key.json
      volumeMounts:
      - name: secret-gmp-test-sa
        mountPath: /gmp
        readOnly: true

    您可以設定容器的 EXTRA_ARGS 環境變數，新增其他旗標，例如指標篩選旗標。這是透過環境變數完成，因為容器規格的 args 區段是由 Prometheus Operator 管理。

    搭配 kube-prometheus 使用

    您可以設定使用熱門 kube-prometheus 程式庫建立的部署作業，以使用 Managed Service for Prometheus。

    Kube-prometheus 在預設命名空間和服務帳戶中，有一些緊密的內部依附元件，因此建議只變更將資料傳送至 Managed Service for Prometheus 時所需的最低欄位數。

    在 manifests/prometheus-prometheus.yaml 中，取代圖片規格並將 replicas 減少至 1，即可關閉高可用性集合：

        apiVersion: monitoring.coreos.com/v1
    kind: Prometheus
    ...
    spec:
      image: gke.gcr.io/prometheus-engine/prometheus:v2.53.5-gmp.1-gke.2
      ...
      replicas: 1
      version: v2.35.0
      ...

    如果您在 GKE 上執行，且未修改節點上的預設服務帳戶，套用修改後的資訊清單後，應該會立即開始將資料傳送至 Managed Service for Prometheus。否則可能需要設定及套用服務帳戶。在 GKE 上執行並使用工作負載身分時，您可能必須在 prometheus-k8s 命名空間中建立並授權 monitoring 服務帳戶。如果是在非 GKE Kubernetes 叢集上執行，請按照 prometheus-operator 專區中的操作說明進行。

    請注意，kube-prometheus 預設會收集大量指標，但其中大部分在 GKE 等代管 Kubernetes 環境中通常都不需要。如要節省擷取費用，您可以自訂 kube-prometheus，只擷取您關心的指標，並積極篩選匯出的指標。

    如需更多建議，請參閱「費用控管和歸因」。

    高可用性部署

    替換用的 Prometheus 二進位檔內建支援高可用性收集作業，可透過領導者選舉機制達成。高可用性模式下的 Prometheus 伺服器會照常收集指標及評估規則，但只有其中一個伺服器會將資料傳送至 Google Cloud Managed Service for Prometheus。

    相同 Prometheus 伺服器的副本一律必須具有相同的設定，包括相同的 external_labels。這項規定與其他系統不同，其他系統會使用特殊外部標籤 (例如 __replica__) 讓副本明顯不同。

    Kubernetes API 伺服器是支援的領導者選舉後端，可透過設定下列標記啟用：

    ./prometheus
  ...
  --export.ha.backend=kube \
  --export.ha.kube.namespace=LEASE_NAMESPACE \
  --export.ha.kube.name=LEASE_NAME

    LEASE_NAMESPACE 和 LEASE_NAME 值會識別租約資源，領導者選舉會透過該資源進行。指向相同資源的所有 Prometheus 伺服器都屬於相同的副本集。Prometheus 部署作業的 Kubernetes 服務帳戶需要讀取及寫入相應 Lease 資源的權限。在 Kubernetes 叢集外部執行 Prometheus 伺服器時，您可以使用 --export.ha.kube.config 旗標提供明確的設定。

    完成後，即可將 replicas 值調高至 2 以上。

    保留的標籤

    Managed Service for Prometheus 會使用六個保留標籤，在 Monarch 中明確識別資源：

    • project_id：與指標相關聯的 Google Cloud 專案 ID。必填。
    • location：資料儲存的實體位置 (Google Cloud 區域)。這個值通常是 GKE 叢集的區域。如果資料是從 AWS 或地端部署作業收集而來，則值可能是最接近的 Google Cloud 區域。必填。
    • cluster：與指標相關聯的 Kubernetes 叢集名稱。如果不是在 Kubernetes 上執行，這可用做任意階層層級，例如執行個體群組。選填，但強烈建議填寫。
    • namespace：與指標相關聯的 Kubernetes 命名空間名稱。 如果不是在 Kubernetes 上執行，這可用做任意階層層級，例如例項子群組。選填，但強烈建議填寫。
    • job：Prometheus 目標的工作標籤 (如已知)；規則評估結果可能為空白。這是必要項目，通常會由 Prometheus 自動新增。
    • instance：Prometheus 目標的執行個體標籤 (如果已知)；規則評估結果可能為空白。這是必要項目，通常會由 Prometheus 自動新增。如果手動設定或重新標記，請勿使用 localhost 等硬式編碼值，否則會導致時間序列衝突。

    在 Google Cloud上執行時，系統會自動為每個指標新增 project_id、location 和 cluster 標籤。

    雖然不建議在 Google Cloud上執行時覆寫 project_id、location、cluster 和 namespace 標籤，但您可以使用 Prometheus 設定的 global.external_labels 區段覆寫這些標籤。詳情請參閱「在Google Cloud 外部執行自行部署的收集作業」。

    如果您使用任何預留標籤做為指標標籤，自行部署的收集作業會將指標標籤做為預留標籤的值。這項功能提供一定程度的彈性，但如果使用 location 標籤參照的不是Google Cloud 區域，可能會導致錯誤。

    設定 statsd_exporter 和其他集中回報指標的匯出工具

    如果您使用 Prometheus 的 statsd_exporter、Istio 的 Envoy、SNMP 匯出工具、Prometheus Pushgateway、kube-state-metrics，或是其他類似的匯出工具，代表其他資源在環境中執行時，會透過這些工具中介並回報指標，因此您需要對匯出工具進行一些小變更，才能搭配 Managed Service for Prometheus 使用。

    如需設定這些匯出工具的操作說明，請參閱「疑難排解」一節中的這則附註。

    二進位檔部署作業

    如要在非容器化環境中執行，可以直接建構替代的 Prometheus 二進位檔。

    建構來源

    如果您有自行編譯 Prometheus 的現有程序，可以將我們的 GitHub 存放區透明地代入程序中。Managed Service for Prometheus 有自己的版本標記擴充功能，可區分發布版本與上游版本。

    如要建構純二進位檔，機器上必須安裝 Go 工具鍊和最新版本的 NPM/Yarn。詳情請參閱「上游建構操作說明」。

    1. 複製存放區：

      git clone https://github.com/GoogleCloudPlatform/prometheus &&
cd prometheus

    2. 查看所需版本標記：

      git checkout v2.53.5-gmp.1

    3. 如要建立 Managed Service for Prometheus tarball，請執行下列指令：

      make build && make tarball

    就目錄結構和功能而言，產生的 tarball 和二進位檔與上游變體完全相容。

    建立及更新指標和標籤的限制

    Managed Service for Prometheus 會對建立新指標，以及為現有指標新增指標標籤，強制執行每分鐘的速率限制。通常只有在首次與 Managed Service for Prometheus 整合時，才會達到這項速率限制，例如將現有的成熟 Prometheus 部署作業遷移至自行部署的收集作業時。這並非資料點的擷取速率限制。只有在建立前所未見的指標，或是在現有指標中新增標籤時，才會套用這項速率限制。

    這項配額是固定的，但只要在每分鐘的限制內建立新指標和指標標籤，任何問題都應會自動解決。

    詳情請參閱「疑難排解」一節。

    在 Google Cloud外部執行自行部署的收集作業

    在 Compute Engine 環境、GKE 環境，或您使用具備足夠授權的帳戶執行 gcloud login 的機器上，您可以執行自行部署的收集作業，無須進一步設定。在 Google Cloud以外，您需要明確提供憑證、用來儲存指標的 project_id，以及用來儲存指標的 location (Google Cloud 區域)。即使在非 Kubernetes 環境中執行，您也應設定 cluster 和 namespace 標籤。

    如要提供服務帳戶金鑰，請使用 --export.credentials-file 標記或 GOOGLE_APPLICATION_CREDENTIALS 環境變數，詳情請參閱「明確提供憑證」。

    建議根據讀取作業的預定租戶模式選擇 project_id。根據您日後規劃的讀取方式 (使用指標範圍)，選擇要儲存指標的專案。如果您不在意，可以將所有內容放在同一個專案中。

    建議您為 location 選擇最靠近部署作業的 Google Cloud 區域。所選 Google Cloud 區域與部署位置的距離越遠，寫入延遲時間就越長，也越容易受到潛在網路問題影響。建議您參閱這份跨多個雲端的區域清單。如果您不在意，可以將所有內容放在一個 Google Cloud 區域。你無法使用 global 做為位置資訊。

    如果是在 Kubernetes 環境中執行，請將 cluster 和 namespace 值設為本機叢集和命名空間。如果是在 Kubernetes 以外的環境中執行，請將這些值設為符合階層架構的值。舉例來說，在 AWS 上執行的 VM 環境中，請將 cluster 值設為 __aws__，並將 namespace 值設為執行個體 ID。您可以透過呼叫本機中繼資料伺服器的重新標記規則，動態填入執行個體 ID。

    如要取得最簡單的運作範例，您可以執行下列指令，在本機執行自我監控的 Prometheus 二進位檔：

    ./prometheus \
  --config.file=documentation/examples/prometheus.yaml \
  --export.label.project-id=PROJECT_ID \
  --export.label.location=REGION \
  --export.label.cluster=CLUSTER_NAME \

    本範例假設您已將 REGION 變數設為 us-central1 等值。

    不過，我們建議您在 Prometheus 設定的 global.external_labels 區段中，為受管理服務設定 export 目標標籤。舉例來說，在 Kubernetes 環境中，您可能會使用下列設定：

    global:
  external_labels:
    project_id: PROJECT_ID
    location: REGION
    cluster: CLUSTER_NAME
    namespace: local-testing

scrape_configs:
  ...

    在 Google Cloud 以外執行 Managed Service for Prometheus 會產生資料傳輸費用。將資料移轉至 Google Cloud會產生費用，從其他雲端移出資料也可能產生費用。您可以透過 --export.compression=gzip 旗標啟用壓縮功能，盡量減少這類費用。

    後續步驟