AWS Integartion 導入後にメトリクスがリソースタグで装飾されない場合のトラブルシューティングガイド

はじめに

AWS Integration を導入後、「リソースタグでメトリクスをフィルタリングできない」という壁にぶつかることがあります。本ブログでは、AWS Integration のタグ/メタデータ収集の仕組みとトラブルシューティング手順について解説します。

1. Metric Streams の AWS Integration における「タグ収集」の仕組み

現行の AWS Integration では、メトリクスを AWS から New Relic に連携するために CloudWatch Metric Streams を利用しています。Metric Streams 自体はリソースのカスタムタグ（例：Environment や Project）をメトリクスデータと一緒に New Relic に送信しているわけではありません。New Relic における AWS データの装飾（Decoration）は、以下の二重構造で成り立っています。

メトリクスデータ: CloudWatch Metric Streams を通じて、低遅延で New Relic にストリーミングされます。
メタデータ/リソースタグ: New Relic のバックエンドワーカーが、Resource Groups Tagging API や AWS Config API などを介し、別途定期的に AWS の API を利用して取得します。

New Relic は、届いたメトリクスに含まれる各エンティティの識別子を元にして、別ルートで取得したタグ情報を内部でメトリクスデータに連結しています。つまり、Metric Streams を利用していても、AWS API 経由のタグ取得プロセスが健全でなければ、タグによるメトリクスの装飾はできず、タグを用いてメトリクスデータにクエリすることができません。

また、メトリクスをタグで装飾可能なのは、New Relic 内に作成されたエンティティに関するメトリクスのみである点に注意が必要です。例えば、AWS 上では ECS サービスにタグを追加することが可能ですが、2026 年 3 月時点の動作として、New Relic では ECS サービスのエンティティは作成されないため、ECS サービスのタグを用いて ECS サービスメトリクスを装飾することはできません。New Relic 内に作成されるエンティティを把握するためには、Entity explorer(UI 上の "All Entities")をご確認ください。

メトリクスの装飾は、New Relic インフラストラクチャにより非同期かつ定期的に実行されます。現在の動作として、タグがメトリクスに反映されるまでには、設定完了後最大 15 分程度お待ちください。

2. ケーススタディ：EC2 インスタンスでタグが表示されない場合

最も一般的な EC2 を例に、トラブルの切り分け方を見ていきましょう。AWS Integartion で New Relic に連携されたメトリクスがタグで装飾されているかどうかを確認するためには、例えば以下のような NRQL クエリを実行します。以下の NRQL クエリでは、メトリクスが持つすべての属性名を keyset 関数で表示します。

FROM Metric
SELECT keyset()
WHERE aws.Namespace = 'AWS/EC2' AND aws.region = '<ご利用の AWS リージョン>'

上記のクエリを実行した結果、"tags." で始まる属性がなければタグの連携が失敗している可能性があります。例えば、Name というタグが EC2 インスタンスに付与されている場合、当該の EC2 インスタンスのメトリクスの属性として "tags.Name" という属性が追加されます。そのような属性を確認できない場合には、以下のトラブルシューティング手順に進んでください。

3. トラブルシューティング

トラブルシューティングの手順では、大きく「前提条件を確認する」「IAM ロールの権限を確認する」という二段階の手順をとります。

Step 1: 前提条件を確認する

既述の点もありますが、AWS リソースのメトリクスデータにリソースタグが追加されるための前提条件は以下になります。

AWS リソースが存在する AWS リージョンで AWS Config が有効化されている
- 確認点: 対象となる AWS リソースが存在する AWS リージョンの AWS Config マネージメントコンソールを開き、AWS Config のセットアップを促すメッセージ(以下の画像の赤枠で囲まれた部分)が表示されていないか確認します。AWS Config のセットアップが完了していない場合には、セットアップを完了してください。ダッシュボードの表示を促される場合、セットアップは完了していると考えられます。

