¿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
JBoss es un Servidor de Aplicaciones Java completo, de código abierto, desarrollado por Red Hat. Y sí, yo también pienso en Apache Tomcat en estos momentos, pero hay diferencias entre ellos explicadas por ejemplo 
Si contamos con un servidor Apache, quizá nos interese pasarlo a nginx con el menor downtime posible. Yo he hecho alguna prueba partiendo del siguiente entorno:
Hace ya unos años, y sin ningún software de administración tipo Puppet/Chef/Ansible, creamos un documento para que todos los técnicos pudieran decir la suya respecto a los pasos a dar tras instalar un sistema operativo Linux (CentOS en nuestro caso), con tal de no olvidarnos ninguno e ir mejorando entre todos este proceso de configuración inicial de un servidor. Eso significa que si tú, amado lector, tienes cualquier sugerencia de mejora, no dudes en dejarla en los comentarios.
Otro post que tenía en borradores y que he decidido rescatar. Esta vez sobre hardware, con comandos tan básicos como útiles.
Ya vimos cómo 
Últimamente he estado leyendo sobre cómo y cuando actualizar un servidor Linux (Fedora/CentOS/Red Hat en mi caso), de cara a aplicar los últimos parches de seguridad y mantener el sistema actualizado. Resulta que no soy el único que se pregunta sobre si hay algún tipo de guía, recomendaciones, o mejores prácticas para updatear sistemas.
Es muy posible que queramos tener un control de usuarios y permisos en nuestro repositorio git centralizado, si por ejemplo, tenemos a varios equipos de varios desarrolladores trabajando cada uno con un repositorio diferente. Afortunadamente, existen varias soluciones a este problema pero yo me he quedado con 
Maldet