こんにちは。SCSKの井上です。
この記事では、New RelicのInfrastructureエージェントの導入方法について解説します。手順を説明する前に、まずInfrastructureエージェントを導入すると何ができるのか、リソース消費は増えないのかなど、よくある疑問に触れていますので、理解を深めてから実際の手順に挑んでいきます。
はじめに
New Relic Infrastructureは、オンプレミスサーバやクラウド環境の基盤を観測するための機能を提供します。この機能により、CPU、メモリ、ディスクI/O、ネットワーク、プロセスなどのリソースをリアルタイムで可視化できます。ハードウェアの性能を見える化することで、インフラに関する問題を迅速に発見し、対応することが可能です。
利用には、観測対象のサーバに New Relic Infrastructure エージェントをインストールする必要があります。エージェントは常駐プロセスとしてシステム観測に必要となるテレメトリデータを収集し、New Relicプラットフォームへ送信します。エージェントをインストールしただけでは、New Relicへログは転送されません。ログを New Relic に集約することで、各サーバーにログインせずに一元管理が可能になります。これにより、障害調査の迅速化や、サーバーログ調査の属人化解消など、運用効率が向上し工数削減につながります。この記事では導入に必要な手順を解説していきます。
事前準備
すでにNew Relicアカウント、ライセンスキー、ユーザーキーをすでに発行済の前提で記載しています。発行の手順については、過去の記事をご参考いただけますと幸いです。この記事での導入対象はamazon linux2023としています。
エージェントの動作環境
New Relic Infrastructure エージェントを導入にあたりシステム要件があります。下記は、執筆当時のものになりますので、最新版は下部の公式サイトをご確認ください。
| カテゴリ | 詳細 |
| 対応アーキテクチャ | 最新情報は下記、公式サイトをご参照ください。 |
| 対応OS(Linux/Windows/macOS) | 最新情報は下記、公式サイトをご参照ください。 |
| 権限 | Linux :root推奨
Windows:Administrator必須 |
| ホスト名要件 | 固有であること(localhost不可) |
| ネットワーク要件 | New Relicへのアウトバウンドデータ送信にHTTPS(443)を使用。受信ポートは開く必要無し。
TLS1.2以上の通信 |
| コンテナ対応 | Kubernetes/ECS/EKS対応。最新情報は下記、公式サイトをご参照ください。 |
| 設定管理ツール | Ansible、Chef、Puppet、Elastic Beanstalk対応 |
| リソース消費 | 軽量(詳細は、次章に記載) |
ファイアウォールやセキュリティポリシーで外部との通信制限がされている場合は、New Relicエージェントがデータ送信できるようにドメインやエンドポイントを追加する必要があります。
Infrastructure エージェント導入によるリソース消費を知る
New Relic Infrastructure エージェントを入れると、システム負荷が増えることが予想されます。以下、New Relicが公開している情報です。エージェント自体は軽量ですが、監視対象が増えると収集・処理のためのリソースが比例して増えますので、まずはテスト環境等に導入して様子を見るほうが良いですね。
| ホストタイプ | ベース環境 | CPU使用率 | 仮想メモリ | 常駐メモリ | ディスク使用量 |
| Linuxシングルタスク | EC2 | 約0.3% | 約1GB | 約25~35MB | 約50MB |
| Linux Docker | EC2 (CentOS7, 25コンテナ/100プロセス) | 約0.8% | 約1GB | 約25~35MB | 約50MB |
Infrastructureエージェントを導入することで何ができるの?
Infrastructure エージェントを導入することで、サーバの負荷や異常なプロセスの検出、リソースの障害検知・アラートを通知、新しいアプリケーションやサービスのデプロイ後に、インフラストラクチャの健全性を確認し、リソース高騰等の問題がないかをチェックすることができます。
どんなデータが収集されるの?
実際にどんなデータがどれくらいの間隔で収集されるのかを下記に整理しました。収集間隔はデフォルト値のため、設定ファイルにて変更することはできます。名前がSampleとついているのは、一定間隔で取得したサンプル値を表すためになります。New relicでは導入されているシステムへの負荷を抑えるため、例えば5秒ごとにCPU使用率のデータを取得する場合、その5秒間目の値をサンプルとして保存しています。
| イベント名 | 説明 | 参照 |
| SystemSample | CPU、メモリ、ディスク、ネットワークなど、サーバー全体の状態を5秒ごとに記録 | New Relic data dictionary | New Relic Documentation |
| ProcessSample | 各アクティブプロセスに関して、20秒ごとに記録 | New Relic data dictionary | New Relic Documentation |
| StorageSample | マウントされた単一のストレージデバイスを20秒ごとに記録 | New Relic data dictionary | New Relic Documentation |
| NetworkSample | ネットワークデバイスのインタフェースおよびアドレス情報、使用量データを10秒ごとに記録 | New Relic data dictionary | New Relic Documentation |
| ContainerSample | 各DockerコンテナのID、名前、イメージ、イメージ名、またCPU、メモリ、ネットワークに関するデータを15秒ごとに記録 | New Relic data dictionary | New Relic Documentation |
| InfrastructureEvent | 構成情報またはシステム状態が追加/削除/変更されると、そのアクティビティ発生時に記録 | New Relic data dictionary | New Relic Documentation |
上記のデータ以外にもインフラ基盤から出力されるログをNew Relicに送ることができます。ただし、エージェントをインストールしただけでは、ログは転送されませんので、明示的にどのログを転送したいかを設定ファイルに記載する必要があります。
データ(ログ)送信の仕組み
Infrastructure エージェントをインストール後、Infrastructure エージェントは、/etc/newrelic-infra/logging.d/ に配置された yml ファイルを Fluent Bit の設定に変換し、Fluent Bit がログの送信を実施します。そのため、Infrastructure エージェントをインストールした際に、Fluent-bitのプロセスも常駐します。転送経路はTLSで暗号化されており、ログはNew Relicのログエンドポイントに送信された後、保存時にも暗号化されます。これにより、ログデータは送信中も保存中も安全に保護されます。ログ転送については、Fluent-bit以外にも対応しています。メトリクスデータについては、エージェントから直接New Relicのプラットフォームに送信しています。ログをNew Relicへ送信する前にログに個人情報や認証に関わるデータが出力されていないかを確認する必要があります。New Relicのプラットフォームはデータ転送は暗号化され、データ保存はセキュアな環境で管理されていますが、個人情報や機密データはNew Relicに送信しないようログ送信対象を除外などの対処する必要があります。
Infrastructure エージェントのインストール
インストール手順にはガイドを利用したインストール方法とパッケージを指定してインストールする方法があります。この記事ではガイドに沿ってインストールしますので、導入についての難易度は低めです。10分-15分程度でインストールは完了します。インストール後のNew Relicの使い方や見方については別記事にて解説していきます。
Infrastructure エージェントの設定ファイル
Infrastructure エージェントをインストール後、ymlが作成されます。エージェントのログ出力レベルなど、エージェントの動作を制御するため設定はymlファイルに記述しますが、yml設定ファイルよりも環境変数の値が優先されます。
以下は、Infrastructure エージェントインストール時に作成されます(他にもある可能性があります)。
| ファイル名 | 役割 | デフォルトパス(Linux) | 備考 |
| newrelic-infra.yml | Infrastructure Agent の基本設定 | /etc/newrelic-infra.yml | エージェント起動時に読み込まれる。記載後、エージェント再起動必要 |
| logging.yml | ログ転送設定 | /etc/newrelic-infra/logging.d/logging.yml | 記載後、エージェント再起動不要 |
| integrations.d/*.yml | 各種インテグレーション設定 | /etc/newrelic-infra/integrations.d/ | サービスごとに配置 |
目的に応じて、設定ファイルの編集箇所や内容は異なります。この記事で解説するファイルは2つになります。
newrelic-infra.yml:New Relic Infrastructure エージェントを制御する設定ファイル
logging.yml :New Relic Infrastructure エージェントでログ送信を設定するためのファイル
デフォルトで”newrelic-infra.yml”に記載されている内容
ガイドに従ってインストールした場合、以下の内容が記述されています。それぞれどのような意味を持つのかを説明します。プロセス情報の収集はGuided installでインストールした場合、デフォルトは有効(true)で起動しています。
記載場所:/etc/newrelic-infra.yml
| 設定値 | 内容 |
| enable_process_metrics: true | OS上で動作しているプロセスのCPU、メモリ使用量などの情報をNew Relicに送信 |
| status_server_enabled: true | HTTPで自身のエージェントの状態を確認
ガイド付きインストールを使用する場合、デフォルトで有効。 |
| status_server_port: 18003 | 上記を実施するためのポート番号 |
| license_key: ***** | 記載したキーで紐づけられているアカウントにデータが送信 |
| custom_attributes:
nr_deployed_by: newrelic-cli |
New Relic CLIを使ってデプロイされたことを示すカスタム属性
CLI が自動的に付与するメタ情報 |
エージェントのメトリクスデータ取得間隔の変更
サンプリング頻度が高いと、New Relicへの送信データ量が増え、コストやネットワーク帯域に影響を与える可能性があります。メトリクスデータの取得間隔を変更したい場合、以下のサンプルの値を記載することで、変更することができます。設定変更後はエージェントの再起動が必要です。
記載場所:/etc/newrelic-infra.yml
| 設定値 | 最小値 (単位:秒) |
| metrics_network_sample_rate | 10 |
| metrics_process_sample_rate | 20 |
| metrics_storage_sample_rate | 5 |
| metrics_system_sample_rate | 5 |
エージェントログレベルの変更とログローテーション
記載場所:/etc/newrelic-infra.yml
log: level: INFO #ERROR/WARN/INFO/DEBUG file: /var/log/newrelic-infra/newrelic-infra.log rotate: max_size_mb: 100 #100MBを超えたらローテーション(設定値は例) max_files: 10 #最大10世代分のログを保持(設定値は例) compression_enabled: true #古いログを圧縮して保存 file_pattern: YYYY-MM-DD_hh-mm-ss.log #ローテーション時のファイル名パターン(設定値は例)
サーバーログ送信設定
アプリケーションログ、セキュリティ関連ログ、システムログなど、サーバー内でエラーが出力されていても、New Relicに送信しなければ、一つ一つサーバーにログインして確認しなければなりません。New Relicのコンソール画面でエージェントを導入したサーバのログを見たい場合、転送するログをymlに記載する必要があります。設定ファイルは以下になりますが、環境によっては格納場所が異なる可能性があります。デフォルトで送信対象のログが記載されていますが、不要な場合は削除しても問題ありません。この変更については、エージェントの再起動は不要です。
記載場所:/etc/newrelic-infra/logging.d/logging.yml
記載例は以下になります。attributes以下のラベル名(ここではservice,env)は自由にカスタマイズできますが、デフォルトで用意されているラベルがあります。
logs:
- name : logging.yml内においてどのログについての設定か、識別のみに用いる
file : ここで指定されたパスのログファイルがNew Relicに転送
attributes : ログに関連付ける追加情報を指定 (この行は何も書かない)
service : ログ検索の際にキーワードで検索するラベル例 (apache,httpd)
env : ログ検索の際にキーワードで検索するラベル例 (prd,stg)
・・・
logtypeで設定したキーワードが赤枠部分に表示されます。検索を行う際、デフォルトで用意されている「Attributes」カテゴリも活用することで、目的のログを素早く絞り込むことができます。ただし、設定反映後以降のみ対象となりますので、過去にさかのぼって反映はすることができません。デフォルトで用意されているラベルもここから確認することができます。
ログに個人情報や認証に関わるデータが出力されていないかを確認する必要があります。データ転送は暗号化され、データ保存はセキュアな環境で管理されていますが、個人情報や機密データはNew Relicに送信しないよう設定する必要があります。
エージェントのログファイル
Infrastructureエージェントを導入したにもかかわらず、New Relicのコンソール画面にホストが表示されない、またはメトリクスが更新されない場合、エージェントの動作や通信に問題がある可能性があります。その際は、以下のログに記録された内容を確認してください。
/var/log/newrelic-infra/newrelic-infra.log
Infrastructure エージェントの動作プロセス
エージェントをインストールした後、サーバーには以下のプロセスが動作しています。サーバーのリソースが高騰している場合、以下のプロセスについて確認します。必要に応じて収集対象や間隔を見直します。
| プロセス名 | 意味 | 用途 |
| newrelic-infra-service | サービス管理プロセス | エージェントの起動・停止 |
| newrelic-infra | エージェントプロセス | メトリクス、プロセスの収集・転送、ログ転送
エージェントの再起動はこのプロセスを実施 |
| fluent-bit | ログ転送プロセス | ログを収集・転送 |
Infrastructure エージェントのリトライ処理
CPUやメモリなどのメトリクス情報は送信失敗した時点で破棄されますが、設定変更やパッケージのインストール・更新などの構成情報は、送信が失敗しても通信が回復した後でNew Relicに送信されます。短時間に大量のリトライが起きるとシステムへの負荷がかかるため、再送は再試行間隔を伸ばすことでシステム負荷を軽減する”バックオフパターン”に従って行われます。
Infrastructure エージェントの動作サポート期限
メーカーがOSのサポートを終了するまで、New Relicにおいてもエージェント動作をサポートします。パッケージはサポート終了(EOL)後のシステムでも利用できる場合がありますが、動作保証はありません。New Relic Infrastructureエージェントを含め、日々新機能が追加されています。新機能を利用するには、エージェントのバージョンアップが必要です。New Relicでは、3か月ごとのInfrastructureエージェントのバージョンアップを推奨しています。自動でバージョンアップはされませんので、リリースノートを確認し、定期的なバージョンアップを計画することが求められます。
さいごに
本記事では、New Relic Infrastructureでできること、収集できる情報、インストール手順からログ送信設定について解説しました。導入は意外と簡単だと感じた方も多いのではないでしょうか。ログを収集・送信するためには、設定ファイルに専用の記述を追加し、ログ転送機能を有効化する必要があります。これにより、システムログやアプリケーションログを効率的に監視し、トラブルシューティングやパフォーマンス分析に活用できます。次回の記事では、Infrastructure エージェントの具体的な活用方法について解説します。
SCSKはNew Relicのライセンス販売だけではなく、導入から導入後のサポートまで伴走的に導入支援を実施しています。くわしくは以下をご参照のほどよろしくお願いいたします。













