建立綜合監控項目

本文說明如何建立綜合監控器，測試服務、應用程式、網頁和 API 的可用性、一致性和效能。您為應用程式提供測試。合成監控項會執行該指令碼，並記錄測試結果和延遲等額外資料。如要在測試失敗時收到通知，可以設定快訊政策來監控測試結果。

這項功能僅支援 Google Cloud 專案。 如要進行 App Hub 設定，請選取 App Hub 主專案或啟用應用程式的資料夾管理專案。

關於綜合監控

綜合監控項目會定期執行部署在 Cloud Run 的單一用途第 2 代 Cloud Run 函式。建立綜合監控器時，您會定義 Cloud Run 函式 (必須以 Node.js 編寫) 和執行頻率。舉例來說，您可以使用 Puppeteer，將 Cloud Run 函式設定為與網頁互動。您也可以使用 Axios 模組，設定 Cloud Run 函式與 API 互動。您也可以測試虛擬私有雲網路中的資源。

如要建立 Cloud Run 函式，請使用內嵌編輯器，或是上傳 ZIP 檔案。如果選擇使用內嵌編輯器，可以從提供的架構開始。建立合成監控項後，Cloud Monitoring 會使用排程系統，定期執行 Cloud Run 函式。雖然您會指定 Cloud Run 函式所在的區域，但觸發執行的指令可來自正常運作時間檢查伺服器支援的任何區域。詳情請參閱「列出運作時間檢查伺服器 IP 位址」。

您可以建立快訊政策，在測試失敗時收到通知：

  • 使用 Google Cloud 控制台建立綜合監控項目時，系統預設會建立快訊政策。您提供通知管道。預設快訊政策會設為在連續兩次以上測試失敗時通知您。

  • 使用 Cloud Monitoring API 建立合成監控器時，您必須建立快訊政策，監控 Cloud Run 函式執行的 Cloud Run 資源的 uptime_check/check_passed 指標類型。

執行頻率注意事項

您可以設定 Cloud Run 函式的執行頻率。如要判斷執行頻率，請考量服務的服務等級目標 (SLO)。如要找出潛在的 SLO 違規事項，您需要經常執行測試。 不過，服務的 SLO 並非唯一考量。您也需要考量執行率如何轉換為服務負載和成本。每次執行都會對服務造成負載，因此執行 Cloud Run 函式的頻率越高，對服務造成的負載就越大。運作時間檢查的預設執行間隔為一分鐘，僅供參考。

執行頻率也會決定測試失敗時，您收到通知的速度。如果測試連續失敗兩次，監控服務就會開啟事件並傳送通知。舉例來說，如果執行頻率為 5 分鐘，則可能要等 10 分鐘，才會出現兩項測試失敗的結果。第二次測試失敗後，您會收到通知。

Cloud Run 函式程式碼範例

如需範本和範例，請參閱綜合監控功能的範例。 您可以從這些範例著手製作 Cloud Run 函式。 如果您是經驗豐富的開發人員，可以考慮使用 Gemini 生成綜合監控作業用的程式碼，藉此縮短開發時間。使用 Gemini 生成程式碼的功能目前為公開預先發布版。

使用 Google Cloud 控制台建立合成監控項時，可以選取一般範本，這個範本已設定為收集外送 HTTP 要求的追蹤記錄和記錄資料。這項解決方案採用 OpenTelemetry auto-instrumentation-node 模組和 winston 記錄器。由於這項功能依賴開放原始碼產品，追蹤記錄和記錄檔資料的結構可能會有所變更。因此，收集到的追蹤記錄和記錄資料應僅用於偵錯。

您可以自行實作方法，收集傳出 HTTP 要求的追蹤和記錄資料。如需自訂做法的範例，請參閱 SyntheticAutoInstrumentation 類別。

Cloud Run 函式設定

