New Relic の Streaming Export（Data Plus 必須）を使い、Kinesis Firehose 経由でログを S3 にアーカイブする手順を解説。gzip 二重圧縮による文字化けの原因と解決策、Athena でのクエリ方法まで紹介します。

この記事では、New RelicとMicrosoft Azureとのインテグレーション設定について解説します。 はじめに New RelicはMicrosoft Azure との公式インテグレーションを提供しており、Azure Monitorを通じて取得される各種メトリクスを、New Relic上で一元的に可視化できます。この記事ではAzureインテグレーションでできること、コスト、手順について解説していきます。 Azure ネイティブ New Relic サービスの概要 | New Relic Documentation Manage New Relic and Azure integrations with agents installed directly through the Azure Portal docs.newrelic.com   Azureインテグレーションできること Azureインテグレーションでは、New Relic側からの定期的なポーリングによりパフォーマンスデータを取得し、アラート通知、カスタムクエリやダッシュボードの作成が可能です。利用にはNew Relic アカウントが必要であり、Azure Government 環境やクラシックデプロイモデル(現在は新規利用不可)のリソースは監視対象外となります。 New Relic Azureインテグレーションでは、認証情報に必要となるクライアントシークレットが必要になります。クライアントシークレットには最大2年間の有効期限が設定できます。そのため、定期的なローテーションが必要となります。 期限が切れた場合は、Azureインテグレーションの監視が停止しますので、運用対処を検討する必要があります。   Resource Manager デプロイとクラシック デプロイ - Azure Resource Manager Resource Manager デプロイ モデルとクラシック (あるいはサービス管理) デプロイ モデルの違いについて説明します。 learn.microsoft.com Azure監視インテグレーションの設定 | New Relic Documentation How to activate New Relic's integrations with Microsoft Azure. docs.newrelic.com   Azureインテグレーションに伴うコスト New Relic側のコストは、Azureインテグレーション自体に追加料金がかかることはありません。Azureからメトリクスデータが収集されるため、データ量が増加となります。契約しているプランによってはデータ量を超過する可能性があります。 Azure側のコストは、公式ドキュメントに記載通り、コストは発生します。New Relicによる定期的なポーリング間隔でAPIが呼び出されます。そのため、ポーリング間隔APIの呼び出し回数により、APIの課金に影響します。   Azure ネイティブ New Relic サービスの概要 | New Relic Documentation Manage New Relic and Azure integrations with agents installed directly through the Azure Portal docs.newrelic.com Metric APIの紹介 | New Relic Documentation Learn how to report metrics to New Relic from any source with the Metric API. docs.newrelic.com   Azureインテグレーション設定 New RelicのAzureインテグレーションは、Azure Monitorを利用したAPI連携により、エージェントをインストールする必要はありません。そのため、VMやアプリケーション環境に手を加えずに統合監視をすることができます。ただし、OS内部の詳細なメトリクスやプロセスデータも観測したい場合は、New Relic Infrastructureエージェントを導入する検討は必要となります。この記事ではAzureサブスクリプションに対してNew Relic連携用の閲覧権限ロールを付与しますが、Azure Cosmos DB やAzure VMsなど一部のサービスでは、データベースやキー情報といったサービス固有の情報を取得するために、追加の権限設定やカスタムロールの作成が必要となります。   Azure監視インテグレーションの設定 | New Relic Documentation How to activate New Relic's integrations with Microsoft Azure. docs.newrelic.com   全体の流れ New RelicでAzureのメトリクスを収集するためには、Azure側でサービスプリンシパルを作成し、New Relic が Azure API にアクセスするための認証情報を設定します。また、New RelicがAzure Monitorの情報を取得できるようにするため、対象となるサブスクリプションに閲覧者（Reader）権限を付与する事前設定が必要です。その後、取得した認証情報をNew RelicのAzureインテグレーションに登録することで、Azure Monitorのデータを自動的に収集できるようになります。 本記事では、Azure側で必要な情報を設定した後、New Relic側でインテグレーションを有効化するまでの手順を解説します。 Azure側の設定 New RelicでAzureのデータを収集できるようにするため、まず Azure側で必要な設定を行います。 1.Azureにログイン後、「Microsoft Entra ID」をクリックします。 2.左メニューより、管理 ＞アプリの登録をクリックし、「+新規登録」をクリックします。 3.任意の名前の入力(公式ではNewRelic-Integrations)と紐づけるアカウントを選択します。リダイレクトURIは赤枠の通りに指定後、登録をクリックします。 https://www.newrelic.com 4.赤枠のアプリケーションIDとディレクトリID(テナントID)をメモします。この先もメモする値がありますので、どれがどのIDかわかるようにしておくことを推奨します。   5.管理>証明書とシークレットをクリックします。クライアントシークレットタブより「＋新しいクライアントシークレット」をクリックします。 6.クライアントシークレットの名前、有効期限を設定し、追加をクリックします。 7.一度しか表示されないため、シークレット値をコピーしてメモしておきます。 8.サブスクリプションをクリックします。 9.監視対象のサブスクリプションをクリックします。 10.アクセス制御>追加>ロールの割り当ての追加をクリックします。 11.閲覧者をクリックして「次へ」をクリックします。 12.メンバーを選択するをクリックし、項番3で設定したアプリケーション名前をクリックし、「選択」をクリックします。 13.選択した名前が表示されていることを確認し、「レビューと割り当て」をクリックします。 14.ロールが「閲覧者」、選択した名前が表示されていることを確認し、「レビューと割り当て」をクリックします。 15.アクセス制御画面が表示されれば完了です。 16.右上上部の赤枠をクリックし、Azure Cloud Shellを起動します。起動はBashとします。 17.ガイドに従い、適用をクリックします。 18.「az account show」を入力し、赤枠のidをメモします。ここがサブスクリプションIDに該当します。メモ完了後、exitで終了してください。   Azure監視インテグレーションの設定 | New Relic Documentation How to activate New Relic's integrations with Microsoft Azure. docs.newrelic.com New Relic によるAzure 統合 New Relic のパブリッククラウド連携の一つ、Azureとの連携手順をご紹介します newrelic.com   New Relic側の設定 Azure側でNew Relicインテグレーションに必要な設定を完了後、続いてNew Relic側でAzureからデータを取得するための設定を行います。 1.New Relicにログイン後、「Integrations&Agents」より、Microsoft Azureを選択します。 2.Azure側で実施した手順のガイドが書かれています。すでに実施済のため、「Continue」をクリックします。 3.Azure側で実施した手順のガイドが書かれています。すでに実施済のため、「Continue」をクリックします。 4.「Account name」はNew Relicのコンソール上でどのアカウントのインテグレーションかがわかるような命名規則とすることを推奨します。それぞれメモしたIDを入力し、「Add account details」をクリックします。 5.右下にポップアップで以下の画面が表示されます。次の項番に進みます。 6.監視するサービスを選択します。recommendedに従い、Azure Monitor metricsを選択後、Select servicesをクリックし、Continueをクリックします。 7.「Continues」をクリックします。Azure Cloud360はプレビュー版のため、ここでは割愛します。 8.インテグレーション設定が完了しました。See your dataをクリックします。 9.監視するサービスが一覧で表示されています。「See account status dashboard」をクリックします。 10.ポーリング間隔はデフォルトで5分となっていますので、データが表示されるまでにしばらく時間がかかります。   Azure監視インテグレーションの設定 | New Relic Documentation How to activate New Relic's integrations with Microsoft Azure. docs.newrelic.com   編集方法 Azureとのインテグレーション完了後、監視したいサービスを追加・削除したい場合や、ポーリング間隔を変更したい場合の手順について設定します。 1.InfrastructureからAzureを選択後、「Edit account」をクリックします。 2.監視するサービスまたは監視から外すサービスを選択後、「Save changes」をクリックします。 3.監視したいサービス一覧が表示されます。「See account status dashboard」をクリックします。 4.New Relic上で情報を確認することができました。 【参考】データの取得間隔を変更したい、一時的に無効化したい場合は、項番3の画面で「Configure」をクリックして設定ができます。     Azure統合のポーリング間隔 | New Relic Documentation Comparison of New Relic polling intervals and Microsoft Azure data intervals for Azure integrations with New Relic. docs.newrelic.com   さいごに Azure側での事前設定から New Relic側でのインテグレーション有効化までの手順を通じて、New Relic上で Azure リソースの状態を可視化できることを確認しました。Azureインテグレーションを活用することで、エージェントを導入することなく(一部のサービスは除く)、クラウドリソース全体を横断的に監視できます。上記に加え、認証情報の有効期限管理やポーリング間隔、取得データ量に応じたコスト面への配慮も重要となります。今後は、収集したメトリクスを活用したアラート設定やダッシュボード作成など、実運用での活用方法についても検討していくことが有効です。 SCSKはNew Relicのライセンス販売だけではなく、導入から導入後のサポートまで伴走的に導入支援を実施しています。くわしくは以下をご参照のほどよろしくお願いいたします。

