1. イベント契約
1行 api_requests、クエリで使用される型が明示的に示されています。
- timestamp_utc
- Timestamp
- route_template
- Utf8
- status_code
- Int64
- latency_ms
- Float64
仕組み
シグナルから意思決定までのレビュー可能なワークフロー
1
決断でリードする
ダッシュボードは、関連する少数の質問に答える必要があります。利用可能なすべてのグラフではなく、主要な健康状態または結果の指標から始めます。
2
検出後に診断を行う
最初にトレンド ビューとしきい値ビューを配置し、次に、変化を説明する内訳と最近のイベント テーブルを追加します。
3
文書の所有権と応答
ヘッダーとメモを使用して、メトリック、予想される範囲、所有者、および次のステップを定義します。コンテキストにより、インシデント中にダッシュボードが使用可能になります。
共有 Telemetry ダッシュボードの構築
グラフの配置と共同ダッシュボード編集を示す実際の製品のキャプチャ。
境界線
これが置き換えられないもの
- ダッシュボードには、レビューされたクエリがまとめられます。不安定なメトリクス定義を信頼できるものにはしません。
- 共有ボードは、利用可能なすべてのチャートの目録になるのではなく、小さな意思決定セットに焦点を当て続ける必要があります。
- Telemetry ダッシュボードは、インシデント ランブック、所有権モデル、または財務報告のための耐久性のある信頼できる情報源システムに代わるものではありません。
検査可能な証明パス
イベント契約から目に見える答えまで
この例では、宣言されたスキーマ、読み取り専用の SQL、および決定論的な合成結果を使用します。顧客のベンチマークとしてサンプル データを提示せずにワークフローを示します。
2. 読み取り専用 SQL
意味のある 5xx エラー率が最も高いのは、どの API ルートですか?
SELECT
route_template,
COUNT(*) AS requests,
SUM(CASE WHEN status_code >= 500 THEN 1 ELSE 0 END) AS errors,
100.0 * SUM(CASE WHEN status_code >= 500 THEN 1 ELSE 0 END)
/ NULLIF(COUNT(*), 0) AS error_rate_pct
FROM api_requests
WHERE timestamp_utc >= now() - INTERVAL '24 hours'
GROUP BY route_template
HAVING COUNT(*) >= 20
ORDER BY error_rate_pct DESC
LIMIT 10;3. 合成結果
検索の総トラフィック量が多い場合でも、チェックアウト ルートは最も明らかな信頼性リスクです。
| route_template | requests | エラー |
|---|---|---|
| /api/checkout | 25 | 5 |
| /api/search | 25 | 1 |
| /api/profile | 20 | 0 |
能力
含まれるもの
Explore および SQL クエリ ウィジェット
折れ線、棒、散布図、積み上げ面、および表の結果
セクションの見出しとコンテキストのマークダウンメモ
チームを対象としたダッシュボードのドラッグ、サイズ変更、名前変更、共有
ダッシュボードの作成、更新、リスト、および削除 API
分析を見る
この機能を使用する SQL レシピ
顧客の証拠
チームがこのワークフローを使用する方法
“Telemetry を使用すると、ビジネスで何が起こっているかを追跡、分析、視覚化することが非常に簡単になります。シンプルさとパワフルさの完璧な組み合わせです。”
ナム・カン, ブラウザフロー
文書化されたワークフローを確認する“Telemetry は、ログのダンプとイベントの追跡に最適です。それは簡単で、SQL ワークベンチは高速であり、事前にスキーマについて心配する必要はありません。 REST API 上で SQL を実行すると、データを取得してレポートを Slack に直接ダンプできます。これはセントリーが私にしてくれたことの要点です。”
プレム・ヴィスワナタン, SwiftCX
文書化されたワークフローを確認する関連する機能
イベントから意思決定までのワークフローを継続する
1 つの制作ワークフローから始める
対象範囲を拡大する前に、焦点を絞ったプロンプトを使用し、合成イベントを送信し、最初の有用なクエリを検証します。