Skip to main content
Fetcher responde tres preguntas operativas por HTTP: si el proceso está vivo, si puede servir tráfico ahora mismo, y qué dependencia tiene la culpa. Esta página cubre cada superficie y lo que reporta.

​
Endpoints

El Manager sirve todos estos en SERVER_ADDRESS. El Worker no tiene servidor de API, así que corre un microservidor de salud en HEALTH_PORT, cuyo valor por defecto es 4007. Todos se montan antes de la autenticación. Las sondas de Kubernetes y del balanceador de carga no necesitan token.

​
/health y la autosonda de arranque

/health no es un 200 estático. Al arrancar, Fetcher corre una vez cada sonda de dependencia, en paralelo, y después fija una bandera de proceso con el resultado. Hasta que esa autosonda tiene éxito, /health devuelve 503.
El kubelet reinicia un pod cuyas dependencias fallaron al arrancar. No le envía tráfico. La bandera empieza en falso, así que un proceso que se cae a mitad de la sonda nunca reporta salud por accidente. Apunta tu sonda de liveness a /health.
Cada dependencia también emite el resultado de su autosonda como métrica. Por eso un fallo repetido de arranque aparece en un dashboard, y no solo en los logs.

​
/readyz y las sondas de dependencias

/readyz corre cada sonda registrada en cada petición, en paralelo, con una goroutine por dependencia. El handler no tiene caché ni estado de fondo. Una respuesta en caché abre una ventana en la que Kubernetes sigue enrutando hacia un pod degradado. Un agregado sano devuelve 200. Cualquier otra cosa devuelve 503. El cuerpo de la respuesta reporta cada dependencia por nombre, con su estado, su latencia y su postura de TLS.

​
Qué sondea cada servicio

En modo multi-tenant, las entradas de MongoDB y RabbitMQ compartidos reportan n/a con el motivo multi-tenant: see /readyz/tenant/:id, y las sondas por tenant pasan a ese endpoint.

​
Timeouts por dependencia

Cada sonda corre bajo un plazo fijo. Los valores no son configurables, así que todos los servicios Lerian tienen la misma envolvente de latencia de readiness y un solo umbral de dashboard sirve para toda la flota. Una sonda que ignora su plazo no bloquea la respuesta. El handler pone un resultado down en su lugar.

​
Estado del circuit breaker

La resolución de tenants corre detrás de un circuit breaker. La variable MULTI_TENANT_CIRCUIT_BREAKER_THRESHOLD define cuántos fallos consecutivos lo abren, con un valor por defecto de 5. La variable MULTI_TENANT_CIRCUIT_BREAKER_TIMEOUT_SEC define cuánto permanece abierto, con un valor por defecto de 30 segundos. Cuando el breaker está abierto, la sonda por tenant reporta la dependencia como down con el error circuit breaker open y un estado de breaker open. Eso distingue un breaker disparado de un fallo de conexión común, que es la diferencia entre esperar un reinicio y llamar al dueño de la base de datos.

​
Drenaje ante SIGTERM

Ante SIGTERM o SIGINT, los dos servicios entran en drenaje antes de cerrar conexiones.
  1. /readyz responde 503 de inmediato durante READYZ_DRAIN_DELAY_SEC segundos, con un valor por defecto de 12 y un mínimo de 1.
  2. Kubernetes saca el pod de los endpoints del Service mientras este todavía atiende el trabajo en vuelo.
  3. Solo entonces se cierran las conexiones.
El servicio omite las sondas reales durante el drenaje. La respuesta lleva una sola dependencia sintética llamada draining con estado down, y emite métricas igual que cualquier otra.
Las alertas siguen evaluando durante un despliegue progresivo. La dependencia sintética draining mantiene viva la serie de la métrica, así que un dashboard muestra un drenaje en lugar de un hueco. Define tu periodo de gracia de terminación por encima de la ventana de drenaje.

​
Métricas

/metrics sirve la exposición Prometheus, incluidos los colectores de runtime y de proceso de Go. Los buckets del histograma van de 1 ms a 5.000 ms. Los nombres de métricas, las etiquetas y los buckets son un contrato de plataforma, y los dashboards de toda la flota dependen de ellos. El histograma de duración registra el tiempo de reloj que la sonda aportó al handler, no la latencia que la sonda reportó de sí misma. Ese es el número que explica un /readyz lento.

​
Trazas

Define ENABLE_TELEMETRY=true y apunta OTEL_EXPORTER_OTLP_ENDPOINT a tu colector. Fetcher exporta entonces trazas y métricas de OpenTelemetry por OTLP. Cuatro atributos de recurso dan forma a lo que ves: OTEL_RESOURCE_SERVICE_NAME (fetcher en el Manager, fetcher-worker en el Worker), OTEL_RESOURCE_SERVICE_VERSION, OTEL_RESOURCE_DEPLOYMENT_ENVIRONMENT y OTEL_LIBRARY_NAME. El Engine emite sus propios spans a través de un puerto de un solo método. Un host que no provee ningún tracer recibe una implementación vacía, y el comportamiento no cambia.

​
Qué alertar

  1. /readyz en 503 fuera de una ventana de despliegue. Un nombre de dependencia en el cuerpo de la respuesta te dice cuál.
  2. Una cola de mensajes muertos que crece. Cada mensaje ahí es un job que el Worker no pudo procesar. Consulta Despliegue.
  3. selfprobe_result en 0 para cualquier dependencia. Un pod se reinició sobre una dependencia rota.
  4. Un estado de breaker open en tenant_manager. La resolución de tenants falla, y cada petición acotada por tenant depende de ella.

​
Próximos pasos

Despliegue

Dependencias, colas, escalado y verificaciones de arranque.

Configuración

Todas las variables de entorno, por componente.

Seguridad

Claves, firma, cifrado en reposo y validación de host.

Jobs de extracción

Ciclo de vida del job, estados terminales y eventos.