Durante enero tuve la oportunidad de invertir tiempo de I+D en el desarrollo de una solución de monitoreo que tenía en mente hace tiempo.
En total diseñé e implementé - en entornos de testing - cuatro arquitecturas diferentes, funcionales al 100%, efectivas en la resolución del problema de nuestros clientes al 100%, de las cuales solo una llegó a la instancia de convertirse en un producto. La penúltima resultó ser el mejor enfoque y por ende fue refinada en la que resultó ser una cuarta arquitectura finalmente.
Todas las arquitecturas se basan por completo en software opensource por los múltiples beneficios y ventajas que ello acarrea desde el punto de vista técnico y de negocios.
La primer arquitectura que desarrollé para la Solución de Monitoreo se basó por completo en herramientas opensource Devops de monitoreo, me gusta llamarlas "de 3ra. generación".
La 1ra. generación de herramientas de monitoreo opensource fue la implementación de Nagios original - de los 90 hasta mediados de la década del 2000 - sus software accesorios y derivados opensource comerciales (Zenoss, Zabbix, incluídos etc.); y siempre incluyendo componentes accesorios importantes, como RRDTool (usado en la tremenda herramienta MRTG, también de 1ra. generación).
La 2da. generación está representada por los diversos forks de Nagios* y las reimplementaciones de las ideas de Nagios en nuevas arquitecturas e ideas de cómo hacer monitoreo en software opensource, y allí tenemos principalmente a Icinga y los miles de plugins que fueron codeados en hasta esa época y que integrados a Nagios (u otro core similar), podían recrear el sistema de monitoreo hasta que prácticamente no era Nagios realmente.
Otras nuevas herramientas importantes surgidas de la 2da. generación incorporaron funcionalidades importantes, intentando suplir las obvias carencias de las herramientas de la 1ra. generación: Ganglia, Munin, OpenNMS, etc.
* Para ser precisos, la versión comercial de Nagios sumó características que la versión opensource no incorporó, y por ello desde más o menos esa época, la versión comercial de Nagios técnicamente podría considerarse una herramienta de monitoreo de 2da. generación, pero no es opensource por completo.
La 3ra. generación de herramientas de monitoreo estaba representada por aquellas herramientas devops nacidas de la conjunción de varias circunstancias del momento, que abarca desde 2010 hasta 2013, en este momento histórico ocurre:
- La aparición y adopción masiva de infraestructuras virtuales (vmware, xen, hyper-v, kvm, etc.); en paralelo casi, aparecen las infraestructuras de nube pública (amazon), y después privada (vmware, openstack, etc.).
- La aparición de la filosofía organizativa de infraestructuras llamada "Devops" fundada en la práctica por IT guys de nuevas startups de ese período y en gral. en sus iniciativas importantes de adopción profunda de infraestructura basadas en cloud y en la necesidad de información de monitoreo detallada, masiva, superando ampliamente las capacidades de casi todas las herramientas de monitoreo opensource de 2da. generación.
- Surge la meme #monitoringsucks que se basa en la opinión más o menos popular de que las herramientas opensource disponibles en ese momento, alrededor de 2010, no son capaces realmente de asumir el desafío impuesto por el avance tecnológico ocurrido en tecnologías de infraestructura.
Estas herramientas son un avance evolutivo de la 2da. generación, adaptadas plenamente a la tendencia masiva en adm. de sistemas opensource a usar software de configuration management (Puppet, Chef, Ansible, SaltStack, etc.), software de virtualización diverso (Vagrant, plataformas SaaS, clouds PaaS, etc.), y tienen la habilidad de poder producir ingentes cantidades de información extrapolando automáticamente los datos obtenidos del monitoreo contínuo, generando casi al vuelo valiosa información de inteligencia de negocios.
Las herramientas que representan la 3ra. generación se caracterizan por tener varios representantes moderadamente estables, de "referencia", que liberan versiones y mejoras regularmente, además de diversas reimplementaciones de código realizadas por los muchos interesados, apuntando a lograr especializaciones muy específicas (y muy interesantes muchas), que no cuadrarían como para ser incorporadas al código de "referencia" de las herramientas.
Todas ellas son en gral. muy estables, desarrolladas pensando en necesidades y requerimientos de negocios (hay startups que se basan por completo en sus herramientas de monitoreo TIENEN que funcionar MUY bien), validadas mediante peer-review y/o por su uso intensivo dentro de infraestructuras de misión crítica, incluyendo en background la publicación de documentación técnica detallada vía GitHub y posteos detallados de las experiencias, casos de uso y resolución de problemas relacionados con ese software en los blogs de los adoptantes (inclusive blogs de ingeníería oficiales de las empresas).
