ZabbixとCloudWatchを連携させて、EC2のカスタムメトリクスを監視してみた

本記事は夏休みクラウド自由研究2026 8/14付の記事です。

こんにちは。SCSKの上田です。
夏休みクラウド自由研究ということで、久しぶりにブログを書いています。

本日は、Zabbixを使ってCloudWatchのカスタムメトリクスを監視してみようと思います。

ZabbixでCloudWatchを利用してEC2を監視する方法は、以前ブログを投稿しておりますので、そちらもご参照ください。（同じ内容の復習も本記事に含んでおります！）

はじめに：標準テンプレート「AWS by HTTP」
ZabbixからAWSへの接続方法（認証方式）
ステップ1：まずは標準メトリクスが取れるか確認する
ステップ2：EC2からカスタムメトリクスをCloudWatchに送信する
ステップ3：Zabbixでカスタムメトリクスを監視する
注意点とユースケース
1. 注意点
2. ユースケース
おわりに

はじめに：標準テンプレート「AWS by HTTP」

Zabbix 7.0には、AWSのAPIを利用してデータを取得する「AWS by HTTP」というテンプレートが標準で用意されています。

これを利用すると、Zabbixサーバー（またはプロキシ）が標準で用意されたスクリプトを実行してAWS APIを叩き、EC2やRDSなどの情報を自動で収集してくれます。スクリプトを自作しなくて良いのが非常に便利です。

ZabbixからAWSへの接続方法（認証方式）

テンプレートのマクロを見ると、接続するためのいくつかの情報を記入するためのマクロが存在します。

マクロ一覧

特に重要なのは認証方法を選択するマクロ「{$AWS.AUTH_TYPE}」で、環境に合わせた3つの方式を選択できます。

設定値	内容
access_key	IAMユーザーの「アクセスキー」と「シークレットキー」を使用します。一番シンプルで、Zabbixがどこにいても利用可能です。
role_base	Zabbixサーバー自体がEC2上で動いている場合に最適です。EC2に付与されたIAMロールの権限を利用するため、キーの管理が不要でセキュアです。
assume_role	特定のロールを引き受けてアクセスします。マルチアカウント環境などで、監視用アカウントから他アカウントの情報を取る際などに使われます。

基本的には、セキュリティの観点から「role_base」が推奨されますが、オンプレミスのZabbixから監視する場合は「access_key」を使うのが一般的です。

今回は、access_ketで認証するやり方で試してみます。

ステップ1：まずは標準メトリクスが取れるか確認する

まずはZabbixとAWSが正しく通信できているかを確認しましょう。

① AWS側での準備
参照用権限（ReadOnlyAccess など）を持つIAMユーザーを作成し、アクセスキーを発行しておきます。

② Zabbix側でホスト作成
「AWS by HTTP」テンプレートをリンクしたホストを作成し、「継承したマクロとホストマクロ」にて必要な情報を入力します。

{$AWS.AUTH_TYPE}：access_key
{$AWS.ACCESS.KEY.ID}：発行したアクセスキー
{$AWS.SECRET.ACCESS.KEY}：発行したシークレットキー
{$AWS.REQUEST.REGION}：ap-northeast-1

③ ホストのディスカバリルールを確認
今回使用するのは「EC2 instances discovery」なので、それ以外は無効にしておきましょう。

④ 最新データの確認
しばらく待つと、ローレベルディスカバリ（LLD）によってインスタンスが発見され、ホストが登録され、データが取得できるはずです。

データ取得を確認

もし取得できない場合は、認証に失敗している可能性があります。ディスカバリのテストをしてみましょう。

ディスカバリのテストを実施

ステップ2：EC2からカスタムメトリクスをCloudWatchに送信する

このテンプレートでは、標準メトリクスしか監視ができません。次に、監視したい「独自のデータ」をEC2からCloudWatchへ飛ばします。今回は例として、**「httpdプロセスの生存数」**をカスタムメトリクスとして送信してみます。

EC2（Linux）上で以下のコマンドを実行します（AWS CLIがインストールされている前提です）。

# httpdプロセスの数をカウントして変数に代入
PROC_COUNT=$(pgrep -c httpd)

# CloudWatchにデータを送信
# --namespace：任意の名前空間（グループ名）
# --metric-name：メトリクス名
# --dimensions：識別子（ここではインスタンスID）
aws cloudwatch put-metric-data \
--namespace "CustomMetrics/App" \
--metric-name HttpdProcessCount \
--dimensions InstanceId=i-0123456789abcdefg \
--value $PROC_COUNT

※ i-0123456789abcdefg は自身のインスタンスIDに書き換えてください。
※ テストのためコマンドで実行していますが、実際の運用ではCloudWatch Agentを利用して定期的にメトリクスを送るのが良いと思います。

これで、CloudWatch側に「MyCustomApp」という名前空間でデータが蓄積され始めます。

ステップ3：Zabbixでカスタムメトリクスを監視する

続いて、CloudWatchにあるカスタムメトリクスをZabbixで取得します。

標準テンプレート「AWS by HTTP」には、「Get metrics data」という、CloudWatchから値を一括取得するアイテムが含まれています。これを「複製」してカスタムメトリクス専用のアイテムを作るとスムーズです。

① アイテムの複製
名前を「Get metrics data（カスタムメトリクス）」とします。

② スクリプトの編集
AWS API（GetMetricData）に送るスクリプトを、先ほど送信したカスタムメトリクスの内容に合わせて書き換えます。

// --- 修正前 ---
renderPayload: function (period, instance_id) {
var metrics_list = [
'StatusCheckFailed:Count',

// ...（中略）...

'EBSByteBalance %:Percent'
];
var metric_payload = [];
metrics_list.forEach(function (metric) {
            // 標準メトリクスの生成処理
            // ...
});
return metric_payload;

},

これを以下のように修正します。

// --- 修正後 ---
renderPayload: function (period, instance_id) {
var metrics_list = [ /* ...標準メトリクスのリスト... */ ];

var metric_payload = [];
// ①標準メトリクスの処理（ここはそのまま）

metrics_list.forEach(function (metric) {
// ...
});

// ②★ここにカスタムメトリクスを追加！★
metric_payload.push({
'Id': 'cwHttpdProcessCount',
'MetricStat': {
'Metric': {
'Namespace': 'CustomMetrics/App',
'MetricName': 'HttpdProcessCount',
'Dimensions': [
{ 'Name': 'InstanceId', 'Value': instance_id }
]
},
'Period': period,
'Stat': 'Average'
}
});

return metric_payload;
},

③ 該当データを抜き出す監視アイテムを作成します
これも既存の「CPU: Utilization」あたりを複製して作成しましょう。

名前：HttpdProcessCount
キー：aws.ec2.HttpdProcessCount
依存アイテム：Get metrics data（カスタムメトリクス）
保存前処理（JSON Path）：$.[?(@.Label == “CustomMetrics/App HttpdProcessCount”)].Values.first().first()

④ 保存と確認
設定を保存し、少し待ってから 【監視データ】＞【最新データ】 を確認します。

注意点とユースケース

注意点

ZabbixとCloudWatchを組み合わせたAWS監視について、何点か注意点があります。

注意点①：コストについて

AWSでカスタムメトリクスを送信する場合、追加のコストが発生します。（2026年7月時点、東京リージョンで概ね月額0.30USD/メトリクス〜）
また、ZabbixでAPIを呼び出す際にもAPIリクエスト料金が発生します。監視間隔を短くすればするほどコストが発生します。
ZabbixはOSSのため、基本的に使用量はかかりません。しかしCloudWatchを使用する場合、上記のAWS利用料金を意識する必要があります。