開始使用自行部署的收集資料

本文說明如何透過自行部署的收集作業，設定 Google Cloud Managed Service for Prometheus。範例應用程式會部署到 Kubernetes 叢集，並由 Prometheus 伺服器監控，而 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.4-gmp.0-gke.1，而非上游 Prometheus 二進位檔。

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

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

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

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

事前準備

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

設定專案和工具

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

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

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

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

        建立新專案

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

      3. 前往「帳單」：

        前往「帳單」頁面

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

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

      新專案預設會啟用 Monitoring API。

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

      1. 前往「API 和服務」：

        前往「API 與服務」

      2. 選取專案。

      3. 點選「啟用 API 和服務」。

      4. 搜尋「監控」。

      5. 在搜尋結果中，按一下「Cloud Monitoring API」。

      6. 如果畫面未顯示「API enabled」(API 已啟用)，請按一下「Enable」(啟用) 按鈕。

  • 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

    • 將 kubectl CLI 設為使用叢集：

      kubectl config set-cluster CLUSTER_NAME

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

設定命名空間

為您建立的資源建立 NAMESPACE_NAME Kubernetes 命名空間，做為範例應用程式的一部分：

kubectl create ns NAMESPACE_NAME

驗證服務帳戶憑證

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

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

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

如果 Kubernetes 叢集未啟用 GKE 適用的工作負載身分聯盟，則可跳過本節。

Managed Service for Prometheus 會使用 Cloud Monitoring API 擷取指標資料。如果叢集使用 GKE 適用的工作負載身分聯盟，您必須授予 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.metricWriter

對 GKE 適用的 Workload Identity 聯盟設定進行偵錯

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

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

實際工作環境中的 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.15.3/examples/example-app.yaml

執行替換的 Prometheus 二進位檔

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

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

    kubectl -n NAMESPACE_NAME apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.15.3/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 伺服器會根據節點的服務帳戶或 GKE 適用的工作負載身分聯盟設定，自動從環境中擷取憑證。在非 GKE 的 Kubernetes 叢集中，必須使用旗標或 GOOGLE_APPLICATION_CREDENTIALS 環境變數，明確提供收集 Prometheus 伺服器的憑證。

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

    gcloud config set project PROJECT_ID

  2. 建立服務帳戶：

    gcloud iam service-accounts create gmp-test-sa

    這個步驟會建立服務帳戶，您可能已在「適用於 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.4-gmp.0-gke.1
    ...
    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.4-gmp.0-gke.1
      ...
      replicas: 1
      version: v2.35.0
      ...

    如果您在 GKE 上執行，且未修改節點上的預設服務帳戶，套用修改後的資訊清單後，應該會立即開始將資料傳送至 Managed Service for Prometheus。否則，您可能必須設定及套用服務帳戶。在 GKE 上執行並使用 workload identity 時，您可能必須在 monitoring 命名空間中建立並授權 prometheus-k8s 服務帳戶。在非 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 exporter、Prometheus Pushgateway、kube-state-metrics，或是其他類似的 exporter，代表環境中執行的其他資源中介並回報指標，則需要對 exporter 進行一些小變更，才能搭配 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.4-gmp.0

    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 region)。即使在非 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 旗標啟用壓縮功能，盡量減少這項費用。

    後續步驟