設定 Cloud Run 函式時，您必須指定執行階段、建構作業、連線和安全性設定，或接受預設設定：

  • 分配的記憶體預設值可能不夠。建議您將這個欄位設為至少 2 GiB。

  • Cloud Run 函式的預設輸入資料移轉設定是允許所有流量。你可以使用這項設定，或限制更嚴格的設定。

    允許所有流量後，Cloud Run 函式執行的第一階段驗證 (在網路層級進行) 一律會通過。第二階段的驗證會判斷呼叫端是否已獲准執行 Cloud Run 函式。授權取決於呼叫者的 Identity and Access Management (IAM) 角色。根據預設，Cloud Monitoring 已獲准執行 Cloud Run 函式。如要瞭解如何查看或修改輸入資料傳輸設定，請參閱「輸入設定」。

Cloud Run 函式限制

  • Cloud Run 函式名稱不得包含底線。

  • 只有在使用一般範本時，才能收集連出 HTTP 要求的追蹤和記錄資料。

  • 系統僅支援 HTTP 函式。如果您使用Google Cloud 控制台建立合成監控器，系統會提供查詢網址的預設函式。預設函式的來源可在 generic-synthetic-nodejs Git 存放區中找到，您可以修改該來源。

    如要瞭解 HTTP 函式，請參閱「撰寫 HTTP 函式」。

  • 如果您使用 API，部署指令必須指定 Cloud Run 函式為第 2 代。如果您使用Google Cloud 控制台，系統會為您處理部署作業。詳情請參閱「部署 Cloud Run 函式」。

  • 執行階段環境僅限 Node.js。詳情請參閱「節點」。支援的 Node.js 版本如下：12、14、16、18 和 20。

綜合監控收集的資料

本節說明系統為合成監控器收集的資料。如要瞭解如何查看執行結果，請參閱「探索綜合監控結果」。

執行記錄

系統會收集每個綜合監控作業的執行結果記錄。這類資料包括：

  • 記錄一段時間內執行作業成功或失敗次數的時間序列。

  • 記錄程式碼執行時間的時間序列。系統不會記錄函式的執行時間。延遲時間資料會以 uptime_check/request_latency 時間序列的形式，寫入 Cloud Run 函式執行的 Cloud Run 資源。這項資料的圖表會顯示在「綜合監控詳細資料」頁面。

  • 記錄包含合成監控執行作業的相關資訊，例如測試和失敗詳細資料。可用的記錄取決於 Cloud Run 函式。舉例來說，如果您使用 Mocha 範本，記錄就會包含測試是否通過、測試時間長度等資訊。如果包含堆疊追蹤，則會列出失敗的程式碼行、錯誤類型和錯誤訊息。

  • (選用) 連出 HTTP 要求的追蹤記錄和記錄。如要瞭解如何收集這項資料，請參閱「要求延遲時間」。

Cloud Run 函式指標和記錄

Cloud Run 函式的指標和記錄。這項資料是由 Cloud Run 函式收集，包括每秒執行次數、執行時間和函式的記憶體用量。

要求延遲時間

Cloud Trace 會自動收集並儲存合成監控器發出的 HTTP 要求延遲時間資料。

如要收集合成監控器發出的傳出 HTTP 要求追蹤、記錄和延遲時間資料，請務必使用一般範本。詳情請參閱綜合監控功能的樣本。

事前準備

