💡

【入門SRE】NewRelicでSREのダッシュボードを作成して可視化する

に公開
Kubernetes
API
SRE
New Relic
SLO
tech

はじめに

SRE（Site Reliability Engineering）として、サービスの健全性を継続的に監視し、異常を早期に検知することは重要な責務です。しかし、監視ツールから大量のメトリクスが取得できても、「見るだけで異常に気づける」ダッシュボードがなければ、オンコール担当者が深夜に異常を発見することは困難です。

本記事では、New Relicを使用して、異常時にすぐに検知できる理想的なSREダッシュボードを構築する方法を紹介します。大型リリースや重要なイベント時に、オンコール担当者が「見るだけで異常に気づける」ダッシュボードの設計指針と実践的な構築方法を紹介します。

本記事で学べること：

  • SREダッシュボードの設計原則と基本方針
  • Golden Signals（Latency、Error、Traffic、Saturation）の可視化方法
  • New Relicでのダッシュボード作成とカスタマイズ方法
  • 異常検知に最適化されたUI/UXの設計
  • 実践的なダッシュボード構成のサンプル

1. SREダッシュボードの目的と設計原則

1.1 ダッシュボードの目的

SREダッシュボードは、単なるメトリクスの表示ではなく、以下の目的を達成する必要があります：

  • 障害の予兆・異常を最短時間で検知する

    • 数秒〜数分で異常を発見できる可視化
    • ノイズではなく、確度の高いシグナルに集中

  • サービス全体の依存関係と影響範囲を理解しやすい

    • API → 内部サービス → DB → 外部依存先の順で配置
    • トラブルシュートの導線に合わせた階層構造

  • オンコール担当が深夜でも直観的に判断できる

    • 色のルールを統一（赤：クリティカル、黄：警戒、青：通常）
    • 正常時は全部青になるように設計（異常が目立つ）

1.2 設計の基本方針

SREダッシュボードは、3つの階層で構成します：

1. 上段は「異常の有無が分かる一枚絵」

  • ここだけで "今のサービスは正常か？" が判別できる
  • 各グラフをシンプルに（線は1〜2本まで）
  • 色のルールを統一

2. 中段は「どこが悪いかを辿れる階層」

  • サービス依存関係の順番で並べる
  • 各サービスの遅延/エラー/スループットを同じレイアウト/色で揃える
  • トラブルシュートの導線に合わせる

3. 下段は「深掘りしないと見えない詳細」

  • JVM・Go runtime・gRPC ステータス
  • DB のトランザクション、ロック、コネクション
  • キューの滞留、Pod のOOM/Kill、再起動数
  • 外部 API の応答速度・エラー率

2. Golden Signals（黄金の4指標）

SREの監視において、最も重要な4つの指標を「Golden Signals」と呼びます。これらを可視化することで、サービスの健全性を包括的に把握できます。

2.1 Latency（遅延）

測定すべき指標：

  • API / gRPC / バッチ処理の主要レイテンシ
  • P95 または P99 で揃える（P50は参考程度）
  • エンドツーエンドのレイテンシと各サービス間のレイテンシ

New Relicでの可視化例：

SELECT percentile(duration, 95) 
FROM Transaction 
WHERE appName = 'my-api' 
FACET name 
TIMESERIES

2.2 Error（エラー）

測定すべき指標：

  • HTTP ステータス別エラー率（4xx、5xx）
  • 例外件数、DB/Tier毎のエラー発生傾向
  • エラーレートの推移（エラー数/総リクエスト数）

New Relicでの可視化例：

SELECT count(*) 
FROM Transaction 
WHERE appName = 'my-api' 
  AND http.statusCode >= 500 
FACET name 
TIMESERIES

2.3 Traffic（負荷）

測定すべき指標：

  • リクエスト数（RPS: Requests Per Second）
  • 外部 API 呼び出し数
  • 大型リリースでは特にスパイク検知が重要

New Relicでの可視化例：

