Graylog en bodegas: logs, roles y prueba de salida
Un caso anonimizado muestra cómo ordenar eventos de red, lectores y stock con Graylog, OpenSearch y permisos por rol sin perder restauración.
En esta nota
Un log de bodega pierde valor cuando llega sin turno, usuario o equipo. En una bodega exportadora de Luján de Cuyo, los cortes de red, lectores de QR y cambios de stock quedaban en chats dispersos. Graylog reúne entradas, reglas y alertas; PostgreSQL registra el inventario operativo que acompaña cada evento. Este caso muestra qué guardar, quién lo consulta y cómo probar salida y restauración.
Dónde se pierde un evento operativo
La documentación de Graylog separa entradas, procesamiento, búsqueda y alertas. Esa división le sirve a una bodega cuando un lector de etiquetas falla en una cámara de frío y nadie sabe si el corte vino del equipo, la red o la aplicación. El sistema heredado que guardaba logs por servidor dejaba respuestas parciales.
La cifra que corrige la costumbre viene de la encuesta Stack Overflow 2024: PostgreSQL aparece con 49% de uso entre desarrolladores. Ese dato global importa en Cuyo porque muchas organizaciones ya pueden guardar inventario, responsables y estados en una base conocida, mientras Graylog conserva eventos y OpenSearch permite buscarlos por tiempo.
El objeto de estatus era una planilla plastificada pegada junto al portón de expedición. Tenía horarios de camiones y teléfonos de soporte escritos con marcador negro. Cuando un escáner fallaba, la planilla decía a quién llamar; no decía qué evento había ocurrido.
Cómo funciona por dentro
El flujo empieza con routers, lectores, servidores y aplicaciones que envían mensajes a una entrada de Graylog. La entrada recibe syslog, HTTP o GELF y guarda hora, origen, tipo y contenido. Graylog procesa el mensaje, aplica reglas, normaliza campos y lo indexa en OpenSearch. PostgreSQL guarda inventario de equipos, turnos, responsables y ubicaciones para cruzar el evento con operación real.
Keycloak o el directorio interno entregan grupos de acceso. Operaciones ve alertas por línea y turno; IT lee detalle técnico; gerencia consulta tendencia y tiempos de corte. El backup copia configuración, base de inventario y snapshots de índices. La prueba restaura un día de eventos y confirma que cada alerta conserve equipo, usuario, ubicación y acción tomada.
La primera alerta útil no busca volumen; busca ausencia. Si un lector deja de enviar eventos durante diez minutos en horario de despacho, Graylog marca el corte y el tablero lo cruza con turno y responsable. La respuesta deja de depender del chat.
Los inputs de Graylog reciben mensajes desde varias fuentes; las reglas convierten texto en campos buscables. El modelo de índices documentado por Graylog ordena rotación, tamaño y búsqueda por tiempo. OpenSearch agrega snapshots para recuperar índices. PostgreSQL queda afuera del índice de logs: guarda inventario y responsables, que cambian menos y necesitan auditoría relacional.
Qué se instala o configura primero
La pila mínima usa Graylog, OpenSearch, MongoDB según requerimiento de Graylog, PostgreSQL para inventario operativo, proxy HTTPS, backup y monitoreo. Para una bodega con 30 a 80 dispositivos, un servidor dedicado y copia externa queda entre USD 140 y USD 300 mensuales. Con dólar vendedor de ARS 1.458, el rango va de ARS 204.120 a ARS 437.400 por mes.
La implementación inicial requiere 45 a 75 horas: inventario de fuentes, entradas, normalización, roles, tableros, alertas y restauración. El primer entregable verificable es una línea de despacho con cinco dispositivos, tres alertas, dos perfiles de consulta y una prueba de salida en CSV y snapshot.
UMSA puede tomar el caso como orden de evidencia operativa: qué fuente emite, dónde se guarda, quién lee, quién administra y cómo se recupera. La bodega conserva sus sistemas de stock; Graylog agrega lectura temporal y prueba de evento.
El caso piloto se arma sobre una línea concreta, no sobre toda la planta. Se eligen lectores de QR, switch, servidor de stock, cámara de frío y aplicación de despacho. Cada fuente recibe un nombre humano, una ubicación y un responsable. El tablero inicial muestra eventos por equipo y por turno, y la primera revisión semanal borra reglas que no ayudaron a decidir.
Dónde se rompe y cómo probarlo
El primer riesgo es el evento sin nombre de equipo. La señal aparece cuando el origen llega como IP y nadie sabe qué lector falló. La prueba cruza IP, inventario y ubicación; si falta relación, la alerta queda incompleta.
El segundo riesgo es el rol amplio. La señal aparece cuando operaciones puede leer datos técnicos sensibles o borrar búsquedas. La prueba crea perfiles de operaciones, IT y gerencia; cada uno intenta ver detalle, editar tablero y exportar.
El tercer riesgo es la retención mal medida. La señal aparece cuando los índices ocupan disco antes del cierre del mes o cuando desaparecen eventos necesarios para reclamos. La prueba fija retención de 90 días, llena un índice de prueba y revisa borrado, snapshot y búsqueda.
El cuarto riesgo es la salida incompleta. La señal aparece cuando el proveedor muestra la búsqueda, pero entrega archivos sin contexto. La prueba exporta eventos, inventario y reglas; después reconstruye una alerta en una carpeta nueva.
La prueba de restauración debe incluir un incidente escrito. Se toma un corte real o simulado, se exportan los eventos, se restaura el índice y se vuelve a armar la línea de tiempo. Si el equipo puede nombrar equipo, usuario, turno, acción y minuto de recuperación, el sistema dejó evidencia. Si sólo aparece una lista de mensajes, falta trabajo de campos.
El evento que no se puede reconstruir ya llegó tarde.
