¿Por qué Zabbix?
Acostumbrado a Nagios, lo primero que busqué en Google para documentarme sobre Zabbix, fue la cadena «Zabbix vs Nagios» (hay un debate muy interesante en reddit). En cualquier caso, aquí hacen una buena comparación entre ambos sistemas de monitorización.
Tras unos días con Zabbix, mi primera impresión es que la configuración vía web de Zabbix quizá sea más amigable que la configuración vía archivos de Nagios, aunque sin duda (y quizá por pasar varios años con Nagios) ésta última resulta más sencilla que no la de Zabbix, que requiere de múltiples configuraciones para poder monitorizar un elemento (el ítem en sí, su triger, el action asociado, la aplicación del ítem, etc.).
Un punto a favor de Zabbix es que parece que la comunicación cliente servidor no ocasionará los problemas que alguna vez me he encontrado con Nagios, de falsos positivos debidos a timeouts en la conexión SSH entre el servidor Nagios y el host a monitorizar (Nagios requiere de plugins adicionales para monitorizar vía NRPE).
A favor de Nagios, pero, está la gran cantidad de plugins que la comunidad ha puesto a nuestra disposición en Nagios Exchange, a primera vista mucho más completos que los plugins de Zabbix.
Componentes de Zabbix
Zabbix consta de un seguido de componentes que interaccionan entre sí:
- Zabbix agent: el agente (o cliente) de Zabbix se instala en aquellos elementos a monitorizar. El agente se encargará de recoger información del sistema y de las aplicaciones y se las hará llegar al Zabbix server. El Zabbix agent puede recoger datos:
- de forma pasiva: el server contacta al agente pidiéndole un dato (por ejemplo el consumo de CPU en ese instante) y el agente responde al server con ese dato.
- de forma activa: en un primer momento, el server le enviará al agente el listado de items a monitorizar. A partir de ese momento, será el agente que de forma periódica recogerá datos sobre esos ítems y se los hará llegar al server.
- Zabbix server: el servidor de Zabbix y por tanto la pieza principal. Consta de una base de datos, una interfaz web y el propio server. Como servidor, se encarga de recoger los datos de los agentes, calcular los triggers, enviar notificaciones, etc. El servidor por tanto, es el repositorio central donde están definidas las configuraciones y donde se almacenan todos los datos y estadísticas recogidos de los agentes.
- Proxy (opcional): se trata de un «recolector de datos» que se situa entre el servidor y los agentes. Si se tiene por ejemplo servidores repartidos en 5 datacenters, cada datacenter podría tener su propio proxy encargado de recoger los datos de los agentes de su datacenter, para posteriormente, hacerle llegar los datos al Zabbix server. Todo proxy requiere de su propia base de datos.
- Java Gateway (opcional): permite monitorizar aplicaciones JMX (Java Management eXtensions) como WildFly/JBoss, Tomcat, Weblogic o Websphere. Zabbix Java Gateway usa la «JMX Management API» para recoger los datos de las aplicaciones JMX remotas monitorizadas.
Fuentes:
https://www.zabbix.com/documentation/2.2/manual/concepts
¿Cómo podríamos saber si un fichero que está siendo subido por FTP ha acabado o no de subirse? Hay algunas posibles soluciones en