Monitoreo de Redes y Servidores con Zabbix: Guía Completa

1. Introducción

En cualquier infraestructura IT, saber qué está ocurriendo en cada servidor, servicio y dispositivo de red en tiempo real es crítico. Sin monitoreo, las fallas se detectan cuando los usuarios reportan problemas, lo que significa tiempo de inactividad no planificado, pérdida de ingresos y daño a la reputación.

¿Por qué Zabbix?

Zabbix es una plataforma de monitoreo open source de nivel empresarial. A diferencia de Nagios (configuración basada en archivos estáticos), Prometheus (ecosistema más orientado a containers) o PRTG (licenciamiento por sensor), Zabbix ofrece:

Característica	Zabbix	Nagios	Prometheus	PRTG
Arquitectura	Centralizada con proxies	Centralizada	Pull distribuido	Centralizada
Auto-descubrimiento	Nativo (LLD + Network Discovery)	Limitado	Service Discovery	Auto-detect
Alertas	Completas (escalado, acciones)	Básicas	Alertmanager	Avanzadas
SNMP / IPMI / JMX	Soporte nativo	Plugins	Exporters	Soporte nativo
Licencia	GPL 2.0 (gratuito)	GPL (gratuito)	Apache 2.0 (gratuito)	Comercial

Arquitectura general

Zabbix sigue un modelo cliente-servidor con tres componentes principales: Zabbix Server (procesamiento central), Zabbix Proxy (recolección distribuida opcional) y Zabbix Agent (instalado en los hosts monitoreados). La base de datos PostgreSQL con TimescaleDB permite manejar millones de métricas por segundo mediante particionado automático.

2. Arquitectura de Zabbix

Comprender la arquitectura es clave para diseñar un despliegue escalable.

Componentes del sistema

Zabbix Server: Motor central que recibe métricas, evalúa triggers, envía alertas y almacena datos. Puede monitorear hasta 10,000+ hosts con hardware adecuado.
Zabbix Proxy: Recolecta datos en ubicaciones remotas y los envía al servidor de forma desatendida. Reduce la carga del servidor principal y funciona en modo offline (almacena en cola).
Zabbix Agent: Proceso liviano instalado en los hosts que recolecta métricas del SO, procesos, servicios y logs. Existen versiones para Windows, Linux, macOS, AIX, Solaris, etc.
Base de datos: PostgreSQL + TimescaleDB ofrece particionado automático por tiempo (hypertables), compresión y mejor rendimiento en queries de series temporales.
Web Interface: Frontend PHP que se conecta a la base de datos. Soporta dashboards, mapas, informes y administración.

Flujo de datos típico:

Host → Agent (Zabbix Agent activo/pasivo)
  → Zabbix Proxy (opcional, para segmentación remota)
    → Zabbix Server (evalúa triggers, escribe en DB)
      → Database PostgreSQL + TimescaleDB (hypertables)
        → Web Interface / API REST → Dashboards y Alertas

Modos de comunicación

Agente pasivo: El servidor consulta al agente en el puerto 10050. Simple y directo.
Agente activo: El agente envía datos al servidor en el puerto 10051. Escala mejor con miles de hosts.
Proxy activo/pasivo: El proxy puede enviar datos al servidor (activo) o esperar a que el servidor los solicite (pasivo).

3. Instalación en Ubuntu 22.04 LTS

A continuación, una instalación completa de Zabbix 7.0 LTS con Nginx, PostgreSQL 16 y TimescaleDB para particionado automático.

Paso 1: Instalar PostgreSQL 16 y TimescaleDB

# Agregar repositorio oficial de PostgreSQL
sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'
wget -qO- https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -

# Agregar repositorio de TimescaleDB
sudo add-apt-repository -y "deb https://packagecloud.io/timescale/timescaledb/ubuntu/ $(lsb_release -cs) main"
wget -qO- https://packagecloud.io/timescale/timescaledb/gpgkey | sudo apt-key add -

sudo apt update
sudo apt install -y postgresql-16 postgresql-client-16 timescaledb-2-postgresql-16