SELECT rate(count(*), 1 second) 
FROM Transaction 
WHERE appName = 'my-api' 
FACET name 
TIMESERIES

2.4 Saturation（飽和）

測定すべき指標：

  • CPU / MEM / スレッドプール / DB コネクション
  • GKE ならノード/Podのリソース水位を統一ルールで並べる
  • キューの滞留、コネクションプールの使用率

New Relicでの可視化例：

SELECT average(cpuPercent) 
FROM SystemSample 
WHERE hostname LIKE 'k8s-node-%' 
FACET hostname 
TIMESERIES

3. New Relicダッシュボードの作成

3.1 ダッシュボードへのアクセス

New Relicでダッシュボードを作成するには、以下の手順でアクセスします：

  1. one.newrelic.com > All capabilities > Dashboards に移動
  2. ダッシュボードインデックスを開く
  3. + Create dashboard をクリック

詳細はNew Relic公式ドキュメント - ダッシュボードの管理を参照してください。

3.2 ダッシュボードの基本設定

ダッシュボードの名前付け：

  • 検索可能なため、意味のある名前を付ける
  • 例：SRE - Production API Dashboard、SRE - Customer Release Monitoring

権限設定：

  • Public - Read and write: チーム全体で編集可能
  • Private: 作成者のみアクセス可能
  • オンコール担当者が確実にアクセスできるよう、適切な権限を設定

3.3 チャートの追加

チャートの追加方法：

  1. ダッシュボード編集画面で + Add widget をクリック
  2. Query を選択してNRQLクエリを入力
  3. チャートタイプを選択（Line、Bar、Area、Pieなど）
  4. チャートのサイズと位置を調整

チャートの配置：

  • 最大で12列のチャートを設定可能
  • 重要な指標は大きく、詳細情報は小さく配置
  • 読む順番に配置（左上 → 右下）

4. 実践的なダッシュボード構成

4.1 上段：異常の有無が分かるSummary

上段には、**「今のサービスは正常か？」**を一目で判断できる指標を配置します。

配置すべきチャート：

  1. API全体のError率

    • 5xxエラーの割合を表示
    • しきい値：0.1%以下（緑）、0.1-1%（黄）、1%以上（赤）

  2. API全体のP95レイテンシ

    • 主要エンドポイントのP95レイテンシ
    • しきい値：SLAに基づいて設定（例：200ms以下）

  3. 主要SLIの達成状況

    • SLA/SLIベースの「赤黄緑ランプ」
    • SLI達成率 >= 99.9% → 緑、99.0〜99.9% → 黄、<99.0% → 赤

  4. GKEノード飽和ランプ

    • CPU/メモリ使用率のサマリー
    • 80%以上で警告、90%以上でアラート

  5. 外部API正常性

    • 依存する外部APIの応答時間とエラー率

NRQL例：

-- API全体のError率
SELECT percentage(count(*), WHERE http.statusCode >= 500) 
FROM Transaction 
WHERE appName = 'my-api' 
TIMESERIES

-- API全体のP95レイテンシ
SELECT percentile(duration, 95) 
FROM Transaction 
WHERE appName = 'my-api' 
TIMESERIES

4.2 中段：どこが悪いかを辿れる階層

中段には、サービス依存関係の順番で各サービスのメトリクスを配置します。

配置順序：

  1. API層

    • 各APIエンドポイントのP95レイテンシ
    • エラー率
    • RPS（Requests Per Second）

  2. 内部サービス層

    • gRPCサービスのレイテンシ
    • gRPC status breakdown
    • サービス間の呼び出し数

  3. データベース層

    • DB wait time / lock time
    • クエリ実行時間
    • コネクションプールの使用率

各サービスの統一レイアウト：

  • 左：P95レイテンシ
  • 中：Error率
  • 右：RPS

同じレイアウトと色で統一することで、異常なサービスを素早く特定できます。

NRQL例：

-- サービス別のP95レイテンシ
SELECT percentile(duration, 95) 
FROM Transaction 
WHERE appName = 'my-api' 
FACET name 
TIMESERIES

