• HOME
  • New RelicでAPM監視を設定する方法：WordPressサーバーにPHPエージェントを入れて遅い処理を特定する

2026年6月1日

  • シェア
  • ツイート

    • 2026年6月1日

    New RelicでAPM監視を設定する方法：WordPressサーバーにPHPエージェントを入れて遅い処理を特定する

    New Relic の APM で WordPress を監視するには、サーバーに PHP エージェントをインストールし、ライセンスキーとアプリ名を設定して PHP-FPM（または Apache）を再起動します。これで、どのページが遅いか、時間がデータベース・外部 API・プラグインのどこで使われているかを継続的に確認できるようになります。この記事では、自分で管理している Linux サーバーへの導入手順、つまずきやすい点、WordPress 向けの設定、データの見方と注意点を説明します。

    導入できる環境と事前準備

    PHP エージェントは PHP の拡張モジュールとして動き、別プロセスのデーモン（newrelic-daemon）が収集したデータを New Relic に送ります。拡張モジュールを追加できる VPS やクラウドのサーバーが対象で、多くの共用レンタルサーバーでは導入できません。

    準備するものは次のとおりです。

    • New Relic のアカウントと、データ送信用のライセンスキー（Ingest 用のキー）
    • サーバーの root 権限
    • PHP のバージョンが、エージェントの対応範囲に入っていること

    対応する PHP のバージョンや OS、無料で使える範囲と課金の条件は変更されることがあるため、New Relic の公式ドキュメントで確認してください（2026年10月現在）。作業はステージング環境で試してから本番に入れ、PHP の設定ファイルを変更する前にバックアップを取っておきます。

    ステップ1：PHP エージェントをインストールする

    New Relic の管理画面には、対話形式でコマンドを案内するガイド付きインストールがあり、初めてならこれを使うのが簡単です。パッケージマネージャーで入れる場合は、公式ドキュメントに記載されたリポジトリと署名鍵を登録してから、PHP エージェントのパッケージを入れます。Debian／Ubuntu ではパッケージ名が歴史的な事情で newrelic-php5 のままですが、PHP 8 系にも対応しています。

    # リポジトリと署名鍵の登録は公式ドキュメントの手順に従う（鍵は更新されることがある）
sudo apt update
sudo apt install newrelic-php5

# インストーラーを実行し、ライセンスキーを入力する
sudo newrelic-install install

    インストーラーは検出した PHP に対して設定ファイル newrelic.ini を配置します。ライセンスキーは環境変数 NR_INSTALL_KEY で渡すこともできますが、シェルの履歴に残らないように注意します。

    つまずきやすい点：CLI と FPM で設定が別

    Ubuntu の PHP は、コマンドライン用（/etc/php/8.3/cli/）と PHP-FPM 用（/etc/php/8.3/fpm/）で読み込む設定ディレクトリが分かれています。php -m で newrelic が表示されても、Web リクエストを処理する PHP-FPM には読み込まれていないことがあります。パスのバージョン番号は環境に合わせて読み替えてください。

    # FPM 側の設定ディレクトリに newrelic.ini があるか
ls /etc/php/8.3/fpm/conf.d/ | grep -i newrelic

# 複数の PHP バージョンが入っている場合は、使っているものを確認
ls /etc/php/

    FPM 側に無い場合は、CLI 側に作られた newrelic.ini を参考に FPM 側にも配置します。

    ステップ2：newrelic.ini の主な設定

    設定ファイルで最初に確認するのは、ライセンスキーとアプリ名です。アプリ名は New Relic 上の表示名になるため、サイトと環境が分かる名前にします。

    ; 例: /etc/php/8.3/fpm/conf.d/newrelic.ini（配置場所は環境による）
newrelic.license = "your-license-key"
newrelic.appname = "example.com (production)"

; SQL はパラメーターを伏せた形で記録する
newrelic.transaction_tracer.record_sql = "obfuscated"

; ブラウザ監視用の JavaScript を自動で挿入するか
newrelic.browser_monitoring.auto_instrument = false

    ステージングと本番で同じアプリ名にするとデータが混ざるため、環境ごとに名前を分けます。アプリ名はセミコロン区切りで複数指定でき、「個別のサイト名」と「全サイト共通の名前」の両方に送ることもできます。

    newrelic.ini のパーミッションは、ライセンスキーが一般ユーザーに読まれないよう root と PHP の実行ユーザーだけが読める形にします。サーバーの構成管理でファイルを Git に入れる場合も、キーは別の仕組みで渡します。

    ブラウザ監視（ページ表示側の計測）を有効にすると、ページに New Relic の JavaScript が挿入され、訪問者の閲覧データが送信されます。使う場合はプライバシーポリシーに外部サービスへの送信を記載し、Cookie の同意管理と整合させてください。上の例では、まずサーバー側の APM だけを使うために自動挿入をオフにしています。

    ステップ3：再起動して届いているか確認する

    設定を反映するには PHP-FPM と、必要に応じてエージェントのデーモンを再起動します。サービス名はバージョンに合わせて変えてください。

    sudo systemctl restart php8.3-fpm