在將儲存合成監控項目的 Google Cloud 專案中，完成下列步驟：

  1. 如要取得必要權限，以便使用 Google Cloud 控制台查看及修改合成監控器，請要求管理員授予您專案的下列 IAM 角色：

    如要進一步瞭解如何授予角色，請參閱「管理專案、資料夾和機構的存取權」。

    您或許還可透過自訂角色或其他預先定義的角色取得必要權限。

  2. Enable the Cloud Monitoring API, Artifact Registry API, Cloud Build API, Cloud Functions API, Cloud Logging API, Pub/Sub API, and Cloud Run Admin API APIs.

    Enable the APIs

  3. 確認 Google Cloud 專案包含預設的 Compute Engine 服務帳戶。啟用 Compute Engine API 時，系統會建立這個服務帳戶，名稱類似於 12345-compute@developer.gserviceaccount.com。

    前往 Google Cloud 控制台的「Service Accounts」(服務帳戶) 頁面：

    前往「Service Accounts」(服務帳戶)

    如果您是使用搜尋列尋找這個頁面，請選取子標題為「IAM & Admin」的結果。

    如果預設的 Compute Engine 服務帳戶不存在，請按一下「建立服務帳戶」，然後完成對話方塊。

  4. 確認預設的 Compute Engine 服務帳戶或您建立的服務帳戶，已獲派「編輯者」角色 (roles/editor)。

    如要查看授予服務帳戶的角色，請按照下列步驟操作：

    1. 前往 Google Cloud 控制台的「IAM」IAM頁面：

      前往 IAM

      如果您是使用搜尋列尋找這個頁面，請選取子標題為「IAM & Admin」的結果。

    2. 選取「包含 Google 提供的角色授權」。
    3. 如果合成監控項使用的服務帳戶未列出，或尚未獲派包含 Cloud Trace 代理者角色 (roles/cloudtrace.agent) 權限的角色，請將這個角色授予服務帳戶。
  5. 設定要用來接收通知的通知管道。建議您建立多種通知管道，詳情請參閱「建立及管理通知管道」和「由 API 建立及管理通知管道」。

  6. Select the tab for how you plan to use the samples on this page:

    Console

    When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

    gcloud

      In the Google Cloud console, activate Cloud Shell.

      Activate Cloud Shell

      At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

      Terraform

      如要在本機開發環境中使用本頁的 Terraform 範例，請安裝並初始化 gcloud CLI，然後使用使用者憑證設定應用程式預設憑證。

      1. Install the Google Cloud CLI.

      2. If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

      3. To initialize the gcloud CLI, run the following command: 

        gcloud init

      4. If you're using a local shell, then create local authentication credentials for your user account: 

        gcloud auth application-default login

        You don't need to do this if you're using Cloud Shell.

        If an authentication error is returned, and you are using an external identity provider (IdP), confirm that you have signed in to the gcloud CLI with your federated identity.

      詳情請參閱 Google Cloud 驗證說明文件中的「 為本機開發環境設定 ADC」。

      REST

      如要在本機開發環境中使用本頁的 REST API 範例，請使用您提供給 gcloud CLI 的憑證。

        After installing the Google Cloud CLI, initialize it by running the following command: 

        gcloud init

        If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

      詳情請參閱 Google Cloud 驗證說明文件中的「Authenticate for using REST」。

      建立綜合監控項目

      控制台

      使用 Google Cloud 控制台建立綜合監控項目時，系統會部署新的 Cloud Run 函式 (第 2 代)，並建立該 Cloud Run 函式的監控項目。您無法建立綜合監控項目來監控現有的 Cloud Run 函式。

      1. 請確認您已啟用必要 API、專案包含預設的 Compute Engine 服務帳戶，且該帳戶已獲派「編輯者」角色 (roles/editor)。詳情請參閱「事前準備」一節。

      2. 前往 Google Cloud 控制台的 「Synthetic monitoring」(綜合監控) 頁面：

        前往「綜合監控」

        如果您是使用搜尋列尋找這個頁面，請選取子標題為「Monitoring」的結果。

      3. 在 Google Cloud 控制台的工具列中，選取您的 Google Cloud 專案。如為「App Hub」設定，請選取 App Hub 主機專案或已啟用應用程式的資料夾管理專案。
      4. 選取「建立綜合監控項目」。

      5. 選取 Cloud Run 函式的範本：

        • 自訂合成監控項：如要收集外送 HTTP 要求的記錄資料或追蹤資料，請使用這個範本。

        • Mocha 綜合監控：編寫 Mocha 測試套件時，請使用這個範本。

        • 失效連結檢查工具：使用這個範本測試 URI，以及在該 URI 找到的可設定連結數量。如要瞭解這個檢查工具的欄位，請參閱「建立失效連結檢查工具」。

      6. 輸入監控器名稱。

      7. 選用：更新「回應逾時」、「檢查頻率」，並新增使用者定義的標籤。

      8. 執行下列其中一個步驟：

      9. 在 Cloud Run 函式對話方塊中，執行下列操作：

        1. 輸入顯示名稱並選取區域。區域內的名稱不得重複。

        2. 在「執行階段、建構作業、連線和安全性設定」專區中，執行下列操作：

          • 查看預設設定，並視需要更新。

          • 在「執行階段服務帳戶」欄位中，選取服務帳戶。

        3. 編輯生成的程式碼，或為 Cloud Run 函式撰寫/上傳程式碼：

          • 如要編輯產生的程式碼，請輸入自己的程式碼，或載入預設的範例函式，然後選取「內嵌編輯器」。範例函式會根據先前選取的範本，將要求傳送至特定網址。你可以修改預設功能。

          • 如要從本機系統載入 ZIP 檔案，請選取「ZIP 上傳」。

            如果您從本機系統上傳 ZIP 檔案，也必須為該檔案指定 Cloud Storage bucket。如果沒有適當的 Cloud Storage 值區，請建立一個。

          • 如要從 Cloud Storage 載入 ZIP 檔，請選取「ZIP from Cloud Storage」(Cloud Storage 中的 ZIP 檔)，然後選取儲存空間值區，再選取要載入的 ZIP 檔。

            您也可以使用 Google Cloud 控制台的 Cloud Run 函式頁面建立函式。如要建立監控該 Cloud Run 函式副本的合成監控器，請前往「來源」分頁，然後點選「下載 zip」。接著即可上傳 ZIP 檔案。

        4. 按一下「套用函式」。

      10. 設定快訊政策：

        1. 選用：更新警告政策名稱和失敗時間長度，系統才會傳送通知。

        2. 新增通知管道。

      11. 點選「建立」。

        系統會建構並部署您定義的 Cloud Run 函式 (第 2 代)，並建立綜合監控項目。

      gcloud

      使用 Google Cloud CLI 或 Cloud Monitoring API 建立合成監控項時，您會將函式名稱傳遞至 API 呼叫。因此，您只能建立綜合監控項目，監控現有的 Cloud Run 函式。

      1. 請確認您已啟用必要 API、專案包含預設的 Compute Engine 服務帳戶，且該帳戶已獲派「編輯者」角色 (roles/editor)。詳情請參閱「事前準備」一節。
      2. 使用 gcloud config set 指令設定預設專案，藉此設定 Google Cloud CLI：

        gcloud config set project PROJECT_ID

        執行上一個指令前，請先取代下列項目：

        • PROJECT_ID：專案的 ID。如要進行 App Hub 設定，請選取 App Hub 主專案或啟用應用程式的資料夾管理專案。
      3. 編寫及部署第 2 代 Cloud Run 函式。

        舉例來說，如要在 Google Cloud/synthetics-sdk-nodejs 存放區中部署 synthetics-sdk-nodejs 範例，請執行下列操作：

        1. 複製存放區並前往原始碼所在位置：

          git clone https://github.com/GoogleCloudPlatform/synthetics-sdk-nodejs.git
