1. イベント契約
1行 api_requests、クエリで使用される型が明示的に示されています。
- timestamp_utc
- Timestamp
- route_template
- Utf8
- latency_ms
- Float64
- status_code
- Int64
仕組み
シグナルから意思決定までのレビュー可能なワークフロー
1
決断から始める
列を選択する前に、運用上または製品に関する質問を書き留めてください。焦点を絞った質問により、解釈および維持できるクエリが生成されます。
2
構文だけでなく結果を検査する
ボリューム、ヌル、時間ウィンドウ、分母、および予期しないグループをチェックします。 SQL は正常に実行でき、それでも間違った質問に答えることができます。
3
クエリが役立つ場合は保存してください
定期的な分析を名前付きクエリ、ダッシュボード ウィジェット、エクスポート、またはアラートに変換することで、チームがインシデントのたびに分析を再作成することがなくなります。
Telemetry での SQL の書き込みと実行
実際のクエリ エディター、オートコンプリート、結果テーブル、およびグラフのワークフローの簡単なキャプチャです。
境界線
これが置き換えられないもの
- 有効なクエリでも、間違った分母、結合、時間境界、またはビジネス定義をエンコードする可能性があります。保存された分析を確認する必要があります。
- インタラクティブなクエリ API は分析用に設計されていますが、大規模な抽出には非同期エクスポート パスを使用する必要があります。
- Telemetry は DataFusion SQL を公開するため、別のウェアハウスのエンジン固有の関数には同等の式が必要になる場合があります。
検査可能な証明パス
イベント契約から目に見える答えまで
この例では、宣言されたスキーマ、読み取り専用の SQL、および決定論的な合成結果を使用します。顧客のベンチマークとしてサンプル データを提示せずにワークフローを示します。
2. 読み取り専用 SQL
テール レイテンシが最も悪いエンドポイントはどれですか?
SELECT
route_template,
COUNT(*) AS requests,
approx_percentile_cont(latency_ms, 0.50) AS p50_ms,
approx_percentile_cont(latency_ms, 0.95) AS p95_ms,
approx_percentile_cont(latency_ms, 0.99) AS p99_ms
FROM api_requests
WHERE timestamp_utc >= now() - INTERVAL '24 hours'
AND status_code < 500
GROUP BY route_template
HAVING COUNT(*) >= 50
ORDER BY p95_ms DESC
LIMIT 10;3. 合成結果
エクスポート リクエストのテールは最も遅く、通常のパフォーマンスと最悪の場合のパフォーマンスの差が最も大きくなります。
| route_template | requests | p50_ms |
|---|---|---|
| /api/reports/export | 50 | 800 |
| /api/projects/:id/sync | 50 | 320 |
| /api/search | 50 | 120 |
能力
含まれるもの
対話型分析のための同期 JSON クエリ
より大きな結果セットの非同期 JSON および Parquet エクスポート
バッファーに保存された最新のイベントと永続的な履歴を組み合わせたリアルタイム クエリ
保存されたダッシュボードの読み取り専用クエリ検証 SQL
クエリ結果のグラフ、テーブル、エクスポート、およびアラート
分析を見る
この機能を使用する SQL レシピ
顧客の証拠
チームがこのワークフローを使用する方法
関連する機能
イベントから意思決定までのワークフローを継続する
1 つの制作ワークフローから始める
対象範囲を拡大する前に、焦点を絞ったプロンプトを使用し、合成イベントを送信し、最初の有用なクエリを検証します。