1. Preparación con conciencia de dependencias (integrada)
El servidor expone dos endpoints de sonda con funciones deliberadamente distintas:| Endpoint | Sonda | Verifica | Autenticación |
|---|---|---|---|
GET /health | liveness | el proceso está vivo (siempre {"status":"ok"}) | ninguna |
GET /ready | readiness | puede servir realmente: Postgres + ClickHouse accesibles | ninguna |
/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:
"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:
-
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 enhttps://api.slack.com/apps, agrega el alcance de botchat:write, instálala en tu espacio de trabajo, copia el Bot User OAuth Token (xoxb-…) e invita al bot al canal (/invite @your-app). -
Crea un
values.yamlcon una etiqueta por despliegue (clusterName) y tu canal de Slack, limitado al namespaceagenteye: -
Instala fijando
--versiona 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 propioclusterName. 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: establecedisableCloudRouting: 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 entreNotReady”.
