はじめに
本記事は、「New Relic 使ってみた情報をシェアしよう！ by New Relic Advent Calendar 2024」の10日目の記事となります。(枠が余っていたので、もらっちゃいました)
今回は、NewRelic synthetic monitoringで指定している各URL毎の個別ダッシュボードを作成したので、その手法を書いていこうと思います。
synthetic monitoringとは
まず、synthetic monitoringとは、NewRelic社の外形監視サービスであり、単純なURLの死活監視やシナリオベースの監視など様々な監視モニタータイプが用意されているので、下記のいずれかを選択し外形監視を設定することになります。監視モニタータイプについて、ざっくり説明するとこんな感じです。
| モニターのタイプ | 説明 |
|---|---|
| Ping monitor | URLの死活監視 |
| Simple Browser | ページの性能監視 |
| Scripted Browser | シナリオ監視 |
| Scripted API | エンドポイント監視 |
| Certificate Check | 証明書の有効期限監視 |
| Step Monitor | シナリオ監視 |
| Broken Links monitor | リンク切れチェック |
今回は、上記のモニタータイプで指定している各URLに対して、各種情報を取得するダッシュボードを作成しましたので、その内容を書いていこうと思います。
ダッシュボード作成
まず、ダッシュボードを作成する際に、「テーブル形式」「グラフ形式」のどちらで出力するのが適しているのかの見極めが必要となります。例を交えながら、各ケース毎に、ダッシュボードの作成をしていこうと思います。
(1)テーブル形式の出力
ケース1：集計作業
テーブル形式で出力したほうがいい例として、集計などで過去のデータをまとめて取得したい場合などに適しています。
実際に例としてNRQLを記載しますが、これで該当期間中の指定したURLの各種情報をテーブル形式で出力することができます。※LIMITをMAXで指定したとしても、最大出力件数は5,000件までなので注意が必要。
SELECT URL,responseCode,duration,durationBlocked,durationReceive,durationSend,durationWait,locationLabel,minionPublicIp,requestBodySize,requestHeaderSize,responseBodySize,responseHeaderSize,port FROM SyntheticRequest WHERE URL = '[URL]' SINCE '2024-12-01T00:00:00 [Asia/Tokyo]' UNTIL '2024-12-31T23:59:59 [Asia/Tokyo]' LIMIT MAX
実際にNRQLを実行した画面イメージは下記の様になります。
上記では、出力項目で「 * 」を指定せずに出力をしてます。
「 * 」を指定してしまうと、どうでもいい情報も出力対象になってしまうので、運用面を考え、出力対象はあらかじめ絞っていたほうがいいです。
参考までに、私が必要だなと思うものを下記にピックアップしたので、ご参照いただければと思います。
| 項目 | 説明 |
|---|---|
| URL | URL |
| Response Code | ホストから返される HTTP 応答コード (例: 200、400、503 など)。 |
| Duration | 最初の HTTP リクエストの開始から最後の HTTP リクエストの終了までの合計時間 (ミリ秒単位)。 |
| Duration Blocked | このリクエストがブロックされた合計時間（ミリ秒単位）。 |
| Duration Receive | このリクエストがデータを受信していた合計時間（ミリ秒単位）。 |
| Duration Send | このリクエストがデータを送信していた合計時間（ミリ秒単位）。 |
| Duration Wait | このリクエストが待機していた合計時間（ミリ秒単位）。 |
| Location Label | アクセス元の国 |
| Minion Public Ip | アクセス元のグローバルIP |
| Request Body Size | ホストへのリクエスト本体のサイズ（バイト単位）。 |
| Request Header Size | ホストへのヘッダー要求のサイズ（バイト単位）。 |
| Response Body Size | ホストからの応答本体のサイズ（バイト単位）。 |
| Response Header Size | ホストからの応答ヘッダーのサイズ（バイト単位）。 |
| Port | アクセスポート |
これで、集計作業などはしやすくなったのですが、最大出力件数が5000件までという制限がネックとなります。(NewRelicさん、改善してくださーい)
さらに、アクセス元のリージョンを複数している場合は、一度に出力できる量はさらに狭まってしまいます。
そこで、必要なリージョンのみに絞って出力するこをおすすめします。上記NRQLのWHEREの指定を下記の様に変更するだけでOKです。
WHERE URL = '[URL]'
↓
WHERE (URL = '[URL]' AND locationLabel = 'Tokyo, JP' )
ケース2：HTTPレスポンスコードの異常値の確認
次にテーブル形式で出力したほうがいい例として、HTTPレスポンスコードで異常値だったものを確認する際にも有効です。
その際は、ケース1のNRQLのWHEREの指定を下記の様に変更するだけでOKです。※HTTPのレスポンスコードが「200, 201, 202, 203, 204, 205, 206, 302, 308)」以外のみを出力対象とする
WHERE URL = '[URL]'
↓
WHERE URL = '[URL]' AND responseCode NOT IN (200, 201, 202, 203, 204, 205, 206, 302, 308)
(2)グラフ形式の出力
ケース3：特定メトリクスのグラフ形式で出力
次にグラフ形式で出力する例を記載しようと思います。
グラフ形式で出力したい場合は、「TIMESERIES」を指定するだけでOKで、後は何の項目を出力対象にするかの指定のみするだけでOKです。
実際に例として、該当URLのdurationを指定した際のNRQLを下記に記載します。
SELECT average(duration) FROM SyntheticRequest WHERE URL = '[URL]' FACET CASES( WHERE (locationLabel = 'Tokyo, JP') AS 'Tokyo, JP', WHERE (locationLabel = 'Seoul, KR') AS 'Seoul, KR') TIMESERIES
画面で見るとこんな感じで、グラフ形式で出力できていることが確認できるかと思います。
最後に
今回は、synthetic monitoringで指定している各URL毎のレポートやダッシュボード作成などをやってみたので、その内容を今日は記載しました。
まだまだ経験が浅い為、ケースは3つほどしか書けなかったのですが、今後知見を増やした際は、どんどん追記していこうと思います。
終わりです('◇')ゞ