ダッシュボードではなくエビデンスについて

sigiro がグラフではなく、ランク付けされたリストと各行に実行可能なクエリを添えて回答する理由。ベースラインとは何か、そしてこの設計が意図的に行わないこととは何か。

sigiro になぜサービスの状態が悪いのかを尋ねると、構造化されたエビデンスが 1 つのブロックとして返されます。ブロックの冒頭には、注目に値するもののランク付けされたリストがあります。各項目には数値を含む 1 行の要約と、その主張を検証するために実行できる SQL クエリが付いています。

グラフは返しませんし、今後も返すことはありません。このページではその選択について説明します。sigiro がどのように異常を判定するのか、見つけたものをどのようにランク付けするのか、なぜクエリが回答と一緒に届くのか、そしてこの設計が意図的に行わないことは何かについてです。

読み手には見えない

グラフは人にとって良い回答です。人は形を見て取り、14:10 の段差に気づき、次に進みます。オブザーバビリティツールは何十年もその瞬間を中心に構築されてきましたし、それらはよくできています。

しかし今や本番環境を修復するのはエージェントであり、エージェントはグラフを見ることができません。読めるのはテキストだけです。そのためループは修正の手前で断ち切られます。エージェントはパッチを書けますが、何が壊れたのかを突き止めることはできず、自分のパッチが機能したかどうかも判断できません。

sigiro はそのギャップを埋める部分です。ダッシュボードの下にあるレイヤーであり、ダッシュボードを置き換えるものではありません。パネルが欲しければ、お手持ちのものを同じテーブルに向けてください。

しきい値ではなく、ベースライン

設定すべきしきい値がないため、設定するものは何もありません。

各系列は、それ自身の直近の履歴と比較されます。sigiro は 7 日間のウィンドウにわたってすべてのシグナルを 5 分間のバケットに集約し、バケット化された系列に対してベイズオンライン変化点検出を実行します。変化点とは、系列の統計的なレジームが変化する点のことです。この検出器全体における唯一の構造的な選択は方向です。sigiro は、変化点以降の平均が変化点以前の平均より悪い場合にシフトを採用します。エラーが増えた、遅くなった、ノイズが増えた、コストが増えた。これは誰かが選んだ数値ではなく、比較です。

検出されるシグナルは 5 つです。

ここから 2 つの帰結が導かれますが、どちらも意外に思われます。

常に遅いサービスは異常ではありません。p95 が 1 週間ずっと 2 秒だったのであれば、そのサービスにとって 2 秒は正常であり、sigiro は何も言いません。これは正しい動作であると同時に、実際の制約でもあります。sigiro が伝えるのは 変化した ものであり、慢性的な障害は変化しないからです。慢性的な障害にはクエリを使ってください。

立ち上げたばかりのサーバーでは何も見つかりません。検出器は、系列が移行元となるレジームを持つまでに複数のバケットを必要とします。一定の系列も非常に短い系列も、構造上、変化点を生成しません。これが最小データ点数のオプションも存在しない理由です。

5 分間のバケットもまた、意図的な鈍さです。これにより検出器は持続的なシフトを検出し、1 分間の瞬間的な変動を無視します。1 分間の障害はこの検出器には見えず、それにはページング（呼び出し）システムが適したツールです。

シフトからインシデントへ、そしてランク付けされたリストへ

実際の障害は複数のシグナルを同時に動かします。エラーが増え、レイテンシが上がり、ログ量が増える。そしてこの 3 つは 3 つの事象ではなく 1 つの事象です。

そのため、シフトはランク付けの前に相関付けされます。同じ 5 分間の検出バケット内、または隣接するバケット内にある 2 つのシフトは、1 つの インシデント 項目に統合され、その構成シフトと、デプロイが時間的に近い場合はその疑わしいデプロイを保持します。相手のいないシフトは単一シグナルの項目のままです。

次にリストが並べ替えられます。第 1 のソートキーは深刻度です。その中で、異常項目は相関シグナルの数、次にシフトの大きさ、次に生の差分の順にランク付けされ、各キーは大きいものから小さいものへとソートされます。したがって 3 シグナルのインシデントは単独のレイテンシシフトより上位になります。これは、1 つの疑問と限られた注意力を持つ読み手にとって正しい順序です。

大きさの項目については 1 文を費やす価値があります。素朴な方法では誤ってしまうからです。sigiro は生の差分ではなく、対称相対変化 (after − before) / (after + before) を使用します。生の差分では、マイクロ秒で測定されたレイテンシのシフトと、パーセントで測定されたエラー率のシフトを比較できません。意味がどうであれ、マイクロ秒が毎回勝ってしまいます。相対形式は単位を持たないため、異なるシグナルのシフトどうしを公正に並べ替えられます。

