Dominar la configuración del ritmo de recolección
Monitorear no es solo activar ítems, sino definir cuándo y cada cuánto deben consultarse.
Zabbix permite controlar con precisión la frecuencia de recolección de datos, balanceando:
Precisión operativa (datos frecuentes para alertas críticas)
Carga del sistema (más ítems → más procesos, más DB, más red)
El operador debe diseñar intervalos razonables, según la importancia del dato, la tecnología involucrada y la capacidad de la infraestructura.
Update interval)Es el valor base. Define cada cuánto Zabbix ejecuta el ítem.
En GUI:
Update interval: 30s
Significa: cada 30 segundos se consultará o esperará el dato.
🧠 Valor recomendado para ítems críticos: 30s, 1m
Para métricas de estado bajo: 5m, 10m, o más.
s, m, h, d)Zabbix permite expresar los intervalos con sufijos legibles:
| Valor en GUI | Equivalencia |
| ------------ | ------------ |
| 30s | 30 segundos |
| 2m | 2 minutos |
| 1h | 1 hora |
| 1d | 1 día |
✅ Esto mejora la legibilidad, evita errores y es compatible con configuraciones programadas o flexibles.
Flexible intervals)Permiten cambiar el intervalo en ciertos horarios.
Ideal para reducir carga fuera de horas pico.
En GUI:
Campo: Flexible intervals
Ejemplo:
Interval: 10s
Period: 1-5,09:00-18:00
Significado:
Lunes a viernes, de 9 AM a 6 PM → recolección cada 10s
Fuera de ese horario → se aplica el Update interval estándar (por ejemplo, 5m)
🧠 Esto permite tener datos detallados solo cuando importa.
Muchos entornos aplican
1mentre 08:00–20:00, y5men la madrugada.Así se optimiza el uso de CPU, disco y red en horas no críticas.
Custom intervals)Permiten definir múltiples reglas horarias con distintos intervalos.
En GUI:
Se muestra como tabla editable por rangos.
Ejemplo de reglas:
| Interval | Period |
| -------- | --------------- |
| 30s | 1-5,08:00-20:00 |
| 2m | 1-5,20:00-23:00 |
| 10m | 6-7 |
🧠 Prioridad:
Custom intervals sobreescriben el Update interval si el periodo aplica.
Si no aplica ningún periodo, Zabbix usa el estándar.
| Error común | Consecuencia | Prevención |
| ---------------------------------------------- | ---------------------------------------------- | ----------------------------------------- |
| 30s en ítems poco relevantes | Sobrecarga de pollers, disco y red innecesaria | Aplicar 5m o más |
| Intervalos muy largos (1h) en ítems críticos | Detección tardía de fallas | Usar 30s, 1m o Custom intervals |
| Demasiados ítems en 10s sin proxy | Saturación del Zabbix Server | Distribuir con proxies o aumentar pollers |
| Sin sufijo (ej. 60) | Interpretación confusa: ¿segundos o minutos? | Siempre usar s, m, h, etc. |
Configuration → Hosts → Items → Columna “Interval”
SELECT hostid, key_, delay, delay_flex FROM items WHERE status=0;
delay: valor base (en segundos)
delay_flex: texto con las reglas adicionales (10s/1-5,08:00-20:00)
En GUI:
Monitoring → Problems → Too many processes busy
Revisar si hay Poller, Unreachable poller, ICMP pinger, etc. saturados
En logs:
tail -f /var/log/zabbix/zabbix_server.log
Errores típicos:
unreachable poller processes more than 75% busy
Cada ítem consume recursos. Un intervalo mal definido puede tumbar un sistema completo.
El operador no solo crea ítems: define ritmos, optimiza flujos y anticipa carga.
El operador reconoce el campo Update interval y su impacto
Sabe usar sufijos correctamente (30s, 5m, etc.)
Puede definir intervalos flexibles según horarios
Distingue entre uso intensivo y moderado
Puede diagnosticar sobrecarga causada por intervalos excesivos