| API / Servicio | Versión (salida) | Versión online | Estado | SSL | Último deploy |
|---|
| Fecha | Servidor / API | Versión | Jira | Inc. | Tipo | Notas |
|---|
| # | Check | Tipo | Frecuencia | Hora límite | Reglas | Estado |
|---|
| Fecha | Actor | Acción | Entidad | Detalle |
|---|
| Recibida | Agente | Fecha | Host | Versión | Checks | Resultado |
|---|
| Nombre | Iniciales | Rol | Activo |
|---|
X-API-Key para empujar salidas/rollbacks a POST /api/integrations/salidas.
Nunca se registran solas: quedan en la campanita 🔌 del topbar para que un admin las revise y confirme.
Cómo se usa
POST https://infra-diario.infosis.tech/api/integrations/salidas
Headers:
X-API-Key: <la key que te paso aparte>
Content-Type: application/json
Body:
{
"jira": "EZG-9526",
"type": "salida",
"notes": "Opcional — texto libre"
}
- jira (requerido): la clave del ticket de Jira de la salida/rollback (ej: EZG-9526).
De ese ticket ya sacamos la versión, el servidor/API afectado y la fecha — no
hace falta mandar nada de eso.
- type (opcional, default "salida"): "salida" o "rollback".
- notes (opcional): texto libre, se guarda como referencia junto al ticket.
Importante: esto NO registra la salida directo en el dashboard. Queda en una cola
de revisión — un admin la confirma con un clic (ya trae los datos autocompletados
desde Jira). Es una medida de seguridad: si el ticket no tiene toda la info clara,
preferimos que alguien lo revise antes de que quede en el historial oficial.
Ejemplo con curl:
curl -X POST https://infra-diario.infosis.tech/api/integrations/salidas \
-H "X-API-Key: LA_KEY" \
-H "Content-Type: application/json" \
-d '{
"jira": "EZG-9526",
"type": "salida",
"notes": "Prueba de integración"
}'
Respuestas:
202 → recibido y encolado. Devuelve { "ok": true, "id": "...", "queued": true }.
400 → falta jira, no es una clave de ticket válida (ej: EZG-1234), type no es
"salida"/"rollback", o notes no es un string.
401 → falta la key, está mal, o fue revocada de nuestro lado.
422 → el body no es JSON válido (casi siempre, saltos de línea sin escapar
dentro de un string — usá \n, nunca un salto real).
Todo lo que entra queda registrado con el nombre de la integración (le asignamos
un nombre a cada key), así que si algo no llega o llega mal se puede rastrear.
POST /api/verif/ingest, header
X-API-Key) tiene su propia clave. Se muestra una sola vez al crearla o rotarla y se guarda hasheada:
si se pierde, rótala. Revocar un agente hace que sus envíos se rechacen (y queden en la auditoría).
Vista general del estado de los servidores Zeus (ERP/POS) en producción: versión instalada, usuarios activos y si el servidor está online. También se ven España (FALL) y los servidores de Staging (que pueden estar apagados sin que sea un problema).
Catálogo de APIs y servicios (K8s, K8s Apps, LX01, LX02, BillApp, Otros) con su versión declarada en el log de salidas vs. la versión que realmente responde el servidor en vivo.
Historial completo de salidas y rollbacks registrados a mano. Es la fuente de verdad de "qué se subió y cuándo".
Se abre con el botón + Registrar salida (arriba a la derecha) o + Nueva entrada desde el Log.
EZG-9526) en Ticket Jira y tocá ⤓ Traer — autocompleta versión, cantidad de incidencias vinculadas, notas y detecta automáticamente los servidores/APIs mencionados en el ticket, y la fecha con la transición del ticket a Merge a Master.El autocompletado de Jira requiere que el proxy esté configurado (ver más abajo, "Proxy de Jira").
Vista anual de Salidas o Incidentes (chips arriba), un mes por bloque. Los días con actividad se colorean según la categoría (Zeus, API's, BillApp, Mixto, RollBack — o la prioridad si es un incidente).
Tres vistas de Salidas a Producción, armadas con una búsqueda JQL fija contra Jira (tickets con el campo "Salida a Producción" cargado, con fecha desde 2026-01-01, excluyendo los proyectos de Tabbi y Base de Datos):
12897): el valor real del campo "Tipo de Evolutivo" cuando está cargado (Evolutivo Modular, Evolutivo Funcional, Hallazgo, Zeus Evolution), o si no — Integraciones (proyecto Integraciones sin ese campo ni etiqueta PG), Migración Servicios de ARCA / ZE HUB (hijos de épicos puntuales), PG (etiqueta PG) y Otros como catch-all. Ambos son clickeables para ver el detalle de tickets, y comparten el botón ↻ Actualizar de la dona.Ajustá el tiempo de vida del caché (TTL) de las consultas de versión/sesión/estado online de servidores, APIs y swaggers. Por defecto son 30 minutos; podés bajarlo si necesitás datos más frescos, o subirlo para reducir la carga sobre los servidores. El cambio aplica al instante, sin recargar la página.
Cualquier cuenta @infosis.tech puede entrar, pero en modo solo lectura. Solo las cuentas que figuran en Configuración → Manejo de usuarios son admin: pueden registrar salidas/rollbacks, incidentes, editar el catálogo, exportar/importar datos y definir las incidencias objetivo del mes.
Un usuario de solo lectura no ve la sección Configuración (ni la importación masiva, que ahora vive ahí dentro), ni la campanita/popup de cambios de versión sin registrar — solo tiene sentido para quien puede registrar salidas.
Cualquier admin puede agregar o quitar otras cuentas del listado. Siempre tiene que quedar al menos una.
El dashboard corre detrás de un nginx que hace de proxy hacia Jira para poder autocompletar tickets sin bloqueo de CORS. Necesita las variables de entorno JIRA_HOST y JIRA_AUTH (usuario y token en Base64) configuradas del lado del servidor/contenedor.
Si ves el mensaje "El proxy de Jira no está disponible en este entorno", significa que esas variables no están configuradas donde corre la app (ej: un despliegue de prueba sin credenciales).
Export descarga un backup en JSON con el Log de salidas, la configuración y los incidentes. Import restaura ese backup — útil para migrar datos entre navegadores/equipos, ya que todo se guarda en el localStorage del navegador (no hay backend de datos).
Marcá qué servidores están corriendo una versión distinta al resto del clúster (rollout en curso). Se muestra la versión detectada en cada uno para referencia.