Zabbix: Primeros pasos — hosts, templates, triggers y alertas

Introducción

Una vez que Zabbix Server está instalado y funcionando (tal como vimos en el artículo anterior), el siguiente paso es empezar a monitorizar equipos reales. En esta guía recorreremos el proceso completo: agregar un host, asignarle plantillas de monitorización, entender los triggers predefinidos, configurar acciones de alerta y explorar las herramientas de visualización como Latest Data, Graphs y Dashboards.

Trabajaremos sobre la interfaz web de Zabbix 7.x, accesible desde http://<servidor>/zabbix.

Paso 1: Agregar un host a Zabbix

Para monitorizar un servidor Linux necesitamos que tenga el Zabbix Agent instalado y configurado para apuntar a nuestro servidor Zabbix. Asumiendo que ya está instalado, agregamos el host desde la interfaz web.

Navegamos a: Data collection → Hosts → Create host (botón azul arriba a la derecha).

Host name: servidor-web-01
Visible name: Servidor Web 01
Templates: Linux by Zabbix agent
Groups: Linux servers
Interfaces: Agent → 192.168.1.10 → 10050 (default)
Monitored by proxy: (no proxy)

Parámetros clave a configurar:

Host name: Debe coincidir con el Hostname definido en /etc/zabbix/zabbix_agentd.conf del equipo monitorizado.
Templates: Seleccionamos «Linux by Zabbix agent» que ya incluye items, triggers y graphs para métricas esenciales.
Host groups: Los grupos organizan los hosts; creamos uno llamado «Linux servers» o usamos uno existente.
Interfaces: La interfaz «Agent» debe apuntar a la IP real del host monitorizado y al puerto 10050.

Hacemos clic en Add y el host aparecerá en la lista. Inicialmente el indicador de disponibilidad (ZBX) estará en gris, y tras unos segundos se pondrá verde si la comunicación es exitosa.

Paso 2: Entender los triggers predefinidos

La plantilla «Linux by Zabbix agent» incluye docenas de triggers listos para usar. Los principales son:

Trigger: CPU utilization > 90% (5m avg)
Expresión: avg(/Linux by Zabbix agent/system.cpu.util[,user],5m) > 0.9
Severidad: Warning

Trigger: Low disk space < 10% (volume /)
Expresión: last(/Linux by Zabbix agent/vfs.fs.size[/,pfree]) < 10
Severidad: Average

Trigger: Unavailable by ICMP ping
Expresión: nodata(/Linux by Zabbix agent/icmpping,30s)=1
Severidad: High

Trigger: Network interface is down (eth0)
Expresión: last(/Linux by Zabbix agent/net.if.status[eth0])<>0
Severidad: Warning

Estos triggers se evalúan constantemente. Cuando la condición se cumple, el trigger pasa al estado PROBLEM. Cuando la métrica vuelve a valores normales, pasa a OK.

Paso 3: Configurar acciones (Actions) para alertas por email

Para recibir notificaciones cuando un trigger se dispare, debemos configurar una Action y un Media type.

3.1 Configurar Media Type (Email)

Ir a: Administration → Media types → Email.

Name: Send Email
SMTP server: smtp.gmail.com
SMTP server port: 587
SMTP helo: gmail.com
SMTP email: zabbix-alerts@tudominio.com
Connection security: STARTTLS
Authentication: Username and password
Username: zabbix-alerts@tudominio.com
Password: ********

Probamos la configuración con el botón Test enviando un email de prueba a nuestra dirección.

3.2 Configurar Action

Ir a: Data collection → Actions → Trigger actions → Create action.

Name: Notificar por email problemas críticos
Conditions:
  - Trigger severity ≥ Average
  - Host group = Linux servers

Operations:
  - Send message to user "Admin" via "Send Email"
    Subject: PROBLEMA: {TRIGGER.STATUS} en {HOST.NAME}
    Message:
    HOST: {HOST.NAME}
    IP: {HOST.IP}
    FECHA: {EVENT.DATE} {EVENT.TIME}
    TRIGGER: {TRIGGER.NAME}
    SEVERIDAD: {TRIGGER.SEVERITY}
    STATUS: {TRIGGER.STATUS}
    ITEM: {ITEM.NAME} = {ITEM.VALUE}

Recovery operations:
  - Send message to user "Admin" via "Send Email"
    Subject: RECUPERADO: {TRIGGER.STATUS} en {HOST.NAME}

Guardamos la acción. A partir de ahora, cuando cualquier trigger de severidad Average o superior se active en un host del grupo «Linux servers», recibiremos un correo electrónico.

Paso 4: Explorar Latest Data y Graphs

Para ver los datos que Zabbix está recolectando en tiempo real:

Latest Data: Monitoring → Latest data. Filtramos por host y vemos la última lectura de cada item (CPU, memoria, disco, red, etc.). Podemos hacer clic en Graph para ver la evolución temporal.
Graphs: Monitoring → Hosts → Graphs. Seleccionamos un host y elegimos entre los gráficos predefinidos de la plantilla: «CPU utilization», «Memory usage», «Network traffic», «Disk I/O».

Ejemplo de datos típicos visibles:
  - CPU: 23.5% (user) / 12.1% (system) / 64.4% (idle)
  - RAM: 4.2 GB / 8.0 GB used (52.5%)
  - Disco /: 120 GB / 256 GB used (46.8%)
  - Red eth0: 15.3 Mbps in / 2.1 Mbps out

Paso 5: Crear un Dashboard personalizado

Los dashboards permiten tener una vista unificada de toda la infraestructura:

Ir a: Monitoring → Dashboards → Create dashboard
Nombre: Resumen Infraestructura

Widgets recomendados:
  1. Problem hosts — hosts con problemas activos (span: 6 cols)
  2. CPU utilization (top 10) — gráfico de CPU de todos los hosts (span: 6 cols)
  3. System status — resumen por severidad de triggers (span: 4 cols)
  4. Clock — reloj digital (span: 2 cols)
  5. Host availability — disponibilidad ZBX / SNMP / IPMI (span: 6 cols)

Podemos compartir el dashboard con otros usuarios y fijarlo como página de inicio por defecto.

Conclusión

Con estos pasos ya tenemos un entorno de monitorización funcional: hosts registrados, métricas recolectadas, triggers evaluando condiciones críticas y notificaciones automáticas por email. En el próximo artículo veremos cómo automatizar todo este despliegue usando Ansible, integrando Zabbix API para agregar hosts y asignar templates de forma programática.