# Configurar TimescaleDB en postgresql.conf
sudo timescaledb-tune --quiet --yes
sudo systemctl restart postgresql

Paso 2: Crear base de datos y usuario

sudo -u postgres createuser --pwprompt zabbix
sudo -u postgres createdb -O zabbix zabbix
sudo -u postgres psql -c "ALTER DATABASE zabbix SET search_path TO public,zabbix;"

# Habilitar TimescaleDB en la base de datos
sudo -u postgres psql -d zabbix -c "CREATE EXTENSION IF NOT EXISTS timescaledb;"

Paso 3: Instalar Zabbix Server, Agent y Frontend

# Agregar repositorio oficial de Zabbix
wget https://repo.zabbix.com/zabbix/7.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_7.0-1+ubuntu22.04_all.deb
sudo dpkg -i zabbix-release_7.0-1+ubuntu22.04_all.deb
sudo apt update

# Instalar paquetes
sudo apt install -y zabbix-server-pgsql zabbix-frontend-php \
  zabbix-nginx-conf zabbix-sql-scripts zabbix-agent \
  zabbix-get zabbix-sender

# Importar esquema de base de datos
zcat /usr/share/zabbix-sql-scripts/postgresql/server.sql.gz | \
  sed 's/CREATE INDEX/CREATE INDEX CONCURRENTLY/g' | \
  sudo -u zabbix psql -d zabbix

# Aplicar particionado de TimescaleDB
cat /usr/share/zabbix-sql-scripts/postgresql/timescaledb.sql | \
  sudo -u zabbix psql -d zabbix

Paso 4: Configurar Zabbix Server

# Editar /etc/zabbix/zabbix_server.conf
sudo tee -a /etc/zabbix/zabbix_server.conf << 'EOF'
DBHost=localhost
DBName=zabbix
DBUser=zabbix
DBPassword=TuPasswordSegura
DBPort=5432
Timeout=30
LogSlowQueries=3000
StatsAllowedIP=127.0.0.1
StartPollers=20
StartPreprocessors=8
StartPingers=5
CacheSize=512M
HistoryCacheSize=256M
TrendCacheSize=128M
HistoryTextCacheSize=256M
ValueCacheSize=256M
EOF

Paso 5: Configurar Nginx

# /etc/nginx/sites-available/default (parcial)
server {
    listen 80;
    server_name monitoring.tudominio.com;

    root /usr/share/zabbix;
    index index.php;

    location / {
        try_files $uri $uri/ =404;
    }

    location ~ \.php$ {
        fastcgi_pass unix:/var/run/php/php8.3-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }
}

# Configurar PHP-FPM
sed -i 's/^max_execution_time = .*/max_execution_time = 600/' /etc/php/8.3/fpm/php.ini
sed -i 's/^max_input_time = .*/max_input_time = 600/' /etc/php/8.3/fpm/php.ini
sed -i 's/^post_max_size = .*/post_max_size = 80M/' /etc/php/8.3/fpm/php.ini

# Iniciar servicios
sudo systemctl enable zabbix-server zabbix-agent nginx php8.3-fpm
sudo systemctl restart zabbix-server zabbix-agent nginx php8.3-fpm

Completa la instalación accediendo a http://monitoring.tudominio.com y siguiendo el asistente web. Los valores por defecto (usuario Admin, contraseña zabbix) te darán acceso al panel.

4. Configuración de Hosts y Templates

Zabbix organiza el monitoreo mediante hosts (entidades monitoreadas) y templates (conjuntos reutilizables de items, triggers y dashboards).

Crear un host manualmente

Desde la interfaz web: Data Collection → Hosts → Create Host:

Nombre: Servidor Web Producción 01
Nombre visible: web-prod-01
Grupos: Linux Servers, Web Servers
Interfaces: Agent 192.168.1.10:10050
Templates: Template OS Linux by Zabbix agent
            Template App HTTP Service
            Template Module ICMP Ping
Macros: {$CPU.UTIL.CRIT} = 90
        {$MEMORY.UTIL.MAX} = 95
        {$DISK.UTIL.CRIT} = 92

Templates incluidos más utilizados