cd synthetics-sdk-nodejs/samples/generic-synthetic-nodejs

        2. 使用 gcloud functions deploy 指令部署 Cloud Run 函式：

          gcloud functions deploy FUNCTION_NAME \
--gen2 --region="us-west2" --source="." \
--entry-point=SyntheticFunction --trigger-http --runtime=nodejs18

          在 gcloud functions deploy 指令中，執行下列操作：

          • 確認 FUNCTION_NAME 欄位的值在部署區域內不得重複。

          • 加上 --gen2 旗標，並設定部署地區。

          • 將 --entry-point 欄位設為下列值：

            • Mocha：SyntheticMochaSuite
            • 非 Mocha：SyntheticFunction。

          • 將 --runtime 欄位設為 nodejs18。

          • 加上 --trigger-http 旗標。

          • 如不想使用預設設定 (允許所有流量)，請設定 --ingress-settings 欄位。

          Cloud Run 函式會建構並部署 Cloud Run 函式。Google Cloud CLI 指令的結果包含函式的相關資訊，包括完整名稱：

          name: projects/PROJECT_ID/locations/REGION/functions/FUNCTION_NAME

          如要進一步瞭解如何部署函式，請參閱「部署 Cloud Run 函式」。

        如要列出 Google Cloud 專案中的 Cloud Run 函式，請使用 gcloud functions list 指令：

        gcloud functions list

        這項呼叫的回應是項目清單，每個項目都會列出一個 Cloud Run 函式：

        NAME: function-1
