New Relicの監視設定DeepDrive~Infrastructure Agentのかゆい所に手を伸ばす設定~

記事タイトルとURLをコピーする

みなさんこんにちは。マネージドサービス部MSS課の塩野(正)です。

オブザーバビリティしてますか?オブザーバビリティって何だっけ?という方に向けて、オライリーの書籍を熟読してオブザーバビリティを理解するこちらの記事をオススメします。

blog.serverworks.co.jp

今回はNew Relicを使いたいからとりあえず初期設定で導入してみたものの、もう少し使いこなしてみたいという方向けの少しだけディープなお話です。

New Relicインフラストラクチャエージェントの設定最適化ガイド

目次

対象読者

  • New Relicを使ってインフラ監視をしている方
  • インフラストラクチャエージェントの設定を少し掘り下げて知りたい方

概要

New Relicのインフラストラクチャエージェントは、システムの監視において重要な役割を果たしています。しかしすべての環境でデフォルトの設定がいいとも限らないため、環境によっては最適なパフォーマンスやセキュリティが得られない場合もあります。当記事では、インフラストラクチャエージェントの設定値を用途毎に整理してみましたので、実際の環境で使えそうな部分を見つけていただければ幸いです。

※記事の中で使用している設定値は下記の公式ドキュメントに記載されているものから抜粋しております。

docs.newrelic.com

パフォーマンス最適化のポイント

この項目では、インフラストラクチャエージェントのパフォーマンスにフォーカスした設定項目をご紹介します。

CPU使用率の最適化

システムのCPU使用率を最適化するための項目です。

  • max_procs
    この設定は、エージェントが使用する論理プロセッサの数を制御します。この値を増やすと、異なるコア間で負荷を分散するのに役立ちます。例えば、8コアのサーバーで4に設定すると、エージェントは最大4つのコアのみを使用します。-1 に設定すると、エージェントは環境変数 GOMAXPROCS を読み込もうとして、この変数が設定されていない場合、デフォルト値はホストで利用可能なコアの総数になります。

  • payload_compression_level
    エージェントから送信されるデータはデフォルトで圧縮され、 データの圧縮レベルを0(圧縮なし)から9(最大圧縮)の間で設定でき、デフォルトは 6 が設定されています。 高い圧縮レベルはネットワーク帯域を節約できますが、CPU使用率が上がります。ペイロード圧縮を無効にするには、payload_compression_level を 0 に設定します。 ※なお、この設定は変更しないことが推奨されています

セキュリティ強化のための設定

この項目では、インフラストラクチャエージェントのセキュリティにフォーカスした設定項目をご紹介します。

機密情報の保護

  • strip_command_line
    この設定が有効な場合、プロセスのコマンドライン引数に含まれる文字列を自動的に除去します。プロセス実行のコマンドラインに機密情報(パスワードなど)などが含まれている場合、その情報が自動的にNew Relicへと取り込まれてしまうため、この設定を変更する際には特に注意が必要です。デフォルトで設定が有効化されていますが、Javaなどのプロセス監視の際にコマンドラインの引数を含めたクエリを書く必要がある場合に必要に応じて変更する項目です。

  • proxy_validate_certificates
    プロキシサーバーの証明書を検証する機能を有効にします。プロキシまでの通信もセキュアな通信を確保する場合に推奨される設定です。

    • ca_bundle_file / ca_bundle_dir
      信頼できる証明書を指定することで、セキュアな通信を確保します。特に社内の独自認証局を使用している環境では重要です。

監視データの最適化

この項目では、インフラストラクチャエージェントのデータの最適化やコスト削減にフォーカスした設定項目をご紹介します。

データ収集の効率化

  • metrics_process_sample_rate
    プロセスの情報を収集する間隔を秒単位で設定します。例えば60秒に設定すると、60秒ごとにプロセス情報を収集します。間隔を長くすることで送信されるデータ量を抑えることができますが、データの粒度は荒くなります。

  • metrics_network_sample_rate
    ネットワークメトリクスの収集間隔を設定します。こちらも間隔を調整することで送信されるデータ量を抑えることができますが、データの粒度は荒くなります。

  • metrics_storage_sample_rate
    サーバにマウントされているストレージデバイスの収集間隔を設定します。こちらも間隔を調整することで送信されるデータ量を抑えることができますが、データの粒度は荒くなります。

  • metrics_system_sample_rate
    サーバー全体の現在の全体的な状態を表すデータの収集間隔を設定します。こちらも間隔を調整することで送信されるデータ量を抑えることができますが、データの粒度は荒くなります。

  • metrics_nfs_sample_rate
    NFSストレージに関するデータの収集間隔を設定します。こちらも間隔を調整することで送信されるデータ量を抑えることができますが、データの粒度は荒くなります。

  • include_matching_metrics / exclude_matching_metrics
    enable_process_metrics がtrueとなっている場合の設定で、必要なプロセスのメトリクスのみを収集することで、ストレージ使用量とネットワーク帯域を節約できます。例えば、特定のアプリケーションのメトリクスのみを収集したい場合などに便利です。

ログ管理の改善

  • max_size_mb / max_files
    ログファイルの自動ローテーションを設定します。デフォルトでは、ログ・ローテーションは無効になっていますが、max_size_mb オプションでログファイルの最大サイズを指定することで設定を有効化できます。これによりディスク容量の枯渇を防ぎつつ、必要なログを保持できます。

クラウド環境での最適化

  • cloud_provider
    使用しているクラウドプロバイダーを明示的に指定することで、メタデータの収集を最適化できます。デフォルトと異なる値に設定されている場合、エージェントがバックエンドにデータを送信する前に、クラウドプロバイダからメタデータ(インスタンスID)の取得に成功するまで待機します。

  • disable_cloud_metadata / disable_cloud_instance_id
    クラウドメタデータの収集が不要な場合、この設定を無効にすることでパフォーマンスを改善できます。

まとめ

よく使われるポイントをまとめてみましたがいかがだったでしょうか。デフォルト値で使用いただいても問題はありませんが、うまく設定することでセキュリティやパフォーマンスを高めたり、コスト削減につなげることができるため、システムの規模や要件によって最適な値を見つけることをオススメいたします。

この記事がどなたかのお役に立てれば幸いでございます。

宣伝

弊社では、お客様環境のオブザーバビリティを加速するための伴走型のNew Relic導入支援サービスなどもご提供しております。 もしご興味をお持ちの方は、こちらのサービスご紹介ページの一番下にあるお問合せフォームよりお問合せ頂けましたら幸いでございます。

◆ 塩野 正人
◆ マネージドサービス部 所属
◆ X(Twitter):@shioccii
◆ 過去記事はこちら

前職ではオンプレミスで仮想化基盤の構築や運用に従事。現在は運用部隊でNew Relicを使ってサービス改善に奮闘中。