[小ネタ] WindowsのCloudWatch Agentで設定の適用に失敗したときの挙動を確認してみた
こんにちは、林です。
Windows ServerのEC2にCloudWatch Agentを入れて、設定ファイルを amazon-cloudwatch-agent-ctl.ps1 の fetch-config で適用しました。ユーザーデータやSSM Run Commandでこの作業を自動化する場合、設定の適用に失敗したことをどう検知するかを決めておく必要があります。
設定が適用されたかどうかを status の出力で判断できるのか気になったので、失敗のパターンごとに挙動を確認してみました。
検証環境
| 項目 | 内容 |
|---|---|
| OS | Windows Server 2025 日本語版 |
| CloudWatch Agent | 1.300073.0b1828 |
| 導入方法 | SSMドキュメント AWS-ConfigureAWSPackage |
| 設定ファイルの配置先 | C:\ProgramData\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent.json |
| 実行方法 | SSM Run Command(AWS-RunPowerShellScript) |
| 実行前の状態 | エージェントを停止し、Configs フォルダを空にする |
設定の適用には以下のコマンドを使います。
& 'C:\Program Files\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1' `
-a fetch-config -m ec2 `
-c file:'C:\ProgramData\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent.json' -s
検証パターン
設定ファイルの状態を変えて、4パターンで fetch-config を実行しました。
参考として、fetch-config を実行せずに amazon-cloudwatch-agent-ctl.ps1 -m ec2 -a start でエージェントを起動した場合も確認しています。
| No | パターン | 設定ファイルの状態 |
|---|---|---|
| 1 | 設定ファイルなし | 指定したパスにファイルが存在しない |
| 2 | JSON構文エラー | 末尾に余分なカンマがある |
| 3 | 設定値の型エラー | 配列であるべき measurement に文字列を指定 |
| 4 | 正しい設定ファイル | エラーなし |
| 参考 | 設定ファイルなしで -a start |
fetch-config を実行せずにエージェントを起動 |
各パターンで確認した項目は以下の4つです。
- 終了コード(
$LASTEXITCODE) - PowerShellの例外
statusの出力Configsフォルダの内容
amazon-cloudwatch-agent-ctl.ps1 では、設定ファイルの検証はエージェント本体の実行ファイル(amazon-cloudwatch-agent.exe)が行い、サービスの起動はスクリプト内の処理で行われます。
設定ファイルの検証エラーは実行ファイルの終了コード($LASTEXITCODE)に、サービスの起動失敗はPowerShellの例外として出力されます。
そのため、終了コードと例外の両方を確認項目にしています。
検証結果
| No | パターン | 終了コード | 例外 | status |
configstatus |
Configs |
|---|---|---|---|---|---|---|
| 1 | 設定ファイルなし | -1 | あり | stopped | not configured | なし |
| 2 | JSON構文エラー | 0 | あり | stopped | configured | file_amazon-cloudwatch-agent.json |
| 3 | 設定値の型エラー | 1 | なし | stopped | not configured | file_amazon-cloudwatch-agent.json.tmp |
| 4 | 正しい設定ファイル | 0 | なし | running | configured | file_amazon-cloudwatch-agent.json |
| 参考 | 設定ファイルなしで -a start |
0 | なし | running | configured | default |
結果から3つのことが分かりました。
status は適用に失敗しても正常に見える
設定ファイルなしで -a start すると、以下の出力とともに既定の設定でエージェントが起動されました。
amazon-cloudwatch-agent is not configured. Applying amazon-cloudwatch-agent default configuration.
このときの status は、正しい設定ファイルを適用したときと同じでした。
{
"status": "running",
"starttime": "2026-09-24T05:19:38",
"configstatus": "configured",
"version": "1.300073.0b1828"
}
status が running、configstatus が configured でも、配置した設定ファイルが適用されているとは限りません。
失敗の判定には終了コードと例外の両方が必要
終了コードで失敗と判定できたのは、設定ファイルなし(-1)と設定値の型エラー(1)でした。
JSON構文エラーは 0 のままでした。
例外で失敗と判定できたのは、設定ファイルなしとJSON構文エラーでした。
設定値の型エラーでは例外が出ませんでした。
スクリプトで失敗を判定するには、終了コードと例外の両方を確認する必要があります。
JSON構文エラーは fetch-config の検証を通るが、サービスは起動しない
JSON構文エラーは、fetch-config の検証でエラーになりません。
検証を行う config-translator(amazon-cloudwatch-agent.exe のサブコマンド)は、JSONを読めなかった設定ファイルを「設定ファイルなし」として扱い、既定の設定で検証を通します。
unable to scan config dir C:\ProgramData\Amazon\AmazonCloudWatchAgent\Configs with error: unable to parse json, error: invalid character '}' looking for beginning of object key string
No json config files found, use the default one
I! Valid Json input schema.
Configuration validation first phase succeeded
このため終了コードは 0 になり、エージェントが読み込む設定ファイル(amazon-cloudwatch-agent.toml)には既定の設定が書かれました。
JSONが不正なときに既定の設定が使われる挙動については、GitHubのIssueにLinuxでの報告がありました。
一方で、サービスの起動時には、サービスとして登録されている start-amazon-cloudwatch-agent.exe が Configs フォルダの設定ファイルをもう一度検証します。こちらの検証では同じJSONの不正でエラーになり、サービスは起動されませんでした。
unable to scan config dir C:\ProgramData\Amazon\AmazonCloudWatchAgent\Configs with error: unable to parse json, error: invalid character '}' looking for beginning of object key string
E! config-translator process exited with non-zero status: 99
fetch-config で例外が出たのは、この起動失敗によるものです。検証は成功として通り、その後のサービス起動で失敗します。
適用結果の判定方法
C:\ProgramData\Amazon\AmazonCloudWatchAgent\Configs フォルダのファイル名で判定します。
Get-ChildItem 'C:\ProgramData\Amazon\AmazonCloudWatchAgent\Configs'
Configs の内容 |
状態 |
|---|---|
file_amazon-cloudwatch-agent.json |
配置した設定ファイルが取り込まれている |
default |
既定の設定で動いている |
file_amazon-cloudwatch-agent.json.tmp のみ、または空 |
取り込みに失敗している |
ただし、JSON構文エラーの場合は、不正な設定ファイルがそのまま file_amazon-cloudwatch-agent.json として取り込まれるため、ファイル名では見分けられません。
このパターンでは、fetch-config の例外と、status が stopped であることで判定します。
スクリプトに組み込む場合は、例外・終了コード・Configs フォルダの3段で判定します。
$ctl = 'C:\Program Files\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1'
$cfg = 'C:\ProgramData\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent.json'
# 1. 例外(設定ファイルなし、JSON構文エラー)
try {
& $ctl -a fetch-config -m ec2 -c "file:$cfg" -s
} catch {
throw "fetch-config failed: $($_.Exception.Message)"
}
# 2. 終了コード(設定値の型エラー)
if ($LASTEXITCODE -ne 0) {
throw "fetch-config failed with exit code $LASTEXITCODE"
}
# 3. Configs フォルダ(既定の設定で動いていないか)
$applied = Get-ChildItem 'C:\ProgramData\Amazon\AmazonCloudWatchAgent\Configs' -Name
if ($applied -notcontains 'file_amazon-cloudwatch-agent.json') {
throw "config not applied. Configs: $($applied -join ', ')"
}
この判定をユーザーデータやSSM Run Commandのスクリプトに入れておくと、適用に失敗したときにスクリプトがエラーで終了するため、実行結果で失敗が分かります。
まとめ
WindowsのCloudWatch Agentで、設定の適用に失敗したときの挙動を確認しました。
statusは、既定の設定で動いていても、正しい設定ファイルを適用したときと同じrunning/configuredを返す- 失敗の種類によって、終了コードは -1 / 0 / 1 と変わり、例外が出る場合と出ない場合がある
- JSON構文エラーは
fetch-configの検証を通り、サービス起動時の再検証で失敗する Configsフォルダのファイル名で、既定の設定(default)か、配置した設定ファイル(file_amazon-cloudwatch-agent.json)かを見分けられる
status だけでは設定の適用を確認できないので、自動化するときは例外・終了コード・Configs フォルダの3段で判定する必要があります。
この記事がどなたかの参考になれば幸いです。最後までご覧いただきありがとうございました!
参考







