1. イベント契約
1行 service_heartbeats、クエリで使用される型が明示的に示されています。
- timestamp_utc
- Timestamp
- service_name
- Utf8
- environment
- Utf8
- status
- Utf8
仕組み
シグナルから意思決定までのレビュー可能なワークフロー
1
オーナーと一緒に信号を選択してください
閾値は、誰かがその意味を理解し、行動できる場合にのみ役に立ちます。ユーザー、収益、または信頼性の結果から始めます。
2
音量と時間の保護策を設定する
小さな分母での比率を避け、通常のスケジュールのジッターを考慮し、必要に応じて不完全なタイム バケットを無視します。
3
応答パスをテストする
合成データを使用して条件をトリガーし、配信を確認し、受信者が適切なクエリまたはダッシュボードを開くのに十分なコンテキストを含めます。
Explore 結果からアラートを作成する
レビューされた結果をダッシュボードまたはしきい値アラートにプロモートする実際の Explore アクション。
境界線
これが置き換えられないもの
- しきい値アラートは異常検出ではないため、レビュー済みのベースライン、十分な量、完全な時間バケットを使用する必要があります。
- 電子メール配信は、完全なインシデント管理およびエスカレーション プロセスに代わるものではありません。
- Telemetry は、シグナルがアクション可能かどうかを推論できません。すべてのアラートには依然として所有者と文書化された対応が必要です。
検査可能な証明パス
イベント契約から目に見える答えまで
この例では、宣言されたスキーマ、読み取り専用の SQL、および決定論的な合成結果を使用します。顧客のベンチマークとしてサンプル データを提示せずにワークフローを示します。
2. 読み取り専用 SQL
ハートビートの送信を停止したと予想されるテレメトリ ソースはどれですか?
SELECT
service_name,
environment,
MAX(timestamp_utc) AS last_seen_at,
COUNT(*) AS heartbeats_in_window
FROM service_heartbeats
WHERE timestamp_utc >= now() - INTERVAL '24 hours'
AND environment = 'production'
GROUP BY service_name, environment
HAVING MAX(timestamp_utc) < now() - INTERVAL '10 minutes'
ORDER BY last_seen_at ASC;3. 合成結果
最も古い last_seen_at 値を最初に調査する必要があります。
| service_name | environment | last_seen_at |
|---|---|---|
| billing_sync | production | 2026-07-27 15:04:00Z |
| email_worker | production | 2026-07-27 15:11:00Z |
能力
含まれるもの
カウント、合計、平均、最小、最大、パーセンタイル条件
大なりと小なりの比較
構成可能な評価間隔と最近のポイントウィンドウ
最新の不完全なバケットのオプションの除外
複数の電子メール受信者とアラート履歴
分析を見る
この機能を使用する SQL レシピ
顧客の証拠
チームがこのワークフローを使用する方法
関連する機能
イベントから意思決定までのワークフローを継続する
1 つの制作ワークフローから始める
対象範囲を拡大する前に、焦点を絞ったプロンプトを使用し、合成イベントを送信し、最初の有用なクエリを検証します。