CloudWatch 客服人員的常見案例 - Amazon CloudWatch

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

CloudWatch 客服人員的常見案例

本節提供不同的案例,概述如何完成 CloudWatch 客服人員的常見組態和自訂任務。

以不同的使用者執行 CloudWatch 代理程式

在 Linux 伺服器上, 預設會以根使用者身分 CloudWatch 執行 。若要讓代理程式以不同的使用者執行,請使用 CloudWatch 代理程式組態檔案中 agent 區段中的 run_as_user 參數。此選項僅供 Linux 伺服器使用。

如果您已使用根使用者身分執行代理,並想要變更為使用不同的使用者身分,請使用下列程序之一。

在執行 Linux 的EC2執行個體上以不同的使用者身分執行 CloudWatch 代理程式
  1. 下載並安裝新的 CloudWatch 代理程式套件。如需詳細資訊,請參閱下載 CloudWatch 代理程式套件

  2. 建立新的 Linux 使用者,或使用 RPM或 DEB 檔案建立cwagent的預設使用者。

  3. 以下列方式之一提供此使用者的登入資料:

    • 如果檔案.aws/credentials存在於根使用者的主目錄中,您必須為要用來執行 CloudWatch 代理程式的使用者建立憑證檔案。這個登入資料檔案會是 /home/username/.aws/credentials。然後,將 common-config.toml 中的 shared_credential_file 參數值設為登入資料檔案的路徑名稱。如需詳細資訊,請參閱(選用) 修改代理或區域資訊的常見組態

    • 如果檔案 .aws/credentials 不存在於根使用者的主目錄中,您可執行下列操作之一:

      • 為您用來執行 CloudWatch 代理程式的使用者建立憑證檔案。這個登入資料檔案會是 /home/username/.aws/credentials。然後,將 common-config.toml 中的 shared_credential_file 參數值設為登入資料檔案的路徑名稱。如需詳細資訊,請參閱(選用) 修改代理或區域資訊的常見組態

      • 將IAM角色連接至執行個體,而不是建立憑證檔案。代理會使用這個角色作為登入資料提供者。

  4. 在 CloudWatch 客服人員組態檔案中,在 agent區段中新增下列行:

    "run_as_user": "username"

    視需要對組態檔案執行其他修改。如需詳細資訊,請參閱 建立 CloudWatch 代理程式組態檔案

  5. 提供使用者必要的許可。使用者必須擁有要收集之日誌檔的讀取 (r) 許可,而且必須擁有日誌檔路徑中每個目錄的 Execute (x) 許可。

  6. 使用您剛才修改的組態檔案啟動代理。

    sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:configuration-file-path
在執行 Linux 的內部部署伺服器上以不同的使用者身分執行 CloudWatch 代理程式
  1. 下載並安裝新的 CloudWatch 代理程式套件。如需詳細資訊,請參閱下載 CloudWatch 代理程式套件

  2. 建立新的 Linux 使用者,或使用 RPM或 DEB 檔案建立cwagent的預設使用者。

  3. 將此使用者的登入資料存放在使用者可以存取的路徑,例如,/home/username/.aws/credentials

  4. common-config.toml 中的 shared_credential_file 參數值設為登入資料檔案的路徑名稱。如需詳細資訊,請參閱(選用) 修改代理或區域資訊的常見組態

  5. 在 CloudWatch 客服人員組態檔案中,在 agent區段中新增下列行:

    "run_as_user": "username"

    視需要對組態檔案執行其他修改。如需詳細資訊,請參閱 建立 CloudWatch 代理程式組態檔案

  6. 提供使用者必要的許可。使用者必須擁有要收集之日誌檔的讀取 (r) 許可,而且必須擁有日誌檔路徑中每個目錄的 Execute (x) 許可。

  7. 使用您剛才修改的組態檔案啟動代理。

    sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:configuration-file-path

CloudWatch 客服人員如何處理稀疏日誌檔案

稀疏檔案是同時具有空白區塊和實際內容的檔案。稀疏檔案透過將代表空白區塊的簡短資訊 (而不是組成區塊的實際空白位元組) 寫入磁碟,以更有效率的方式使用磁碟空間。這使稀疏檔案的實際大小往往比其表面上的大小小得多。

不過, CloudWatch 代理程式處理稀疏檔案的方式,與處理一般檔案的方式不同。當代理程式讀取稀疏檔案時,空白區塊會被視為填滿空位元組的「真實」區塊。因此, CloudWatch 代理程式會將與稀疏檔案的明顯大小一樣多的位元組發佈到 CloudWatch。

設定 CloudWatch 代理程式發佈稀疏檔案可能會導致高於預期 CloudWatch 成本,因此建議您不要這樣做。例如,在 Linux /var/logs/lastlog中通常是非常稀疏的檔案,建議您不要將其發佈至 CloudWatch。