はじめまして。SCSKのすぐろです。 プレビュー版として実装されていたAWS DevOps Agentが2026年3月にGA（一般提供）されましたね。 インシデント発生時に自動で原因調査を行ってくれるサービスですが、実際にどこまで調べてくれるのかが気になったので、Amazon EC2上のWebサーバーで障害を発生させ、DevOps Agentの調査精度と限界を検証してみました。 参照: AWS DevOps Agent is now generally available AWS DevOps Agentとは インシデント発生時に、複数のデータソースを横断的に分析し、根本原因の特定と緩和策の提案を自動で行うマネージドサービスです。AWSネイティブなCloudWatchメトリクス・CloudWatch Logs・CloudTrailに加え、Datadog、Dynatrace、New Relic、Splunk等のサードパーティ製監視ツールや、GitHub、GitLab等のCI/CDパイプライン、ServiceNow、PagerDuty等のチケットシステムとも連携できます。GA版ではAzureやGrafanaのサポートも追加されました。 参照: About AWS DevOps Agent 参照: AWS DevOps Agent GA発表ブログ 料金 従量課金制で、エージェントがタスクに費やした時間に対して秒単位で課金されます。アイドル状態や待機中は課金されません。 課金対象 単価 Investigations（インシデント対応） $0.0083 / agent-second Evaluations（インシデント予防） $0.0083 / agent-second On-demand SRE tasks（チャット） $0.0083 / agent-second 新規利用者には2ヶ月間の無料トライアルがあり、各月Investigation 20時間・Evaluation 15時間・チャット 20時間まで無料で利用できます。 参照: Pricing – AWS DevOps Agent 検証のきっかけ 本番稼働中のWebサーバー(EC2インスタンス)のインシデント調査に使用するにあたり、以下の4点がきになりました。 EC2インスタンスへの影響はあるか DevOps AgentのIAMマネージドポリシー（ AIDevOpsAgentAccessPolicy ）を確認すると、EC2に対しては ec2:Describe* 等の読み取り系APIのみが許可されています。セキュリティドキュメントにも「エージェントが利用可能なツールは、チケットやサポートケースのオープンを除き、リソースを変更することができない」と記載されています。つまり、DevOps Agentの導入・調査によってEC2インスタンスが変更・停止されることはありません。 参照: DevOps Agent IAM permissions 参照: AWS DevOps Agent Security サーバーの中まで見に行ってくれるのか DevOps AgentはAWSのAPIを通じて情報を収集します。OS内部に直接アクセスする機能はドキュメントに記載されていません。OS内部の情報を調査対象にするには、CloudWatch Agent等でCloudWatch Logsやカスタムメトリクスとして事前に送信しておく必要があります。 参照: About AWS DevOps Agent 参照: What is a DevOps Agent Topology? どうやって調査しているのか IAMポリシーにはSSMでコマンドを実行する ssm:SendCommand やSSH接続用の ec2-instance-connect:* は含まれていません。SSHやSSMでEC2に接続するのではなく、AWSのAPIを通じた読み取り専用アクセスのみで調査を行います。 参照: DevOps Agent IAM permissions サーバー内に何かインストールされるのか EC2インスタンス内部にエージェントソフトウェアがインストールされることはありません。導入時に作成されるのはAgent Space（論理コンテナ）やサービスリンクロール等、AWSコントロールプレーン側のリソースのみです。 参照: DevOps Agent IAM permissions 検証 検証環境 EC2: t3.micro（Amazon Linux 2023）、httpd（Apache）をUserDataで起動 CloudWatch Agent: 以下の設定でログ・メトリクスを送信 CloudWatch Agentの設定ファイル（ /opt/aws/amazon-cloudwatch-agent/etc/config.json ）: { "metrics": { "namespace": "DevOpsAgentTest", "metrics_collected": { "mem": { "measurement": ["mem_used_percent"], "metrics_collection_interval": 60 }, "disk": { "measurement": ["used_percent"], "metrics_collection_interval": 60, "resources": ["*"] } } }, "logs": { "logs_collected": { "files": { "collect_list": [ { "file_path": "/var/log/messages", "log_group_name": "/devops-agent-test/messages" }, { "file_path": "/var/log/httpd/error_log", "log_group_name": "/devops-agent-test/httpd-error" }, { "file_path": "/var/log/httpd/access_log", "log_group_name": "/devops-agent-test/httpd-access" } ] } } } } /var/log/messages をCloudWatch Logsに送信することで、OOM KillerなどカーネルレベルのイベントがDevOps Agentの調査対象になります。メモリ・ディスク使用率のカスタムメトリクスも送信し、標準メトリクス（CPU、ネットワーク等）と合わせてDevOps Agentが参照できるようにしています。 検証1: CPU高負荷 SSMで接続し、 yes > /dev/null コマンドでCPUを100%に張り付かせた状態でDevOps Agentに調査を依頼しました。 調査依頼プロンプト: EC2インスタンス(i-xxxxx )のCPU使用率が急上昇しました。原因を調査してください。 結果: CPU使用率が100%に達していることを正しく検知 CloudTrailからタイムラインを構築し、同時刻のイベント（yum update、Inspector 2スキャン、SSMセッション開始）を列挙 「SSMセッション内でCPU集約的なコマンドを実行した可能性がある」と推測 → 実際に正しい方向の推測 調査した結果原因を断定できなかったので仮説を立てている 各仮説に「可能性がある」という表現を使い、断定を避けていた 「調査ギャップ」として確認できなかった事項を明確に報告 真の原因（yesコマンド）にはOS内部のプロセス情報がないため到達できませんでしたが、仮説と事実を区別した誠実な調査結果でした。 調査コスト: 約6分（360秒）→ $2.99（$1=¥150換算で約¥448） 追加検証: SSMセッションログを有効にして再検証 検証1ではDevOps Agentが実行コマンドを特定できなかった原因は、SSMセッション内で何を実行したかのログがCloudWatch Logsに送信されていなかったためです。そこで、SSM Session ManagerのCloudWatch Loggingを有効にし、セッション中のコマンド入出力をCloudWatch Logsに記録する設定を追加した上で、同じCPU高負荷を再現して調査を依頼しました。 調査依頼プロンプト: EC2インスタンス(i-xxxxx )のCPU使用率が急上昇しました。原因を調査してください。 結果: 根本原因を「IAMユーザーxxxxxによる意図的なCPUストレステストの実行」と正確に特定 実行コマンド（ for i in $(seq 1 $(nproc)); do (yes > /dev/null) & done ）を特定 実行ユーザー、セッションID、起動されたプロセスのPIDまで特定 「計画的な負荷テストであり、システム異常やマルウェアではない」と正しく判断 SSMセッションログという1つのデータソースを追加しただけで、検証1の「仮説止まり」が「正確な原因特定」に変わりました。DevOps Agentの調査精度がデータソースの充実度に直結することを改めて裏付ける結果となりました。 検証2: メモリ逼迫によるOOM Killer発動 stress-ng でメモリを枯渇させ、OOM Killerによってhttpdが強制終了される状況を作り、DevOps Agentに調査を依頼しました。検証1と異なり、OOM Killerのログが /var/log/messages → CloudWatch Logs経由でDevOps Agentの調査対象になります。 調査依頼プロンプト: EC2インスタンス(i-xxxxx )上のWebサーバー（httpd、ポート80）が応答しなくなりました。原因を調査してください。 結果: 根本原因を「stress-ngツールによる意図的なメモリ枯渇テスト」と正確に特定 実行ユーザー（SSMセッションユーザー）を特定 実行コマンドとパラメータ（ stress-ng --vm 1 --vm-bytes 900M ）まで特定 OOM Killerが全httpdプロセス（PID含む）を強制終了したことをログから読み取り タイムラインを正確に構築（00:07:17 → 00:11:29 → 00:17:32） メモリ枯渇 → OOM Killer → httpd停止 という因果関係に正しく到達 検証1では仮説止まりだったのに対し、CloudWatch Logsにカーネルログという明確な根拠があったことで、正確な原因特定ができました。 また、調査完了後に「緩和計画」という機能を実行したところ、stress-ngプロセスの停止 → httpdサービスの再起動 → 事後検証（HTTP 200 OK確認）まで、具体的なコマンド付きの復旧手順を提示してくれました。手順通りに実行してWebサーバーの復旧を確認できました。 調査コスト: 約5分（304秒）→ $2.52（$1=¥150換算で約¥379） わかったこと 良かった点 AWSのAPI経由で取得できる情報を横断的に分析し、タイムラインを構築する能力は高い CloudWatch Logsに根拠となるログが存在する場合、実行コマンド・ユーザー・タイムラインまで正確に特定できる（検証2で確認） 調査ギャップ（確認できなかったこと）を報告する仕組みがある EC2インスタンスへの変更やエージェントのインストールは不要 従量課金制で、調査しなければ費用は発生しない 注意が必要な点 OS内部のプロセス状態やローカルログには直接アクセスできない CloudWatch Logsに送信されていない情報は調査対象外 データソースに根拠がない場合、仮説止まりになる（検証1で確認） 調査精度の比較 検証 データソースの根拠 原因特定 評価 検証1（CPU高負荷） △ メトリクスのみ × 仮説止まり 真の原因に到達できず 検証1 追加検証（SSMセッションログ有効） ○ メトリクス + SSMセッションログ ○ 正確に特定 コマンド・ユーザー・PIDまで特定 検証2（メモリ逼迫） ○ メトリクス + OOM Killerログ ○ 正確に特定 コマンド・ユーザーまで特定 まとめ DevOps Agentの調査精度は、データソースに残る根拠の有無に大きく依存します。検証1ではメトリクスだけでは仮説止まりでしたが、SSMセッションログを1つ追加しただけで正確な原因特定に変わりました。 導入を検討する場合は、DevOps AgentがAPIレベルで情報を取得できる環境を整備しておくことが重要だと感じました。CloudWatch Agentによるログ・メトリクスの送信はもちろん、CloudTrailの有効化やVPCフローログの設定など、DevOps Agentが参照できるデータソースを充実させて調査精度を向上させることで、インシデント調査はエージェントにお任せし、業務効率を向上させていきましょう！