STATE: ACTIVE
TRIGGER: HTTP Trigger
REGION: us-west2
ENVIRONMENT: 2nd gen

        如要找出特定 Cloud Run 函式的完整名稱，請執行 gcloud monitoring uptime describe 指令。

      4. 如要建立綜合監控作業，請執行 gcloud monitoring uptime create 指令：

        gcloud monitoring uptime create DISPLAY_NAME --synthetic-target=TARGET

        執行上一個指令前，請先取代下列項目：

        • DISPLAY_NAME：合成監控器的名稱。
        • TARGET：Cloud Run 函式的完整名稱。

      5. 建立快訊政策。

        由於快訊政策設定較為複雜，建議您前往 Google Cloud 控制台的「Synthetic monitors」(合成監控) 頁面，使用相關選項建立快訊政策。採用這種做法時，系統會為您填入大部分的快訊政策欄位。如要使用Google Cloud 控制台建立快訊政策，請按一下「綜合監控」頁面的「建立政策」。

        如果您打算使用 Google Cloud CLI 或 Cloud Monitoring API，請按照下列方式設定條件的篩選器：

        "filter": "resource.type = \"cloud_run_revision\" AND
            metric.type = \"monitoring.googleapis.com/uptime_check/check_passed\" AND
            metric.labels.check_id = \"CHECK_ID\"",

        這項條件會監控綜合監控器寫入的uptime_check/check_passed時間序列。請務必將 CHECK_ID 替換為合成監控項的 ID，該 ID 包含在建立指令的回應資料中。

        如要瞭解如何建立快訊政策，請參閱使用 API 建立快訊政策。

      Terraform

      如要瞭解如何套用或移除 Terraform 設定，請參閱「基本 Terraform 指令」。 詳情請參閱 Terraform供應商參考說明文件。

      如要建立綜合監控項目和快訊政策來監控這項檢查，請按照下列步驟操作：

      1. 安裝及設定 Terraform，如要進行 App Hub 設定，請選取 App Hub 主專案或啟用應用程式的資料夾管理專案。

      2. 請確認您已啟用必要 API、專案包含預設的 Compute Engine 服務帳戶，且該帳戶已獲派「編輯者」角色 (roles/editor)。詳情請參閱「事前準備」一節。

      3. 編輯 Terraform 設定檔並新增 google_storage_bucket 資源，然後套用變更。

        下列程式碼會在 US 位置定義 Cloud Storage bucket：

        resource "google_storage_bucket" "gcf_source" {
   name = "gcf-v2-source-9948673986912-us"
   location = "US"
   uniform_bucket_level_access = true
}

      4. 編輯 Terraform 設定檔並新增 google_storage_bucket_object 資源，然後套用變更。

        這個資源會指定值區中的物件名稱，以及本機系統上的 ZIP 檔案位置。舉例來說，套用下列程式碼後，名為 example-function.zip 的檔案就會新增至儲存空間值區：

        resource "google_storage_bucket_object" "object" {
   name = "example-function.zip"
   bucket = google_storage_bucket.gcf_source.name
   source = "generic-synthetic-node.js.zip"
}

      5. 編輯 Terraform 設定檔並新增 google_cloudfunctions2_function 資源，然後套用變更。

        請確認 google_cloudfunctions2_function 資源指定了 Node.js 執行階段，以及綜合監控器使用的進入點。舉例來說，套用下列程式碼時，系統會部署名為 sm-central1 的函式：

        resource "google_cloudfunctions2_function" "central1" {
   name = "sm-central1"
   location = "us-central1"

   build_config {
      runtime = "nodejs20"
      entry_point = "SyntheticFunction"
      source {
            storage_source {
               bucket = google_storage_bucket.gcf_source.name
               object = google_storage_bucket_object.object.name
            }
      }
   }

   service_config {
      max_instance_count = 1
      available_memory = "256Mi"
      timeout_seconds  = 60
   }
}

      6. 如要建立合成監控器，請編輯 Terraform 設定檔並新增 google_monitoring_uptime_check_config 資源，然後套用變更。

        針對這項資源，請指定 synthetic_monitor 區塊：

        resource "google_monitoring_uptime_check_config" "synthetic" {
   display_name = "sm-central1"
   timeout = "30s"

   synthetic_monitor {
      cloud_function_v2 {
            name = google_cloudfunctions2_function.central1.id
      }
   }
}

      7. 選用：建立通知管道和快訊政策。

        下列步驟會使用 Google Cloud 主控台建立通知管道和快訊政策。這種做法可確保快訊政策只監控綜合監控項目產生的資料。

        1. 如要建立通知管道，請按照下列步驟操作：

          1. 前往 Google Cloud 控制台的 「Alerting」(警告) 頁面：

            前往「Alerting」(快訊)

            如果您是使用搜尋列尋找這個頁面，請選取子標題為「Monitoring」的結果。

          2. 選取「管理通知管道」。
          3. 前往要新增的管道類型，按一下「新增」，然後完成對話方塊。

        2. 如要建立快訊政策，請按照下列指示操作：

          1. 前往 Google Cloud 控制台的 「Synthetic monitoring」(綜合監控) 頁面：

            前往「綜合監控」

            如果您是使用搜尋列尋找這個頁面，請選取子標題為「Monitoring」的結果。

          2. 找出合成監控器，選取「更多」圖示 ，然後選取「新增快訊政策」。
          3. 在對話方塊中，前往「通知和名稱」部分，展開「通知管道」，然後進行選取。
          4. 為快訊政策命名，然後按一下「建立政策」。

      REST

      使用 Google Cloud CLI 或 Cloud Monitoring API 建立合成監控項時，您會將函式名稱傳遞至 API 呼叫。因此，您只能建立綜合監控項目，監控現有的 Cloud Run 函式。

      1. 請確認您已啟用必要 API、專案包含預設的 Compute Engine 服務帳戶，且該帳戶已獲派「編輯者」角色 (roles/editor)。詳情請參閱「事前準備」一節。
      2. 使用 gcloud config set 指令設定預設專案，藉此設定 Google Cloud CLI：

        gcloud config set project PROJECT_ID

        執行上一個指令前，請先取代下列項目：

        • PROJECT_ID：專案的 ID。如要進行 App Hub 設定，請選取 App Hub 主專案或啟用應用程式的資料夾管理專案。
      3. 編寫及部署第 2 代 Cloud Run 函式。

        舉例來說，如要在 Google Cloud/synthetics-sdk-nodejs 存放區中部署 synthetics-sdk-nodejs 範例，請執行下列操作：

        1. 複製存放區並前往原始碼所在位置：

          git clone https://github.com/GoogleCloudPlatform/synthetics-sdk-nodejs.git