AWS Config management console shows messages and buttons to prompt users to setup AWS Config in this AWS region

対象となる AWS リソースは、New Relic 上でエンティティが作成されるリソースか
- 確認点: Entity explorer(UI 上の "All Entities")を参照し、対象となるエンティティが作成されているか確認します

前提条件に問題がない場合には IAM ロールの権限確認の手順に進みます。

Step 2: IAM ロールの権限不足を疑う

AWS Integration に指定した IAM ロールの権限が適切か確認します。IAM ロールの権限として、IAM ロールの信頼ポリシー(Trust Relationship policy)および IAM ロールにアタッチされている IAM ポリシーの双方の権限が適切に設定されている必要があります。調査の対象となる IAM ロールを特定するためには、例えば以下のような NerdGraph API でのクエリを実行することにより、AWS Integration で指定された IAM ロールの情報を取得することが可能です。

(クエリ例)

query {
  actor {
    account(id: <New Relic アカウント ID>) {
      cloud {
        linkedAccounts {
          id
          name
          authLabel  # AWS Integration の場合 IAM ロール ARN が含まれます
          nrAccountId
          integrations {
            id
            name
          }
        }
      }
    }
  }
}

(レスポンス例)

{
  "data": {
    "actor": {
      "account": {
        "cloud": {
          "linkedAccounts": [
            {
              "authLabel": "arn:aws:iam::123456789012:role/NewRelicInfrastructure-Integrations-1234567890ab",
              "id": 222222,
              "integrations": [
                {
                  "id": 3333333,
                  "name": "Fetch Metadata for AWS integrations"
                },
                {
                  "id": 3333334,
                  "name": "Fetch ElastiCache entities"
                },
                {
                  "id": 3333335,
                  "name": "Fetch tags for all integrations"
                }
              ],
              "name": "test-AWS-MetricStreams-2099101D00H00M00S-mstreams",
              "nrAccountId": 1234567
            }
            ...

得られた IAM ロール(レスポンス内の authLabel の ARN を持つ IAM ロール)の信頼ポリシーと IAM ポリシーの設定を確認していきましょう。

Step 2.1: 信頼ポリシーの確認

まず、AWS Integration で設定された IAM ロールの信頼ポリシーを見てみましょう。適切な信頼ポリシーは以下です。New Relic の AWS アカウント(754728514883)が許可されているかを確認するのが重要です。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::754728514883:root"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "sts:ExternalId": "<ご利用の New Relic アカウント ID>"
                }
            }
        }
    ]
}

また、IAM ロールの信頼ポリシーが適切でない場合、IntegrationError イベントタイプに awsErrorMessage 属性を持ったイベントが記録されることがあります。タグ取得に関するエラーイベントは、dataSourceName 属性として "Fetch tags for all integrations" が指定されます。そのようなイベントに関しては、以下のような NRQL クエリで、New Relic インフラストラクチャが IAM ロールを AssumeRole しようとした際のエラーの発生状況を確認することが可能です。

FROM IntegrationError
SELECT count(*)
WHERE dataSourceName = 'Fetch tags for all integrations'
FACET awsErrorMessage 
SINCE 1 day ago

上記のクエリを実行した結果、以下のようなエラーが awsErrorMessage に記載されたイベントの発生を確認できる場合には、信頼ポリシーの設定が適切でない可能性が高いと考えられます。

User: arn:aws:iam::754728514883:user/external_accounts_data_collector is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::123456789012:role/NewRelicInfrastructure-Integrations-1234567890ab (Service: Sts, Status Code: 403, Request ID: aaa99887-1234-5678-aaaa-0123abcd4567) (SDK Attempt Count: 1)

ご利用の AWS アカウント内に上記の ARN を持つ IAM ロールが存在しない場合にも同様のエラーが発生する点にご注意ください。

上記のような信頼ポリシーの権限エラーが発生した場合、New Relic インフラストラクチャは、不要な AWS API コールの発生を抑えるため、AssumeRole 実行時にエラーが発生したことを示すネガティブキャッシュを作成し AssumeRole の実行を抑制します。AssumeRole の実行が抑制された場合には、IntegrationError に以下のようなエラーメッセージ(awsErrorMessage)が記録される場合があります。

Error assuming role from cache

信頼ポリシーの権限エラーが発生した場合、設定をご確認いただいた後、キャッシュが期限切れになるまでの間一時間程度お待ちください。

Step 2.2: IAM ポリシーの確認

IAM ロールにアタッチする IAM ポリシーとしては、特別な理由がない限り AWS マネージドポリシーである ReadOnlyAccess をご利用いただくことをお勧めしています。もし、マネージドポリシーの利用がセキュリティ要件に合わない場合には、以下のドキュメントをご参照いただき、要件に合わせて適切に IAM ポリシーをご設定ください。

Grant New Relic permissions with AWS managed policies | New Relic Documentation

IAM ポリシーによりタグの取得に失敗している場合、IntegrationError に awsErrorCode 属性が AccessDeniedException に指定されたイベントが作成されます。以下のような NRQL クエリを実行することにより、どのような操作(method 属性)で権限エラーが発生したか把握していただくことが可能です。

FROM IntegrationError
SELECT awsErrorCode, method, awsRegion
WHERE dataSourceName = 'Fetch tags for all integrations' AND awsErrorCode = 'AccessDeniedException'
LIMIT MAX
SINCE 1 day ago

エラーが発生している method に合わせて IAM ポリシーの権限を調整してください。IAM ポリシーの調整をしていただいた後は、New Relic インフラストラクチャからタグを取得する周期である 15 分程度お待ちください。

Step 3: NRQL でデータの存在確認を行う

ここまでの手順を実行していただき、IntegrationError に dataSourceName 属性として "Fetch tags for all integrations" が指定されたイベントが記録されなくなった場合には、AWS Integration で連携されるメトリクスにタグ情報が追加されていることが想定されます。再度以下の NRQL クエリで、対象リソースに紐付いている属性を洗い出してみましょう。

FROM Metric
SELECT keyset()
WHERE aws.Namespace = 'AWS/EC2' AND aws.region = '<ご利用の AWS リージョン>'

4. まとめ

本ブログ記事では、AWS Integration で連携されたメトリクスが AWS のリソースタグで装飾されない際のトラブルシューティング手順を見てきました。トラブルシューティングでは主に IAM ロールの権限を確認します。権限設定のトラブルシューティングには、IntegrationError イベントをご確認いただくことが有用です。IntegrationError イベントをご確認いただき、dataSourceName 属性として "Fetch tags for all integrations" が指定されたエラーイベントをご確認ください。また、トラブルを避けるためには、「AWS Integration で指定した IAM ロールの IAM ポリシーにおける権限を削りすぎない」という勇気を持つことも大切です。IAM ポリシーについては、極力 AWS が管理するマネージドポリシーをご利用いただくことで、運用の負荷を軽減することが可能になります。

小ネタ

EC2 インスタンス上で動作させるインフラストラクチャエージェントを用いてログを New Relic に連携する際、EC2 インスタンスに設定されたリソースタグに基づいて、複数のインスタンスのログデータをまとめて取得したい場合があります。ただ、現時点での動作として、ログデータはタグで装飾されないため、直接的にリソースタグを用いてログをフィルタリングすることができません。この場合には、メトリクスデータのタグをうまく仲介させることで、EC2 インスタンスに設定されたリソースタグに基づいてログをフィルタすることが可能です。例えば、以下のような NRQL クエリを実行することが可能です。

FROM Log
SELECT hostname, message 
WHERE entity.guid.INFRA IN (
  FROM Metric
  SELECT entity.guid 
  WHERE aws.Namespace = 'AWS/EC2' AND tags.Env = 'Production'
)