將自訂維度新增至 CloudWatch 客服人員收集的指標

若要新增自訂維度,例如代理程式收集的標籤指標,請將 append_dimensions 欄位新增至列出這些指標的代理程式組態檔案區段。

例如,以下組態檔案範例區段將名為 stackName 的自訂維度與 Prod 值,新增至代理程式收集的 cpudisk 指標。

"cpu":{ "resources":[ "*" ], "measurement":[ "cpu_usage_guest", "cpu_usage_nice", "cpu_usage_idle" ], "totalcpu":false, "append_dimensions":{ "stackName":"Prod" } }, "disk":{ "resources":[ "/", "/tmp" ], "measurement":[ "total", "used" ], "append_dimensions":{ "stackName":"Prod" } }

請記住,無論何時,只要變更代理程式組態檔案,您就必須重新啟動代理程式,才能使變更生效。

多個 CloudWatch 代理程式組態檔案

在 Linux 伺服器和 Windows 伺服器上,您可以設定 CloudWatch 代理程式使用多個組態檔案。例如,您可以使用收集一組指標、日誌和追蹤的常見組態檔,而您一向會從基礎設施的所有伺服器收集它們。然後,您可以使用從某些應用程式或某些情況下收集指標的其他組態檔案。

若要設定,請先建立您要使用的組態檔案。將在相同伺服器上一起使用的任何組態檔案都必須具有不同的檔案名稱。您可以將組態檔案存放在伺服器或參數存放區中。

使用 fetch-config選項啟動 CloudWatch 代理程式,並指定第一個組態檔案。若要在執行中的代理程式附加第二個組態檔案,使用相同命令但請搭配 append-config 選項。會收集組態檔案中列出的所有指標、日誌和追蹤。下列範例命令使用組態存放區作為檔案來說明此案例。第一行使用 infrastructure.json 組態檔案來啟動代理程式,第二個行則附加 app.json 組態檔案。

下列範例命令適用於 Linux。

/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:/tmp/infrastructure.json
/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a append-config -m ec2 -s -c file:/tmp/app.json

下列範例命令適用於 Windows Server。

& "C:\Program Files\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1" -a fetch-config -m ec2 -s -c file:"C:\Program Files\Amazon\AmazonCloudWatchAgent\infrastructure.json"
& "C:\Program Files\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1" -a append-config -m ec2 -s -c file:"C:\Program Files\Amazon\AmazonCloudWatchAgent\app.json"

以下範例組態檔案說明如何使用此功能。第一個組態檔案用於基礎設施中的所有伺服器,第二個組態檔案僅收集來自特定應用程式的日誌,並附加到執行該應用程式的伺服器。

infrastructure.json

{ "metrics": { "metrics_collected": { "cpu": { "resources": [ "*" ], "measurement": [ "usage_active" ], "totalcpu": true }, "mem": { "measurement": [ "used_percent" ] } } }, "logs": { "logs_collected": { "files": { "collect_list": [ { "file_path": "/opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log", "log_group_name": "amazon-cloudwatch-agent.log" }, { "file_path": "/var/log/messages", "log_group_name": "/var/log/messages" } ] } } } }

app.json

{ "logs": { "logs_collected": { "files": { "collect_list": [ { "file_path": "/app/app.log*", "log_group_name": "/app/app.log" } ] } } } }

附加到組態的任何組態檔案都必須具有彼此不同的檔案名稱,且該名稱也必須和初始組態檔案不同。若您搭配具有和代理程式已正在使用組態檔案相同檔案名稱的組態檔案,使用 append-config,則附加命令會覆寫來自第一個組態檔案的資訊,而非附加到其中。即使具有相同檔案名稱的兩個組態檔案位於不同的檔案路徑上,也是如此。

上面的範例顯示了兩個組態檔案的使用,但可以附加到代理程式組態的組態檔案數沒有限制。您也可以混合使用位於伺服器的組態檔案和位於參數存放區的組態。

彙總或彙總 CloudWatch 客服人員收集的指標

若要彙整或累計代理程式收集的指標,請將 aggregation_dimensions 欄位新增至代理程式組態檔案中該指標的區段。

例如,以下組態檔案片段累計 AutoScalingGroupName 維度上的指標。每個 Auto Scaling 群組的所有執行個體的指標都將彙總並可整體檢視。

"metrics": { "cpu":{...} "disk":{...} "aggregation_dimensions" : [["AutoScalingGroupName"]] }

除了以 Auto Scaling 群組名稱彙整之外,若要彙整每個 InstanceIdInstanceType 維度的組合,請新增以下內容。

"metrics": { "cpu":{...} "disk":{...} "aggregation_dimensions" : [["AutoScalingGroupName"], ["InstanceId", "InstanceType"]] }