異常ではない項目は最後に来ます。ログのないエラーのような不整合、対処可能なカバレッジの欠落、そして重複スパンや孤立スパンのようなテレメトリパイプライン自体の障害です。この最後のグループは、読み手が何よりも先に問うべき質問に答えます。そもそもこのデータは信頼できるのか、という質問です。

クエリは回答と一緒に届く

主張を行うすべての行には drill_down_sql が付いています。その主張を生み出したクエリであり、/v1/query にそのままポストできます。

これは私たちが最も強く擁護する設計上の要素であり、その理由は利便性ではありません。検証できる主張は、種類の異なる主張だからです。あなたも、あなたのエージェントも、自動診断を信じる必要はありません。クエリを実行してください。ウィンドウを広げてください。フィルタを変えて、その主張が生き残るかどうかを確かめてください。

これは、代替手段では修正できない失敗も修正します。検証できない要約は、信じるか捨てるかしかありません。そして検証不可能な要約を与えられたエージェントは、それを信じてしまいます。クエリは反証可能です。sigiro が間違っているとき — そして時には間違います — クエリは低コストでそれを見つける手段です。

もう 1 つ、より静かな利点があります。クエリは、あなたの次の質問が始まる場所でもあります。コピーして述語を 1 つ変えれば、sigiro が思いもよらなかったことを問いかけたことになります。ドリルクエリが保存済みビューへのリンクではなく、実テーブルに対する生の SQL である理由はここにあります。

なぜ 5 回ではなく 1 回の呼び出しなのか

従来の調査の形は 5 往復です。メトリクスストアにクエリを投げ、推論し、トレースストアにクエリを投げ、推論し、ログストアにクエリを投げ、推論し、イベントストアにクエリを投げ、推論する。各往復は安価ですが、各モデル呼び出しはそうではありません。そのためモデルが実時間を支配し、合計で数十秒に達します。またエージェントは、ウィンドウが断片で埋まるにつれて以前のコンテキストを失っていきます。

/v1/diagnose は sigiro の内部でクエリを並列に実行し、相関付けされた 1 つのブロックを返します。ランク付けされたリストは、同じクエリがすでに返したデータから Rust で組み立てられるため、追加のクエリも追加のメモリもかかりません。1 往復、1 回のモデル呼び出し、1 つの首尾一貫した全体像です。完全なブロックは、生のスパンダンプではなく数十キロバイトの構造化されたエビデンスであり、これは現代のコンテキストウィンドウのごく一部です。

この設計は、レスポンスが大きくなり単一の呼び出しが遅くなるという代償を払っています。読み手が呼び出しの合間に数秒間推論する場合には正しいトレードオフであり、10 秒ごとに 50 個のパネルを更新するダッシュボードにとっては誤ったトレードオフです。sigiro は前者の読み手のために作られています。

この設計が意図的に行わないこと

正直なリストです。どれも望むのが妥当なことだからです。

アラートは通知しません。 通知経路も、人へのエスカレーションもありません。GET /v1/anomalies はポーリングするテーブルです。スケジュールされたエージェントや cron ジョブが想定される呼び出し元です。

ビジネスインパクトによるランク付けはしません。 ランク順は統計的なものです。sigiro はあなたのどのサービスが決済を扱っているかを知らないため、バックグラウンドワーカーの大きなシフトが、チェックアウトの小さなシフトより上位になることがあります。どのサービスが重要かはあなたが知っており、sigiro はどの系列が動いたかを知っています。

原因の説明はしません。 ランク付けされたリストが示すのは、何が変化したか、どれだけ変化したか、どのシグナルが一緒に動いたかであり、時間的に近いデプロイがあればそれを疑わしいデプロイとして挙げます。時間的な相関は原因ではありません。エビデンスとドリルクエリは、あなた自身、またはあなたのエージェントの判断のためのものであり、診断はそれを生み出したクエリを伴う仮説です。

何も描画しません。 構築すべきパネルもなく、腐っていくパネルもありません。それこそが要点であり、同時に一部の読み手が最も恋しく思うものでもあります。

次に読む

• テーブルについて、そしてそれらがどの機械を記述しているか
• デプロイ検出について、そしてスパンが保持すべきもの — 疑わしいデプロイがどこから来るのか
• API リファレンス — Finding と DiagnosisBlock のフィールドの完全な一覧