Zabbix: monitorizar un restaurante o un hotel, con los TPV, las impresoras de cocina e internet vigilados antes del servicioZabbix: monitoring a restaurant or hotel, with the POS, kitchen printers and internet watched before service

Qué vas a conseguir

Que el móvil de la guardia suene antes que el teléfono del encargado: Zabbix vigilando internet, el servidor del TPV y su base de datos, las impresoras de cocina, los terminales, la red y el SAI del local. Con avisos que llegan solo cuando importan, y silencio mientras el local está cerrado.

Antes de empezar

• La versión: Zabbix 7.0 LTS (junio de 2024, soporte completo hasta junio de 2027). La 8.0 LTS está en release candidate a finales de octubre de 2026: para producción, 7.0 hasta su primera versión de correcciones. La 6.0 LTS ya solo tiene soporte limitado: planifica la actualización.
• Dónde va cada pieza: un servidor central y un Zabbix proxy en cada local, en un equipo pequeño siempre encendido, que sigue recogiendo datos aunque se caiga internet. Con el servidor dentro del local, sus avisos dependen de la misma línea que vigila.
• El inventario del local con IP fijas o reservas de DHCP (guía de ICG y HIOPOS).
• SNMP de solo lectura, mejor SNMPv3; con v2c, nunca la comunidad public.
• Puertos: 10050/TCP del proxy al agente y 10051/TCP hacia el servidor. Con el proxy en modo activo, el local solo necesita salida.
• El horario de servicio (comidas, cenas, desayunos del hotel) y quién está de guardia cada día.

1. Servidor, proxy y agentes

El servidor central, en Ubuntu 24.04 con PostgreSQL y Nginx, desde el repositorio oficial:

›wget https://repo.zabbix.com/zabbix/7.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_latest_7.0+ubuntu24.04_all.deb›sudo dpkg -i zabbix-release_latest_7.0+ubuntu24.04_all.deb && sudo apt update›sudo apt install zabbix-server-pgsql zabbix-frontend-php php8.3-pgsql zabbix-nginx-conf zabbix-sql-scripts zabbix-agent2›sudo -u postgres createuser --pwprompt zabbix›sudo -u postgres createdb -O zabbix zabbix›zcat /usr/share/zabbix-sql-scripts/postgresql/server.sql.gz | sudo -u zabbix psql zabbix# DBPassword en /etc/zabbix/zabbix_server.conf; listen y server_name en /etc/nginx/conf.d/zabbix.conf›sudo systemctl restart zabbix-server zabbix-agent2 nginx php8.3-fpm›sudo systemctl enable zabbix-server zabbix-agent2 nginx php8.3-fpm

En el local, el paquete zabbix-proxy-sqlite3 y tres líneas que deciden casi todo en /etc/zabbix/zabbix_proxy.conf:

ProxyMode=0Server=zabbix.corp.exampleHostname=PRX-BRISADBName=/var/lib/zabbix/zabbix_proxy.dbProxyOfflineBuffer=24

• ProxyMode=0 es activo: el proxy llama al servidor, no al revés. El Hostname tiene que coincidir con el nombre dado en Administration › Proxies.
• ProxyOfflineBuffer son las horas que el proxy guarda datos sin conexión. Por defecto es 1: un corte de internet de una tarde se pierde. Con 24 horas cubres una noche entera.
• En el servidor del TPV (Windows), Zabbix Agent 2 con el MSI: Server y ServerActive apuntan al proxy, y el 10050 abierto solo desde él.

2. Plantillas: qué vigilar en cada equipo

• ICMP Ping necesita fping en el proxy. Da tres elementos (icmpping, icmppingloss, icmppingsec) y el trigger Unavailable by ICMP ping.
• Una impresora puede responder al ping con la tapa abierta o sin papel. El elemento que de verdad dice si acepta comandas es el puerto de impresión: comprobación simple net.tcp.service[tcp,,9100] cada minuto, no más a menudo.
• Los datáfonos van en su red de pagos. Solo se vigilan si la segmentación lo permite y está documentado en el alcance de PCI DSS; si no, se quedan fuera.
• Un grupo de hosts por local (Locales/Brisa) y etiquetas (servicio:tpv, servicio:sala).

