本文へ移動
Telemetry
ドキュメントを見る
はじめに更新日: 2026年8月2日Telemetry 編集チームと製品チームによるレビュー2 最小読み取り時間

コーディング エージェントでこのドキュメントを使用してください

Claude Code、Codex、Cursor、または別のコーディング エージェント用の集中プロンプト パックを開き、それをここで説明するワークフローに適応させます。

このページの内容
  1. 意思決定指向のウィジェットを 1 つ作成する
  2. 最初のダッシュボードは小さくしてください
  3. 制限付きアラートを作成する
  4. 条件の両側をテストする
  5. 応答を定義する

最初のダッシュボードとアラートを作成する

ダッシュボードには、レビューされた回答が保存されている必要があります。アラートは、所有者と有用な応答を持つ条件を識別する必要があります。グラフがもっともらしいという理由だけで、未検証のクエリを宣伝しないでください。

このチュートリアルは、リクエスト量とエラー率 SQL から開始します。 最初のTelemetry SQLクエリを書く.

意思決定指向のウィジェットを 1 つ作成する

Telemetry でクエリを実行し、結果と一致するグラフを選択して、 ダッシュボードに追加.

API エラー率の結果の場合:

  • 時間が主要な軸である場合は、折れ線グラフを使用します。
  • 少数のルート テンプレートのセットを比較する場合は、棒グラフを使用します。
  • 正確な値、ボリュームしきい値、およびいくつかの測定値を表示しておきたい場合は、テーブルを使用します。

ウィジェットの名前は、実装ではなく決定に基づいて付けます。 「API ルート別サーバーエラー率」は「クエリ 7」よりも明確です。

分母を表示しておきます。 1 つのリクエストで 1 つのエラーが発生したルートが、10,000 のリクエストで 500 のエラーが発生したルートよりも上位にランクされることはありません。リクエスト ボリュームとエラー パーセンテージの両方を含めるか、SQL で最小ボリューム条件を強制します。

最初のダッシュボードは小さくしてください

有用な最初の信頼性ダッシュボードには次のものが含まれる場合があります。

  1. 時間の経過に伴うリクエスト量。
  2. 時間の経過に伴うサーバー エラーの割合。
  3. ルート別の p95 遅延。
  4. 上位のエラー カテゴリまたはフィンガープリント。
  5. アクセスが承認された場合のみ、影響を受けるアカウントのテーブル。

各ウィジェットは、検査可能な行または保存された SQL にリンクバックする必要があります。複数のグラフ スタイルで同じ指標を繰り返すことは避けてください。

参照 ダッシュボードの作成 レイアウトと所有権のガイダンス用。

制限付きアラートを作成する

1 本の時系列線から始めます。X 軸に時間、Y 軸に 1 つの数値メトリクスを表示し、グループ化や分割は行いません。 Telemetry のみが提供する アラートの作成 この狭いチャート形状では、しきい値、最近のポイント ウィンドウ、状態、通知がすべて 1 つの順序付けられたシグナルを参照するためです。グループ化されたグラフでは、どの線が、すべての線が、または各線が独立してアラートを制御しているかが不明瞭になります。

ダッシュボード上で複数行の比較を維持します。アラートの場合は、1 つの母集団にフィルターをかけるか、グループを意図的に集約するか、グループに異なるしきい値または所有者が必要な場合は個別のアラートを作成します。参照 アラート 完全な理論的根拠と例については、こちらをご覧ください。

検証された単線グラフまたはクエリ結果を開き、選択します アラートの作成。定義:

  • 集計と測定。
  • 評価する最後のデータポイントの数。
  • 比較としきい値。
  • 評価間隔。
  • 不完全な最新のバケットを無視するかどうか。
  • 応答を所有する受信者。

合成開発テーブルの場合は、非ページング電子メール アラートから始めます。制作例は次のとおりです。

p95 of the last 5 completed data points is greater than 850 ms

または:

server_error_pct is greater than 5% and requests is at least 100

正確なしきい値は、サービスの目的、トラフィック パターン、および応答ポリシーによって異なります。コピーした数値はベースラインの代わりにはなりません。

条件の両側をテストする

次のような制御された合成イベントを送信します。

  1. アラートをしきい値以下のままにしておきます。
  2. 結果をしきい値より上に移動します。
  3. 予想される受信者に通知を作成します。
  4. 回復後はしきい値以下に戻ります。

クエリ、しきい値、受信者、および応答リンクを記録します。次に、合成行を本番レポートから削除するか、明確に分離します。

応答を定義する

すべてのアラートには短いアクションが必要です。

  • 関連するダッシュボードを開きます。
  • 影響を受けるルート、リリース、アカウントを検査します。
  • リクエストまたはワークフロー識別子と関連付けます。
  • 軽減するか、ロールバックするか、監視を継続するかを決定します。
  • 復旧時間と顧客への影響を個別に記録します。

アラートの動作とトラブルシューティングについては、以下をお読みください。 アラート そして アラートの配信とトラブルシューティング。 計装を広くデプロイする前に、 本番環境の計装チェックリスト.

関連製品の機能

レビュー済みの SQL を所有するしきい値と応答のワークフローに昇格します。

所有権と技術リファレンス

Telemetry 編集チームがこの説明を所有しています。製品チームは動作、例、境界をレビューします。

編集基準を見直す