こんにちは、インフラチームテックリードの櫻井です。
今回はNew Relicを本番環境だけではなくステージング環境にも入れてみるといいことがあるよということを紹介したいと思います。
この記事はNew Relic Advent Calendar 2023の12日目の記事になります。
New Relic、入れていますか？
皆さんは運用しているサービスのステージング環境にNew Relicを入れていますか？
本番環境にはNew Relicを入れているけど、ステージング環境には入れていないという人も多いのではないかと思います。
実際に当社でも以前は本番環境にのみNew Relicがインストールされており、ステージング環境にはインストールされていませんでした。
そんな当社だからこそ分かる、ステージング環境にNew Relicを入れるべき理由とステージング環境にNew Relicを入れるときにおすすめの設定を紹介したいと思います。
ステージング環境にNew Relicを入れるべき3つの理由
本番リリース前にエラーの検知と調査がしやすくなる
ステージング環境にNew Relicを入れてエラーが発生したときのアラート通知を設定しておけば、ステージング環境で動作確認しているときにエラーが発生した場合にすぐに気づくことができ、エラーを含んだ状態での本番リリースを未然に防ぐことができます。
また発生したエラーを他の人に共有するときにはNew RelicのURLを共有するだけで良いので、複数人でエラーやログを調査するのもとてもやりやすくなります。
実際に当社でもステージング環境でエラーを検知したことでインシデントを未然に防ぐことができたことが何度もありました。
New Relicの新機能を試しやすくなる
New Relicの新機能を試すためにはエージェントの設定の変更とサーバーの再起動が必要な場合があります。
そのままサーバーを再起動すると一時的にレスポンスを返せなくなってしまうため、本番環境でサーバーを再起動するためにはローリングアップデートなどの仕組みが必要です。
しかしステージング環境では社内のメンバーが使用しているだけなので、気軽にエージェントの設定変更とサーバーの再起動を試すことができます。
また万が一エージェントの設定を変更したことで障害が発生してしまったとしても、ステージング環境なら設定を元に戻すだけで良いので安心です。
料金がホスト数ではなく転送するデータ量とユーザー数で決まる
New Relicでは料金が監視対象のホスト数ではなく、実際に転送するデータ量とユーザー数によって決まります。
これはDatadogやMackerelなど監視対象のホスト数で料金が決まるサービスとは大きく異なる点です。
サービスのアクセス数にもよりますが、一定以上のアクセス数があるサービスの場合は本番環境に比べてステージング環境の方がアクセス数が少なく、データの転送量も少なくなるのではないかと思います。
監視対象のホスト数で料金が決まる場合はステージング環境で本番環境と同じ料金を支払うのはもったいないと感じてしまうかもしれませんが、New Relicの料金体系ならステージング環境の料金を安く抑えることができるかもしれません。
ステージング環境にNew Relicを入れるときにおすすめの設定
次にステージング環境にNew Relicを入れるときにおすすめの設定を紹介します。
APMで使用する言語はPHPを想定して書いているので、他の言語については対応するドキュメントを参照ください。
AppNameの設定
まずアプリケーション名をデフォルトの設定から変更します。
このときサービス名の後ろに Staging をつけるなど、必ず本番環境とは違うアプリケーション名になるように設定します。
アラート通知の設定
次にステージング環境でエラーが発生したときやパフォーマンスが低下したときに気づくことができるようにアラートの通知を設定しておきます。
このとき本番環境とは別でアラートを作成し、例えば通知先にSlackを設定しているなら通知先のチャンネルも本番環境とステージング環境で別にしておくのがおすすめです。
またステージング環境に限らずですが、重要なアラートはメンションをつけて通知したり、enrichmentsを設定して関連するデータを添付したりするのがおすすめです。
Infinite Tracingの設定
New RelicにはDistributed Tracingという機能があり、分散サービスのパフォーマンス分析やエラーの調査などにとても役立ちます。
この機能はデフォルトで有効化されていますが、デフォルトでは head-based sampling というサンプリング方法になっており、一定数がランダムにサンプリングされるようになっています。
Infinite Tracingという機能を有効化することで tail-based sampling というサンプリング方法になり、サンプリング条件や割合などを柔軟に変更することができるようになります。
Infinite Tracingを有効化する方法や詳細は以前の記事で紹介しているので、良ければこちらも読んでみてください。
APMのログ転送設定の変更
New RelicのAPMエージェントにはMonologなどのログフレームワークからNew Relic Logsにログを転送する機能がデフォルトで有効化されています。
また、このとき転送したログはLogs in Contextという機能を使ってTraceに紐付けられており、ログがどのような状況で出力されたのか調べやすくなっています。
しかしデフォルトでは転送するログレベルがWARN以上のものに設定されているため、ステージング環境でINFOログやDEBUGログなどを転送したいという場合は newrelic.application_logging.forwarding.log_level からログレベルを変更する必要があります。
また、Monologのログ転送を行う場合はデフォルトだと第二引数の $context がNew Relicに転送されません。
$context をNew Relicに転送したい場合はPHPエージェントのv10.14.0.3から使えるようになった newrelic.application_logging.forwarding.context_data.enabled を true に設定するなどの対応が必要です。
まとめ
今回はステージング環境にNew Relicを入れることについて紹介しました。
もしこれを読んでステージング環境にもNew Relicを入れてみようと思っていただけたら幸いです。
また、今後はステージング環境だけでなく各自の開発環境にNew Relicを入れてみるのも他のメンバーの開発環境のエラーをデバッグしたりするのに便利そうなので試してみたいと思います。
