Zabbix Docker Lab (producción-ready)

Zabbix 7.0 LTS completo con Docker Compose, armado como se despliega en clientes reales — no como los compose de juguete que abundan en GitHub:

• PostgreSQL + TimescaleDB particionado (el default oficial para history/trends — sin esto, un Zabbix con 200+ hosts se arrastra en meses)
• Grafana integrado con el datasource de Zabbix preconfigurado
• Backups de la base incluidos con rotación (un Zabbix sin backup de su DB es una bomba de tiempo)
• Healthchecks y depends_on correctos — el stack levanta en orden y se recupera solo ante reinicios
• Todo parametrizado por .env

Arquitectura

┌─────────────────┐     ┌──────────────────────┐
│ zabbix-frontend │────▶│    zabbix-server     │───▶ polling agentes/SNMP
│   (nginx :8080) │     └──────────┬───────────┘
└─────────────────┘                │
┌─────────────────┐                ▼
│     Grafana     │────▶ ┌──────────────────┐
│     (:3000)     │      │ PostgreSQL 16 +  │
└─────────────────┘      │ TimescaleDB      │
                         └────────┬─────────┘
                                  ▼
                         ┌──────────────────┐
                         │ backup (cron     │──▶ dumps rotados
                         │  container)      │    7d/4sem/6m
                         └──────────────────┘

Quick start

cp .env.example .env   # completar passwords
docker compose up -d

# Frontend: http://localhost:8080  (Admin / zabbix — cambiarlo de inmediato)
# Grafana:  http://localhost:3000

Qué tiene de diferente a los compose típicos

Detalle	Por qué importa
TimescaleDB con timescaledb-tune	Las tablas history* y trends* crecen sin freno; el particionado nativo es la diferencia entre un Zabbix ágil y uno que muere al año
Housekeeping deshabilitado para history/trends	Con TimescaleDB el housekeeping lo hace el particionado — dejar ambos activos duplica trabajo y traba la DB
Backup container con pg_dump + rotación GFS	La config de Zabbix (templates, hosts, maps) vive en la DB; perderla = reconstruir todo a mano
Healthcheck real de la DB antes de levantar el server	Sin esto, el primer boot falla en carrera y deja el schema a medias
Grafana + plugin Zabbix provisionado	Los dashboards ejecutivos se hacen en Grafana; Zabbix sigue siendo el motor de alertas
SNMP traps habilitado	Routers, switches, UPS — el 50% del monitoreo de infra física

Despliegue en cliente (checklist)

1. Copiar .env.example a .env y generar passwords fuertes
2. docker compose up -d y verificar docker compose ps (todo healthy)
3. Cambiar password de Admin en el frontend
4. Configurar medios de alerta (email/Telegram) en Alerts → Media types
5. Crear host groups por sitio/área del cliente
6. Agregar hosts o configurar auto-registration (ver mi repo zabbix-rescue-toolkit para discovery)
7. Configurar el backup a destino externo (S3/NAS) — el dump local no alcanza
8. Dashboards de Grafana para el cliente

Escalado

• Hasta ~500 hosts / ~1k NVPS: este compose tal cual en un VPS de 4-8 GB
• Más grande: separar la DB a un host propio, agregar proxies Zabbix por sitio (los proxies bufferan datos si se corta el enlace)

Licencia

MIT