3. Los triggers que importan antes del servicio

Cinco problemas paran un servicio. Cada uno con un trigger claro y la severidad que le corresponde:

• Internet se mide desde el local contra dos destinos a la vez: uno solo da falsas alarmas. El del proxy sin contacto salta en el servidor central cuando el local entero desaparece.
• Con 4G de respaldo, la caída de la fibra no corta el servicio, pero hay que saberlo: el trigger de enlace caído de la WAN en la plantilla del router, como Warning.
• service.info[...,state] devuelve 0 con el servicio en marcha (6 es detenido, 255 que no existe). El nombre, como MSSQL$TPV, sale de services.msc.

4. Avisos a la guardia: correo y Telegram

Primero los tipos de medio, en Alerts › Media types:

• Email: servidor SMTP, puerto 587 con STARTTLS y una cuenta propia para Zabbix.
• Telegram: el tipo de medio viene incluido. Crea un bot con @BotFather, pega el token en el parámetro api_token y prueba con Test. En cada usuario, en Users › Users › Media, el tipo Telegram con el chat ID en Send to.

En el medio de cada usuario, When active limita las horas (1-7,11:00-24:00) y las severidades que le llegan. Después la acción, en Alerts › Actions › Trigger actions:

• Reconocer (acknowledge) el problema corta el paso 2.
• El mensaje lleva {HOST.NAME}, {TRIGGER.NAME} y {EVENT.SEVERITY}: local y equipo sin abrir el portátil.

5. Mantenimientos: cierre, descanso semanal y cambios

Un local cerrado no es una incidencia. Los mantenimientos, en Data collection › Maintenance:

• With data collection sigue guardando datos: el martes ves qué pasó el lunes. Los problemas se marcan como suprimidos y, con Pause operations for suppressed problems, no avisan.

Un mantenimiento sin fecha de fin, o que abarca todo el local, esconde también la caída de verdad. Limítalo por etiquetas y ponle siempre final.

6. El ticket: "una tormenta de alertas a las 13:05"

Sábado, 13:05. A la guardia le llegan 47 mensajes de Telegram en dos minutos: todos los TPV, los comanderos, las impresoras y la pantalla de cocina de un mismo local, sin respuesta. La sala está llena.

1. El primero de la lista: en Monitoring › Problems, filtrado por el local y ordenado por hora, el primero es SW-BRISA-01: Unavailable by ICMP ping a las 13:04:40. Lo demás es consecuencia: un problema real y 46 copias.
2. Confirmar en el local: el switch está apagado; alguien ha desenchufado la regleta de la barra para una cafetera. A las 13:08 todo responde.
3. Reconocer el problema con lo ocurrido: se para la escalada.
4. Dependencias de triggers: cada trigger de TPV, impresora y pantalla del local depende del ping de SW-BRISA-01, y el switch depende de Proxy del local sin contacto. En los triggers que vienen de plantilla, la dependencia se añade en el host, en la pestaña Dependencies. Con eso, la próxima vez llega un único aviso: el del switch.
5. El ruido de los comanderos: se apagan al cargarse cada noche y algunos se duermen a media tarde. Severidad Warning, sin aviso, y un trigger con recuperación separada: problema con max(/CMD-01/icmpping,#5)=0 y recuperación con min(/CMD-01/icmpping,#3)=1, para que no abra y cierre cada minuto.
6. El cierre: causa (regleta compartida), acción (switch al SAI) y mejora (dependencias en los demás locales).

Siguientes pasos

• La guía de ICG y HIOPOS tiene el inventario de terminales e impresoras que alimenta a Zabbix.
• La red que vigilas aquí, con sus VLAN y el 4G de respaldo, está en la guía de MikroTik y TP-Link: red y WiFi de un restaurante u hotel.
• La revisión de cada mañana antes del servicio (terminales, comanderos, impresoras de cocina y la línea de respaldo) es la idea del repositorio 34-venue-service-readiness de mi GitHub.

¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.