Objetivo y alcance
Diseñar una plataforma Zabbix que conserve visibilidad durante cortes de enlaces y pueda crecer sin degradar base ni operación.
Contexto técnico
En múltiples sedes, proxies recolectan localmente y almacenan datos durante interrupciones. La arquitectura debe dimensionar items, frecuencia, historia, tendencias y eventos.
La escala no depende sólo de cantidad de hosts. Checks frecuentes, preprocesamiento, discovery y retención cambian carga de servidor y base de datos.
Arquitectura y criterios
- Ubicar proxies según conectividad y límites operativos.
- Estandarizar plantillas, tags y grupos.
- Dimensionar base por valores por segundo y retención.
- Separar señales accionables de telemetría histórica.
- Proteger credenciales, front-end y agentes.
Implementación recomendada
- Inventariar sedes, activos, enlaces y métricas.
- Estimar carga y diseñar servidor, base y proxies.
- Crear plantillas versionadas y convenciones.
- Pilotear una sede y probar pérdida de enlace.
- Medir colas, cachés, base y tiempo de evaluación.
Riesgos y controles
- Descubrimientos sin límites generan carga inesperada.
- Retención extensa sin partición degrada base.
- Un proxy comprometido puede exponer credenciales de monitoreo.
Validación y evidencia
- El proxy conserva y entrega datos tras un corte.
- Colas y tiempos permanecen dentro de objetivos.
- Una nueva sede se incorpora mediante un procedimiento repetible.
Operación continua
Monitorear Zabbix con métricas internas, controlar versiones de plantillas y revisar crecimiento, unsupported items y proxies desconectados.
Próximo paso
Calcular valores por segundo y retención de una sede piloto antes de dimensionar el entorno completo.