モジュール XXII — health、SLA とアップタイム

モジュール XXII は、estate の AI コンポーネントについて 3 つの問いに答える — 何が healthy で、何が劣化またはダウンしているか、そして何が何に依存するか。それは エージェントと MCP サーバーの信頼性に限定されており、ホストやインフラ全般の health ではない。このページは、このモジュールが何を測定し、何を実体化し、その正直な 端がどこにあるかのリファレンスである。

概要

XXII はコアの消費者であり、プローバ(探査器)ではない。顧客のインフラへ ソケットを開くことはコネクタの関心事であり、封印された観測セットに health の種別は 存在しない。したがって health は、モジュールが証明できるシグナルから導出される:

• Liveness(受動)。 MCP サーバーに接触するセッションやエージェント — または 行動するエージェント — は、その対象が生きている証拠である。これは対象の last-seen マーカーを更新し、依存関係エッジを畳み込む。
• 能動プローブの結果。 外部のヘルスチェッカーまたはエージェント自身が、チェック ごとのレポートエンドポイントに結果を投稿する — 「ヘルスチェック / OTEL メトリクス」の 正直な取り込み経路。
• Staleness(陳腐化)。 既知の対象が、期待されるケイデンス内で見られなくなること 自体がシグナルである。バックグラウンドのスイープがそれを degraded に、次いで down に遷移させ、インシデントを開く。スイープは劣化させるかダウンとマークする だけである。回復はもっぱら実際の liveness から来るため、新規に作成された チェックが誤った回復を発することは決してない。

コントラクトとエンティティ

このモジュールは 4 つのエンティティを所有する。health check は、オペレータが 宣言した監視対象(エージェントまたは MCP サーバー)で、期待されるケイデンスと SLA ターゲットを持ち、対象の現在のスナップショット状態 — healthy、degraded、down、 unknown — を運ぶ。health event は、アップタイムと SLA が再構成される追記専用の 遷移台帳であり、実行中のカウンタとして保存されることは決してない。health incident は、劣化またはダウンした期間の open→resolved のライフサイクルで、対象ごとに 1 つの開いたインシデントが強制される。health dependency は自動発見される origin → target エッジ — 依存関係マップで、冪等に蓄積される。

health は宣言されたチェックに対してのみ実体化される。生きていると観測されたが 宣言されたチェックがない対象は、依存関係マップ上で正直に observed として提示される — 生きているのを見たが、health は測定していない — これは healthy(宣言された チェックがシグナルした)とも、unknown(名前はあるが liveness の証拠がない)とも異なる 状態である。本製品は、計算していない「測定済み healthy」状態を決して捏造しない。 XXII はまた、対象がコア id である場合に、対象の現在状態をコアの HealthStatus エンティティにミラーリングし、他のプレーンがエージェントや MCP の health を読めるように する。

消費するものと生成するもの

XXII は、受動 liveness と依存関係マップのためにバスから edge.observed を消費し、加えてその API に届く能動プローブのレポートを消費する。それは生成するが、 配信しない。down、degraded、recovered、SLA-breach のシグナルは、最小データの FindingReport として finding.reported チャネルに発行される — これは モジュール XV(通知) が Slack、PagerDuty、 SIEM へルーティングする製品全体のアラートストリームである。XXII は決して配信せず、 自身の検出結果を購読することも決してない。

正直な制約

• 宣言されたものしか測定しない。 health は宣言されたチェックに対してのみ実体化 される。生きているが宣言されていない対象は observed(生きているのを見たが測定 していない)と読まれ、決して healthy にはならない。信頼性はオペレータが宣言する チェックの分だけしか完全にならない。
• プローバではない。 XXII はあなたのインフラへソケットを決して開かない。 liveness、投稿されたプローブ結果、沈黙から信頼性を導出する — そのため、テレメトリを 発さず外部チェッカーも持たない対象については、シグナルの不在が(陳腐化として) シグナルとして扱われ、health の証明としては扱われない。
• アップタイムと SLA は追記専用の台帳から再構成される。ライブのメーターとして 保持されるのではない。数値は、要求されたウィンドウについて記録された遷移を反映する。
• アクチュエーションなし。 このモジュールは本質的に統治し観測する — アクチュ エーション表面を持たない(モジュール概要 を参照)。 検出して報告する。是正は人間または下流の関心事である。
• ワイヤー上は最小データ。 保存される状態はステータス、信頼性メトリクス、依存 関係である — ペイロード、プロンプト、シークレット、PII は決して保存されない。 プローブが運びうる唯一の機微な詳細(エラーメッセージ)は一方向ハッシュに縮約される。 表示されるのは短い非機微の要約のみである。

関連

• イベントバスリファレンス — edge.observed(liveness)と finding.reported(XXII が発するシグナル)。
• モジュール XV — 出力統合と通知 — XXII の health 検出結果を宛先へルーティングする。
• モジュール概要 — XXII の位置とアクチュエーションの区分。
• アーキテクチャ概要 — エンジン、バス、コア層。
• 正直さと制約 — 本製品が今日観測するものと、アクチュエートするもの。