Template	Monitorea
Template OS Linux by Zabbix agent	CPU, memoria, disco, red, procesos, sistema de archivos
Template App HTTP Service	Disponibilidad y rendimiento de sitios web
Template Module ICMP Ping	Latencia y pérdida de paquetes
Template DB MySQL by Zabbix agent	Queries, conexiones, innodb, replicación
Template Net Network Generic Device SNMPv2	Interfaces, tráfico, errores en switches/routers

Crear un template personalizado

Para crear un template para Nginx:

1. Data Collection → Templates → Create Template
2. Nombre: Template App Nginx HTTP por Agent
3. Groups: Templates/Applications
4. Crear item:
   - Name: Nginx - active connections
   - Key: nginx.active_connections
   - Type: Zabbix agent (active)
   - Key: web.page.get["http://localhost/nginx_status","",""]
   - Preprocessing: JSONPath ($.connections.active)
   - Update interval: 60s
5. Crear trigger:
   - Name: Alta tasa de conexiones activas en Nginx
   - Expression: avg(/Template App Nginx HTTP por Agent/nginx.active_connections,5m) > 1000
   - Severity: Warning

Configuración en el servidor Nginx para exponer el estado:

# /etc/nginx/sites-available/default
location /nginx_status {
    stub_status on;
    allow 127.0.0.1;
    deny all;
}

5. Items y Triggers

Los items recolectan datos; los triggers evalúan condiciones sobre esos datos para generar eventos.

Tipos de Items

Tipo	Descripción	Caso de uso
Zabbix agent	Métricas del SO vía agente Zabbix	CPU, RAM, disco, procesos
SNMP	Consulta dispositivos de red vía OIDs	Switches, routers, impresoras
IPMI	Hardware de servidores (BMC/iDRAC)	Temperatura, ventiladores, voltaje
HTTP agent	Realiza peticiones HTTP(S)	APIs REST, health checks
JMX	Métricas de Java (JMX)	Tomcat, Kafka, Elasticsearch
Trapper	Recibe datos vía zabbix_sender	Métricas personalizadas
Calculated	Fórmulas basadas en otros items	Porcentajes, promedios

Expresiones de Trigger: ejemplos reales

# CPU al 90% durante 5 minutos
avg(/host/system.cpu.util,5m) > 90

# Disco raíz por encima del 85%
last(/host/vfs.fs.size[/,pused]) > 85

