2022.02.28[Mon]

New Relic NRQLを用いたダッシュボード作成例

  • パフォーマンス
  • NewRelic

目次

New Relic NRQLを用いたダッシュボード作成例

当社ではアプリケーションのモニタリングにNew Relicを採用しています。( https://newrelic.com/jp )

この記事ではNew Relicのダッシュボードの実例を紹介します。

New Relicの各ツール(APM, BROWSER, Infrastructure, Mobile…)はそれぞれ専用のデータ表示・分析用画面がを持っています。ですが、そのままだと各ツールをそれぞれチェックしなければならず、少々使い勝手が悪いと感じることがあります。ダッシュボードを用いるとそれらを横断的に組み合わせて一つの画面を作ることができます。また、収集したデータをユーザーが利用できるようにNRQLというクエリ言語を用いて、New Relic上の様々なデータを組み合わせて、任意のグラフや表を作成することができます。

(ダッシュボードの作成・編集方法のドキュメントはこちら: https://docs.newrelic.com/jp/docs/query-your-data/explore-query-data/dashboards/introduction-dashboards

ダッシュボードに入れるグラフは、各ツールに元から設定されているグラフをコピーしたものと、NRQLを用いて作成したものがあります。コピーしたものの場合は中身の条件などをいじることはできません。

ダッシュボードの作成方針

今回は、毎日チェックするものを集めたダッシュボードを作成しました。重要な観点は主に

 - エラー監視
 - サーバー負荷の変化
 - ユーザーへのパフォーマンスの変化

の3点です。
これら3つの観点は、問題があったら対応する必要のあるクリティカルな観点であるためです。自分たちの変更のリリースによるものであればリリース後に気付くことができますが、APIやサードパーティープラグイン側の変更によっての影響は気付きづらいため、このダッシュボードで定期監視することで気付くことができます。
逆に、問題が発覚してもすぐに対応する必要が無い指標は段々と気にしなくなる上にその分の場所をとるので、確認頻度を分けた別のダッシュボードを用意したほうが確認しやすいものになります。

各グラフの解説

全体の画像

ここから、一段ずつ見ていきます。

1段目

・APM Summary Average

APM Overviewよりコピー。URI総合のため影響箇所によっては変動が見づらいが全体にとってどれくらいかが見られます。

・APM Error rate 

APM Error タブよりコピー。サーバー側エラー監視。基本0です。

・Top 5 errors 

APM Error タブよりコピー。Top 5 というのはクライアントだと少々狭いが、普段あまり出てないサーバー上では充分です。

2段目

・APM duration × 3 (各ページ)

主要なページというのが3つ決まっているのでそれぞれのサーバー側パフォーマンス。durationと書いてありますがレスポンスタイムのこと。APIの待ち時間が分離して表示されるようにしてある。ページの名前はAPMエージェントで付けています。( https://docs.newrelic.com/jp/docs/apm/agents/nodejs-agent/api-guides/nodejs-agent-api/ )

SELECT (average(webDuration - externalDuration))*1000 as 'node' , average(externalDuration)*1000 as 'web external' from Transaction where appName = 'APM-APP-NAME' and name = 'WebTransaction/Custom/XYZ' TIMESERIES auto
3段目

・APM /_next/static response time
・APM /static response time

ページのパフォーマンスではありませんが、過去にアセットのみレスポンスが遅い、アップデートにより劇的に変化したということがあったため。

・APM Summary Throughput

単体で特に目印となるわけではありませんが、サーバー負荷が高い状態などを別の側面から確認できます。

4段目

・APM VM Memory Usage
・APM VM CPU Utilization
・APM VM EventLoop

APM Node VMsよりコピーしたグラフ。以前、フレームワークアップデートでレスポンスタイムなどには現れない潜在的なサーバー負荷の上昇があったことを受けて。

5段目

・BROWSER Route change 
BROWSER Page Viewsで見られるグラフがコピーできないので同様のものを作成。

SELECT average(duration), average(jsDuration) from BrowserInteraction where appName = 'APP-NAME' and browserInteractionName = 'item' TIMESERIES auto

・BROWSER Frontend vs Backend

BROWSER Summary よりコピー。 vs という言葉に意味はなく、別々に時系列で見られるというものです。

6段目

・BROWSER Page views with javascript errors
・BROWSER average Duration
・BROWSER Throughput

BROWSER Summary よりコピー。 エラー・速度・量といった基本的な監視事項。

7段目

・Core web vitals (modified)

Core Web Vitalsは重要な指標の一つとしています。一覧性を高めるためにFIDを10分の1、CLSを10倍にしてスケールを合わせてあります。

SELECT percentile(largestContentfulPaint, 75), percentile(firstInputDelay, 75)/10 as 'FID/10' ,percentile(cumulativeLayoutShift, 75)*10 as 'CLSx10' FROM PageViewTiming WHERE (appId = 1XXXX1111) TIMESERIES auto

・BROWSER User-centric page load times
・First interaction by device type

BROWSER Summary よりコピー。基本的な監視事項

以上の21グラフになります。

本記事では当社の用途に合わせた一例を紹介しました。ダッシュボード作成の参考になれば幸いです。プロダクトの性質やチーム・開発のフェーズによって重要な視点は異なります、それぞれのチームに合わせてカスタマイズをしていくことで快適なモニタリングをすることができます。

Share

大量のTypeScriptの型エラーを解決した話