Las startups IT y empresas de éxito como Arista, Cloudera, Sonian, Etsy, Netflix, etc. usan - y crean - herramientas de monitoreo opensource de nueva tecnología, muy buenas, estables y confiables, apropiadas para mantener funcionando los sistemas de empresas muy exitosas o rumbo al éxito, pero no son muy populares, más que nada por desconocimiento.
¿Qué herramientas de monitoreo opensource se están usando en la "frontera"?
¿Qué es lo último que funciona bien en producción, soluciona problemas importantes, es seguro, estable, pero todavía no es un software de monitoreo popular (como Ganglia o Nagios)?
La homework es ver qué hace cada herramienta, de qué puede consumir y hacia donde puede publicar datos (cof cof Nagios cof cof).
OpenTSDB - Monitoreo con soporte de altas cargas (vía HBase/Hadoop)
http://www.slideshare.net/thecupoflife/opentsdb-in-a-real-enviroment
http://www.slideshare.net/geoffanderson/monitoring-mysql-with-opentsdb-19982758
http://www.slideshare.net/cloudera/4-opentsdb-hbasecon
Sensu
https://github.com/sensu
https://speakerdeck.com/joemiller/practical-examples-with-sensu-monitoring-framework
Graphite
http://graphite.wikidot.com/
http://graphite.readthedocs.org/en/1.0/tools.html
Logster - Generador de métricas desde Logs para Graphite y Ganglia
https://github.com/etsy/logster
Logstash - (fijáte la parte de "outputs" > Nagios, Ganglia, OpenTSDB, Graphite, Pagerduty, etc.)
http://logstash.net/docs/1.1.13/
(GUI para Logstash) - http://kibana.org/about.html
- Etc.
Mostrando entradas con la etiqueta monitoring. Mostrar todas las entradas
Mostrando entradas con la etiqueta monitoring. Mostrar todas las entradas
sábado, 3 de agosto de 2013
sábado, 15 de junio de 2013
Monitoreo básico de infraestructuras con software opensource
En el link del final hay una buena descripción de cómo monitorear infraestructuras con software opensource, bajo Linux mayormente (aunque varias se pueden correr bajo Windows Server).
Me inclino por las soluciones simples en gral., si es que son aplicables, y lo son en la mayoría de los casos, o al menos permiten obtener una prestación de monitoreo muy por encima de simplemente monitorear los servicios "a mano" (esperando que un cliente avise que hay problemas).
En sus configuraciones más rápidas, simples y por defecto en gral. las herramientas de abajo permiten:
- Nagios: monitoreo de servicios, envío de alertas (mail)
- MRTG: monitoreo de tráfico de red (no envía alertas)
- Ganglia: monitoreo avanzado de performance (no envía alertas)
- OpenNMS:
* Auto-discovery de equipos de red y servers,
* Permite y registra monitoreo simple vía ping para cualquier dispositivo en la red que tenga una dirección IP.
* Permite y registra monitoreo SNMP en dispositivos publicando SNMP (cualquier equipo de networking y servers deberían hacer esto).
* Envío de alertas por timeout en ping monitoring (mail)
- Cacti: (el que menos me gusta por cierto), básicamente nos permite ir agregando cualquier dispositivo de la red que soporte SNMP. El agregado es manual y no es demasiado intuitivo en gral., lo que dificulta la tarea cuando se trabaja con equipamiento "no estándar" para Cacti (casi cualquier cosa que no sea un device de red con SNMP o un server con un agente SNMP). Por ejemplo, algo que se puede complicar muy fácilmente de cargar en Cacti: un hipervisor ESX o un Hyper-V.
De todos modos, Cacti permite la configuración manual vía herramienta web del registro detallado y graficación de datos, algo que en MRTG, fuera de la configuración por defecto, exige trabajo manual. Por eso es bueno tener algo como Cacti funcionando en la red, listo para generar reportes si fuera necesario.
OpenNMS también tiene la posibilidad de generar reportes, pero van a ver que la configuración por defecto es limitada en cuanto a qué información registra y luego puede graficar. Por ejemplo, si queremos hacer gráficas de todos los puertos de un switch, aunque el switch esté bien configurado en SNMP, la configuración por default de OpenNMS solamente registra los parámetros globales del hardware, no el tráfico por puerto.
Customizaciones
Son inevitables para alcanzar integraciones útiles, por ejemplo:
- Lograr que Nagios alerte sobre picos de tráfico en determinados puertos de red de la infraestructura (típicamente, alertas de tráfico en puertos que mueven tráfico hacia/desde internet, y en horarios desusados, por ejemplo fines de semana en horario nocturno). Se debe integrar Nagios con Cacti o MRTG.
http://bigunix.blogspot.com.ar/2009/07/how-to-monitor-bandwidht-using-mrtg-and.html
http://nagioses.blogspot.com.ar/2009/03/monitoreando-routers-y-switches.html
http://nagios.sourceforge.net/docs/3_0/mrtggraphs.html
- Lograr que Nagios alerte sobre picos de consumo agregado de recursos de varios servidores en conjunto (Nagios en sí solamente va a alertar por picos de servidores individuales, por cierto). Se debe integrar Nagios con Ganglia.
http://sourceforge.net/apps/trac/ganglia/wiki/ganglia_nagios_integration
Las customizaciones no son exageradamente difíciles de lograr, inclusive están previstas en las mismas herramientas en varios casos. De todos modos, implican integrar el funcionamientod de una o más herramientas y para eso el funcionamiento individual ya debe ser óptimo.
Limitaciones
La limitación obvia actual de casi toda herramienta de monitoreo son los escenarios dinámicos.
Esa discusión es para otro artículo, pero en gral. la mayoría de los escenarios a monitorear son mayormente estáticos, excepto que hablemos de muy pocas organizaciones con infraestructuras altamente dinámicas, en las que - igualmente - las configuraciones básicas de las herramientas de arriba e incluso de muchas herramientas de software propietario de monitoreo, no son aplicables.
http://www.linuxscrew.com/2012/03/22/linux-monitoring-tools/
miércoles, 12 de junio de 2013
MRTG - Configuración rápida para Debian Wheezy
MRTG:
http://oss.oetiker.ch/mrtg/
Este procedimiento paso a paso sirve para el caso en que necesitamos empezar a monitorear rápidamente desde unos pocos a centenares de puertos físicos en equipamiento de red (switches, routers), y otros equipos (servidores, appliances varios, etc.), que publiquen información usando agentes SNMP.
Esos agentes deben ser configurados en los equipos a monitorear, esta tarea normalmente es muy fácil de hacer en equipamiento de red, se tarda algo más en configurar agentes en sistemas operativos y appliances (hay que instalar y configurar el servicio, probarlo).
La configuración por default de MRTG empieza a guardar información y a ordenarla de modo tal de disponer de datos diarios, semanales, mensuales y anuales por elemento monitoreado (interfaces físicas como puertos y lógicas como vlans, por ejemplo).
MRTG es sumamente mucho más potente que esta configuración básica, pero esa flexibilidad requiere mayor tiempo de análisis, planificación y configuración, lo que suele ir contra la necesidad de iniciar el acopio de información sobre el tráfico de red lo antes posible. Una plan alternativo sería montar muy rápido una infraestructura básica de acopio de información y en background iniciar el montaje de una infraestructura más refinada y específica.
Se puede usar MRTG en Linux, Windows, etc. más o menos con la misma simplicidad que muestra el procedimiento de abajo. Esta configuración es para Linux, Debian Wheezy.
Espero que les sea util.
Las fuentes, se las debo, básicamente es un tutorial ensamblado desde varias fuentes con un objetivo puntual: velocidad de implementación.
Pasos para configurar:
0) Configurar SNMP en server/equipo de red (esta configuración trabaja con la comunidad "public")
Cisco
http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a0080094aa4.shtml
http://www.netcraftsmen.net/resources/archived-articles/370-configuring-snmp-in-cisco-routers.html
Linux & Windows
http://juliorestrepo.wordpress.com/2012/06/27/configuracion-de-un-agente-snmp-en-linux-y-windows-metodo-julio-restrepo/
1) Instalar MRTG:
apt-get install mrtg
2) Ver si funciona agente snmp en cliente a agregar
snmpwalk -v 2c -c public IP-cliente
3) Crear configuracion
cfgmaker public@IP-cliente > /etc/mrtg-switch-ubicacion-nombre.cfg
4) Modificar WorkDir en .cfg y crear directorio
y apuntar a un subdir (para no mezclar los png/index de varios equipos)
* Este paso asume que vas a usar un directorio para los files generados para cada dispositivo/server que vas a monitorear. Por ejemplo, usando un subdirectorio:
mkdir /var/www/mrtg/switch-ubicacion-nombre/
5) Crear Index
indexmaker --title="Nombre-del-switch - IP-cliente - Modelo switch" --output /var/www/mrtg/switch-ubicacion-nombre/index.html /etc/mrtg-switch-ubicacion-nombre.cfg
*Este paso asume que tenés instalado un servidor web (apache por ejemplo), que publica archivos desde el directorio /var/www (En Debian, te haría falta crear el directorio mrtg y darle ownership al usuario www-data), así:
apt-get install apache2
mkdir /var/www/mrtg
chown -R www-data:www-data /var/www/mrtg
6) Correr mrtg para obtener datos iniciales
env LANG=C /usr/bin/mrtg /etc/mrtg-switch-ubicacion-nombre
7) Probar en Navegador y ver si dibuja bien los datos
8) Cargar a Crontab para que genere datos cada 5 min. y loguee información (un archivo por equipo):
"crontab -e" como root y agregar lo siguiente:
#
# Nombre-del-switch - IP-cliente - Modelo switch
#
*/5 * * * * root if [ -x /usr/bin/mrtg ] && [ -r /etc/switch-ubicacion-nombre.cfg ] && [ -d "$(grep '^[[space:]]*[^#]*[[:space:]]*WorkDir' /etc/mrtg-switch-ubicacion-nombre.cfg | awk '{ print $NF }')" ]; then mkdir -p /var/log/mrtg ; env LANG=C /usr/bin/mrtg /etc/mrtg-switch-ubicacion-nombre.cfg 2>&1 | tee -a /var/log/mrtg/mrtg-switch-ubicacion-nombre.log ; fi
http://oss.oetiker.ch/mrtg/
Este procedimiento paso a paso sirve para el caso en que necesitamos empezar a monitorear rápidamente desde unos pocos a centenares de puertos físicos en equipamiento de red (switches, routers), y otros equipos (servidores, appliances varios, etc.), que publiquen información usando agentes SNMP.
Esos agentes deben ser configurados en los equipos a monitorear, esta tarea normalmente es muy fácil de hacer en equipamiento de red, se tarda algo más en configurar agentes en sistemas operativos y appliances (hay que instalar y configurar el servicio, probarlo).
La configuración por default de MRTG empieza a guardar información y a ordenarla de modo tal de disponer de datos diarios, semanales, mensuales y anuales por elemento monitoreado (interfaces físicas como puertos y lógicas como vlans, por ejemplo).
MRTG es sumamente mucho más potente que esta configuración básica, pero esa flexibilidad requiere mayor tiempo de análisis, planificación y configuración, lo que suele ir contra la necesidad de iniciar el acopio de información sobre el tráfico de red lo antes posible. Una plan alternativo sería montar muy rápido una infraestructura básica de acopio de información y en background iniciar el montaje de una infraestructura más refinada y específica.
Se puede usar MRTG en Linux, Windows, etc. más o menos con la misma simplicidad que muestra el procedimiento de abajo. Esta configuración es para Linux, Debian Wheezy.
Espero que les sea util.
Las fuentes, se las debo, básicamente es un tutorial ensamblado desde varias fuentes con un objetivo puntual: velocidad de implementación.
Pasos para configurar:
0) Configurar SNMP en server/equipo de red (esta configuración trabaja con la comunidad "public")
Cisco
http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a0080094aa4.shtml
http://www.netcraftsmen.net/resources/archived-articles/370-configuring-snmp-in-cisco-routers.html
Linux & Windows
http://juliorestrepo.wordpress.com/2012/06/27/configuracion-de-un-agente-snmp-en-linux-y-windows-metodo-julio-restrepo/
1) Instalar MRTG:
apt-get install mrtg
2) Ver si funciona agente snmp en cliente a agregar
snmpwalk -v 2c -c public IP-cliente
3) Crear configuracion
cfgmaker public@IP-cliente > /etc/mrtg-switch-ubicacion-nombre.cfg
4) Modificar WorkDir en .cfg y crear directorio
y apuntar a un subdir (para no mezclar los png/index de varios equipos)
* Este paso asume que vas a usar un directorio para los files generados para cada dispositivo/server que vas a monitorear. Por ejemplo, usando un subdirectorio:
mkdir /var/www/mrtg/switch-ubicacion-nombre/
5) Crear Index
indexmaker --title="Nombre-del-switch - IP-cliente - Modelo switch" --output /var/www/mrtg/switch-ubicacion-nombre/index.html /etc/mrtg-switch-ubicacion-nombre.cfg
*Este paso asume que tenés instalado un servidor web (apache por ejemplo), que publica archivos desde el directorio /var/www (En Debian, te haría falta crear el directorio mrtg y darle ownership al usuario www-data), así:
apt-get install apache2
mkdir /var/www/mrtg
chown -R www-data:www-data /var/www/mrtg
6) Correr mrtg para obtener datos iniciales
env LANG=C /usr/bin/mrtg /etc/mrtg-switch-ubicacion-nombre
7) Probar en Navegador y ver si dibuja bien los datos
8) Cargar a Crontab para que genere datos cada 5 min. y loguee información (un archivo por equipo):
"crontab -e" como root y agregar lo siguiente:
#
# Nombre-del-switch - IP-cliente - Modelo switch
#
*/5 * * * * root if [ -x /usr/bin/mrtg ] && [ -r /etc/switch-ubicacion-nombre.cfg ] && [ -d "$(grep '^[[space:]]*[^#]*[[:space:]]*WorkDir' /etc/mrtg-switch-ubicacion-nombre.cfg | awk '{ print $NF }')" ]; then mkdir -p /var/log/mrtg ; env LANG=C /usr/bin/mrtg /etc/mrtg-switch-ubicacion-nombre.cfg 2>&1 | tee -a /var/log/mrtg/mrtg-switch-ubicacion-nombre.log ; fi
domingo, 19 de mayo de 2013
CentOS Dojo 2013
David Wesley, el "nubby admin" (el nombre de su blog), nos dejó un detallado live-blog del evento CentOS Dojo, donde participaron sysadmins que están manejando varias de las más interesantes infraestructuras del mundo (Pinterest, GetPantheon, etc.), y hablaron de DevOps y administración, a full. David nos deja los resúmenes de las charlas y queda en nosotros rastrear esas presentaciones por youtube, slideshare, y sitios similares (un par de "golpes" de google y listo).
Ah, Pinterest usa Ganglia, un favorito local en mi blog :-D
http://thenubbyadmin.com/2013/05/10/may-2013-centos-dojo-live-blogging-event/
sábado, 11 de mayo de 2013
Instalación y Configuración de Ganglia en Debian Wheezy 7.0
Este tutorial configura un servidor de monitoreo Ganglia y su interfaz web, y lo deja preparado para trabajar en modo multicast (es la configuración por defecto de Ganglia), luego de instalar el componente cliente de Ganglia en otros servidores, los datos se empiezan a recibir automáticamente en el servidor monitor.
Desde el punto de vista técnico, no realizamos en realidad ninguna configuración, simplemente se instala el software. El paso C) de configuración se realiza al solo efecto de darle un nombre al grupo de servers a monitorear.
La configuración de nombres en los servers - que realizamos durante la instalación en A) y B) - es necesaria para permitir una buena identificación de los hosts en la interfaz web.
Requerimientos
Dos instalaciones base de Debian Wheezy 7.0 terminadas (y actualizada opcionalmente), un cliente y un servidor.
Las IPs de los servidores van a ser obtenidas vía DHCP, de modo de simplificar el tutorial (es una buena práctica configurar los servers con IPs estáticas)
En este caso las IPs son:
- IP del servidor de monitoreo - 192.168.0.100
- IP del cliente de monitoreo - 192.168.0.105
Pasos para la Instalación y Configuración de Ganglia
A) Instalar cliente
B) Instalar server
C) Configurar server
Luego de este punto ya estamos en condiciones de replicar la instalación del cliente en otros servidores, y en minutos el server monitor Ganglia va a empezar a recibir los datos de monitoreo de esos nuevos servers cliente configurados.
Instalación del cliente Ganglia
1)
- Configurar /etc/hosts con los nombres de los servidores a monitorear.
127.0.0.1 localhost
127.0.1.1 monitor-cliente.local.net monitor-cliente
- Configurar /etc/hostname:
monitor-cliente
Luego reiniciamos el sistema.
2) Instalación del Cliente Ganglia:
apt-get install ganglia-monitor
Listo
3) Verificar que el servicio esté activo, corremos:
service ganglia-monitor restart
y tendría que ejecutar sin errores.
4) Obtenemos y guardamos la IP del server para asociarla estáticamente a un nombre en el server monitor:
ifconfig
Instalación del servidor Ganglia
1)
- Configurar /etc/hosts con los nombres de los servidores a monitorear.
127.0.0.1 localhost
127.0.1.1 monitor-server.local.net monitor-server
# servidores adicionales
#
# el nombre debe coincidir con el hostname
# configurado en el server mismo
192.168.0.100 monitor-cliente.local.net monitor-cliente
- Configurar /etc/hostname:
monitor-server
Luego reiniciamos el sistema.
2) Instalación del Server Ganglia (que incluye la instalación del cliente Ganglia > "ganglia-monitor" para poder monitorearse a sí mismo)
apt-get install ganglia-monitor ganglia-webfrontend gmetad
Aceptar o o no cuando pide reiniciar Apache no es relevante, cualquier opción va a funcionar igual (el script de post-instalación NO carga la configuración de Ganglia-web en Apache)
3) Activar sitio web Ganglia donde ver la información gráfica:
- Ir a /etc/ganglia-webfronted, localizar el .conf de Apache
- Crear un link simbólico del mismo en /etc/apache/conf.d
- Reiniciar Apache (service apache2 restart)
Listo, instalación terminada.
4) Verificar que los servicios estén activos, corremos:
service ganglia-monitor restart
service gmetad restart
y tendrían que ejecutarse sin errores.
Si miramos en la configuración de Apache en /etc/ganglia-webfrontend/apache.conf (activa en Apache con el link que creamos antes), vemos que Ganglia está en el directorio "ganglia" de nuestro webserver.
En un navegador probar Ganglia: http://192.168.0.105/ganglia
Configuración del Servidor Ganglia
1) Configurando Ganglia Fácilmente
- Ver la configuración en el archivo /etc/gmetad.conf (no editar nada)
data_source "My Cluster" localhost
2) Configurar en /etc/gmond.conf
name = "Taller"
y reiniciar servicio Gmond: service ganglia-monitor restart
Nos fijamos ahora en el Ganglia Web como cambió el nombre del cluster Ganglia de "unspecified" ("sin especificar"), a "Taller".
Luego de terminar esta configuración, ya vamos a ver cómo Ganglia empezó a tomar los datos del servidor cliente que acabamos de instalar, y en un par de minutos, solamente se ven los datos del server (localhost), y del cliente (debian-monitor-cliente).
* En el sitio Ganglia, el server debian-monitor-server se ve como "192.168.0.102", que es la IP de localhost para el server.
Soluciones de problemas comunes y Tips
Problema: gráficos que no aparecen (en versiones viejas de Ganglia)
Si para el servidor remoto hay problemas para graficar la información, lo agregamos manualmente al /etc/gmetad.conf del server monitor:
data_source "miservermonitor" localhost
data_source "miotroserver" 192.168.0.101
(los nombres usados en gmetad.conf para el data_source no son relevantes, no figuran en ningun gráfico, solo deben ser diferentes entre sí)
Problema: Hosts (servers) que no existen siguen apareciendo en los gráficos
Si vemos que luego de las pruebas, tenemos varios hosts "fantasma", resultado de haber reconfigurado un par de veces, vamos a reconfigurarlo para eliminar los servidores inexistentes de las gráficas.
Lo vemos claramente en la interfaz:
CPUs Total: 5
Hosts up: 3
(y tenemos configurados solamente 2 hosts)
a) Detenemos gmetad (service gmetad stop) en el server monitor.
b) Vamos al directorio donde se guardan las gráficas: /var/lib/ganglia/rrds
c) Borramos los directorios pertinentes (prestar atencion a los nombres y buscar los nombres de los hosts que no existen).
Tip: Correr una GUI Ganglia mejorada con versiones viejas de Ganglia.
Si nuestra distribución instala una versión vieja de Ganglia, la interfaz web va a ser la anterior a la actual. Se puede usar la interfaz actual (o actualizar manualmente la nueva cuando salgan nuevas versiones), con versiones viejas de Ganglia, sin problemas.
Para actualizar solo la interfaz, lo tenemos que hacer manualmente.
Las instrucciones de abajo configuran la interfaz actualizada en un directorio "/ganglia2" en el webserver, y así seguimos teniendo la interfaz anterior en "/ganglia" (es útil para evitar problemas al actualizar paquetes).
Instrucciones
1) Descargamos el código fuente más nuevo de Ganglia Web:
http://sourceforge.net/projects/ganglia/files/ganglia-web/3.5.2/
2) Instalamos requisitos (figuran en el readme):
apt-get install php-services-json
3) Crear un directorio para instalar allí los archivos de la interfaz actualizada (si usamos el directorio por defecto, va a sobreescribir la interfaz actual, instalada por los paquetes de la distribución):
mkdir /usr/share/ganglia-web-2
4) Descomprimir el archivo bajado en un directorio temporal.
5) Modificar el makefile, cargamos el directorio destino /usr/share/ganglia-web-2
DESTDIR = /usr/share/ganglia-web-2
y como usuario a www-data (el usuario de Apache para Debian):
APACHE_USER = www-data
luego corremos:
makefile install
6) Crear y activar la configuración para Apache:
cd /etc/apache2/conf.d/
touch apache-web2.conf
echo "Alias /ganglia2 /usr/share/ganglia-web-2" > apache2-web2.conf
service apache2 restart
Probamos yendo a la URL:
http:/IP/ganglia2
viernes, 10 de mayo de 2013
Taller de monitoreo de servidores con Ganglia
Mañana a las 14.00 hs. voy a dictar un taller de monitoreo de servidores con Ganglia, el lugar es la Facultad de Ciencias Exactas y Naturales (FACENA), UNNE, por 9 de Julio casi San Lorenzo (Corrientes, AR).
En el taller se va a mostrar como se instala y configura Ganglia para monitorear servidores, paso a paso (vamos a usar Debian Linux como sistema base). Para beneficio de los asistentes y los que no puedan ir, va a quedar disponible el tutorial en este blog (mi blog personal).
Acá podés ver la implementación - en producción, en la vida real - de Ganglia para monitorear la infraestructura de servidores (+900 servers al momento) Wikipedia > http://ganglia.wikimedia.org/
viernes, 3 de mayo de 2013
Estado del monitoreo opensource (al 2013)
Lo que hay en herramientas de monitoreo opensource, lo que funciona, lo que no funciona, lo ideal y que ya está disponible (pero no son tan populares como Nagios), por ejemplo: Graphite, Riemann, Logstash, Sensu, etc.
Linkeo una presentación reciente, donde un engineer con bastante experiencia (laburó en Heroku, ahora está en Github, etc.) en grandes infraestructuras, comenta cómo se monitorea grandes números de infra (centenares a miles de servers, alta carga, miles de usuarios, etc.), usando software opensource.
Cada slide, bien comentado.
https://speakerdeck.com/obfuscurity/the-state-of-open-source-monitoring
Linkeo una presentación reciente, donde un engineer con bastante experiencia (laburó en Heroku, ahora está en Github, etc.) en grandes infraestructuras, comenta cómo se monitorea grandes números de infra (centenares a miles de servers, alta carga, miles de usuarios, etc.), usando software opensource.
Cada slide, bien comentado.
https://speakerdeck.com/obfuscurity/the-state-of-open-source-monitoring
lunes, 18 de marzo de 2013
Training de Monitoreo; instrucciones paso a paso: JffNMS
Siguiendo con la promoción del curso de monitoreo que voy a estar dictando en abril, les copio uno de los instructivos de implementación paso a paso que voy a estar utilizando en el curso. En este caso vemos cómo se instala Jffnms.
Instalación de JffNMS en Debian
-------------------------------
Software: http://www.jffnms.org/
Demo: http://jffnms.enc.com.au/
user: admin
pass: admin
Documentación de soporte
- http://sourceforge.net/apps/mediawiki/jffnms/index.php?title=Linux_Installation
- /usr/share/doc/README.debian
1) apt-get install jffnms
2) Aceptar cuando el asistente ofrece configurar dbconfig-common (configura la DB automáticamente)
- Tener la contraseña de root de mysql
- Usar como contraseña de JffNMS, la cadena "jffnms" (ayuda en la instalación más tarde)
- La configuración de la DB estará en:
/etc/dbconfig-common/jffnms.conf
3) En /etc/jffnms encontramos el archivo de configuración para Apache, crear un enlace simbólico desde /etc/jffnms a /etc/apache2/conf./jffnms-apache.conf (ese sería el nombre del link):
ln -s /etc/jffnms a /etc/apache2/conf./jffnms-apache.conf
4) service apache2 restart
5) Entrar en http://server/jffnms
y
- verificar que el acceso a la DB esté en OK
- verificar qué herramientas no están en OK (para instalarlas si hace falta)
luego grabar
6) Al volver a entrar a http://server/jffnms
el user por default es admin, clave admin
Instalación de JffNMS en Debian
-------------------------------
Software: http://www.jffnms.org/
Demo: http://jffnms.enc.com.au/
user: admin
pass: admin
Documentación de soporte
- http://sourceforge.net/apps/mediawiki/jffnms/index.php?title=Linux_Installation
- /usr/share/doc/README.debian
1) apt-get install jffnms
2) Aceptar cuando el asistente ofrece configurar dbconfig-common (configura la DB automáticamente)
- Tener la contraseña de root de mysql
- Usar como contraseña de JffNMS, la cadena "jffnms" (ayuda en la instalación más tarde)
- La configuración de la DB estará en:
/etc/dbconfig-common/jffnms.conf
3) En /etc/jffnms encontramos el archivo de configuración para Apache, crear un enlace simbólico desde /etc/jffnms a /etc/apache2/conf./jffnms-apache.conf (ese sería el nombre del link):
ln -s /etc/jffnms a /etc/apache2/conf./jffnms-apache.conf
4) service apache2 restart
5) Entrar en http://server/jffnms
y
- verificar que el acceso a la DB esté en OK
- verificar qué herramientas no están en OK (para instalarlas si hace falta)
luego grabar
6) Al volver a entrar a http://server/jffnms
el user por default es admin, clave admin
lunes, 25 de febrero de 2013
Cómo hace el equipo de Operaciones para detener los problemas en sus vías
Traducción del original:
How the Technical Operations team stops problems in their tracks
Cómo hace el equipo de Operaciones para detener los problemas en sus vías
La semana pasada leías sobre como el equipo de operaciones técnicas de la Fundación Wikimedia ("Ops"), gastó centenares o miles de horas de trabajo para refactorizar y automatizar todos los servicios que provee, para prepararse para la migración de datacenter de Enero. Una recompensa de ese trabajo: nuestros sitios no estuvieron caídos tan a menudo, y cuando lo estuvieron, el downtime fue por buenos motivos.
"Otra cosa que ilustra nuestro crecimiento y madurez es nuestro downtime" dice el ingeniero de Operaciones Peter Youngmeister.
"Algo que es menos visible para la gente fuera de Ops es la clase de downtime que tenemos. Por ejemplo, ya no tenemos más el tipo "Oops, solté un cable" o "Ese server la palmó", porque las cosas son mucho más robustas ahora, mucho más redundantes. Un montón de eso es producto del masivo impulso a la automatización por el que pasamos, el cual nos permite crear redudancia mucho más fácilmente, y nos deja ocupar nuestro tiempo, en vez de estar "apagando incendios".
El ingeniero de la Fundación Wikimedia Roan Kattouw añade "o 'el server DB maestro tiene el disco lleno' - esa ocurrió unas pocas veces años atrás, y ya no ocurre más ahora."
Para arreglar las crisis rápidamente, necesitamos monitoreo: herramientas que automáticamente chequeen por problemas y alerten a nuestros ingenieros cuando algo está roto. En los primeros días de nuestros sitios, simplemente confiabamos en que habría algun sysadmin online y disponible en caso de que alguien notara algun problema y se quejara en IRC. Varios años atrás, comenzamos a usar Nagios para monitoreo y asignamos una rotación de "pagers", para decidir a quien despertar primero en caso de crisis.
Nagios corre test automatizados chequeando el comportamiento de nuestro sitio (como "¿Devuelve el puerto 80 un HTTP 301?"), y chequea ciertos números clave para asegurarse que los valores encontrados están dentro de un rango aceptable (por ejemplo, para testear y ver si nos estamos quedando sin memoria). Si un test falla, Nagios envía alarmas vía emails, IRC y SMS.
El monitoreo nos ayuda a manejar la crisis rápido, pero a menudo no ayuda a resolver el problema en sí.
"Nagios es grandioso para decirte cuando las cosas están rotas, y es basura para decirte por qué", explica Peter. "El trabajo que Asher Feldman ha realizado creando perfilado de datos (data profiling), es más útil".
Como lo explica Roan "Perfilado de datos es el acto de generar datos sobre 'Cuanto tiempo ha gastado la gran tarea X en realizar la subtarea Y' La razón para ello es que:
1) Uno de esos pequeños Ys podría en realidad no ser tan pequeño y ser un problema
2) Por la regla de 80-20, para algunos Ys, la optimización tendrá un impacto mayor, así que hace falta encontrarlos.
El perfilado de datos genera conocimiento acerca del comportamiento de nuestros sistemas, así los ingenieros pueden entender mejor como debería estar funcionando el cluster, y ofrece tips para resolver problemas.
Nosotros usamos dos sistemas de perfilado para obtener datos en tiempo-serie: Ganglia a nivel de host, y Graphite a nivel de aplicación. (conseguíte un login al Labs para ver Graphite). En los pasados dos años, configuramos Ganglia para cubrir muchos más datos, y en 2012 empezamos a usar Graphite. A mejores datos, se vuelve más útil para la resolución de problemas, y el Director de Operaciones CT Wook regularmente revisa el dashboard para ir viendo problemas por venir y alertar a su equipo. Esto reduce los downtimes.
Por ejemplo, en una página de Ganglia, previamente solo teníamos acceso a datos de host: espacio libre en disco, carga, etc. Recientemente añadimos datos específicos de Apache, como request por segundo y número de threads idle. Esta información adicional ayuda a los sysadmins en la resolución de problemas. "Uno puede verlo y hacer mejore deducciones que solo 'Oops, el server tiene mucha carga'," explica Peter.
Como la "puppetización", las mejoras en perfilado fueron una inversión del equipo de Operaciones. "Hay un plugin para Ganglia que arma estadísticas de performance de Apache. Me costó horas configurarlo totalmente, Pero, de vuelta, es pensar hacia adelante, una deuda que debemos honrar, en vez de insultarnos a nosotros mismos cuando no esté allí - esa información - cuando la necesitemos. Es un emprendimiento masivo decidir hacer las cosas del Modo Correcto, configurar una plataforma, en vez de hacer millones de cosas de 'una-sola-vez'."
Mientras que la "puppetización", mejora del monitoreo y perfilado, preparaban para la migración de datacenter, el equipo de Operaciones tuvo que diferir otros trabajos no urgentes. "Ops era menos capaz de dar soporte a muchos equipos", dice Peter, "por ejemplo, Recolección de Fondos solo tenía unos cuantos servers y podían hacer con ellos lo que quisieran, a diferencia de cómo es ahora donde Jeff Green (un ing. de operaciones), está trabajando en armar un asombroso sistema, PCI-compliant a tiempo completo. O Análisis era muy independiente/sin respaldo, porque había tan pocas horas/hombre para darles soporte que no estaban siquiera manteniendo el sitio activo..creo que el ensamble del EQIAD (el datacenter de Virginia), es muy demostrativo de la deuda técnica que tenía Ops."
Ahora Peter mira hacia adelante viendo a Wikimedia "instalar más datacenter, dramáticamente más rápido". El equipo de Operaciones está en preparativos para adicionar un datacenter en la costa oeste de Norteamérica. El Site Architech Asher Feldman ve un "arco continuado de refinamiento" en el futuro del equipo, en vez de "desafíos que terminan para ser reemplazados por nuevos desafíos". "Los desafíos en hacer escalar MediaWiki no van a dejar de existir a corto plazo, tampoco la necesidad de modernización incremental de la arquitectura en múltiples niveles". Por ejemplo, Ops necesita continuamente "puppetizar" ciertos servicios; algunos módulos también necesitan manifiestos Puppet tuneados para funcionar, no solo en el site principal, sino también en los Wikimedia Labs.
Podés chequear los objetivos del equipo de Operaciones para 2012-2013 y leer sobre lo que viene a continuación (incluyendo mejoras en búsquedas y seguridad).
Sumana Harihareswara, Engineering Community Manager
Copyright notes: NOLA Hackathon 20 by Ben Hartshorne, under CC-BY-SA 3.0 Unported, from Wikimedia Commons, Eqiadwmf 9045 by Rob Halsell, under CC-BY-SA 3.0 Unported, from Wikimedia Commons
How the Technical Operations team stops problems in their tracks
Cómo hace el equipo de Operaciones para detener los problemas en sus vías
La semana pasada leías sobre como el equipo de operaciones técnicas de la Fundación Wikimedia ("Ops"), gastó centenares o miles de horas de trabajo para refactorizar y automatizar todos los servicios que provee, para prepararse para la migración de datacenter de Enero. Una recompensa de ese trabajo: nuestros sitios no estuvieron caídos tan a menudo, y cuando lo estuvieron, el downtime fue por buenos motivos.
"Otra cosa que ilustra nuestro crecimiento y madurez es nuestro downtime" dice el ingeniero de Operaciones Peter Youngmeister.
"Algo que es menos visible para la gente fuera de Ops es la clase de downtime que tenemos. Por ejemplo, ya no tenemos más el tipo "Oops, solté un cable" o "Ese server la palmó", porque las cosas son mucho más robustas ahora, mucho más redundantes. Un montón de eso es producto del masivo impulso a la automatización por el que pasamos, el cual nos permite crear redudancia mucho más fácilmente, y nos deja ocupar nuestro tiempo, en vez de estar "apagando incendios".
El ingeniero de la Fundación Wikimedia Roan Kattouw añade "o 'el server DB maestro tiene el disco lleno' - esa ocurrió unas pocas veces años atrás, y ya no ocurre más ahora."
Para arreglar las crisis rápidamente, necesitamos monitoreo: herramientas que automáticamente chequeen por problemas y alerten a nuestros ingenieros cuando algo está roto. En los primeros días de nuestros sitios, simplemente confiabamos en que habría algun sysadmin online y disponible en caso de que alguien notara algun problema y se quejara en IRC. Varios años atrás, comenzamos a usar Nagios para monitoreo y asignamos una rotación de "pagers", para decidir a quien despertar primero en caso de crisis.
Nagios corre test automatizados chequeando el comportamiento de nuestro sitio (como "¿Devuelve el puerto 80 un HTTP 301?"), y chequea ciertos números clave para asegurarse que los valores encontrados están dentro de un rango aceptable (por ejemplo, para testear y ver si nos estamos quedando sin memoria). Si un test falla, Nagios envía alarmas vía emails, IRC y SMS.
El monitoreo nos ayuda a manejar la crisis rápido, pero a menudo no ayuda a resolver el problema en sí.
"Nagios es grandioso para decirte cuando las cosas están rotas, y es basura para decirte por qué", explica Peter. "El trabajo que Asher Feldman ha realizado creando perfilado de datos (data profiling), es más útil".
Como lo explica Roan "Perfilado de datos es el acto de generar datos sobre 'Cuanto tiempo ha gastado la gran tarea X en realizar la subtarea Y' La razón para ello es que:
1) Uno de esos pequeños Ys podría en realidad no ser tan pequeño y ser un problema
2) Por la regla de 80-20, para algunos Ys, la optimización tendrá un impacto mayor, así que hace falta encontrarlos.
El perfilado de datos genera conocimiento acerca del comportamiento de nuestros sistemas, así los ingenieros pueden entender mejor como debería estar funcionando el cluster, y ofrece tips para resolver problemas.
Nosotros usamos dos sistemas de perfilado para obtener datos en tiempo-serie: Ganglia a nivel de host, y Graphite a nivel de aplicación. (conseguíte un login al Labs para ver Graphite). En los pasados dos años, configuramos Ganglia para cubrir muchos más datos, y en 2012 empezamos a usar Graphite. A mejores datos, se vuelve más útil para la resolución de problemas, y el Director de Operaciones CT Wook regularmente revisa el dashboard para ir viendo problemas por venir y alertar a su equipo. Esto reduce los downtimes.
Por ejemplo, en una página de Ganglia, previamente solo teníamos acceso a datos de host: espacio libre en disco, carga, etc. Recientemente añadimos datos específicos de Apache, como request por segundo y número de threads idle. Esta información adicional ayuda a los sysadmins en la resolución de problemas. "Uno puede verlo y hacer mejore deducciones que solo 'Oops, el server tiene mucha carga'," explica Peter.
Como la "puppetización", las mejoras en perfilado fueron una inversión del equipo de Operaciones. "Hay un plugin para Ganglia que arma estadísticas de performance de Apache. Me costó horas configurarlo totalmente, Pero, de vuelta, es pensar hacia adelante, una deuda que debemos honrar, en vez de insultarnos a nosotros mismos cuando no esté allí - esa información - cuando la necesitemos. Es un emprendimiento masivo decidir hacer las cosas del Modo Correcto, configurar una plataforma, en vez de hacer millones de cosas de 'una-sola-vez'."
Mientras que la "puppetización", mejora del monitoreo y perfilado, preparaban para la migración de datacenter, el equipo de Operaciones tuvo que diferir otros trabajos no urgentes. "Ops era menos capaz de dar soporte a muchos equipos", dice Peter, "por ejemplo, Recolección de Fondos solo tenía unos cuantos servers y podían hacer con ellos lo que quisieran, a diferencia de cómo es ahora donde Jeff Green (un ing. de operaciones), está trabajando en armar un asombroso sistema, PCI-compliant a tiempo completo. O Análisis era muy independiente/sin respaldo, porque había tan pocas horas/hombre para darles soporte que no estaban siquiera manteniendo el sitio activo..creo que el ensamble del EQIAD (el datacenter de Virginia), es muy demostrativo de la deuda técnica que tenía Ops."
Ahora Peter mira hacia adelante viendo a Wikimedia "instalar más datacenter, dramáticamente más rápido". El equipo de Operaciones está en preparativos para adicionar un datacenter en la costa oeste de Norteamérica. El Site Architech Asher Feldman ve un "arco continuado de refinamiento" en el futuro del equipo, en vez de "desafíos que terminan para ser reemplazados por nuevos desafíos". "Los desafíos en hacer escalar MediaWiki no van a dejar de existir a corto plazo, tampoco la necesidad de modernización incremental de la arquitectura en múltiples niveles". Por ejemplo, Ops necesita continuamente "puppetizar" ciertos servicios; algunos módulos también necesitan manifiestos Puppet tuneados para funcionar, no solo en el site principal, sino también en los Wikimedia Labs.
Podés chequear los objetivos del equipo de Operaciones para 2012-2013 y leer sobre lo que viene a continuación (incluyendo mejoras en búsquedas y seguridad).
Sumana Harihareswara, Engineering Community Manager
Copyright notes: NOLA Hackathon 20 by Ben Hartshorne, under CC-BY-SA 3.0 Unported, from Wikimedia Commons, Eqiadwmf 9045 by Rob Halsell, under CC-BY-SA 3.0 Unported, from Wikimedia Commons
domingo, 24 de febrero de 2013
Review de Ganglia como solución de monitoreo de performance
Ganglia como solución de monitoreo tiene un solo objetivo: poder recolectar información útil sobre la performance general de los sistemas cliente, lo antes posible con mínima a nula necesidad de configuración del lado del cliente.
El escenario base para el cual fue creado Ganglia es monitorear miles de servidores que son creados, arrancados y apagados dinámicamente, por ende la necesidad de modificar manualmente la configuración está casi ausente de sus escenarios de deployment por defecto. Vean el apartado "WHO USES GANGLIA?" en la homepage:
http://ganglia.sourceforge.net/
Ganglia recolecta diversas informaciones de carga de los servidores monitoreados (CPU, espacio en disco, procesos, etc.), y no requiere modificar la configuración original en los clientes para esto, aunque tiene muchas posibilidades de configuración:
http://sourceforge.net/apps/trac/ganglia/wiki/TitleIndex
La idea básica es instalar el server, instalar el cliente, modificar muy poco los archivos de configuración y tener la recogida de datos funcionando.
Tiene una interfaz web muy simple y útil, también muy fácil de instalar, que accede directamente a a la represantación gráfica - realizada vía RRDD - de los datos recogidos.
Instalaciones típicas
El deployment por default basado en multicasting funciona exactamente así: se instala el servidor, se instala el cliente, no se tocan las configuraciones por defecto en los servers clientes(cero modificación a los archivos de configuración), se modifica, una sola línea en el servidor de monitoreo:
# /etc/gmetad.conf on monhost
data_source "MyCluster" monhost
y si la red permite el tráfico necesario por default (UDP/8649 y TCP/8649), en poco tiempo Ganglia va a empezar la recolección de información de los servers clientes monitoreados.
Hay tres escenarios adicionales de configuración: unicasting (necesario cuando hay servers a monitorear en redes diferentes), monitoreo de varios clusters (están explicados en el documento de abajo, y también el escenario de multicasting antes explicado):
http://sourceforge.net/apps/trac/ganglia/wiki/ganglia_quick_start
En la práctica si bien no es indispensable, sí se vuelve necesario realizar algo de configuración:
- Organizar los servers monitoreados en grupos (se hace modificando la configuración en los clientes)
- Bindear el servicio a una IP específica en un server (disponible para servidor y clientes)
- Configurar diferentes puertos aparte de los UDP y TCP 8649, para escuchar y enviar datos, recomendable cuando hay muchos hosts a monitorear (pero muchos).
Conclusiones
Ganglia funciona muy bien como solución de monitoreo de performance y recolección de datos para archivo, ya que luego de un tiempo de iniciada la recolección se puede ir viendo los datos por hora, por día, por semana, mes, etc.
No tiene las capacidades típicas - y necesarias - para funcionara como software de monitoreo+alerta de eventos, pero no tiene ese objetivo tampoco.
Ganglia resulta muy útil para realizar capacity assestment (CA) y poder justificar efectivamente la necesidad o no de recursos adicionales para los servidores. Combinando Ganglia con otro recolector de información SNMP como Cacti u OpenNMS se puede realizar un assestment *casi completo respecto de los recursos en existencia, su utilización actual, histórica y realizar inferencias potencialmente acertadas de las necesidades de infraestructura a futuro.
* Hay escenarios donde hay más software y hardware de infraestructura involucrado, por lo que un capacity assestment basado en consumo de recursos de hardware de servidores y networking no va proveer el ámbito completo de awareness necesario para una correcta asesoría.
Por ejemplo, en infraestructura virtualizadas basada en Vmware, para realizar CA se vuelve necesario software adicional como:
http://www.vmware.com/products/capacity-planner/overview.html
miércoles, 20 de febrero de 2013
Testeo rápido de monitoreo opensource, update de capabilities al 2013
Fue una semana movida hasta ahora, estuve re-analizando el status de diferentes soluciones de monitoreo basado en soft opensource, y desde el lunes estuve deployando Nagios, Icinga, Ganglia, Cacti, OpenNMS y Zabbix, y estoy instalando Sensu ahora mismo.
Las viejas quejas de todos los que usamos soft de monitoreo desde hace años se hacen muy evidentes al trabajar con todo ese software.
Básicamente OpenNMS es lo que mejor funcionó out-of-the-box, llevando solamente un par de horas la primer instalación+configuración completa (la 1ra. fue la de prueba también), y luego con un par de clicks, un auto-discovery barrió muy bien un rango detectando los dispositivos de mi red prueba. Configurar thresholds y la mensajería fue un poco más trabajoso, otra hora de trabajo, leyendo un poco una documentación bastante confusa y más confusos mails de pedidos de ayuda de usuarios y respuestas vagas. Claro, la solución era bastante simple e intuitiva...luego de haberla hecho funcionar la primera vez. Básicamente funciona bastante bien, pero es un poco inestable en el sentido de que deployar plugins y adicionales rápido - vía apt por ejemplo - no va a terminar siempre en un OpenNMS completamente estable, y se puede llegar a tener un servicio funcionando perfectamente durante horas luego de instalar plugins, y luego al primer reinicio del sistema, algo triggerea una falla en el arranque, y los mensajes de error son básicamente el volcado del output de la Java VM, y pocas veces contienen información útil para hacer la recuperación (el "profile" de respuesta de los foros/listas apunta mucho a que los users avanzados de OpenNMS están muy familiarizados con identificar "partes" de la configuración del soft a modificar/arreglar mirando directamente el volcado de la JVM, más que a buscar/encontrar esa información en alguna documentación).
Por ejemplo, al instalar el plugin de monitoreo de DHCP, configurarlo, y luego desinstalarlo, dejó al software incapaz de arrancar por la falta de los binarios para arrancar el servicio, en este caso fue con suerte y el mensaje de error indicaba claramente que el fallo se debía a que no podía arrancar el servicio de monitoreo de DHCP, y la solución era simplemente volver a comentar el servicio en el file de configuración correspondiente (y así desactivar el intento de arrancarlo al inicio de OpenNMS).
Cacti fue muy fácil de instalar, el uso de Cacti es tan sencillo que casi nadie se preocupó por crear tutoriales de cómo agregar un dispositivo y llegar a generar (y ordenar), las gráficas; pero.."sencillo" no implica que sea totalmente intuitivo, y estuve una buena media hora jugando con la GUI hasta entender el workflow para agregar dispositivos y generar la información gráfica, motivo base para deployar Cacti (de todos modos, al parecer, OpenNMS está generando "exactamente" la misma información, pero claro, hay que navegar varios menúes hasta encontrarla, en Cacti se la tiene a la vista luego del login directamente).
Ganglia es desde siempre mi primer opción para levantar información de performance y uso de servers, principalmente porque se instala muy rápido, no requiere más que instalar el soft servidor, el soft cliente, y "engancharlos" mediante configuración (hay que decirle al soft cliente, al agente ganglia en el server a monitorear, cual es su - o sus - server a aceptar en comunicaciones). Luego de instalar Ganglia y dejarlo tomando información, me puse a revisar la demás opciones y a medio camino de estar bastante decidido a implementar OpenNMS y Cacti, Ganglia ya tenía perfiles gráficos armados de mis sistemas de testing.
A Zabbix lo instalé en minutos (y un par de agentes también), y la GUI si bien es muy atractiva, no es tan intuitiva como la de OpenNMS (que no es demasiado intuitiva tampoco), de todos modos ubiqué la capability de auto-discovery y triggereé un rápido discovery, que no llegó a captar ni un solo dispositivo en el mismo rango de red que había cargado dos horas antes en OpenNMS (y donde este último soft detectó perfectamente mis servers y dispositivos de prueba, datos snmp incluídos). Así que fui de la GUI a la documentación sin encontrar mayor explicación del procedimiento de agregado - "intuitivo" - de dispositivos, de ahí fui buscar en foros y listas de correo, sin encontrar nada de vuelta, supongo que es algo tan fácil que nadie se molestó en escribir un paso-a-paso, así que dejé Zabbix funcionando y sin configurar por ahora (hasta encontrar cómo agregar dispositivos). Igualmente, a cada golpe de Google no dejo de encontrar las recomendaciones de que Zabbix es "muy fácil", supongo que se refieren a la instalación, pero tengo que dedicarle más de los 20 minutos que le dediqué para poder concluir algo sobre el software (y poder cargar al menos un par de dispositivos de prueba). Si llega a funcionar, podría tener un poco más de utilidad que OpenNMS inclusive.
Nagios (e Icinga, en mi primer contacto con el soft, utilicé mi expertise en Nagios y lo pude configurar/administrar sin issue alguno, así que la portabilidad de skills la puedo confirmar) es lo que dejé para probar al final, es una tentación el querer a producción el soft más fácil de configurar y más rápido de deployar, ello no siempre significa que el software sea razonablemente fácil de administrar en el día a día (bah, en el caso de Nagios ES fácil de administrar), y/o que escale muy bien siquiera a mediano plazo.
Nagios no escala nada bien en ambientes dinámicos, donde los servers suben y bajan de producción constantemente, y la medida básica de esto es implementar nagios para monitorear ambientes en clouds, sin embargo, si implementas Nagios en ambientes virtualizados, rápidamente verás como solo tus servers en producción y estables son permanentemente monitoreados, mientras que los demás servers que son arrancados y apagados dinámicamente, inclusive aunque estén en producción, lentamente van quedando atrás mientras las configuraciones de Nagios solo se dedican a controlar los servers que están funcionando continuamente, sin downtimes dinámicos.
Aparte está la tentación de integrar Nagios+Cacti, RRDD+Nagios, Nagios+lo que sea, una solución que rápidamente va a dejar de reflejar correctamente el verdadero perfil de performance total de ambientes virtualizados, claro, a menos que elijas manejar la arquitectura de modo que tus servers "fijos" en producción están siempre funcionando en determinados hipervisores y los demás, en producción pero dinámicamente arrancados/apagados y los de testing (que se crean y borran regularmente), quedan limitados a otros hipervisores.
Mmm, hay un problema en que justamente, la posibilidad de utilizar las capacidades ociosas en los hipervisores es la razón para virtualizar en principio, así que "limitar" el foco de la infraestructura virtualizada porque un(1) software no tiene capabilities para "seguir" el dinamismo de la infra virtual es quitarle capabilities en exceso a la solución de virtualización. Consideren por ejemplo que esa limitación se potencia radicalmente cuando los servers corren en infras virtualizadas con configuraciones complejas (las que definen jerarquías para el apagado dinámico de VMs en hipervisores bajo determinados perfiles de performance, por ejemplo).
Claro, Nagios puede ser "adaptado" a escenarios dinámicos, pero esa misma configuración va a ser estática (básicamente se podría "jugar" con schedulear downtimes programados que coincidan con los downtimes estimables que van a tomar las VMs cuando la infra virtualizada apague los servers), con el resultado de que por un lado configuramos la infra virtual para que se adapte automáticamente y por el otro lado tenemos que lidiar con (re)adaptar manual/continuamente la configuración del software de monitoreo para los servers.
Casi nada de estas conclusiones es nuevo (vean los links de monitoring-sucks), ni tampoco utilizar software comercial es la solución (tiene las mismas limitaciones para adaptarse a infraestructuras dinámicas en general), y no es que no suceda lo mismo con el resto del software que probé: OpenNMS, Cacti, Ganglia, etc.
Me falta testear Groundwork y HypericHQ (similar a Zabbix, comerciales, pero opensource o freeware al menos), y ver que tal se comportan. Me resulta curioso como las páginas de todos los software de monitoreo que se venden dicen que son los mejores o algo similar :-D > "Monitoring The World's Largest Web Applications"
Al rearrancar la semana voy a testear Sensu y ver cual es su perfil de adaptación a escenarios dinámicos, ya que hay bastante material en la red prometiendo mucho a este respecto:
Planeo escribir algo (cuando tenga la experiencia práctica), de Sensu - en español - para que al menos alguien que googlee desde LATAM/ES "sensu" a corto plazo al menos encuentre algo de material en español y de 2013 entre los primeros hits.
Links:
Suscribirse a:
Entradas (Atom)