先決條件限制封裝結構、JSON 結構描述和組態設定在中建立多檢查 Canary AWS 管理主控台使用 Synthetics APIs AWS 建立多檢查 Canary 在中建立多檢查 Canary CloudFormation 身分驗證組態疑難排解

建立多檢查藍圖 Canary

Amazon CloudWatch Synthetics 多檢查藍圖透過提供簡單的 JSON 組態，協助您建立 Synthetics Canary。您可以使用步驟式循序方式綁定最多 10 種不同類型的 HTTP/DNS/SSL/TCP 檢查，以節省成本。每個檢查都包含針對檢查結果提供基本驗證的聲明。

多重檢查 Canary 是專為簡單的使用案例而設計，只需要基本檢查，而不需要無周邊瀏覽器。如需更複雜的使用案例，請檢閱 Amazon CloudWatch Synthetics 提供的其他 Canary 類型。

先決條件

必須使用 syn-nodejs-3.0+ 才能建立多檢查 Canary
使用 Authentication and Secrets Manager 組態時，您必須確保 Canary ExecutionRoleArn 允許存取這些秘密的許可
使用 Sigv4 身分驗證時，您必須確保 Canary ExecutionRoleArn 允許許可存取相關角色

限制

HTTP 回應大小不能大於 1 MB
最多 10 個定義的變數。
使用 JSON RFC 時，Checks JSON 可能提供重複的欄位，但只會使用最後一個序列欄位
在中 AWS 管理主控台，多檢查 Canary 預設為顯示多檢查步驟指標，以輕鬆識別每個檢查的可用性。移除檢查時，此圖表可能仍會在可用性圖表中顯示檢查，直到指標停止作用中至少 3 小時為止

封裝結構、JSON 結構描述和組態設定

將用於 Canary 的 JSON Checks 組態必須命名為 blueprint-config.json。組態必須遵循結構描述，並遵循下的指示撰寫 Node.js 多重檢查藍圖的 JSON 組態。

將壓縮blueprint-config.json為 ZIP 檔案，並在下列其中一個建立工作流程中提供它。有synthetics.json組態時，也會壓縮在相同的 ZIP 檔案中。以下是名為的 zip 檔案範例multi-checks.zip。



multi-checks.zip
├── blueprint-config.json
└── synthetics.json

在中建立多檢查 Canary AWS 管理主控台

開啟 Amazon CloudWatch 合成主控台。
選擇 Create Canary (建立 Canary)。
在使用藍圖下，選擇多重檢查。

在設定檢查下，您會看到兩個索引標籤：檢查和 Canary 組態。
選取執行時間版本 syn-nodejs-3.0 或更新版本。
遵循下的程序撰寫 Node.js 多重檢查藍圖的 JSON 組態來描述您要執行的檢查。或者，主控台提供您可以建置的預設 JSON 組態。
選擇 Create Canary (建立 Canary)。

使用 Synthetics APIs AWS 建立多檢查 Canary

使用 CreateCanary API 並在 Code 參數內提供欄位/值，BlueprintTypes="multi-checks"而非 Handler。同時指定 Handler BlueprintTypes和時，ValidationException會顯示。提供的執行時間版本必須是 syn-nodejs-3.0 or later。



aws synthetics create-canary \
    --name my-multi-check-canary \
    --code ZipFile="ZIP_BLOB",BlueprintTypes="multi-checks" \
    --runtime-version syn-nodejs-3.0 \
    ...

// Or if you wanted to use S3 to provide your code.

aws synthetics create-canary \
    --name my-multi-check-canary \
    --code S3Bucket="my-code-bucket",S3Key="my-zip-code-key",BlueprintTypes="multi-checks" \
    ...

在中建立多檢查 Canary CloudFormation

在多檢查 Canary 的 CloudFormation 範本中，在 Code 參數內提供欄位/值，BlueprintTypes="multi-checks"而不是 Handler。同時指定 Handler BlueprintTypes和時，ValidationException會顯示。提供的執行時間版本必須是 syn-nodejs-3.0 or later。

範本範例：



SyntheticsCanary:
    Type: 'AWS::Synthetics::Canary'
    Properties:
      Name: MyCanary
      RuntimeVersion: syn-nodejs-3.0
      Schedule: {Expression: 'rate(5 minutes)', DurationInSeconds: 3600}
      ...
      Code:
        S3Bucket: "my-code-bucket"
        S3Key: "my-zip-code-key"
        BlueprintTypes: ["multi-checks"]
      ...

身分驗證組態

