CloudWatchの新機能「pipelines OTelメトリクス処理」を試してみた
はじめに
2026年6月30日、Amazon CloudWatch pipelinesがOpenTelemetry(OTel)メトリクスの処理・エンリッチに対応しました。
CloudWatch pipelinesはフルマネージドのテレメトリデータ処理サービスです。今回のアップデートにより、OTelメトリクスの取り込みパス上で属性の追加・削除・リネームなどの変換処理を、インフラ管理なしで適用できるようになりました。
| 観点 | Before | After(pipelines利用) |
|---|---|---|
| ラベル追加方法 | アプリ計装修正 or カスタムCollector構築 | パイプラインYAML設定のみ |
| インフラ管理 | OTel Collector / 中間サーバーの運用 | フルマネージド、パイプライン処理自体の追加料金なし |
| 適用スコープ | アプリ単位 | 対象アカウント内の該当メトリクスに一括適用 |
| 事前テスト | 検証環境でのデプロイが必要 | test-telemetry-pipeline でドライラン |
本記事では、ALB(Application Load Balancer)のOTelメトリクスに対してパイプラインでラベルを追加し、PromQLで反映を確認するまでの手順を紹介します。
前提条件:
- OTel Vended Metric Enrichmentが有効であること(
aws cloudwatch get-otel-enrichmentでStatus: Running)。有効化の手順は公式ドキュメントを参照 - AWS CLI v2(
aws observabilityadminサブコマンドが利用可能なバージョン)
検証内容
パイプライン設定の作成
以下のYAML設定を作成しました。
pipeline:
source:
cloudwatch_metrics:
format: otlp
selection_criteria:
- match_all:
- 'instrumentation_scope.name == "cloudwatch.aws/elasticloadbalancing"'
processor:
- add_attributes:
attributes:
- key: resource.attributes["team"]
value: "platform"
- key: resource.attributes["cost_center"]
value: "engineering"
sink:
- cloudwatch_metrics: {}
- source:
cloudwatch_metricsを指定し、format: otlpでOTelメトリクスを対象とする - selection_criteria:
instrumentation_scope.nameでALBのメトリクスのみを選択する。OTelエンリッチメントされたAWSサービスメトリクスはcloudwatch.aws/<service>という命名規則になっている - processor:
add_attributesでresource.attributesにカスタムラベルを追加する - sink: 本記事の構成では
cloudwatch_metricsに出力する
バリデーション
validate-telemetry-pipeline-configuration で構文を確認します。設定ファイルはJSON形式で渡します。
# config.json を作成
cat > config.json << 'EOF'
{
"Body": "pipeline:\n source:\n cloudwatch_metrics:\n format: otlp\n selection_criteria:\n - match_all:\n - 'instrumentation_scope.name == \"cloudwatch.aws/elasticloadbalancing\"'\n processor:\n - add_attributes:\n attributes:\n - key: resource.attributes[\"team\"]\n value: \"platform\"\n - key: resource.attributes[\"cost_center\"]\n value: \"engineering\"\n sink:\n - cloudwatch_metrics: {}\n"
}
EOF
aws observabilityadmin validate-telemetry-pipeline-configuration \
--region ap-northeast-1 \
--configuration file://config.json
ドライランテスト
test-telemetry-pipeline でサンプルデータを流して変換結果を事前確認できます。
aws observabilityadmin test-telemetry-pipeline \
--region ap-northeast-1 \
--signal-type METRIC \
--configuration file://config.json \
--records '[{"Data": "<OTLPメトリクスJSON>", "Type": "JSON"}]'
ALBのvended metricsを模したテストデータを入力した結果です。
:::detailsテスト入力(OTLP JSON)
{
"resourceMetrics": [{
"resource": {
"attributes": [
{"key": "cloud.provider", "value": {"stringValue": "aws"}},
{"key": "cloud.region", "value": {"stringValue": "ap-northeast-1"}},
{"key": "cloud.resource_id", "value": {"stringValue": "arn:aws:elasticloadbalancing:ap-northeast-1:XXXXXXXXXXXX:loadbalancer/app/test-alb/12345"}}
]
},
"scopeMetrics": [{
"scope": {"name": "cloudwatch.aws/elasticloadbalancing"},
"metrics": [{
"name": "RequestCount",
"sum": {
"dataPoints": [{
"asInt": "100",
"timeUnixNano": "1782882000000000000",
"attributes": [
{"key": "LoadBalancer", "value": {"stringValue": "app/test-alb/12345"}},
{"key": "AvailabilityZone", "value": {"stringValue": "ap-northeast-1a"}}
]
}],
"aggregationTemporality": 1,
"isMonotonic": true
}
}]
}]
}]
}
:::
:::detailsテスト出力(変換後)
{
"resourceMetrics": [{
"resource": {
"attributes": [
{"key": "cloud.provider", "value": {"stringValue": "aws"}},
{"key": "cloud.region", "value": {"stringValue": "ap-northeast-1"}},
{"key": "cloud.resource_id", "value": {"stringValue": "arn:aws:elasticloadbalancing:ap-northeast-1:XXXXXXXXXXXX:loadbalancer/app/test-alb/12345"}},
{"key": "team", "value": {"stringValue": "platform"}},
{"key": "cost_center", "value": {"stringValue": "engineering"}}
]
},
"scopeMetrics": [{
"scope": {"name": "cloudwatch.aws/elasticloadbalancing"},
"metrics": [{
"name": "RequestCount",
"sum": {
"aggregationTemporality": 1,
"dataPoints": [{
"asInt": "100",
"attributes": [
{"key": "LoadBalancer", "value": {"stringValue": "app/test-alb/12345"}},
{"key": "AvailabilityZone", "value": {"stringValue": "ap-northeast-1a"}}
],
"timeUnixNano": "1782882000000000000"
}],
"isMonotonic": true
}
}]
}]
}]
}
:::
変換結果は期待どおりで、team と cost_center の属性が追加されつつ、メトリクス名やdatapoint属性はそのまま保持されています。
パイプラインの作成
デプロイします。
aws observabilityadmin create-telemetry-pipeline \
--region ap-northeast-1 \
--name "elb-otel-enrich-demo" \
--configuration file://config.json \
--tags '{"purpose":"blog-demo"}'
{
"Arn": "arn:aws:observabilityadmin:ap-northeast-1:XXXXXXXXXXXX:telemetry-pipeline/XXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
}
ステータスを確認します。
aws observabilityadmin list-telemetry-pipelines --region ap-northeast-1
{
"PipelineSummaries": [{
"Name": "elb-otel-enrich-demo",
"Status": "ACTIVE",
"ConfigurationSummary": {
"Sources": [{"Type": "cloudwatch_metrics"}],
"Processors": ["add_attributes"],
"ProcessorCount": 1,
"Sinks": ["cloudwatch_metrics"]
}
}]
}
パイプラインが ACTIVE 状態になりました。
PromQLでの確認
パイプライン適用後、PromQLでラベルが追加されたメトリクスを照会します。PromQL APIは https://monitoring.<region>.amazonaws.com/api/v1/query で、SigV4署名付きHTTPリクエストで利用します。
awscurl --service monitoring --region ap-northeast-1 -X POST \
"https://monitoring.ap-northeast-1.amazonaws.com/api/v1/query" \
-d 'query=RequestCount{LoadBalancer=~".*"}' \
-H "Content-Type: application/x-www-form-urlencoded"
なお、resource.attributes に追加した属性は、PromQL上では @resource. プレフィックス付き(例: @resource.team)で参照されます。
本検証では、パイプライン作成から約30秒後に反映が確認できました(反映までの時間は状況により変動する可能性があります)。
{
"status": "success",
"data": {
"resultType": "vector",
"result": [{
"metric": {
"@aws.account": "XXXXXXXXXXXX",
"@aws.region": "ap-northeast-1",
"@instrumentation.@name": "cloudwatch.aws/elasticloadbalancing",
"@resource.cloud.resource_id": "arn:aws:elasticloadbalancing:ap-northeast-1:XXXXXXXXXXXX:loadbalancer/app/my-app-alb/XXXXXXXXXXXXXXXX",
"@resource.cost_center": "engineering",
"@resource.team": "platform",
"AvailabilityZone": "ap-northeast-1c",
"LoadBalancer": "app/my-app-alb/XXXXXXXXXXXXXXXX",
"__name__": "RequestCount",
"__temporality__": "delta",
"__type__": "Sum"
},
"value": [1782882912.884, "58"]
}]
}
}
@resource.team: "platform" と @resource.cost_center: "engineering" が、パイプラインで追加されたラベルです。今回のクエリで返った合計12系列(複数のAZ・TargetGroupの組み合わせ)すべてに、追加したラベルが付与されていました。
追加したラベルは、sum by を使ってチーム単位に集計することもできます。なお、ラベル名に @ や . を含む場合はダブルクォートで囲む必要があります。
awscurl --service monitoring --region ap-northeast-1 -X POST \
"https://monitoring.ap-northeast-1.amazonaws.com/api/v1/query" \
-d 'query=sum by ("@resource.team") (RequestCount{LoadBalancer=~".*"})' \
-H "Content-Type: application/x-www-form-urlencoded"
{"status":"success","data":{"resultType":"vector","result":[{"metric":{"@resource.team":"platform"},"value":[1782884478.325,"475"]}]}}
team: "platform" に紐づくALBメトリクスが集計され、12系列の合計値が返っています。
Vended metrics 保護の動作確認
メトリクスパイプラインのプロセッサ一覧と適用可否は後述の表を参照してください。add_attributes 以外の破壊系プロセッサにはvended metrics保護が組み込まれており、AWSサービスメトリクスには適用されずパススルーされます。
公式ドキュメントによると、instrumentation_scope.name が cloudwatch.aws/ で始まるメトリクスに対しては、破壊系プロセッサはパススルーされます。
test-telemetry-pipeline で実際にこの動作を確認しました。
rename_metrics の適用結果比較
vended metricsには破壊系プロセッサが適用されず、パススルーされます。以下は rename_metrics で確認した結果です。
| 対象 | scope.name | 入力メトリクス名 | 出力メトリクス名 | 結果 |
|---|---|---|---|---|
| ALBメトリクス | cloudwatch.aws/elasticloadbalancing |
RequestCount |
RequestCount |
vended metricsのためパススルー(未適用) |
| カスタムメトリクス | my-app/metrics |
RequestCount |
elb.request.count |
正しく適用された |
vended metricsに対しては保護機能が実際に機能していることが確認できました。設定ミスでAWSサービスメトリクスの名前や属性が意図せず変更される事故を防げます。つまり、利用可能なのは非破壊の add_attributes(overwrite_if_key_exists: false)のみです。
注意事項
※ 本記事で実挙動を確認したのは rename_metrics のパススルーです。その他の破壊系プロセッサおよび add_attributes の上書き動作については、公式ドキュメントの記載に基づきます。
- selection_criteria ではOTTLパスを使ってマッチ対象を絞ります。利用可能なパスは以下です
resource.attributes["key"]instrumentation_scope.namemetric.namedatapoint.attributes["key"]
- メトリクスパイプラインの上限は300パイプライン/アカウント、20プロセッサ/パイプラインです
- パイプライン処理自体に追加料金はかかりません。取り込みには標準のCloudWatch OTelメトリクス取り込み料金が適用されます
まとめ
CloudWatch pipelinesのメトリクス処理機能を使い、ALB(Application Load Balancer)のOTelメトリクスにチームやコストセンターのラベルを追加できました。パイプライン設定だけで完結します。
アプリケーション計装の変更やCollectorなどの中間処理レイヤーを用意せずに、AWSサービス由来のOTelメトリクスへ属性を付与できる点が便利です。test-telemetry-pipeline によるドライラン確認でデプロイ前に変換結果を検証できるため、安心して導入できます。
追加したラベルはPromQLから参照でき、sum by ("@resource.team") のような集計にも利用できます。チームやコストセンター単位でメトリクスを集計したい場面で活きる機能です。
CloudWatchには、Organizations内のメトリクスを集約する「Metrics Centralization」も追加されています。アカウント横断でのメトリクス集約と、本記事で紹介したチーム別ラベル付与を組み合わせる展開も考えられそうです。
参考リンク