cd synthetics-sdk-nodejs/samples/generic-synthetic-nodejs

        2. 使用 gcloud functions deploy 指令部署 Cloud Run 函式：

          gcloud functions deploy FUNCTION_NAME \
--gen2 --region="us-west2" --source="." \
--entry-point=SyntheticFunction --trigger-http --runtime=nodejs18

          在 gcloud functions deploy 指令中，執行下列操作：

          • 確認 FUNCTION_NAME 欄位的值在部署區域內不得重複。

          • 加上 --gen2 旗標，並設定部署地區。

          • 將 --entry-point 欄位設為下列值：

            • Mocha：SyntheticMochaSuite
            • 非 Mocha：SyntheticFunction。

          • 將 --runtime 欄位設為 nodejs18。

          • 加上 --trigger-http 旗標。

          • 如不想使用預設設定 (允許所有流量)，請設定 --ingress-settings 欄位。

          Cloud Run 函式會建構並部署 Cloud Run 函式。Google Cloud CLI 指令的結果包含函式的相關資訊，包括完整名稱：

          name: projects/PROJECT_ID/locations/REGION/functions/FUNCTION_NAME

          如要進一步瞭解如何部署函式，請參閱「部署 Cloud Run 函式」。

        如要列出 Google Cloud 專案中的 Cloud Run 函式，請使用 gcloud functions list 指令：

        gcloud functions list

        這項呼叫的回應是項目清單，每個項目都會列出一個 Cloud Run 函式：

        NAME: function-1
