本ブログ記事では、New Relic の ECS Integration (nri-ecs)を Amazon ECS Fargate 環境に導入した後、動作確認を行う手順を解説します。
ステップ1: New Relic にコンテナデータが連携されていることを確認
ContainerSample イベントタイプのデータポイントが New Relic に連携されているかを NRQL クエリで確認します。
(クラスタ名での検索)
FROM ContainerSample
SELECT *
WHERE ecsClusterName = <クラスタ名>
(ECS タスク定義での検索)
FROM ContainerSample
SELECT *
WHERE ecsTaskDefinitionFamily = '<タスク定義名>
上記のようなクエリにより、データポイントが一件でも連携されている場合には nri-ecs は適切に動作しています。データを確認できない場合には、ステップ2に進みます。
ステップ2: デバッグログによるトラブルシューティングを実行
本項目では、ステップ1の手順でデータの連携を確認できない場合のデバッグ手順をご説明します。
デバッグログの有効化
ECS タスク定義中、nri-ecs に関するコンテナ設定を変更します。
環境変数の追加
nri-ecs の設定（タスク定義の環境変数）に以下を追加します。
- 環境変数名: NRIA_VERBOSE
- 値: 1
NRIA_VERBOSE を 1 に設定することで、nri-ecs の詳細ログが出力されるようになります。
logConfiguration の設定
続いて、awslogs ドライバを利用して、コンテナのログ出力を CloudWatch ロググループに転送します。以下のような設定を、ECS タスク定義中、インフラストラクチャエージェントを稼働させるコンテナの設定に追加します。
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "<CloudWatch ロググループ名(例: /newrelic-infra/ecs>)",
"awslogs-region": "<CloudWatch Logs を利用する AWS リージョン(例: ap-northeast-1)>",
"awslogs-stream-prefix": "verbose"
}
},タスク定義例
以上の二つの設定を導入したタスク定義の例(インフラストラクチャエージェントのコンテナ部分を抜粋)としては以下のようなものになります。
{
"cpu": 256,
"environment": [
{
"name": "NRIA_CUSTOM_ATTRIBUTES",
"value": "{\"nrDeployMethod\":\"downloadPage\"}"
},
{
"name": "NRIA_IS_FORWARD_ONLY",
"value": "true"
},
{
"name": "NRIA_VERBOSE",
"value": "1"
},
{
"name": "NRIA_PASSTHROUGH_ENVIRONMENT",
"value": "ECS_CONTAINER_METADATA_URI,ECS_CONTAINER_METADATA_URI_V4,FARGATE"
},
{
"name": "FARGATE",
"value": "true"
}
],
"essential": true,
"image": "newrelic/nri-ecs:latest",
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "<CloudWatch ロググループ名(例: /newrelic-infra/ecs>)",
"awslogs-region": "<CloudWatch Logs を利用する AWS リージョン(例: ap-northeast-1)>",
"awslogs-stream-prefix": "verbose"
}
},
"memoryReservation": 512,
"mountPoints": [],
"name": "newrelic-infra",
"portMappings": [],
"secrets": [
{
"name": "NRIA_LICENSE_KEY",
"valueFrom": "<Systems Manager パラメータ名>"
}
],
"systemControls": [],
"volumesFrom": []
}上記の設定はあくまで例ですので、設定内容をご利用の環境や要件に合わせて調整してください。
デバッグログの確認
ロググループに出力されるログから、エラーが発生していないか確認します。基本的には、level=error のメッセージを探します。エラー詳細の例としては、以下のようなエラーが挙げられます。
- invalid license: ライセンスキーの設定ミス
- ネットワークエラーに関するキーワード(Timeout/Connection refused/context deadline exceeded 等): New Relic へのアウトバウンド通信（HTTPS/443）がセキュリティグループやプロキシ、Network ACL で遮断されている可能性
ライセンスキーエラーの場合には、以下のようなメッセージが、指定されたロググループ内のログストリームに記録されます。
time="2025-12-19T05:33:05Z" level=error msg="can't load configuration file" component="New Relic Infrastructure Agent" error="invalid license. Check agent's config file or NRIA_LICENSE_KEY environment variable"上記のようなメッセージが記録されている場合には、Systems Manager パラメータストアや環境変数で設定されたライセンスキーが想定通りかご確認ください。
ネットワークエラーが発生した際には、以下のようなメッセージが記録される場合があります。
time="2025-12-19T06:20:12Z" level=error msg="metric sender can't process" component=MetricsIngestSender error="error sending events: Post \"https://infra-api.newrelic.com/infra/v2/metrics/events/bulk\": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)" postCount=196 sendErrorCount=4上記のようなメッセージが記録されている場合には、ECS クラスタが動作するネットワーク環境の設定を見直してください。
設定を見直していただいた後、以下のような「メトリクスの送信に成功した」ことを示すメッセージが記録されていれば、nri-ecs の設定は適切であると判断できます。
time="2025-12-19T05:43:56Z" level=debug msg="Metrics post succeeded." component=MetricsIngestSender postCount=56注) 上記のメッセージ例は 2025 年 12 月時点でのものであり、将来的に変更される場合がある点をご了承ください
まとめ
- コンテナに関するデータが New Relic に連携されているか、ContainerSample への NRQL クエリで確認する
- ContainerSample にデータを確認できない場合には、デバッグログにより nri-ecs の動作を確認する
本ブログに掲載されている見解は著者に所属するものであり、必ずしも New Relic 株式会社の公式見解であるわけではありません。また、本ブログには、外部サイトにアクセスするリンクが含まれる場合があります。それらリンク先の内容について、New Relic がいかなる保証も提供することはありません。
