はじめに
こんにちは。マネージドサービス部の福田です。
今月はNew Relic Advent Calendar 2024が開催されていることもありますが
知識のアウトプットとしてもブログ執筆していたら本ブログで6記事目になりました。
アウトプット大事ですね
今年最後のブログはNew Relicダッシュボードを作成する機会が多かった年なので
ダッシュボード作成時意識していることだったり含めて振り返りのブログ記事になります。
New Relicのダッシュボードでどのようなことが実現できるのかは以下ブログを参考にしていただければと思います
ちなみに以下ブログがダッシュボードに関する最初の記事な気がしています。
よく使用していた機能①：Thresholds機能
New Relicのダッシュボードにある「Customize this visualization」内のThresholds機能を活用するとダッシュボードのチャートに閾値表示することが可能になり
データの正常、異常値を視覚的に見やすくすることができます。
Thresholdsの設定画面は以下になります。
境界線の設定
折れ線グラフなどで、データがどの範囲に収まるべきか「from」から「to」までの範囲を設定できます。
この設定により、データが正常な範囲内にあるかどうかを一目で確認できます。
各閾値はそれぞれSeverity levelを以下のように割り振ることが出来、それぞれ対応する色が異なります。
- Good：緑
- Warning：黄色
- Approaching critical：オレンジ
- Critical：赤
- Neutral：背景色なし
グラフへの文字記載について
- 例1: 「to」が指定されている場合
- 指定した位置に文字が表示されます。
- 例2: 「to」が空欄の場合
- 上限がないとみなされ、グラフの最上部に文字が記載されます。
複数の閾値を持つ場合の対応例
- 以下の条件を満たすダッシュボードチャートを作成したいとします
- チャートには2つの表示項目(ネットワークトラフィック(IN/OUT))がある。
- 各表示項目には異なる閾値が設定されている。
- 閾値が視覚的にわかるよう、テキストや背景色で表現したい。
問題点
以下のような設定の場合。条件が重複してしまい、正確な表現が難しくなります：
- 450MB以下は正常：from 450MB to 0
- 450MB以上は異常：from 450MB
- 1.5GB以下は正常：from 1.5GB to 0
- 1.5GB以上は異常：from 1.5GB
この場合、「450MB以上」と「1.5GB以下」の条件が重複し、どちらの閾値も明確に区別できなくなります。
解決策案
条件を整理し、ダッシュボード全体での「正常性」を優先的に表現しつつ、各項目の閾値情報も見えるようにします。
| 項目 | 範囲/閾値 | 背景色/線の色 | テキスト |
|---|---|---|---|
| ダッシュボード全体の正常 | from 450MB to 0 | 緑（Good） | ネットワークトラフィック量(IN/OUT)<450MB |
| ダッシュボード全体の異常 | from 451MB | 赤 （Critical） | （半角および全角のスペース） |
| 1つ目の項目 | from 450MB to 450MB | オレンジ （Approaching critical） |
ネットワークトラフィック量(IN)>450MB |
| 2つ目の項目 | from 1.5GB to 1.5GB | 黄色（Critical） | ネットワークトラフィック量(OUT)>1.5GB |
その他グラフ形式のThresholds機能活用例
設定した閾値に基づいて正常および異常値かどうかを把握することが出来ます。
よく使用していた機能②：ダッシュボード変数
NRQL（New Relic Query Language）でリソース名を直接記述せず、ダッシュボード変数を使用することで、他システムへの流用が容易になります。
これにより、変更箇所がダッシュボード変数のみになるためダッシュボードの管理工数が削減されます
ダッシュボード変数設定方法
| 項目名 | 説明 |
|---|---|
| Name to use in queries | クエリ内で使用する変数の名前。NRQLクエリ内で{{指定した変数名}}として参照されます。 |
| Display name (optional) | ダッシュボードのフィルターバー上に表示される名前。 |
| Type | 変数のタイプを選択します。以下の3つから選択可能： - Text variable：テキスト入力 - List variable：カンマ区切りで選択肢を入力（例： prod,staging,dev）- Query variable ：NRQLから動的に値を取得 |
| Fetch data from this account | 変数の値を取得するアカウントを指定します。 |
| Query | 変数の値を取得するためのNRQLクエリを入力します。 (例：SELECT uniques(countryCode) FROM PageAction ） |
| Ignore time picker | オンにすると、上記NRQLの時間範囲が他の時間ピッカーより優先されます。 |
| Multi-value | 複数の値を同時に選択できるようにするオプション。 |
| Default value | 変数のデフォルト値を設定します。 |
| Output format | 変数の出力形式を指定します（例：文字列、数値、識別子など）。 |
変数を用いたダッシュボードチャートのNRQLの補足
- = {{変数値}}を使用した場合は単一の値が表示されます。
- IN ({{変数値)) を使用した場合:選択された値はOR条件として扱われます
= の場合
WHERE level = {{level}}
# 以下のように一つの条件のみ表示
WHERE level = 'ERROR'
IN の場合
WHERE level IN ({{level}}))
# 以下のように複数の条件が表示
WHERE level IN ('ERROR', 'WARNING'))
ダッシュボード例：ログを重要度（ERROR、WARN、INFO）ごとに表示したい
ERRORログのみの表示
WARNログのみの表示
INFOログのみの表示
複数の重要度（ERROR、WARN)ログを表示
ダッシュボード変数の設定をしている中で個人的に感じたこと
ダッシュボード変数の値をNRQLで動的に取得する際には、New Relicに収集されたデータを使用します。
そのため、ログ情報をログレベルごとに表示したい場合は、ログの形式を統一してNew Relicに送信することが重要です。
例えば、同じエラーログでも「Error」「ERROR」「err」など表記が異なると、ダッシュボードのプルダウンメニューで選択する際に混乱を招く可能性がありますので
ログの仕様を統一したり、タグ付けなどでデータを加工してからNew Relicに送ると、ダッシュボード設定が効率的に行えると感じました。
ダッシュボードの変数の詳細は以下ブログに記載しています
作成したダッシュボード
最後に今年作成したダッシュボードのうち個人的に活用しているダッシュボードと思ったよりも活用できなかったダッシュボードについて紹介します。
コストに関するダッシュボード
個人検証時にコストが知りたかったので作成したダッシュボードになります。
作成したダッシュボードは定期的にSlackへ通知するようにしております。
ダッシュボード内容としては以下です。
- AWSの利用料金およびコスト削減推奨内容
- New Relicのデータ転送量
- New Relicユーザ数の増減およびユーザ操作履歴
AWSの利用料金およびコスト削減推奨内容
New Relicのデータ転送量
ちなみに以下設定箇所よりダッシュボード情報を抽出する環境を5アカウントまで跨ぐことが出来ます。 この機能を活用することで一つのダッシュボードの画面で複数アカウントのNew Relicデータ転送量の把握が可能になります。
New Relicユーザ数の増減およびユーザ操作履歴
コスト削減については以下ブログも執筆しているのでもし気になる方がいらっしゃったらご覧いただければと思います。
あまり活用しなかった/携われなかったダッシュボード
SLIに関するダッシュボードになります。
以下のようにブログを執筆しましたがあまり深掘りできなかったのが無念です。
来年はSLI/SLOを深ぼっていきたいです。
ダッシュボード（可視化）周りで来年やりたいこと
ダッシュボードメンテナンスの簡略化を目指す
ダッシュボードを作成する中で様々なダッシュボード作成できることはわかりましたが、作成後のメンテナンスが意外と大変だなーと思います。
特にThresholds機能とかですね。TerraformやNerdGraphを使用するにしてももう少しぱっと見で変更箇所把握できて修正も楽できるような仕組み化が必須だなと感じました。
Map Widgetの利用
Map Widgetは、New Relicが提供する「Custom visualizations」機能の一つで、緯度・経度を含むデータを地図上に表示することができます。
この機能を使えば、システムやユーザーの状態を地理的な観点から把握でき、問題箇所やトラフィックの傾向を迅速に特定することが可能になります。
※追加ライセンス費用なしで利用できます
以下ブログでも記載しておりますがICMP PING監視とLookup Tableを組み合わせて
全国に存在するオンプレ機器のパフォーマンスをMap Widget上への表示を目指していきたいです。
Pathpointの利用
Pathpointの詳細は以下ブログに記載されております。
これはSLIのダッシュボード作成でも関わってくる内容だと思うのでこの機能もしっかりと使いこなしていきたいです。
以下は上記ブログに記載されているPathpointの画面イメージです。
Pathpointを利用することで例えばECサイトにて以下活用が可能になるのでパフォーマンス低下に伴う解決までの時間が大幅に短縮＆作業効率化が図れると思います。
- Webフロントエンド（ログイン機能や商品カタログ表示など）のパフォーマンス低下が売上や顧客満足度にどう影響しているかをリアルタイムで把握
- その原因となるバックエンドやインフラ要素を特定
さらに、Pathpointの設定では通常エンティティを指定対象としますが、トランザクション単位でモニタリングしたい場合は トランザクションをキートランザクションとして設定することでPathpointの対象にすることが可能です。
まとめ
New Relicダッシュボードだけでなくオブザーバビリティについて考えさせられる一年でした。
オブザーバビリティおよびNew Relic活用方法のほかにも今年参加したISUCONは悔しい思いをしたので来年はボトルネック特定後の パフォーマンス改善まで出来るようなスキルを身に着けていきたいです！！
宣伝
弊社では、お客様環境のオブザーバビリティを加速するための伴走型のNew Relic導入支援サービスなどもご提供しております。 もしご興味をお持ちの方は、こちらのサービスご紹介ページの一番下にあるお問合せフォームよりお問合せ頂けましたら幸いでございます。