-- サービス別のエラー率
SELECT percentage(count(*), WHERE http.statusCode >= 500) 
FROM Transaction 
WHERE appName = 'my-api' 
FACET name 
TIMESERIES

-- サービス別のRPS
SELECT rate(count(*), 1 second) 
FROM Transaction 
WHERE appName = 'my-api' 
FACET name 
TIMESERIES

4.3 下段：原因特定用の深掘り

下段には、原因特定に必要な詳細情報を配置します。

配置すべきチャート：

  1. JVM/ランタイムメトリクス

    • Heap使用率
    • GC頻度と時間
    • スレッド数

  2. Kubernetesメトリクス

    • Pod再起動数
    • OOM Kill発生数
    • ノードのリソース使用率

  3. キューとストリーム

    • キューの滞留数
    • メッセージ処理速度

  4. 特定顧客のメトリクス

    • 大型流入のトラフィック
    • エラー率
    • レイテンシ

NRQL例：

-- Pod再起動数
SELECT count(*) 
FROM K8sPodSample 
WHERE restartCount > 0 
FACET podName 
TIMESERIES

-- キューの滞留数
SELECT average(queueDepth) 
FROM QueueSample 
WHERE appName = 'my-api' 
FACET queueName 
TIMESERIES

5. UI/UXの工夫

5.1 色の統一ルール

色のルールを統一することで、異常を素早く識別できます：

  • 赤（#FF0000）: クリティカルな異常

    • Error率 > 1%
    • レイテンシがSLAの2倍以上
    • リソース使用率 > 90%

  • 黄（#FFA500）: 警戒が必要

    • Error率 0.1-1%
    • レイテンシがSLAの1.5-2倍
    • リソース使用率 80-90%

  • 青（#0066CC）: 正常

    • すべての指標が正常範囲内

正常時は全部青になるように設計することで、異常が目立ちます。

5.2 視線誘導と配置

読む順番に配置：

  • 左上から右下へ自然な流れで配置
  • 重要な指標はカード形式で大きく表示
  • 関連するチャートを近くに配置

カード形式の活用：

重要な指標（Error率、SLA達成率など）は、数値と色で一目で分かるカード形式で表示します。

5.3 タイムピッカーと時間範囲

タイムピッカーの活用：

  • デフォルトでは過去1時間を表示
  • インシデント時は過去5分〜15分に絞り込む
  • カスタム時間範囲で特定の期間を分析

更新間隔：

  • リアルタイム監視：1分間隔
  • 通常監視：5分間隔
  • 過去データの分析：手動更新

詳細はNew Relic公式ドキュメント - タイムピッカーを参照してください。

6. 大型流入向けの追加モニタリング

6.1 顧客別メトリクス

大型流入向けリリースでは、特定の顧客IDのみのメトリクスを追加することで、影響範囲の特定が早まります。

追加すべきメトリクス：

  • 特定の顧客IDのトラフィック
  • エラー率
  • レイテンシ

NRQL例：

-- 顧客別のトラフィック
SELECT rate(count(*), 1 second) 
FROM Transaction 
WHERE appName = 'my-api' 
  AND customerId = 'VIP-001' 
TIMESERIES

-- 顧客別のエラー率
SELECT percentage(count(*), WHERE http.statusCode >= 500) 
FROM Transaction 
WHERE appName = 'my-api' 
  AND customerId = 'VIP-001' 
TIMESERIES

6.2 SLA/SLIベースのランプ

SLAランプの実装：

視認性を重視した「SLAランプ」は深夜帯に強いです。

  • SLI達成率 >= 99.9% → 緑
  • 99.0〜99.9% → 黄
  • <99.0% → 赤

NRQL例：

-- SLA達成率の計算
SELECT 
  percentage(count(*), WHERE duration < 200) as 'SLA達成率'
FROM Transaction 
WHERE appName = 'my-api' 
TIMESERIES

7. アラートの整理基準

7.1 ノイズを防ぐための判断基準