當您的 Canary 對已驗證的端點提出 HTTP 請求時，您可以將藍圖 Canary 的步驟設定為使用四種身分驗證類型之一：基本、API 金鑰、OAuth 用戶端登入資料和 SigV4。與其自行設定請求標頭，您可以在藍圖定義中指定身分驗證類型，而 Synthetics 會遵循指定的身分驗證類型，將提供的身分驗證資訊填入 HTTP 請求的元件。

您可以在藍圖步驟中使用身分驗證區段指定身分驗證類型。您可以指定要使用的身分驗證機制、所選身分驗證機制所需的屬性，以及 Synthetics 會使用提供的資訊來建構 HTTP 請求的身分驗證標頭。

由於以純文字儲存秘密（例如密碼或 API 金鑰）是安全問題，因此 Synthetics 支援與整合 AWS Secrets Manager。當您想要在 Synthetics 藍圖 Canary 中驗證 HTTP 請求時，您可以參考存放身分驗證資訊的秘密，而 Synthetics 會處理擷取秘密並將其快取到您的 Canary 中。此方法為 Synthetics 提供秘密，同時安全地存放秘密，而無需在藍圖組態中以純文字指定秘密。

如需詳細資訊 AWS Secrets Manager，請參閱什麼是 AWS Secrets Manager？

基本身分驗證

Synthetics 實作 RFC 7617 中定義的基本 HTTP 身分驗證機制。程序的運作方式如下：

使用者名稱和密碼對是從藍圖組態提供。
使用者傳遞是透過串連使用者名稱、單一冒號 ("：") 字元和密碼來建立。
user-pass 是 UTF-8 編碼，然後轉換為 base64 編碼字串。
此 base64 編碼的 user-pass 以下列格式在 "Authorization" 標頭中提供：Authorization： Basic {base64-encoded-user-pass}

例如，如果使用者代理程式想要傳送 user-id "Aladdin" 和密碼 "open sesame"，則會使用下列標頭欄位：Authoric： Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

範例組態：



"Authentication": {
    "type": "BASIC",
    "username": MY_USERNAME, // Required
    "password": MY_PASSWORD // Required
}

API 金鑰身分驗證

您可以提供 API 金鑰來驗證 HTTP 請求。當您使用 API 金鑰身分驗證時，您提供的 API 金鑰會放入 "X-API-Key" HTTP 標頭。如果您有自訂資源在標頭中尋找此標頭以外的 API 金鑰標頭，您可以選擇指定不同的標頭名稱，讓 Synthetics 將 API 金鑰放入其中。

範例組態：



"Authentication": {
    "type": "API_KEY",
    "apiKey": S0A1M2P3L4E5, // Required
    "header": X-Specific-Header // Optional, defaults to "X-API-Key"
}

SigV4 身分驗證

