最新のアップデートの詳細はこちら。New Relic アップデート(2023年9月)
はじめに
『あれはどこにいった？いつもの所に置いてないな・・・。最後に使ったのいつだっけ？』こんな経験を日常生活の中で、一度も言ったことはないんじゃないでしょうか？
もし『あ、そうだそうだ。昨日の夜に帰ってきた時いつもの鍵を置いておく場所じゃなくて、テーブルの上に置いたままだった。』と聞くしていれば、いつもの場所に鍵がなくても、慌てる時間はその時だけで、すぐに鍵を見つけることができますよね。
それと同じで、システムにおける変更情報を記録しておくと、いつもと違うぞという事象に遭遇した際に、その記録を振り返ることで何が起きているかをとても簡単に推測することができるようになります。
New Relicでは、Change Trackingという仕組みを提供しており、これにより様々な変更情報を管理することができるようになっています。
どんな仕組み？
どうやって登録する？
詳細は公式ドキュメントに取りまとめられているので、是非一読してもらうことをおすすめしますが、NerdGraphというGraphQL APIを介して、変更に関する情報をNew Relic上に登録することができるようになっています。
補足: APIを利用する際は、API-KeyというヘッダにAPI Keyの値を設定頂く必要があります。API Keyの取得にはこちらのブログを参照して下さい。
変更情報をNerdGraph経由で登録する場合、以下のフィールドが必須となっています。
- entityGuid: New Relicに登録されているどの管理対象に関連した変更であるかを指定します。
- version: 『値は何でもよい』とあるので、管理のし易いフォーマットを採用して下さい。例えば、ver01や00.00.01といた情報を指定します。
その他に、changelogやdescriptionといったオプションの属性を用いることで、より詳細な変更に関する情報をNew Relicに登録することができます。
mutation {
changeTrackingCreateDeployment(
deployment: {
version: "0.0.1",
entityGuid: "ここにentityGuidの文字列を設定する" }
)
{
deploymentId
entityGuid
}
}
登録内容をどこで確認する？
New Relicポータルの主要機能(APM & Services, Browser, Mobile, Synthetic Monitoring, InfrastructureのHosts など)のUIにアクセスするとメニューにChange Trackingが現れるので、そちらから登録した変更作業前後のデータを参照することが可能です。
補足: 確認する限りだと、メニュー名は共通でしたが、メニュー自体の配置されるグループは機能ごとに異なっていました。活用の際はご注意下さい。
このChange Trackingメニューにアクセスすると、登録された変更の記録がリストとして表示され、その一覧から参照したい記録を選択することで詳細情報を確認することが可能です。
補足: 手元の環境で試してみたところ、APIを介して登録する際にentityGuidで指定する管理対象のタイプによって表示されるデータが変わる様です。
なにが見えるの？
変更管理の詳細画面ですが、はじめに管理対象のタイプに関わらず共通のデータが表示されます。
デフォルトで以下に関する情報を確認することができます。
- 管理対象に関連づいているエラーの発生数
- 発生した分間のログ発生数
- 管理対象に関連づいたアラートの発生数
また、画面上から参照したいメトリックやイベント情報を追加することも可能です。
続いて、APM/Infrastructure/Browserの主要エージェントでは次のデータが表示されます。
バックエンドアプリケーション(APM)
APMのデータとして、変更前後でトランザクションがどの様に改善されたか、また、応答時間、スループット(分毎のリクエスト処理数)、エラー発生率、CPU利用率、Apdexスコア、メモリ利用率、データベースへアクセスするトランザクション割合といったパフォーマンス指標が表示されます。
トランザクションのパフォーマンスの改善を確認することができます。
バックエンドアプリケーションの主要なパフォーマンス指標の変化を確認することができます。
サーバ(Infrastructure)
Infrastructureのデータとして、
- CPU利用率
- メモリ利用率
- ストレージ利用率
- データ入出量(bits/sec)
の変化を確認することができます。
フロントエンドアプリケーション(Browser)
Browserのデータとして、
- 分間あたりのページビュー数
- LCP(75パーセンタイル)
- FID(75パーセンタイル)
- 発生エラー数
- ページ読み込み時間
- 分間あたりのAJAXリクエスト数
の変化を確認することができます。
どんな使い方ができるのか
各管理対象に紐づいて変更情報を登録できるので、管理対象自身の変更情報を残すという使い方が主な目的となるかと思います。例えば、バックエンドアプリケーションの新バージョンをリリースしたですとか、サーバのキャパシティを増強したなどです。
一方で、Change Trackingの画面では変更が発生した時間を指定して登録を行うことができるので、管理対象自身ではなくその周辺の変更も併せて記録することで、周辺の変更が管理対象にどの様な影響を与えたのかという観点での記録も可能です。例えばですが、バックエンドアプリケーションの前段のロードバランサやセキュリティソリューションの変更、CDNのキャッシュ設定の変更といったものがあるかと思います。まだまだ他にもあるかと思いますが、挙げさえて頂いた例は、変更を行うことで管理対象へ多大な影響を与える可能性があるものです。そういった潜在的な影響を及ぼす周辺の変更についても管理対象に紐づけて変更記録をつけ、パフォーマンスやキャパシティの負荷に変化がないのか、影響があった場合でも許容できる範囲なのかという観点で集めたデータを活用することができます。
これらの変更を1つ1つデータとして記録していくことで、あっては欲しくないですが、突然の障害やパフォーマンスの劣化が確認された際に、確認すべき箇所を狭めることができ、過去に遡りながら原因を特定していくことができる様になりますね。
まとめ
Change Trackingは、すごく便利そうですね。是非、この機能を用いて、システムやサービスに適切な確認すべきチェックポイントをデータに埋め込んでいきましょう。そうすることで、何か想定外なことが起きた場合、変更の記録1つ1つを戻りながら変化の起点を探し当てることができるよういになります。その結果、原因を解決するためのスピードは早くなることが期待できますし、原因調査の時間が圧縮した分を再発防止のための時間であったり、より良いものに改善するための時間に充てることができるようになりますね。
New Relicを用いて実現できるとても便利な機能は他にもたくさんあります。ご興味がある方は、下のリンクにアクセスしたり、無料アカウントを是非トライしてみて下さい。
New Relic株式会社のQiita Organizationでは、
新機能を含む活用方法を公開していますので、ぜひフォローをお願いします。
無料アカウントの詳細はこちらです。