ダッシュボードと連携したアラート設定により、確度の高い通知を実現します。

アラート設定の原則：

  • 短期スパイクでは鳴らさない（5分移動平均を使用）
  • 中軸サービスのみを対象にする
  • しきい値は本番の過去データから逆算（感覚では決めない）
  • Error + Latency の複合条件で精度が上がる

複合条件の例：

  • Error率上昇 AND P95レイテンシが一定時間以上悪化 → アラート
  • どちらか片方だけなら警告止まり

7.2 アラートの優先度設定

Critical（緊急）：

  • Error率 > 1% かつ 継続時間 > 5分
  • P95レイテンシがSLAの2倍以上 かつ 継続時間 > 5分
  • リソース使用率 > 90% かつ 継続時間 > 10分

Warning（警告）：

  • Error率 0.1-1% かつ 継続時間 > 10分
  • P95レイテンシがSLAの1.5-2倍 かつ 継続時間 > 10分
  • リソース使用率 80-90% かつ 継続時間 > 15分

8. ダッシュボードの管理とメンテナンス

8.1 ダッシュボードの複製と共有

ダッシュボードの複製：

  • 右隅のアイコンをクリックし、Duplicate dashboardを選択
  • 複製版には「コピー」が付けられる
  • 名前を変更し、関連するアカウントを選択して権限を追加

ダッシュボードの共有：

  • PDFファイルとしてエクスポート可能
  • チャートをPNG画像またはリンクとして共有可能
  • パーマリンクをコピーして共有

詳細はNew Relic公式ドキュメント - ダッシュボードの管理を参照してください。

8.2 テンプレート変数の活用

テンプレート変数を使用することで、1つのダッシュボードで複数の環境やサービスを監視できます。

変数の例：

  • $app: アプリケーション名
  • $environment: 環境（production、staging）
  • $customerId: 顧客ID

使用方法：

  1. ダッシュボード編集画面でDashboard Optionsを開く
  2. Template variablesセクションで変数を定義
  3. NRQLクエリで$appなどの変数を使用

8.3 定期的なレビューと改善

レビューのポイント：

  • ダッシュボードを見て、実際に異常を発見できたか
  • 不要なチャートはないか
  • 重要な指標が抜けていないか
  • 色や配置が直感的か

改善のサイクル：

  1. ダッシュボードを使用してインシデント対応
  2. インシデント後に振り返り（Retrospective）
  3. ダッシュボードの改善点を洗い出し
  4. 改善を実装
  5. 再度レビュー

9. 実践例：完成イメージ

9.1 ダッシュボード構成のサンプル

上段：一目で異常が分かるSummary

中段：API → Internal Service → DB の順で配置

下段：原因特定用の深掘り

9.2 異常時の見え方

正常時：

  • すべてのチャートが青（正常）
  • 数値が安定している
  • トレンドが予測可能

異常時：

  • 該当するチャートが赤または黄に変わる
  • 異常なサービスが一目で分かる
  • 上段 → 中段 → 下段の順で原因を特定

10. まとめ

本記事では、New Relicを使用したSREダッシュボードの構築方法を紹介しました。

重要なポイント：

  1. Golden Signals（Latency、Error、Traffic、Saturation）を可視化
  2. 上段で異常の有無、中段で異常の場所、下段で原因を特定
  3. 色のルールを統一し、正常時は全部青になるように設計
  4. サービス依存関係の順番で配置し、トラブルシュートの導線に合わせる
  5. 大型流入向けには顧客別メトリクスとSLAランプを追加

次のアクション：

  1. 既存本番のメトリクスを棚卸し
  2. Golden Signalsの線を先に作る
  3. 依存関係マップを並べ替える
  4. ダッシュボードの初版を作り、SRE内でレビューする
  5. 実際のインシデント対応で使用し、改善を繰り返す

適切に設計されたダッシュボードは、オンコール担当者が深夜でも直観的に異常を発見し、迅速に対応するための強力なツールとなります。

参考資料

Discussion