Saltar al contenido principal
Detecta cuándo un despliegue de AgentEye está caído o degradado, no solo cuando tus agentes se comportan de forma incorrecta. La detección es nativa de Kubernetes y, de manera crucial, independiente de AgentEye: lee el estado de los pods desde el plano de control de Kubernetes y verifica las dependencias esenciales de AgentEye, por lo que sigue funcionando cuando el servidor, ClickHouse o Postgres es lo que está caído. Hay dos capas. La primera está integrada; la segunda es opcional.

1. Preparación con conciencia de dependencias (integrada)

El servidor expone dos endpoints de sonda con funciones deliberadamente distintas:
EndpointSondaVerificaAutenticación
GET /healthlivenessel proceso está vivo (siempre {"status":"ok"})ninguna
GET /readyreadinesspuede servir realmente: Postgres + ClickHouse accesiblesninguna
/ready devuelve 200 con "status":"ready" y cada verificación en "ok" cuando ambas dependencias esenciales son accesibles, y 503 con "status":"not_ready" cuando alguna no lo es. Ambas respuestas incluyen un pequeño cuerpo:
Redis es una caché opcional que el servidor puede omitir sin problemas, por lo que se reporta a modo informativo pero nunca hace fallar el readiness. Muestra "ok" cuando hay una caché configurada y "not_configured" en caso contrario; nunca aparece como "down". En los manifiestos de Kubernetes incluidos, la sonda de readiness apunta a /ready y la de liveness permanece en /health. El efecto: un servidor que está en ejecución pero no puede alcanzar su base de datos se retira del Service y aparece como NotReady, un estado sobre el que el monitoreo de tu clúster (descrito más adelante) puede generar alertas, mientras que el liveness se mantiene liviano para que un breve problema de dependencia nunca provoque el reinicio de un pod. La sonda usa un umbral de fallo generoso para que un problema momentáneo no cause que las réplicas entren y salgan de rotación.

2. Alertas de fallos de pods con Robusta (opcional)

Robusta es un monitor nativo de Kubernetes que observa el servidor de API y envía fallos de pods (CrashLoopBackOff, OOMKilled, ImagePullBackOff, Pending/NotReady, Failed, desalojos) a Slack. Como observa el plano de control en lugar de consultar a AgentEye, genera alertas incluso cuando AgentEye no puede responder en absoluto. Robusta se incluye como complemento opcional en el paquete de lanzamiento. Actívalo con el chart Helm estándar de Robusta y el pequeño archivo de valores que se muestra a continuación:
  1. Agrega el repositorio del chart y obtén un bot token de Slack (xoxb-…) para el canal:
    Dado que la configuración siguiente mantiene todo dentro del clúster (disableCloudRouting: true), el token proviene de una aplicación de Slack autoalojada: crea una aplicación en https://api.slack.com/apps, agrega el alcance de bot chat:write, instálala en tu espacio de trabajo, copia el Bot User OAuth Token (xoxb-…) e invita al bot al canal (/invite @your-app).
  2. Crea un values.yaml con una etiqueta por despliegue (clusterName) y tu canal de Slack, limitado al namespace agenteye:
  3. Instala fijando --version a una versión conocida y estable del chart de Robusta (versiones) para nunca instalar un chart sin probar:

Qué reporta

  • El estado de los pods de Kubernetes (qué pod de AgentEye está fallando y por qué) y el tag de imagen de cada pod, es decir, la versión del componente en ejecución.
  • Ningún dato de eventos de AgentEye ni dato de clientes sale jamás del clúster.
  • Los valores incluidos restringen las alertas al namespace agenteye, por lo que las cargas de trabajo no relacionadas en el mismo clúster no se reportan.

Un único lugar para cada despliegue

Apunta el Robusta de cada despliegue a un canal de Slack compartido, cada uno con su propio clusterName. Cada alerta se etiqueta con ese valor, de modo que un solo canal muestra el estado de toda tu flota y puedes identificar de un vistazo qué despliegue está afectado.

Interrupciones totales del clúster

Un observador puramente interno al clúster no puede reportar una interrupción total del clúster o de la red (cae junto con el clúster). Si necesitas eso, habilita el sink de la UI de Robusta opcional: establece disableCloudRouting: false y agrega un robusta_sink (con un token obtenido de robusta gen-config) a sinksConfig. Esto añade un panel de control agregado multiclúster y marca cualquier clúster que deje de registrarse.

Solución de problemas

Consulta la sección Health Monitoring de enterprise-docs/troubleshooting.md para los casos de “no llegan alertas” y “el servidor sigue alternando entre NotReady”.