STATE: ACTIVE
TRIGGER: HTTP Trigger
REGION: us-west2
ENVIRONMENT: 2nd gen

        如要找出特定 Cloud Run 函式的完整名稱，請執行 gcloud monitoring uptime describe 指令。

      4. 如要建立綜合監控作業，請按照下列步驟操作：

        1. 按一下 projects.uptimeCheckConfigs.create 開啟該方法的 API 參考頁面。
        2. 按一下「試用」開啟 APIs Explorer。

        3. 設定下列欄位，然後執行指令。

          • 父項欄位：要建立綜合監控作業的專案。 如要進行 App Hub 設定，請選取 App Hub 主專案或啟用應用程式的資料夾管理專案。這個欄位的格式如下：

            projects/PROJECT_ID

          • 在要求主體中，指定下列項目：

            • displayName：設為合成監控項目的顯示名稱。
            • syntheticMonitor：設為 Cloud Run 函式的完整名稱。

          如果成功，API 呼叫的回應會類似下列內容：

          {
"name": "projects/myproject/uptimeCheckConfigs/17272586127463315332",
"displayName": "MyMonitor",
...
"syntheticMonitor": {
 "cloudFunctionV2": {
    "name": "projects/myproject/locations/us-west2/functions/function-1",
    "cloudRunRevision": {
    "type": "cloud_run_revision",
    "labels": {
       "project_id": "myproject",
       "configuration_name": "",
       "location": "us-west2",
       "revision_name": "",
       "service_name": "function-1"
    }
    }
 }
}
}

      5. 建立快訊政策。

        由於快訊政策設定較為複雜，建議您前往 Google Cloud 控制台的「Synthetic monitors」(合成監控) 頁面，使用相關選項建立快訊政策。採用這種做法時，系統會為您填入大部分的快訊政策欄位。如要使用Google Cloud 控制台建立快訊政策，請按一下「綜合監控」頁面的「建立政策」。

        如果您打算使用 Google Cloud CLI 或 Cloud Monitoring API，請按照下列方式設定條件的篩選器：

        "filter": "resource.type = \"cloud_run_revision\" AND
            metric.type = \"monitoring.googleapis.com/uptime_check/check_passed\" AND
            metric.labels.check_id = \"CHECK_ID\"",

        這項條件會監控綜合監控器寫入的uptime_check/check_passed時間序列。請務必將 CHECK_ID 替換為合成監控項的 ID，該 ID 包含在建立指令的回應資料中。

        如要瞭解如何建立快訊政策，請參閱使用 API 建立快訊政策。

      定價

      一般來說，Cloud Monitoring 系統指標是免費的，但外部系統、代理程式或應用程式的指標則否。系統會根據擷取的位元組數或樣本數，對可計費指標收費。

      如要進一步瞭解 Cloud Monitoring 定價，請參閱下列文件：

      排解綜合監控問題

      本節提供相關資訊，協助您排解合成監控器問題。

      啟用 API 後顯示的錯誤訊息

      您開啟綜合監控作業的建立流程，系統會提示您啟用至少一個 API。啟用 API 後，會顯示類似以下的訊息：

      An error occurred during fetching available regions: Cloud Functions API has