# エージェントとデーモンのログ
sudo tail -n 50 /var/log/newrelic/php_agent.log
sudo tail -n 50 /var/log/newrelic/newrelic-daemon.log

    サイトに何回かアクセスし、数分待つと APM の一覧に設定したアプリ名が表示されます。表示されない場合は、次の順に確認します。

    1. FPM 側に設定が読み込まれていない：ステップ1の確認を行う
    2. ライセンスキーの誤り：ログに認証のエラーが出ていないか確認する
    3. 送信できない：ファイアウォールやプロキシで New Relic への HTTPS の外向き通信が止まっていないか確認する。必要な宛先は公式ドキュメントに記載されています
    4. ログにエラーがなく、データも来ない：アクセスが少ない場合は時間を置いて再確認する

    ステップ4：WordPress のデータを読む

    PHP エージェントは WordPress を自動で認識し、トランザクション（リクエストの種類）ごとに応答時間を集計します。画面の名前や配置は更新で変わるため、ここでは見るべき観点で説明します。

    • 応答時間が長いトランザクション：遅い URL やテンプレートの種類を特定する
    • 時間の内訳：PHP の処理、データベース、外部サービスのどこで時間を使っているか
    • 遅いクエリ：同じクエリの大量実行や、インデックスが効かないクエリがないか
    • WordPress のフックやプラグイン単位の時間：どのプラグインの処理が重いかの手がかりになる。表示の有無はエージェントの設定とバージョンに依存します
    • エラー率：PHP の致命的エラーや例外が増えていないか

    管理画面の admin-ajax.php や WP-Cron、REST API への定期的なリクエストが上位に来ることがよくあります。heartbeat の間隔、重い定期処理、外部 API の呼び出しなど、フロントの閲覧とは別の原因を疑う手がかりになります。特定のページの詳細を調べたいときは、該当箇所を Query Monitor などで手元で再現すると原因を絞りやすくなります。

    API で計測を補う

    エージェントの API 関数を使うと、トランザクション名を分かりやすくしたり、計測が不要なリクエストを除外したりできます。エージェントが無い環境でもエラーにならないよう、関数の存在を確認してから呼び出します。mu-plugin として置く例です。

    <?php
/**
 * Plugin Name: New Relic tweaks (mu-plugin)
 */
add_action( 'admin_init', function () {
	if ( ! function_exists( 'newrelic_name_transaction' ) ) {
		return;
	}
	// admin-ajax のトランザクションを action ごとに分ける
	if ( wp_doing_ajax() && isset( $_REQUEST['action'] ) ) {
		$action = sanitize_key( wp_unslash( $_REQUEST['action'] ) );
		newrelic_name_transaction( 'admin-ajax/' . $action );
	}
} );

    トランザクション名に URL の ID やユーザー名のように値が無数にあるものを入れると、集計が細かくなりすぎて見づらくなります。上の例は action 名に限っています。newrelic_add_custom_parameter() で属性を追加する場合も、メールアドレスなどの個人情報は送らないようにします。

    ステップ5：アラートを設定する

    監視は異常に気づけて初めて役に立ちます。New Relic のアラート機能で、応答時間やエラー率、Apdex（応答時間に対する満足度の指標）が一定の値を超えたら通知する条件を作ります。閾値は、導入後しばらくの平常時の値を見てから決めると、誤報が減ります。通知先はメールのほか、チャットツールとの連携などが選べます。

    運用上の注意

    エージェントはリクエストごとに少しの負荷を加えます。多くの環境では小さな差ですが、導入前後で応答時間を比べておくと安心です。また、データ量の多いサイトでは無料枠を超えることがあるため、データの取り込み量を管理画面で定期的に確認します。不要になったら、拡張を無効にしてから PHP-FPM を再起動し、パッケージを削除します。

    まとめ

    • New Relic の APM は PHP エージェントを拡張として入れ、ライセンスキーとアプリ名を設定して PHP-FPM を再起動すると使えます
    • CLI と FPM で設定ディレクトリが分かれている点が最も多いつまずきで、FPM 側に newrelic.ini があるかを確認します
    • SQL はパラメーターを伏せて記録し、ブラウザ監視を使う場合はプライバシーポリシーを更新します
    • 応答時間の内訳、遅いクエリ、プラグイン単位の時間を見て原因を絞り、API はガードを付けた mu-plugin で使います
    • 平常時の値を基準にアラートを設定し、データ量と負荷を定期的に確認します
    Views: 81

    お気軽にご相談ください

    お見積りへ お問い合わせへ
    閉じる
    ▲