New Relic エージェントトラブルシューティング - Agent固有の問題解決
New Relicエージェントは、システムとアプリケーションの監視において中核的な役割を果たします。しかし、環境の複雑さや設定の細かさから、エージェント固有の問題が発生することがあります。本記事では、Infrastructure AgentとAPM Agentでよく発生する問題とその解決方法を、ログ解析の手法とともに詳しく解説します。
エージェント診断の基本手法
ログファイルの場所と確認方法
New Relicエージェントの問題解決において、ログファイルの確認は最も重要な手順です。各エージェントは、異なる場所にログファイルを生成するため、正確な場所を把握することが必要です。
Linuxシステムでは、Infrastructure Agentのログは通常/var/log/newrelic-infra/ディレクトリに保存されます。APM Agentの場合は、言語によって異なり、Javaエージェントはlogs/newrelic_agent.log、PHPエージェントは/var/log/newrelic/といった場所になります。
Windowsシステムでは、%PROGRAMFILES%\New Relic\配下にログファイルが生成されることが一般的です。正確なパスは、インストール時の設定により異なる場合があります。
ログレベルの調整と詳細情報の取得
通常の運用では、ログレベルはINFOまたはWARNに設定されていますが、問題解決時にはDEBUGレベルに変更することで、より詳細な情報を取得できます。ただし、デバッグログは大量の情報を出力するため、本番環境では一時的な使用に留めることが重要です。
ログレベルの変更は、設定ファイルの編集またはエージェントの再起動により反映されます。問題解決後は、パフォーマンスへの影響を避けるため、元のログレベルに戻すことを忘れないでください。
Infrastructure Agent特有の問題
エージェントの起動と停止の問題
Infrastructure Agentが正しく起動しない場合、まずサービスの状態を確認します。
具体的なサービス確認・操作コマンド
Linux環境（systemd）:
# エージェント状態確認
sudo systemctl status newrelic-infra
sudo systemctl is-active newrelic-infra
sudo systemctl is-enabled newrelic-infra
# エージェント操作
sudo systemctl start newrelic-infra # 開始
sudo systemctl stop newrelic-infra # 停止
sudo systemctl restart newrelic-infra # 再起動
sudo systemctl enable newrelic-infra # 自動起動有効
# ログ確認
sudo journalctl -u newrelic-infra -f # リアルタイムログ
sudo journalctl -u newrelic-infra --since "1 hour ago" # 過去1時間Linux環境（init.d）:
# エージェント操作
sudo service newrelic-infra status
sudo service newrelic-infra start
sudo service newrelic-infra restart
sudo chkconfig newrelic-infra on # 自動起動有効Windows環境:
# サービス状態確認
sc query "newrelic-infra"
net start | findstr newrelic
# サービス操作
net start "newrelic-infra"
net stop "newrelic-infra"
sc config "newrelic-infra" start= auto # 自動起動設定起動失敗の一般的な原因には、設定ファイルの構文エラー、権限不足、依存関係の不備などがあります。設定ファイルnewrelic-infra.ymlの構文をYAMLバリデーターで確認し、エージェントの実行ユーザーが適切な権限を持っているかを検証します。
メモリ不足やディスク容量不足も起動を阻害する要因となります。システムリソースの状況を確認し、必要に応じてリソースの増強を検討しましょう。
統合（Integrations）の問題
Infrastructure Agentの統合機能に問題が発生する場合、個別の統合ログを確認することが重要です。MySQL、Apache、Dockerなどの統合は、それぞれ独自の設定とログを持っています。
統合設定ファイルの認証情報が正しいか、対象サービスへの接続が可能かを確認します。特に、パスワードの変更やファイアウォール設定の変更後に問題が発生することが多く見られます。
統合によっては、特定のバージョンのソフトウェアのみをサポートしている場合があります。互換性マトリックスを確認し、サポートされているバージョンの組み合わせを使用していることを確認しましょう。
カスタム属性の問題
カスタム属性が正しく収集されない場合、属性名の制限や値のデータ型に問題がある可能性があります。New Relicでは、属性名に使用できる文字数や文字種に制限があり、これらを超過すると属性が破棄されます。
属性値のサイズ制限も重要な要素です。大きすぎる値は自動的に切り詰められるか、完全に破棄される可能性があります。ログで属性の処理状況を確認し、制限内に収まるよう調整します。
APM Agent特有の問題
言語別エージェントの設定問題
APM Agentは言語ごとに異なる特性を持ち、それぞれ固有の問題があります。Javaエージェントでは、JVMオプションの設定やクラスパスの問題が発生しやすく、適切なagent jarファイルの指定と引数の設定が必要です。
Node.jsエージェントでは、モジュールの読み込み順序が重要で、New Relicモジュールを他のモジュールより先に読み込む必要があります。この順序が間違っていると、正しくインストルメンテーションが行われません。
Python、PHP、Ruby、.NETそれぞれのエージェントも、言語固有の設定要件があります。公式ドキュメントの設定例と現在の設定を詳細に比較し、相違点を特定することが重要です。
トランザクションの追跡問題
一部のトランザクションが追跡されない場合、エージェントのインストルメンテーション範囲やフィルタ設定に問題がある可能性があります。デフォルトでは、フレームワークで処理されるリクエストのみが自動的に追跡されます。
カスタムトランザクションの場合、手動でのインストルメンテーションが必要になることがあります。適切なAPIを使用してトランザクションの開始と終了を明示的に記録する必要があります。
非同期処理やバックグラウンドジョブの追跡には、特別な設定が必要な場合があります。これらの処理が正しく追跡されるよう、エージェントの非同期処理サポート機能を有効にしましょう。
パフォーマンスへの影響
APM Agentが本番システムのパフォーマンスに大きな影響を与える場合、設定の見直しが必要です。トランザクションサンプリング率を調整し、収集する情報量を最適化することで、オーバーヘッドを削減できます。
データベースクエリの詳細収集や深いスタックトレースの取得は有用ですが、高負荷環境では無効にすることを検討しましょう。必要な情報のみを収集するよう設定を調整することで、効率的な監視を実現できます。
ネットワークと接続性の問題
ファイアウォールとプロキシの設定
エージェントがNew Relicサーバーに接続できない場合、ネットワーク設定を詳細に確認する必要があります。New Relicが使用するドメインとポートを、ファイアウォールの許可リストに追加することが必要です。
企業環境では、プロキシサーバー経由での接続が必要になることが多く、プロキシ設定の詳細な設定が求められます。認証が必要なプロキシの場合は、認証情報も適切に設定する必要があります。
SSL/TLS証明書の検証に関する問題も発生することがあります。企業内のセキュリティポリシーにより、証明書検証の設定を調整する必要がある場合があります。
DNS解決の問題
DNS設定に問題がある場合、エージェントがNew Relicのエンドポイントを解決できない可能性があります。nslookupやdigコマンドを使用して、必要なドメイン名が正しく解決されるかを確認しましょう。
IPv6環境では、IPv6とIPv4の両方の設定を確認する必要があります。一部の環境では、IPv6接続が優先されるが実際には接続できない、という問題が発生することがあります。
ログ解析の実践的手法
エラーパターンの特定
エージェントログから問題を特定するため、一般的なエラーパターンを理解することが重要です。接続エラー、認証エラー、設定エラーなど、エラーの種類により対処法が異なります。
ログの時系列分析により、問題の発生タイミングと他のシステム変更との関連性を特定できます。デプロイメント、設定変更、インフラストラクチャの変更と問題発生の相関関係を調査しましょう。
ログの統合と分析
複数のエージェントログを統合して分析することで、システム全体の問題を把握できます。Infrastructure AgentとAPM Agentのログを時系列で整理し、関連する問題を特定する手法が効果的です。
ログ管理ツールを活用することで、大量のログデータから必要な情報を効率的に抽出できます。正規表現やフィルタ機能を活用し、特定のパターンやエラーを迅速に特定しましょう。
高度なトラブルシューティング手法
デバッグモードの活用
重大な問題の場合、エージェントのデバッグモードを有効にして詳細な情報を収集します。デバッグモードでは、内部処理の詳細な情報が記録されるため、問題の根本原因を特定しやすくなります。
ただし、デバッグモードは大量のログを生成し、システムパフォーマンスに影響を与える可能性があります。本番環境では短時間の使用に留め、問題解決後は通常モードに戻すことが重要です。
サポートチケット作成時の情報準備
New Relicサポートにチケットを作成する際は、事前に必要な情報を整理しておくことで、迅速な解決が期待できます。エージェントバージョン、設定ファイル、関連するログ、エラーメッセージ、再現手順などを体系的に整理しましょう。
環境情報（OS、アプリケーションバージョン、ネットワーク構成）も重要な情報です。問題の影響範囲と発生頻度も明確に記述することで、適切な優先度での対応が期待できます。
まとめ
New Relicエージェントのトラブルシューティングは、体系的なアプローチと適切なツールの活用により効率化できます。ログ解析の技術を習得し、問題パターンを理解することで、多くの問題を迅速に解決できるようになります。
定期的なエージェントの健全性チェックと予防的なメンテナンスにより、問題の発生を最小限に抑えることができます。次回は、データが表示されない場合の具体的な診断手順について詳しく解説します。
関連記事: データが表示されない場合の対処法関連記事: 一般的な問題と解決法