not been used in project PROJECT_ID before or it is disabled.

      錯誤訊息建議您確認 API 已啟用，然後建議您稍候並重試操作。

      如要確認 API 是否已啟用，請前往專案的「APIs & Services」(API 和服務) 頁面：

      前往「API 與服務」頁面

      確認 API 已啟用後，即可繼續建立流程。API 啟用作業透過後端傳播後，系統就會自動解決問題。

      系統未追蹤連出 HTTP 要求

      您可以設定綜合監控器，收集輸出 HTTP 要求的追蹤記錄資料。您的追蹤資料只會顯示一個範圍，類似於下列螢幕截圖：

      Cloud Trace 只顯示一項追蹤記錄。

      如要解決這個問題，請確認服務帳戶已獲派 Cloud Trace 代理者角色 (roles/cloudtrace.agent)。編輯者角色 (roles/editor) 也足夠。

      如要查看授予服務帳戶的角色，請按照下列步驟操作：

      1. 前往 Google Cloud 控制台的「IAM」IAM頁面：

        前往 IAM

        如果您是使用搜尋列尋找這個頁面，請選取子標題為「IAM & Admin」的結果。

      2. 在 Google Cloud 控制台的工具列中，選取您的 Google Cloud 專案。如為「App Hub」設定，請選取 App Hub 主機專案或已啟用應用程式的資料夾管理專案。
      3. 選取「包含 Google 提供的角色授權」。

      4. 如果合成監控器使用的服務帳戶未列出，或未獲授包含 Cloud Trace 代理者角色 (roles/cloudtrace.agent) 權限的角色，請將這個角色授予服務帳戶。

        如果您不知道服務帳戶名稱，請在導覽選單中選取「服務帳戶」。

      「處理中」狀態

      「綜合監控」頁面會列出狀態為 In progress 的綜合監控。狀態為 In progress 表示合成監控項是最近建立的，因此沒有任何資料可供顯示，或是函式部署失敗。

      如要判斷函式是否部署失敗，請嘗試下列做法：

      • 請確認 Cloud Run 函式名稱不含底線。如果存在底線，請移除底線並重新部署 Cloud Run 函式。

      • 開啟綜合監控的「綜合監控詳細資料」頁面。

        如果看到下列訊息，請刪除合成監控器。

        Cloud Function not found for this Synthetic monitor. Please confirm it exists or delete this monitor.

        錯誤訊息指出函式已遭刪除，因此綜合監控項目無法執行該函式。

      • 開啟函式的 Cloud Run functions 頁面。如要從「綜合監控詳細資料」頁面開啟這個頁面，請按一下「程式碼」，然後按一下函式名稱。

        如果看到類似下列內容的訊息，表示函式部署失敗。

        This function has failed to deploy and will not work correctly. Please edit and redeploy

        如要解決這項失敗問題，請查看函式程式碼並修正錯誤，避免函式無法建構或部署。

      建立綜合監控器時，部署及執行函式可能需要幾分鐘的時間。

      警告狀態

      「綜合監控」會列出狀態為 Warning 的綜合監控。Warning 狀態表示執行結果不一致。這可能表示測試的設計有問題，或是測試的內容行為不一致。

      未通過狀態

      「綜合監控」清單會列出狀態為 Failing 的綜合監控項目。如要進一步瞭解失敗原因，請查看最近的執行記錄。

      • 如果顯示錯誤訊息「Request failed with status code 429」，表示 HTTP 要求的目標拒絕了指令。如要解決這項失敗問題，請變更綜合監控項目的目標。

        端點 https://www.google.com 會拒絕綜合監控發出的要求。

      • 如果失敗傳回的執行時間為 0ms，則 Cloud Run 函式可能記憶體不足。如要解決這項失敗問題，請編輯 Cloud Run 函式，然後將記憶體至少增加到 2 GiB，並將 CPU 欄位設為 1。

      無法刪除綜合監控項目

      您使用 Cloud Monitoring API 刪除合成監控器，但 API 呼叫失敗，並傳回類似下列內容的回應：

      {
  "error": {
    "code": 400,
    "message": "Request contains an invalid argument.",
    "status": "INVALID_ARGUMENT",
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.DebugInfo",
        "detail": "[ORIGINAL ERROR] generic::invalid_argument: Cannot delete check 1228258045726183344. One or more alerting policies is using it.Delete the alerting policy with id projects/myproject/alertPolicies/16594654141392976482 and any other policies using this uptime check and try again."
      }
    ]
  }
}

      如要解決失敗問題，請刪除監控綜合監控結果的快訊政策，然後刪除綜合監控。

      後續步驟