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. /readyz/tenant/:id está registrado en ambos servicios; fuera del modo multi-tenant devuelve HTTP 400 e indica que el modo multi-tenant está deshabilitado.

​
/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. La comprobación global tenant_manager solo confirma que el cliente está configurado. Durante la validación del tenant, un breaker abierto de Tenant Manager devuelve 503. Después de validar, una comprobación de MongoDB o RabbitMQ con alcance de tenant puede reportar down, circuit breaker open y breaker_state: open. Eso distingue un breaker disparado de un fallo de conexión común.

​
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. Configura los atributos de recurso de OTEL para tu despliegue: OTEL_RESOURCE_SERVICE_NAME, OTEL_RESOURCE_SERVICE_VERSION, OTEL_RESOURCE_DEPLOYMENT_ENVIRONMENT y OTEL_LIBRARY_NAME. Los ejemplos distribuidos usan fetcher para el Manager y fetcher-worker para el Worker; esos valores son configurables, no valores predeterminados de ejecución. 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. Una comprobación por tenant con breaker_state: open. Un breaker abierto de Tenant Manager también puede aparecer como 503 durante la validación; la comprobación global tenant_manager informa la configuración del cliente, no el estado del breaker.

​
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.