AWS SigV4 （簽章第 4 版）是將身分驗證資訊新增至 AWS API 請求的 AWS 簽署通訊協定。若要提出 SigV4-authenticated，您需要指定您要提出請求的區域和服務，以及識別您希望 Canary 在提出此 SigV4 請求時擔任之 IAM 角色的 ARN (AWS 資源名稱）。Synthetics 會擔任 roleArn 中提供的 IAM 角色，並使用它來驗證您的 AWS API 請求。

範例組態：



"Authentication": {
    "type": "SIGV4",
    "region": us-west-2, // Required
    "service": s3, // Required
    "roleArn": arn:AWS:iam:12345678912:role/SampleRole // Required
}

SigV4 考量事項

若要讓 Synthetics 擔任您在 SigV4 身分驗證區段中提供的角色，必須設定連接至該角色的信任政策，以允許 Canary 擔任提供的 roleArn。您需要信任的 AWS 委託人是 Canary 擔任的角色 AWS STS。它採用 aws:sts::{account_running_the_canary}:assumed-role/<canary_name>/<assumed_role_name>arn 格式：。

例如，如果您在帳戶 0123456789012 中有一個名為 test-canary 的 Canary，且其擔任的角色名為 canary-assume-role，則信任政策需要包含此陳述式，Canary 才能正確擔任 roleArn for SigV4 身分驗證：



{
    "Effect": "Allow",
    "Principal": {
        "AWS": "arn:AWS:sts::123456789012:assumed-role/test-canary/"
    },
    "Action": "sts:AssumeRole"
}

OAuth 用戶端憑證

Synthetics 會實作 RFC 6479 第 4.4 節中定義的 OAuth 用戶端憑證授予類型。如果您想要對使用 OAuth 權杖端點發行的承載字符進行身分驗證的端點發出 HTTP 請求，Synthetics 可以代表您請求和管理承載字符。當您使用 OAuth 機制時，Synthetics 會執行下列步驟：

搭配 clientId 和 clientSecret 使用基本身分驗證機制來驗證對 tokenUrl 的請求，這是發出承載字符的端點
如果您提供選用的範圍、對象和資源參數，這些參數會包含在字符請求中
使用 tokenUrl 傳回的存取字符來驗證您的 HTTP 請求
安全地存放從 tokenUrl 傳回的重新整理權杖，以供未來的權杖請求使用

範例組態：



"Authentication": {
    "type": "OAUTH_CLIENT_CREDENTIALS",
    "tokenUrl": ..., // Required
    "clientId": ..., // Required
    "clientSecret": ..., // Required
    "scope": ..., // Optional
    "audience": ..., // Optional
    "resource": ..., // Optional
}

OAuth 考量事項

Synthetics 會在傳回 401 或 407 回應時重新整理 OAuth 權杖。

AWS Secrets Manager 整合

為了避免以純文字形式存放秘密值（例如密碼或 API 金鑰），Synthetics 提供與的整合 AWS Secrets Manager。您可以使用格式參考藍圖組態中的整個秘密值${aws_SECRET:<secret_name>}，或參考特定金鑰 ${aws_SECRET:<secret_name>:<secret_key>}。

例如，如果您有名為 login/basic-auth-credentials 的秘密，請使用下列 JSON 結構存放使用者名稱和密碼：



{
    "username": "Aladdin",
    "password": "open sesame"
}

您可以在藍圖組態中參考使用者名稱和密碼，如下所示，而 Synthetics 會處理擷取秘密值，並使用其金鑰來驗證您的請求：



"Authentication": {
    "type": "BASIC",
    "username": ${AWS_SECRET:login/basic-auth-credentials:username},
    "password": ${AWS_SECRET:login/basic-auth-credentials:password}
}

若要允許 Synthetics 擷取指定的秘密，Canary 擔任的角色 ARN 需要具有 secretsManager：GetSecretValue 許可。如果秘密是使用客戶受管金鑰而非 AWS 受管金鑰 AWS/秘密管理員加密，則您也需要該金鑰的 kms:Decrypt 許可。

範例許可：



{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "secretsmanager:GetSecretValue",
            "Resource": "arn:AWS:secretsmanager:us-east-1:123456789012:secret:secretName-AbCdEf"
        },
        {
            "Effect": "Allow",
            "Action": "kms:Decrypt",
            "Resource": "arn:AWS:kms:us-east-1:123456789012:key/key-id"
        }
    ]
}

疑難排解

常見的故障診斷失敗

多檢查藍圖的基礎程式碼是以 Typescript 撰寫。請參閱 Canary 故障診斷頁面以取得常見故障：故障診斷故障的 Canary。

JSON 檢查組態語法錯誤

當有任何與 Canary 的 JSON 檢查組態相關的語法錯誤時， AWS 管理主控台會在您嘗試建立 Canary 時為您提供失敗原因。如果您使用 API 或建立 Canary CloudFormation，則第一次執行 Canary 時會看到失敗。建議針對多重檢查 Canary 使用安全 Canary 更新工作流程。如需詳細資訊，請參閱執行安全 Canary 更新。

網路或逾時失敗

對於任何與逾時相關的間歇性或一致性故障，網路連線故障（例如 ENOTFOUND、ECONNRESET) 會考慮開啟DEBUG日誌，以便以下執行會提供檢查失敗原因的更多其他詳細資訊。若要這樣做，請提供環境變數 CW_SYNTHETICS_LOG_LEVEL： "DEBUG"。

如果仍有無法偵錯的故障，請考慮聯絡 AWS Support 或檢查 CloudWatch Synthetics 提供的任何其他 Canary 類型是否更符合您的使用案例。

您的瀏覽器已停用或無法使用 Javascript。

您必須啟用 Javascript，才能使用 AWS 文件。請參閱您的瀏覽器說明頁以取得說明。

文件慣用形式

使用 Canary 藍圖

使用適用於 Google Chrome 的 CloudWatch Synthetics Recorder

建立多檢查藍圖 Canary

主題

先決條件

限制

封裝結構、JSON 結構描述和組態設定

在 中建立多檢查 Canary AWS 管理主控台

使用 Synthetics APIs AWS 建立多檢查 Canary

在 中建立多檢查 Canary CloudFormation

身分驗證組態

基本身分驗證

API 金鑰身分驗證

SigV4 身分驗證

SigV4 考量事項

OAuth 用戶端憑證

OAuth 考量事項

AWS Secrets Manager 整合

疑難排解

常見的故障診斷失敗

JSON 檢查組態語法錯誤

網路或逾時失敗

在中建立多檢查 Canary AWS 管理主控台

在中建立多檢查 Canary CloudFormation