> ## Documentation Index
> Fetch the complete documentation index at: https://docs.befailproof.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Health Monitoring

> Документация AgentEye Health Monitoring.

Узнайте, когда развертывание AgentEye **само по себе** неработоспособно или деградировано, а не только когда ваши агенты ведут себя неправильно. Обнаружение **нативно для Kubernetes** и, что самое важное, **независимо от AgentEye**: оно читает состояние подов из плоскости управления Kubernetes и проверяет жесткие зависимости AgentEye, поэтому срабатывает даже когда неработоспособен сервер, ClickHouse или Postgres.

Существует два слоя. Первый встроен; второй — опциональный.

## 1. Осведомленная о зависимостях готовность (встроено)

Сервер предоставляет два конечных точки проверки с намеренно разными функциями:

| Конечная точка | Проверка  | Что проверяется                                                  | Аутентификация |
| -------------- | --------- | ---------------------------------------------------------------- | -------------- |
| `GET /health`  | liveness  | процесс запущен (всегда `{"status":"ok"}`)                       | нет            |
| `GET /ready`   | readiness | может фактически обслуживать: **Postgres + ClickHouse** доступны | нет            |

`/ready` возвращает `200` с `"status":"ready"` и всеми проверками `"ok"` когда обе жесткие зависимости доступны, и `503` с `"status":"not_ready"` когда хотя бы одна недоступна. Оба ответа содержат небольшое тело:

```json theme={null}
{ "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](https://github.com/robusta-dev/robusta) — монитор, нативный для Kubernetes, который отслеживает сервер API и отправляет сообщения об отказах подов (`CrashLoopBackOff`, `OOMKilled`, `ImagePullBackOff`, `Pending`/`NotReady`, `Failed`, вытеснения) в Slack. Поскольку он наблюдает за плоскостью управления, а не запрашивает AgentEye, он генерирует оповещения даже когда AgentEye вообще не может обслуживать.

Robusta поставляется как опциональный компонент в комплект выпуска. Включите его с помощью стандартного Helm-чарта Robusta и небольшого файла значений, показанного ниже:

1. Добавьте репозиторий чарта и получите **токен бота** Slack (`xoxb-…`) для канала:

   ```bash theme={null}
   helm repo add robusta https://robusta-charts.storage.googleapis.com
   helm repo update
   ```

   Поскольку конфигурация ниже держит все внутри кластера (`disableCloudRouting: true`), токен поступает от самохостируемого приложения Slack: создайте приложение на `https://api.slack.com/apps`, добавьте область бота `chat:write`, установите его в свой workspace, скопируйте **Bot User OAuth Token** (`xoxb-…`) и пригласите бота на канал (`/invite @your-app`).

2. Создайте `values.yaml` с меткой для каждого развертывания (`clusterName`) и вашим каналом Slack, ограниченным пространством имен `agenteye`:

   ```yaml theme={null}
   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; удалите для расширения
   ```

3. Установите, закрепив `--version` на известную хорошую версию Robusta-чарта ([releases](https://github.com/robusta-dev/robusta/releases)) так, чтобы вы никогда не устанавливали непроверенный чарт:

   ```bash theme={null}
   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 и никакие данные клиентов** никогда не покидают кластер.
* Комплектные значения ограничивают оповещения **пространством имен `agenteye`**, поэтому несвязанные рабочие нагрузки в том же кластере не отчитываются.

### Одно место для каждого развертывания

Направьте Robusta каждого развертывания на **один общий канал Slack**, каждый с собственным `clusterName`. Каждое оповещение помечено этой меткой, поэтому один канал показывает здоровье вашего целого флота, и вы можете определить, какое развертывание затронуто с первого взгляда.

### Полные сбои кластера

Чисто внутренний наблюдатель кластера не может отчитаться о **сбое всего кластера или сети** (он выходит из строя вместе с кластером). Если вам это нужно, включите опциональный **Robusta UI sink**: установите `disableCloudRouting: false` и добавьте `robusta_sink` (с токеном из `robusta gen-config`) в `sinksConfig`. Это добавляет агрегированную многокластерную панель управления и отмечает любой кластер, который перестал проверяться.

## Устранение неполадок

Смотрите раздел **Health Monitoring** в [enterprise-docs/troubleshooting.md](/ru/agenteye/troubleshooting) для «оповещения не поступают» и «сервер продолжает переключаться `NotReady`».