12. Ítems - agent, trapper, external, calculated, SNMP, simple checks

Reconocer los distintos mecanismos de entrada de datos y su uso práctico

Introducción conceptual

Cada ítem en Zabbix representa una fuente específica de datos.

Pero no todos los ítems funcionan igual ni se alimentan de la misma forma.

Un operador debe ser capaz de identificar el tipo de ítem, entender de dónde vienen sus datos, y saber por qué puede fallar.

No basta con ver “No data” en la GUI.

Es necesario saber si el ítem espera datos, los genera, los calcula o los obtiene de terceros.

🧩 Tabla resumen – Tipos de ítems en Zabbix

| Tipo de ítem            | ¿Quién lo alimenta?                            | Modo    | Uso principal                               | Riesgos comunes                            |

| ----------------------- | ---------------------------------------------- | ------- | ------------------------------------------- | ------------------------------------------ |

| Zabbix agent          | Server o Proxy consulta al agente              | Pull    | CPU, RAM, procesos, disco                   | Puerto cerrado, agente caído, timeout      |

| Zabbix agent (active) | Agente envía al server                         | Push    | Ítems desde sistemas NAT/remotos            | Hostname incorrecto, ServerActive inválido |

| Zabbix trapper        | zabbix_sender u otro proceso externo         | Push    | Scripts personalizados, eventos programados | Ítem no creado, key incorrecta             |

| External check        | Server ejecuta comando o script externo        | Pull    | Validación con binarios, monitoreo puntual  | Script lento, permisos, timeout            |

| Calculated            | Zabbix calcula fórmula a partir de otros ítems | Interno | Sumar, restar, combinar métricas            | Ítems fuente sin datos, error en fórmula   |

| SNMP                  | Server consulta por protocolo SNMP             | Pull    | Switches, routers, impresoras, UPS          | Comunidad errónea, firewall, OID inválido  |

| Simple check          | Server hace prueba básica (ping, TCP, DNS)     | Pull    | Validación rápida de disponibilidad         | Host apagado, puerto cerrado, DNS mal      |

| HTTP agent            | Server ejecuta petición HTTP/REST              | Pull    | Monitoreo de APIs, sitios, webhooks         | Código de estado inesperado, timeout       |

🟢 1. Zabbix agent y Zabbix agent (active)

  • Ya abordados en profundidad en módulos anteriores.

  • Permiten recolección local del sistema operativo.

  • Definidos en la GUI como:


Type: Zabbix agent

Key: system.cpu.util[,user]

El operador debe revisar:

  • Si el agente está corriendo

  • Si el ítem tiene update interval correcto

  • Si el canal (pasivo o activo) está bien definido

2. Zabbix trapper

Ítem pasivo: espera que otro sistema le envíe los datos.

  • No se recolecta por sí mismo

  • Necesita uso de zabbix_sender o API personalizada

  • Ideal para métricas que solo existen cuando el evento ocurre

    El ítem debe ser creado previamente.

Zabbix no acepta datos para ítems inexistentes.

🧪 Diagnóstico:


zabbix_sender -z <ip_server> -s "web01" -k "custom.metric" -o 55

Si el ítem no existe o no es de tipo trapper, se ignora sin error visible en GUI.

🟡 3. External check

Ejecuta un comando o script directamente en el Zabbix Server (no en el host monitoreado).

  • Se usa cuando el Server necesita validar algo que no expone Zabbix Agent.

  • Por ejemplo: verificar si existe un archivo NFS, ejecución de binario, conectividad con algún puerto complejo, etc.

    Ruta del script:


/etc/zabbix/externalscripts/

Ejemplo en GUI:


Key: ext.burp.client.status.sh[webserver01]

Type: External check

🧨 Riesgos:

  • Script demasiado lento → supera tiempo máximo (Timeout=3)

  • Permisos incorrectos

  • Script no existe o tiene error

    Ver en logs:


tail -f /var/log/zabbix/zabbix_server.log

🟠 4. Calculated

No obtiene datos, los calcula internamente con base en otros ítems.

  • Ideal para consolidar información: sumas, promedios, comparaciones, expresiones condicionales

  • Usa funciones como last(), avg(), min(), etc.

    Ejemplo:


last(/srv01/output.1) + last(/srv01/output.2)

Muy útil para:

  • Convertir Watts a Kilowatts

  • Sumar CPU de varios núcleos

  • Promediar disco usado entre discos

🧨 Riesgos:

  • Ítems fuente sin datos → el ítem calculado queda en “No data”

  • Error en fórmula → ítem se invalida

  • No es evaluado por proxy, solo por el Server

5. SNMP agent (v2c, v3)

Consulta a un equipo que expone datos por protocolo SNMP (UDP 161)

  • Requiere una OID válida

  • Se configura comunidad (public, private, personalizada)

  • SNMPv3 permite autenticación y cifrado

🧪 Diagnóstico en consola:


snmpget -v2c -c public <ip> 1.3.6.1.2.1.1.3.0

🧨 Riesgos:

  • Comunidad incorrecta → timeout

  • OID inválida → “No such object”

  • Firewall bloqueando UDP/161

    Cada ítem SNMP debe tener un tiempo de respuesta bajo (<1s), o causará problemas en el poller del Server o Proxy.

⚪ 6. Simple check

Usado para validar cosas básicas como:

  • Ping (ICMP)

  • Puertos abiertos (TCP)

  • Resolución de DNS

  • Tiempo de respuesta de red

    Ejemplo:


Key: icmpping

Type: Simple check

🧨 Limitaciones:

  • No ofrece detalles (no mide CPU, RAM, procesos)

  • Solo dice si algo está “arriba o abajo”

  • Algunos checks dependen de binarios en el Server

🧪 Diagnóstico y visualización por tipo de ítem

  1. En GUI:

   Monitoring → Latest Data → Host → Filtro por Type

  1. En SQL (PostgreSQL):

SELECT hostid, key_, type, name FROM items WHERE status=0;

Tipos numéricos de ítems:

| Tipo                  | Valor numérico en DB |

| --------------------- | -------------------- |

| Zabbix agent          | 0                    |

| SNMPv1                | 1                    |

| Trapper               | 2                    |

| Simple check          | 3                    |

| SNMPv2                | 4                    |

| Zabbix agent (active) | 7                    |

| External check        | 10                   |

| Calculated            | 15                   |

| SNMPv3                | 16                   |

| HTTP agent            | 18                   |

🧠 Reflexión operativa

*Cada ítem tiene su propio canal de vida.

Entender de dónde vienen los datos permite detectar fallos antes de que sean visibles.

Un operador maduro no solo ve "No data", sino que sabe por qué no llega y de dónde se espera.*

✅ Resultado esperado

  • El operador reconoce todos los tipos de ítems en GUI

  • Sabe qué canal alimenta a cada uno (pull, push, interno)

  • Puede diagnosticar fallas por tipo (SNMP sin comunidad, external sin permisos, calculated sin fuente)

  • Entiende el valor operativo de elegir el tipo correcto de ítem