コモンイベント契約書
これらのクエリを再利用可能に保つフィールド
- timestamp_utc、サービス、ホスト、リージョン、環境、およびリソース
- cpu_utilization_pct、memory_utilization_pct、disk_utilization_pct、および request_rate
- instance_type、replica_count、展開、および capacity_limit
SQL より前の定義
クエリでは決定できないこと
- 1単一のスパイクでアラートを発行するのではなく、複数の完全なバケットにわたる持続的な飽和を定義します。
- 2単位と使用率の分母をリソースの種類全体で一貫させます。
- 3より多くの容量を推奨する前に、リソースのプレッシャーをサービス需要に結び付けてください。
推奨される順序
最初にビルド検出、次に診断
分析パターン
結果で決定を説明する
需要と使用率を組み合わせる
インフラストラクチャの変更を通常のワークロードの増加から分離できるように、リソース使用量の横にリクエストまたはジョブの量をプロットします。
持続的なプレッシャーを見つける
完全なタイム バケットと連続したしきい値違反を使用して、容量リスクと短期間のバーストを区別します。
導入境界を比較する
飽和状態をサービス、リージョン、ホスト クラス、またはデプロイメントごとに分類して、不均一な負荷とロールアウトの回帰を特定します。
完全なレシピ
クエリをコピーし、仮定を検証します
初心者system_metrics
ホストとコンテナのリソースの飽和状態を確認する
サンプル量を維持しながら、持続的な CPU、メモリ、ディスク使用率によってインフラストラクチャ ソースをランク付けします。
どのインフラストラクチャ ソースが永続的にリソース制限を受けていますか?
SQL と結果を参照してください。中級者cache_request_events
キャッシュミスとスタンピードのリスクを見つける
ヒット率、バックエンド コスト、および同時ミスを、制限されたキャッシュ キー パターンごとに比較します。
どのキャッシュ キー パターンが低いヒット率とバックエンドの同時作業を組み合わせていますか?
SQL と結果を参照してください。上級者向けincident_lifecycle_events
インシデントの検出と復旧時間を計算する
構造化されたインシデント ライフサイクル イベントの検出にかかる時間と回復にかかる時間を計算します。
各サービスがインシデントを検出して回復するまでにどれくらいの時間がかかりますか?
SQL と結果を参照してください。初心者kubernetes_workload_events
ワークロードごとに Kubernetes 再起動を検索する
コンテナーの再起動イベント、準備エラー、および観測された累積再起動数によって、Kubernetes ワークロードをランク付けします。
どの Kubernetes ワークロードが再起動され、準備チェックに失敗していますか?
SQL と結果を参照してください。しきい値の前にイベント コントラクトを適応させる
分析パターンを維持しますが、テーブル名、フィールド タイプ、ビジネス定義、時間枠、および最小ボリューム ルールを独自のイベントに対して検証します。パブリッシュされたすべてのクエリも計画され、ピン留めされたエンジンを使用して空の型付きテーブルに対して実行されます。