或者,若要將指標彙整至一個集合,請使用 []

"metrics": { "cpu":{...} "disk":{...} "aggregation_dimensions" : [[]] }

請記住,無論何時,只要變更代理程式組態檔案,您就必須重新啟動代理程式,才能使變更生效。

使用 CloudWatch 代理程式收集高解析度指標

metrics_collection_interval 欄位指定收集指標的時間間隔 (以秒為單位)。藉由為此欄位指定小於 60 的值,就會以高解析度指標來收集指標。

例如,若您的指標都必須是高解析度,且每 10 秒收集一次,請為 metrics_collection_interval 區段下方的 agent 指定 10 作為值,以作為全域指標的收集間隔。

"agent": { "metrics_collection_interval": 10 }

或者,以下範例會設定每秒收集 cpu 指標一次,而所有其他指標則每分鐘收集一次。

"agent":{ "metrics_collection_interval": 60 }, "metrics":{ "metrics_collected":{ "cpu":{ "resources":[ "*" ], "measurement":[ "cpu_usage_guest" ], "totalcpu":false, "metrics_collection_interval": 1 }, "disk":{ "resources":[ "/", "/tmp" ], "measurement":[ "total", "used" ] } } }

請記住,無論何時,只要變更代理程式組態檔案,您就必須重新啟動代理程式,才能使變更生效。

將指標、日誌和追蹤傳送到不同帳戶

若要讓 CloudWatch 代理程式將指標、日誌或追蹤傳送到不同的帳戶,請在傳送伺服器的代理程式組態檔案中指定 role_arn 參數。此role_arn值指定代理程式在將資料傳送至目標帳戶時所使用的目標帳戶中IAM的角色。將指標或日誌交付給目標帳戶時,此角色可讓傳送帳戶擔任在目標帳戶中的對應角色。

您也可以在代理程式組態檔案中指定單獨的 role_arn 字串:一個用於傳送指標,一個用於傳送日誌,一個用於傳送追蹤。

以下範例是組態檔案 agent 區段的一部分,這部分會設定代理程式在將資料傳送給不同帳戶時使用 CrossAccountAgentRole

{ "agent": { "credentials": { "role_arn": "arn:aws:iam::123456789012:role/CrossAccountAgentRole" } }, ..... }

或者,以下範例設定在傳送指標、日誌和追蹤時傳送帳戶所用的不同角色:

"metrics": { "credentials": { "role_arn": "RoleToSendMetrics" }, "metrics_collected": {....
"logs": { "credentials": { "role_arn": "RoleToSendLogs" }, ....

需要政策

當您role_arn在客服人員組態檔案中指定 時,也必須確保傳送和目標帳戶IAM的角色具有特定政策。傳送和目標帳戶的角色都應該要有 CloudWatchAgentServerPolicy。如需將此政策指派給角色的詳細資訊,請參閱 在 Amazon EC2執行個體上建立IAM角色以搭配 CloudWatch 代理程式使用

傳送帳戶的角色也必須包含下列政策。當您編輯角色時,您可以在IAM主控台的許可索引標籤上新增此政策。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sts:AssumeRole" ], "Resource": [ "arn:aws:iam::target-account-ID:role/agent-role-in-target-account" ] } ] }

目標帳戶中的角色必須包含下列政策,以便識別傳送帳戶使用IAM的角色。當您編輯角色時,您可以在IAM主控台的信任關係索引標籤上新增此政策。您在目標帳戶中新增此政策的角色,就是您在 建立IAM角色和使用者以搭配 CloudWatch 客服人員使用 中建立的角色。這個角色是在傳送帳戶使用的政策中以 agent-role-in-target-account 指定的角色。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::sending-account-ID:role/role-in-sender-account" ] }, "Action": "sts:AssumeRole" } ] }

統一 CloudWatch 代理程式與舊版 CloudWatch Logs 代理程式之間的時間戳記差異

相較於先前的 CloudWatch Logs CloudWatch 代理程式,代理程式支援不同的一組時間戳記格式符號。這些差異如下表所示。

兩種代理程式都支援的符號 僅統一 CloudWatch 代理程式支援的符號 僅舊版 CloudWatch Logs 代理程式支援的符號

%A、%a、%b、%B、%d、%f、%H、%l、%m、%M、%p、%S、%y、%Y、%Z、%z

%-d、%-l、%-m、%-M、%-S

%c、%j、%U、%W、%w

如需新 CloudWatch 代理程式支援符號含義的詳細資訊,請參閱 Amazon CloudWatch 使用者指南 中的 CloudWatch 代理程式組態檔案:日誌區段。如需 CloudWatch Logs 代理程式支援符號的相關資訊,請參閱 Amazon CloudWatch Logs 使用者指南 中的代理程式組態檔案