SQL 構造化イベント用ダッシュボード

仕組み

シグナルから意思決定までのレビュー可能なワークフロー

決断でリードする

ダッシュボードは、関連する少数の質問に答える必要があります。利用可能なすべてのグラフではなく、主要な健康状態または結果の指標から始めます。

検出後に診断を行う

最初にトレンドビューとしきい値ビューを配置し、次に、変化を説明する内訳と最近のイベントテーブルを追加します。

文書の所有権と応答

ヘッダーとメモを使用して、メトリック、予想される範囲、所有者、および次のステップを定義します。コンテキストにより、インシデント中にダッシュボードが使用可能になります。

共有 Telemetry ダッシュボードの構築

グラフの配置と共同ダッシュボード編集を示す実際の製品のキャプチャ。

境界線

これが置き換えられないもの

ダッシュボードには、レビューされたクエリがまとめられます。不安定なメトリクス定義を信頼できるものにはしません。
共有ボードは、利用可能なすべてのチャートの目録になるのではなく、小さな意思決定セットに焦点を当て続ける必要があります。
Telemetry ダッシュボードは、インシデントランブック、所有権モデル、または財務報告のための耐久性のある信頼できる情報源システムに代わるものではありません。

検査可能な証明パス

イベント契約から目に見える答えまで

この例では、宣言されたスキーマ、読み取り専用の SQL、および決定論的な合成結果を使用します。顧客のベンチマークとしてサンプルデータを提示せずにワークフローを示します。

1. イベント契約

1行 api_requests、クエリで使用される型が明示的に示されています。

timestamp_utc: Timestamp
route_template: Utf8
status_code: Int64
latency_ms: Float64

イベント契約書を閲覧する

2. 読み取り専用 SQL

リクエストが 20 件以上ある API ルートのうち、5xx エラー率が最も高いのはどれですか？

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. 合成結果

チェックアウトは 25 件中 5 件のリクエストで失敗しました。検索は 25 件中 1 件でした。

route_template	requests	エラー
/api/checkout	25	5
/api/search	25	1
/api/profile	20	0

クエリ、結果、および警告を検査する

能力

含まれるもの

Explore および SQL クエリウィジェット

折れ線、棒、散布図、積み上げ面、および表の結果

セクションの見出しとコンテキストのマークダウンメモ

チームを対象としたダッシュボードのドラッグ、サイズ変更、名前変更、共有

ダッシュボードの作成、更新、リスト、および削除 API

ドキュメント

ダッシュボード設計ガイドダッシュボード API SQL レシピライブラリ

分析を見る

この機能を使用する SQL レシピ

ルート別のAPIエラー率の計算

API ルートを 5xx エラー率で順位付けします。1 件の失敗が結果を大きく左右しないよう、リクエストが 20 件未満のルートを除外します。

レシピを開く

Webhook の再試行回復を測定する

永続的な Webhook エラーを、後の試行で回復した配信から分離します。

レシピを開く

SQL でサインアップからアクティベーションまでのファネルを構築する

サインアップ、オンボーディング、統合、最初の価値のマイルストーンを通じてユニークユーザーのコンバージョンを計算します。

レシピを開く

顧客の証拠

チームがこのワークフローを使用する方法

"Telemetry を使用すると、ビジネスで何が起こっているかを追跡、分析、視覚化することが非常に簡単になります。シンプルさとパワフルさの完璧な組み合わせです。"

ナム・カン, ブラウザフロー

顧客事例を読む

"Telemetry は、ログのダンプとイベントの追跡に最適です。それは簡単で、SQL ワークベンチは高速であり、事前にスキーマについて心配する必要はありません。 REST API 上で SQL を実行すると、データを取得してレポートを Slack に直接ダンプできます。これはセントリーが私にしてくれたことの要点です。"

プレム・ヴィスワナタン, SwiftCX

顧客事例を読む