Reenvío de registros

Un reenvío de registros (log drain) envía los registros de ejecución de tus servicios a tus propias herramientas a medida que se escriben: Datadog, Grafana Loki (incluido Grafana Cloud) o cualquier endpoint HTTPS. Los reenvíos de registros se incluyen en el plan Pro y superiores.

Añadir un reenvío

Los propietarios y administradores del equipo abren Account settings → Log Drains (para el equipo seleccionado en la barra lateral) y hacen clic en Add log drain:

Destino	Qué necesitas
Datadog	Una clave de API (en Datadog: Organization Settings → API Keys) y el sitio de tu cuenta, como datadoghq.com o datadoghq.eu.
Loki	La URL de push, como https://logs-prod-012.grafana.net/loki/api/v1/push; a una URL sin ruta se le añade /loki/api/v1/push. Para Grafana Cloud, el usuario (el ID numérico del stack) y un token con logs:write. El inquilino de un Loki multiinquilino se envía como X-Scope-OrgID.
HTTP	Cualquier URL https://. Zenavo le envía JSON por POST, firmado (ver abajo).

Elige All projects, including new ones, o solo algunos proyectos. Test envía una línea en el momento y muestra si llegó. Hasta 5 reenvíos por equipo.

Las URL, las claves de API y las contraseñas son secretos: se guardan cifrados y la consola solo muestra el host y la ruta del destino. Zenavo solo envía a hosts cuyas direcciones son todas públicas, y no sigue redirecciones. Añadir, cambiar, probar y eliminar reenvíos queda en el registro de auditoría.

Qué se envía

Cada línea que imprime un servicio en ejecución, con los valores de las variables censurados ([REDACTED]) como en todas partes, etiquetada con el equipo, el proyecto y el servicio. Los registros de compilación no se reenvían.

Destino	Formato
Datadog	Se envía a https://http-intake.logs.<site>/api/v2/logs con ddsource: zenavo, service el nombre del servicio, hostname el nombre del proyecto y las etiquetas project, project_id, service_id y team_id.
Loki	Un stream por servicio, con las etiquetas source="zenavo", project, project_id, service, service_id y team_id.
HTTP	El JSON de abajo.

Las líneas salen en lotes de hasta 500 líneas, o cada 2 segundos. Un lote que falla se reintenta tras 1, 5 y 15 segundos; las peticiones que el destino rechaza (como una clave de API incorrecta: cualquier respuesta 4xx salvo 408 y 429) no se reintentan. Después, el lote se descarta. Cada reenvío almacena hasta 10.000 líneas; cuando no da abasto, se descartan las líneas más nuevas. La consola muestra la última entrega de cada reenvío o por qué falló, y cuántas líneas se descartaron. Los registros de la consola, en directo y guardados, nunca se ven afectados por un reenvío.

La entrega es al menos una vez: cuando el plano de control se reinicia, los últimos minutos pueden volver a enviarse.

Contenido HTTP

{
  "logs": [
    {
      "time": "2026-10-22T08:00:00.123456789Z",
      "message": "GET /cart 200 12ms",
      "team_id": "team_…",
      "project_id": "proj_…",
      "project": "shop",
      "service_id": "svc-…",
      "service": "web"
    }
  ]
}

Cualquier respuesta 2xx cuenta como entregada. Cada petición lleva X-Zenavo-Timestamp (segundos Unix) y X-Zenavo-Signature: v1=<hex>, el HMAC-SHA256 de <timestamp>.<cuerpo sin procesar> con el secreto de firma del reenvío, el mismo esquema que los webhooks de notificaciones. El secreto (whsec_…) se muestra una vez al añadir el reenvío; New secret lo sustituye y muestra el nuevo una vez.

Planes

Los reenvíos de registros necesitan el plan Pro, Team o Enterprise. Cuando un equipo pasa a un plan sin ellos, sus reenvíos dejan de enviar; se pueden seguir desactivando, editando o eliminando, y vuelven a funcionar tras mejorar el plan.