Zabbix 7.4 en municipios: proxies, cortes y mapas
Un caso municipal muestra cómo Zabbix 7.4 ordena cortes, proxies, mapas y alertas sin depender de mensajes sueltos de guardia.
Antes, una delegación llamaba cuando el enlace ya estaba caído; después, Zabbix 7.4 mostró el corte, el proxy y el mapa en la misma guardia. En un municipio pequeño del Gran Mendoza, sistemas necesitaba separar fallas de energía, radio y servidor sin caminar cada edificio. Esta nota explica cómo se arma una operación mínima con proxy, triggers, mapas, permisos y restauración.
Dónde aparece el corte que llega tarde
El problema operativo era el WhatsApp de guardia. Un mensaje decía “no anda Rentas”, otro decía “se cayó Internet” y un tercero mandaba una foto borrosa de un rack de pared con la patchera marcada a birome. Cada aviso tenía un pedazo del problema y nadie podía firmar el horario exacto del corte. Stack Overflow 2025 registró que el 35,4% de quienes respondieron usa entre 6 y 10 aplicaciones o plataformas de trabajo. Ese dato ayuda a mirar el caso local: cuando la guardia usa chat, planilla, consola del proveedor y acceso remoto, el corte aparece varias veces y con horarios distintos. Zabbix 7.4 suma una ventaja concreta para esa escena: proxy, triggers, mapas y discovery pueden ordenar edificios, enlaces y servidores en una sola consola. Cada alerta gana origen, hora, estado y responsable. Un corte sin hora deja soporte a ciegas.
Cómo funciona por dentro
El flujo tiene siete pasos. Primero, cada router, radio, switch o servidor expone una métrica por agente, SNMP, ping o chequeo HTTP. Segundo, un proxy Zabbix en la delegación recibe esos datos y los retiene si el enlace hacia el servidor central se corta. Tercero, cuando vuelve la conectividad, el proxy envía cola pendiente y evita huecos en la historia. Cuarto, el servidor Zabbix guarda hosts, ítems, eventos y usuarios en su base. Puede usar PostgreSQL para conservar datos estructurados: equipos, estados, disparos de alerta y permisos. Quinto, los triggers comparan valores contra umbrales y generan un evento con severidad. Sexto, los mapas muestran relaciones entre sede, enlace, equipo y servicio. Séptimo, las notificaciones envían el aviso al grupo correcto y dejan registro de acuse. Los permisos se separan por rol. La guardia lee eventos y reconoce problemas; infraestructura edita hosts y triggers; gerencia mira reportes. El backup copia base, configuración y archivos de Zabbix. La restauración se prueba levantando un servidor temporal y comprobando que tres hosts históricos, un mapa y un trigger vuelven con sus datos. Network discovery aporta otro control. Recibe rangos IP y reglas de búsqueda, detecta equipos que responden y entrega candidatos para alta o revisión. En una red municipal ayuda a descubrir radios cambiados, switches sin nombre y servicios que quedaron vivos después de una obra. El alta automática se limita a plantillas conocidas; los demás equipos pasan por aprobación de infraestructura.
Qué se instala o configura primero
La primera pila puede ser Zabbix server 7.4, PostgreSQL, frontend web, un proxy por zona complicada y plantillas para routers, Linux y servicios HTTP. El primer entregable verificable es un mapa con tres sedes, cinco equipos, un trigger de caída de enlace y una alerta enviada a la guardia. Con dólar oficial vendedor a $1535, una VM de 4 vCPU y 8 GB para el servidor puede costar entre USD 25 y USD 40 mensuales, unos $38.000 a $61.000 antes de impuestos. Cada proxy puede correr en una mini PC existente o una VM chica; el costo real aparece en relevamiento, nombres de sedes, permisos y pruebas. UMSA puede acompañar este orden desde infraestructura y operación diaria: inventario inicial, plantilla por tipo de equipo, tablero para guardia y ensayo de restauración. En un municipio, el aprendizaje útil es nombrar cada sede igual en red, soporte y reportes. Si cada área usa un nombre distinto, la alerta vuelve a perder tiempo.
Dónde se rompe y cómo probarlo
El primer riesgo es medir solo ping. La señal aparece cuando el enlace responde, pero el sistema de turnos no abre. La prueba agrega un chequeo HTTP y compara ping contra servicio real durante una caída simulada. El segundo riesgo es dejar proxies sin cola suficiente. La señal aparece cuando faltan datos después de un corte largo. La prueba desconecta el proxy durante veinte minutos, genera eventos y revisa que el servidor central reciba la cola al reconectar. El tercer riesgo es llenar la guardia de alertas repetidas. La señal aparece cuando un mismo corte dispara veinte mensajes. La prueba apaga un switch de laboratorio y verifica que la dependencia reduzca eventos secundarios. El cuarto riesgo es perder mapas y plantillas en una reinstalación. La prueba restaura backup en una VM limpia y valida tres objetos: mapa, trigger y usuario de guardia. El quinto riesgo es aceptar nombres distintos para una misma sede. La señal aparece cuando un enlace figura con dos rótulos. La prueba cruza inventario, mapa y proveedor antes de cerrar el mes. Una guardia madura no promete que el enlace nunca cae; promete decir qué cayó, cuándo empezó y quién tomó el caso.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.