# Servicio HTTP caído (3 chequeos fallidos consecutivos)
max(/host/net.tcp.service[http],#3) = 0

# Tasa de errores en interfaz de red alta
rate(/host/net.if.in[eth0,errors],5m) > 100

# Comparación de latencia ICMP contra umbral
avg(/host/icmppingsec,10m) > 0.500

# Caída repentina de conexiones MySQL
max(/host/mysql.active_connections,5m) / avg(/host/mysql.active_connections,30m) < 0.5

Trigger con dependencias

Si un servidor está caído, no tiene sentido alertar por cada servicio individual. Las dependencias evitan tormentas de alertas:

Trigger padre: Servidor Web Prod 01 está CAÍDO
  └─ Depende: Servicio HTTP en Web Prod 01 no disponible
  └─ Depende: MySQL en Web Prod 01 no responde
  └─ Depende: Latencia alta en Web Prod 01

6. Discovery y Auto-registro

En entornos con decenas o cientos de servidores, configurar cada host manualmente es inviable. Zabbix ofrece tres mecanismos de descubrimiento.

Network Discovery

Escanea rangos de red y descubre dispositivos por ICMP, puertos SNMP o servicios:

Configuración: Data Collection → Discovery → Create discovery rule
Name: Descubrimiento Red Local 192.168.1.0/24
IP range: 192.168.1.1-254
Checks:
  - ICMP ping (discover si responde ping)
  - SNMP v2c (discover dispositivos SNMP)
  - Zabbix agent (discover si hay agente en puerto 10050)
Delay: 3600s (1 hora)

Acciones de discovery:
  - Si Device status = Up AND Service = Zabbix agent
    → Add host to group "Linux Servers"
    → Link template "Template OS Linux by Zabbix agent"

Auto-registro de Agentes Activos

Los agentes activos pueden registrarse automáticamente en el servidor sin configuración previa:

# En /etc/zabbix/zabbix_agent2.conf
Server=monitoring.tudominio.com
ServerActive=monitoring.tudominio.com:10051
Hostname=web-prod-01
HostMetadata=linux,webserver,production
TLSConnect=psk
TLSPSKIdentity=web-prod-01
TLSPSKFile=/etc/zabbix/zabbix_agentd.psk

# En el servidor Zabbix, crear acción de auto-registro:
Administration → Actions → Auto-registration
Conditions: Host metadata like "linux"
            Host metadata like "production"
Operations: Add to group "Linux Servers"
            Add to group "Production"
            Link template "Template OS Linux by Zabbix agent"

Low-Level Discovery (LLD)

Zabbix descubre automáticamente discos, interfaces de red, monitores SNMP, etc.:

# LLD para discos - Template OS Linux ya lo incluye:
{#FSNAME} → /, /var, /home
{#FSTYPE} → ext4, xfs
{#FSLABEL} → root, var

# Ejemplo de trigger generado por LLD:
last(/host/vfs.fs.size[{#FSNAME},pused]) > 90
# Esto genera alerta individual para cada disco montado

7. Alertas y Notificaciones

Zabbix soporta múltiples media types para enviar alertas por diferentes canales.

Media Type: Correo electrónico

Administration → Media Types → Email
SMTP server: smtp.gmail.com
SMTP server port: 587
SMTP helo: gmail.com
SMTP email: monitoreo@tudominio.com
Connection security: STARTTLS
Authentication: Username & Password
Username: monitoreo@tudominio.com
Password: contraseña_de_aplicación

Media Type: Telegram

# Crear bot en Telegram con @BotFather
# Obtener token: 1234567890:ABCdefGHIjklmNOPqrStuVWXyz

Administration → Media Types → Telegram
Token: 1234567890:ABCdefGHIjklmNOPqrStuVWXyz
API URL: https://api.telegram.org

# Obtener Chat ID:
# Enviar mensaje al bot y luego visitar:
# https://api.telegram.org/bot<TOKEN>/getUpdates

# Mensaje personalizado:
{TPLCONTENT}

# Trigger: {TRIGGER.NAME}
# Host: {HOST.NAME}
# Severidad: {TRIGGER.SEVERITY}
# Fecha: {EVENT.DATE} {EVENT.TIME}
# Estado actual: {TRIGGER.STATUS}

Media Type: Slack (Webhook)

# Crear Slack App en api.slack.com → Webhooks entrantes
# Obtener URL: https://hooks.slack.com/services/T00/B00/xxxxx

Administration → Media Types → Webhook
Parameters:
  - payload: {"text": "{ALERT.MESSAGE}"}
  - url: https://hooks.slack.com/services/T00/B00/xxxxx
Content-Type: application/json

Escalado de alertas

Define escalados para que si un problema no se resuelve, se notifique a niveles superiores:

Configuración: Alerts → Actions → Trigger Actions → Create action
Name: Escalado de Incidentes Críticos

Etapa 1 (0-15 min):
  Notificar al Grupo SysAdmin vía Telegram
  Enviar email al equipo de turno

Etapa 2 (15-60 min):
  Notificar al Líder de Infraestructura vía Telegram + SMS
  Crear ticket en sistema ITSM (vía webhook)

Etapa 3 (> 60 min):
  Notificar al CTO
  Escalar a Gerencia vía email + Slack

Default operation step duration: 900s (15 min)

8. Dashboards y Visualización

Zabbix 7.0 ofrece dashboards altamente personalizables con widgets en HTML5.

Crear un Dashboard de Estado General

Monitoring → Dashboards → Create dashboard
Name: Estado General Infraestructura

Widgets recomendados:
1. Filtro de tiempo (Time period selector)
2. Problems (Severity + Host group filter)
3. Top hosts con más problemas
4. CPU promedio por grupo (Gauge)
5. Memoria disponible (Gauge)
6. Tráfico de red por interfaz (Graph classic)
7. Últimos 20 eventos críticos (Problem events)
8. Disponibilidad de servicios (Single statistic)
9. Estado de proxies (Map - navigation tree)
10. SLA semanal (SLA report widget)

Gráficos avanzados

# Graph classic - Comparativa de CPU
Items: system.cpu.util[system,user], system.cpu.util[system,system],
       system.cpu.util[system,iowait]
Tipo: apilado (stacked)
Eje Y: 0-100%
Color: #3b82f6, #22c55e, #ef4444

# Graph - Tráfico de Red
Items: net.if.in[eth0,bytes], net.if.out[eth0,bytes]
Tipo: línea
Unidad: bits/s (aplicar *8 en preprocessing)
Umbral: 1Gbps línea de referencia

Mapas de red

Los mapas permiten visualizar topologías con estado en tiempo real:

Monitoring → Maps → Create map
Name: Topología Red Producción

- Añadir iconos de servidores, switches, firewalls
- Conectar con enlaces (líneas)
- Configurar label para mostrar tráfico:
  Enlace SW-CORE → WEB-PROD-01:
    Label: {host:net.if.in[ge0,bytes].last()} / {host:net.if.out[ge0,bytes].last()}
- Color de icono según estado (automático)

Reportes de SLA

Reports → SLA → Create SLA
Name: SLA Servicios Críticos
Periodo: Mensual
Horario: 24x7 (o 8x5 para servicios ofimáticos)

Indicadores (SLIs):
  Disponibilidad HTTP: 99.9%
  Latencia MySQL < 500ms: 99.5%
  Ping < 50ms: 99.8%

SLO: 99.9%

Reporte automático:
  Enviar primer día de cada mes a gerencia vía email

9. Caso Práctico: Monitoreo Completo de un Servidor Web

Vamos a construir el monitoreo integral de un servidor web Linux que ejecuta Nginx, MySQL y una aplicación PHP. Este es un escenario real que cubre las capas de infraestructura, aplicación y red.

Template combinado: "Template Web Server Full Stack"

--- Items ---
# Sistema Operativo
CPU utilization (5min avg):          system.cpu.util[all,avg5]
Memory available:                    vm.memory.size[available]
Disk / utilization:                  vfs.fs.size[/,pused]
Disk /var/log utilization:           vfs.fs.size[/var/log,pused]
Disk /var/lib/mysql utilization:     vfs.fs.size[/var/lib/mysql,pused]
Network throughput eth0 in:          net.if.in[eth0,bytes]
Network throughput eth0 out:         net.if.out[eth0,bytes]

# Nginx
Nginx active connections:            web.page.get["http://localhost/nginx_status"]
Nginx requests per second:           web.page.get["http://localhost/nginx_status"]
Nginx accepted connections (total):  web.page.get["http://localhost/nginx_status"]

# MySQL
MySQL uptime:                        mysql.uptime
MySQL active connections:            mysql.active_connections
MySQL queries per second:            mysql.qps
MySQL slow queries:                  mysql.slow_queries
MySQL replication lag (slave):       mysql.replication_lag
MySQL InnoDB buffer pool hitrate:    mysql.innodb.buffer_pool_hit_rate

# Aplicación - Health Check
App health endpoint:                 web.page.get["http://localhost/health"]
App response time:                   web.page.get["http://localhost/health"]
App database connection test:        web.page.get["http://localhost/db-check"]

# Red
ICMP ping latency:                   icmppingsec
Packet loss:                         icmppingloss

Triggers críticos

# Críticos (severidad: Disaster)
CPU > 95% por 10 minutos:
  avg(/host/system.cpu.util[all,avg5],10m) > 95

Memoria disponible < 512MB:
  last(/host/vm.memory.size[available]) < 536870912

Disk / 100% (root):
  last(/host/vfs.fs.size[/,pused]) > 98

MySQL caído:
  last(/host/mysql.uptime) < 60

# Altos (severidad: High)
CPU > 85% por 15 minutos:
  avg(/host/system.cpu.util[all,avg5],15m) > 85

Disk / > 90%:
  last(/host/vfs.fs.size[/,pused]) > 90

Slow queries > 10 en 5 minutos:
  rate(/host/mysql.slow_queries,5m) > 10

Nginx conexiones > 2000 activas:
  last(/host/nginx.active_connections) > 2000

# Medios (severidad: Average)
Disk /var/log > 85%:
  last(/host/vfs.fs.size[/var/log,pused]) > 85

Replicación MySQL con lag > 30s:
  last(/host/mysql.replication_lag) > 30

App health endpoint retorna != 200:
  last(/host/app.health.check) <> 200

Latencia de ping > 100ms:
  avg(/host/icmppingsec,5m) > 0.100

Acciones de alerta para este servidor

--- Acción: "Web Server Critical Alert" ---

Condiciones:
  Trigger severity >= High
  Host groups = Web Servers

Operaciones:
  Enviar Telegram al grupo #sysadmin-alertas
    Mensaje: 🔴 CRITICAL | {HOST.NAME}
             {TRIGGER.NAME}
             Valor actual: {ITEM.VALUE}
             {EVENT.DATE} {EVENT.TIME}

  Ejecutar script remoto (acción de recuperación):
    sudo systemctl restart nginx mysql
    (vía script personalizado en zabbix_agentd.conf:
     UserParameter=app.restart[*],sudo systemctl restart $1)

  Enviar email a gerencia si no se resuelve en 30 min
  (usando escalado de etapas)

Dashboard específico para el servidor web

Widgets en dashboard "Web Server Prod - Host Single":

Fila 1: Estado general
- Problem widgets (solo este host)
- Single statistic: CPU, Memory, Disk, Uptime

Fila 2: Rendimiento
- Graph: CPU (user/system/iowait) apilado
- Graph: Memory (total/used/available)
- Graph: Disk I/O (read/write ops)

Fila 3: Aplicación
- Graph: Nginx connections (active/waiting)
- Graph: MySQL QPS y conexiones activas
- Single statistic: App response time (avg 5m)

Fila 4: Red
- Graph: Tráfico eth0 (in/out, bits/s)
- Gauge: Latencia ICMP (ms)

10. Mantenimiento y Buenas Prácticas

Un Zabbix mal mantenido puede degradarse hasta volverse inoperante. Estas prácticas garantizan un monitoreo confiable a largo plazo.

Housekeeping de base de datos

TimescaleDB gestiona automáticamente la retención mediante políticas de particionado. Configuración recomendada:

# Políticas de retención (TimescaleDB)
SELECT add_retention_policy('history', INTERVAL '90 days');
SELECT add_retention_policy('history_log', INTERVAL '30 days');
SELECT add_retention_policy('history_str', INTERVAL '90 days');
SELECT add_retention_policy('history_text', INTERVAL '90 days');
SELECT add_retention_policy('history_uint', INTERVAL '90 days');
SELECT add_retention_policy('trends', INTERVAL '3 years');
SELECT add_retention_policy('trends_uint', INTERVAL '3 years');

# Compresión de chunks viejos (ahorra 80-90% espacio)
SELECT add_compression_policy('history', INTERVAL '7 days');
SELECT add_compression_policy('history_uint', INTERVAL '7 days');
SELECT add_compression_policy('trends', INTERVAL '30 days');
SELECT add_compression_policy('trends_uint', INTERVAL '30 days');

Distribución con Proxies

# Recomendaciones por tamaño de infraestructura:

Pequeña (< 100 hosts):
  Server + DB en mismo servidor (8 vCPU, 16 GB RAM, SSD)

Mediana (100-1000 hosts):
  Server dedicado (16 vCPU, 32 GB RAM, NVMe)
  Proxy por región/data center (4 vCPU, 8 GB RAM)
  PostgreSQL + TimescaleDB en server separado

Grande (1000-10000+ hosts):
  Server en HA (capa activa-pasiva con keepalived)
  Múltiples proxies por ubicación geográfica
  DB clusterizada (Patroni/Repmgr con replicación)
  Frontend web con balanceador y sesiones persistentes

Versionado de Templates

# Exportar templates a YAML/XML y versionarlos en Git
Data Collection → Templates → Export

# Estructura recomendada en repositorio:
monitoreo/
├── templates/
│   ├── linux-base.yaml
│   ├── web-server-fullstack.yaml
│   ├── network-snmp.yaml
│   └── custom-app.yaml
├── macros/
│   └── global-macros.yaml
├── maps/
│   └── topologia-red.yaml
└── scripts/
    └── restart-service.sh

# Importar desde API con curl (automatizable en CI/CD):
curl -s -X POST \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $ZABBIX_TOKEN" \
  -d @template.json \
  http://monitoring/api_jsonrpc.php

Backup strategy

# Backup diario de la base de datos (pg_dump con compresión)
#!/bin/bash
BACKUP_DIR="/backup/zabbix"
DATE=$(date +%Y%m%d_%H%M%S)
DB="zabbix"

pg_dump -h localhost -U zabbix -d $DB \
  --exclude-table='history*' \
  --exclude-table='trends*' \
  --exclude-table='*_history_*' \
  --exclude-schema='_timescaledb_internal' \
  -F c -f "$BACKUP_DIR/${DB}_config_${DATE}.dump"

# Los datos históricos se respaldan con menos frecuencia:
pg_dump -h localhost -U zabbix -d $DB \
  --data-only -t 'history*' -t 'trends*' \
  -F c -f "$BACKUP_DIR/${DB}_history_${DATE}.dump"

# Retención: 30 días config, 7 días history
find $BACKUP_DIR -name "*history*" -mtime +7 -delete
find $BACKUP_DIR -name "*config_*" -mtime +30 -delete

# Backup de archivos de configuración
tar czf "$BACKUP_DIR/zabbix_etc_${DATE}.tar.gz" \
  /etc/zabbix/ /etc/nginx/sites-enabled/zabbix

Monitoreo del propio Zabbix

# Items internos (Zabbix internal monitoring):
Server internal items:
  zabbix[queue] - datos pendientes de procesar
  zabbix[requiredperformance] - NVP/s requeridos vs reales
  zabbix[process,busy,poller,%,avg] - % ocupación de procesos
  zabbix[history_cache,%,used] - uso de history cache
  zabbix[preprocessing_queue,avg] - cola de preprocessing

# Estos items deben tener triggers alertando si:
- Queue > 1000 por más de 5 minutos (proxy o server saturado)
- Requiredperformance > actual (necesitas más recursos)
- Cache usage > 80% (aumentar CacheSize en zabbix_server.conf)

Recomendaciones finales

Usa macros de host para parámetros que varían por servidor (umbrales, credenciales SNMP). Nunca hardcodees valores en los templates.
Agrupa hosts por función y criticidad: Production / Staging / Development. Aplica acciones diferentes según el grupo.
Documenta los triggers: usa el campo "Description" y "URL" para enlazar a runbooks.
Prueba las alertas: usa zabbix_get y zabbix_sender para simular métricas y verificar que los triggers se disparen correctamente.
Revisa el Performance Check: Reports → System Information → Performance debe mostrar "Zabbix server is running" con valores verde en cache usage y queue.
Actualiza con cuidado: lee las notas de versión. Zabbix 6.0 LTS → 7.0 LTS requiere migración de base de datos y cambios en templates.

Conclusión

Zabbix es una herramienta madura, flexible y gratuita que puede monitorear desde un pequeño servidor hasta infraestructuras de nivel enterprise con decenas de miles de dispositivos. Su combinación de descubrimiento automático, templates reutilizables, alertas multicanal y dashboards personalizables lo convierten en la opción ideal para equipos IT que necesitan visibilidad completa sin depender de licencias costosas.

Esta guía ha cubierto desde la instalación en Ubuntu 22.04 con TimescaleDB hasta la creación de un template completo para servidores web, pasando por alertas con Telegram y Slack, descubrimiento automático de hosts, mapas de red y buenas prácticas de mantenimiento. Con estas bases, puedes construir un sistema de monitoreo profesional, escalable y listo para producción.