ヘルスモニタリング

AgentEye のデプロイメント自体がダウンまたは劣化状態にあるときを、エージェントの誤動作とは独立して把握できます。検出は Kubernetes ネイティブであり、重要な点として AgentEye から独立しています。Kubernetes コントロールプレーンからポッドの状態を読み取り、AgentEye のハード依存関係を確認するため、サーバー、ClickHouse、または Postgres がダウンしている場合でも検知が機能します。 2 つのレイヤーがあります。1 つ目は組み込み済み、2 つ目はオプトイン式です。

1. 依存関係を考慮したレディネス（組み込み済み）

サーバーは意図的に異なる役割を持つ 2 つのプローブエンドポイントを公開しています：

エンドポイント	プローブ	確認内容	認証
`GET /health`	liveness	プロセスが生存している（常に `{"status":"ok"}` を返す）	なし
`GET /ready`	readiness	実際にリクエストを処理できるか：Postgres + ClickHouse に疎通できるか	なし

/ready は両方のハード依存関係に疎通できる場合、"status":"ready" と各チェック "ok" を含む 200 を返します。どちらかに疎通できない場合は "status":"not_ready" を含む 503 を返します。いずれのレスポンスにも小さなボディが含まれます：

{ "status": "not_ready",
  "checks": { "postgres": "ok", "clickhouse": "down", "redis": "not_configured" } }

Redis はサーバーが機能を低下させながらも動作し続けられるオプションのキャッシュであるため、情報として報告されますが、レディネス判定に影響しません。キャッシュが設定されている場合は "ok"、設定されていない場合は "not_configured" と表示され、"down" になることはありません。バンドルされた Kubernetes マニフェストでは、readiness プローブが /ready を指し、liveness は /health のままです。この構成により、実行中だがデータベースに接続できないサーバーは Service から切り離されて NotReady 状態として表示され（以下のクラスター監視でアラートを発火できます）、liveness は軽量なままに保たれるため、一時的な依存関係の瞬断でポッドが再起動されることはありません。プローブには十分な失敗閾値が設定されているため、一時的な瞬断でレプリカがローテーションから外れてフラッピングすることもありません。

2. Robusta によるポッド障害アラート（オプトイン）

Robusta は Kubernetes ネイティブのモニターで、API サーバーを監視し、ポッドの障害（CrashLoopBackOff、OOMKilled、ImagePullBackOff、Pending/NotReady、Failed、エビクション）を Slack に通知します。AgentEye に問い合わせるのではなくコントロールプレーンを監視するため、AgentEye が全くリクエストを処理できない状態でもアラートを発火します。 Robusta はリリースバンドルのオプトインアドオンとして提供されています。以下に示す標準の Robusta Helm チャートと小さな values ファイルを使用して有効化します：

チャートリポジトリを追加し、対象チャンネル用の Slack ボットトークン（xoxb-…）を取得します：
helm repo add robusta https://robusta-charts.storage.googleapis.com helm repo update
以下の設定ではすべてをクラスター内に閉じているため（disableCloudRouting: true）、トークンはセルフホスト型の Slack アプリから取得します。https://api.slack.com/apps でアプリを作成し、chat:write ボットスコープを追加してワークスペースにインストール後、Bot User OAuth Token（xoxb-…）をコピーし、ボットをチャンネルに招待してください（/invite @your-app）。

デプロイメントごとのラベル（clusterName）と Slack チャンネルを指定した values.yaml を作成します。スコープは agenteye 名前空間に限定します：

clusterName: "acme-prod"            # デプロイメントごとのラベル。すべてのアラートに付与される
enablePrometheusStack: false        # ポッドクラッシュアラートのみ。メトリクススタックは不要
disableCloudRouting: true           # クラスター内から直接 Slack に配信
sinksConfig:
  - slack_sink:
      name: vendor_slack
      slack_channel: "agenteye-fleet-health"
      api_key: "REPLACE_WITH_SLACK_BOT_TOKEN"   # xoxb-… (--set またはシークレットの使用を推奨)
      scope:
        include:
          - namespace: [agenteye]   # AgentEye 名前空間のアラートのみ。広げる場合は削除

--version を既知の安定した Robusta チャートリリースに固定してインストールします（リリース一覧）。未テストのチャートがインストールされることを防ぐためです：

helm install robusta robusta/robusta \
  --namespace robusta --create-namespace \
  --version <pin-a-known-good-version> \
  -f values.yaml \
  --set sinksConfig[0].slack_sink.api_key=$ROBUSTA_SLACK_TOKEN

報告される内容

Kubernetes のポッド状態（どの AgentEye ポッドがなぜ障害を起こしているか）と各ポッドのイメージタグ（実行中のコンポーネントのバージョン）。
AgentEye のイベントデータも顧客データもクラスター外に出ることはありません。
バンドルされた values は agenteye 名前空間にアラートを限定しているため、同じクラスター上の無関係なワークロードは報告されません。

すべてのデプロイメントを一箇所で管理

各デプロイメントの Robusta を一つの共有 Slack チャンネルに向け、それぞれに固有の clusterName を設定します。すべてのアラートにそのラベルが付与されるため、一つのチャンネルでフリート全体の健全性を確認でき、どのデプロイメントに問題があるかを一目で把握できます。

クラスター全体の障害

純粋にクラスター内で動作するウォッチャーは、クラスター全体またはネットワーク全体の障害を報告することができません（クラスターと一緒にダウンしてしまうため）。その場合はオプションの Robusta UI シンクを有効化してください。disableCloudRouting: false に設定し、sinksConfig に robusta_sink（robusta gen-config で取得したトークンを使用）を追加します。これにより、集約されたマルチクラスターダッシュボードが追加され、チェックインが停止したクラスターにフラグが立てられます。

トラブルシューティング

「アラートが届かない」および「サーバーが NotReady をフラッピングし続ける」については、enterprise-docs/troubleshooting.md の ヘルスモニタリング セクションを参照してください。

​1. 依存関係を考慮したレディネス（組み込み済み）

​2. Robusta によるポッド障害アラート（オプトイン）

​報告される内容

​すべてのデプロイメントを一箇所で管理

​クラスター全体の障害

​トラブルシューティング