Esta es una pregunta canónica sobre el software de monitoreo.
También relacionado: ¿Qué herramienta utiliza para monitorear sus servidores?
Necesito monitorear mis servidores; ¿Qué debo tener en cuenta al decidir una solución de monitoreo?
monitoring
Kyle Brandt
fuente
fuente
Respuestas:
Hay muchas soluciones de monitoreo por ahí. Todos tienen sus preferencias y cada negocio tiene sus propias necesidades, por lo que no hay una respuesta correcta. Sin embargo, puedo ayudarlo a descubrir qué es lo que desea buscar al elegir una solución de monitoreo.
¿Para qué sirven los sistemas de monitoreo?
En general, los sistemas de monitoreo tienen dos propósitos principales. El primero es recopilar y almacenar datos a lo largo del tiempo. Por ejemplo, es posible que desee recopilar la utilización de la CPU y graficarla con el tiempo. El segundo propósito es alertar cuando las cosas no responden o no están dentro de ciertos umbrales. Por ejemplo, es posible que desee alertas si pings no puede llegar a un determinado servidor o si la utilización de la CPU está por encima de un cierto porcentaje. También hay sistemas de monitoreo de registros como Splunk, pero los estoy tratando por separado.
Estas dos funciones principales a veces vienen en un solo producto, otras veces y más común es tener un producto dedicado a cada propósito.
¿Cuáles son los componentes y características principales en los sistemas de monitoreo?
Encuestadores :
todos los sistemas de monitoreo necesitan algún tipo de encuestador para recopilar los datos. No todos los datos se recopilan de la misma manera. Debe observar su entorno y decidir qué datos necesita y cómo se pueden recopilar. Luego, asegúrese de que el sistema de monitoreo que elija sea compatible con lo que necesita. Algunos métodos comunes incluyen:
Si tiene principalmente un sistema operativo en su entorno o un sistema operativo primario, ciertos sistemas pueden tener más opciones que otros.
Configuración :
en los sistemas de monitoreo, suele haber una gran cantidad de reutilización de objetos. Por ejemplo, desea monitorear una determinada aplicación como Apache o IIS en un grupo de servidores. O desea que ciertos umbrales se apliquen a grupos de servidores. También puede tener ciertos grupos de personas para estar "de guardia". Por lo tanto, un buen sistema de plantillas es vital para un sistema de monitor.
La configuración generalmente se realiza a través de una interfaz de usuario o archivos de texto. La opción de interfaz de usuario generalmente será más fácil, pero los archivos de texto tienden a ser mejores para la reutilización y las variables. Entonces, dependiendo de su personal de TI, puede preferir la simplicidad sobre el poder.
Interfaz de usuario : la interfaz
más común para sistemas de monitoreo en estos días es una interfaz web. Algunas cosas para evaluar con respecto a la interfaz web son:
Motor de alerta :
el motor de alerta debe ser flexible y confiable. Hay muchas formas diferentes de ser notificado, incluyendo:
Otras características a buscar son:
Es importante confiar en que cuando algo sale mal, recibirá la alerta. Esto se reduce a dos cosas:
Almacenamiento de datos :
si el sistema recopila y almacena datos (es decir, sistemas que incluyen gráficos), el sistema almacena datos. Una implementación muy común tanto para la tienda como para la representación gráfica es RRD, por ejemplo.
Algunas características para buscar en el almacén de datos son:
Biblioteca de
gráficos : los gráficos pueden ser útiles para identificar rápidamente tendencias y dar contexto al estado actual de algo en función de su historial. Algunos incluyen tendencias que pueden ser útiles para predecir cosas antes de que sucedan (es decir, quedarse sin espacio en disco). Asegúrese de que los gráficos le brinden la información que cree que va a necesitar de manera clara.
Controles de acceso :
si tiene una organización grande, es posible que necesite controles de acceso porque ciertos administradores solo deberían poder ajustar ciertas cosas. También es posible que desee paneles públicos de cara. Si esto es importante, debe asegurarse de que el sistema de monitoreo tenga los controles que necesita.
Otras características
Informes :
un sistema que proporciona buenos informes puede ayudarlo a identificar qué necesita mejorar durante largos períodos de tiempo. Por ejemplo, puede dar una buena respuesta a cosas como "¿qué sistemas fallan más?". Esto puede ser importante cuando intentas convencer a la gerencia para que gaste dinero en ciertas cosas, como pruebas contundentes de negocios.
Características especializadas :
Algunos sistemas de monitoreo están dirigidos a productos específicos o tienen más soporte que otros. Por ejemplo, si lo principal que necesita monitorear es el servidor SQL, o si hace un uso intensivo de los productos VMWare, debería ver qué tan bien son compatibles.
Plantillas de monitoreo predefinidas :
un sistema que viene con muchas plantillas predefinidas (o tiene una base de usuarios que ha creado muchas plantillas) puede ahorrar mucho tiempo.
Descubrimiento :
si tiene un entorno grande o cambiante. Algunos sistemas ofrecen la posibilidad de agregar nuevos sistemas a través de una API o ejecutar análisis para encontrar nuevos servidores o componentes.
Monitoreo distribuido:
si tiene varias ubicaciones para monitorear, puede ser útil tener sondeos de monitoreo en cada ubicación en lugar de que muchos sistemas independientes estén monitoreando a través de la WAN.
Algunos sistemas de monitoreo populares
Hay muchos sistemas de monitoreo por ahí. Tenemos una lista con un resumen de esta vieja pregunta . Para una referencia rápida, algunas de las que más escucho son:
Cómo decidir en base a lo anterior
La razón por la que no puedo decirte qué usar es porque cada organización tiene sus propias necesidades. Si desea tomar la decisión correcta, debe pensar en todos los componentes anteriores y descubrir qué características son importantes para su organización. Luego, encuentre un sistema o sistemas que afirmen proporcionar lo que necesita y pruébelos. Algunos de estos cuestan un poco, mucho o son gratis. Teniendo todo eso en cuenta, puede hacer su elección. Por lo que he usado, están lejos de ser perfectos, pero al menos puedes intentar conseguir algo que se ajuste.
fuente
Es útil distinguir entre monitoreo y alertas. Monitorear significa recolectar datos y hacer gráficos. Alertar significa enviarme un SMS cuando un servidor se cae en medio de la noche.
Nagios es para alertar. Cacti y Munin son para monitorear. Otros productos combinan las dos funciones. Zenoss y Zabbix son ejemplos.
Comenzaría respondiendo algunas preguntas:
¿Necesita monitorear servidores, dispositivos de red, aplicaciones o los tres?
¿Existen limitaciones sobre qué métodos puede usar para monitorear? ¿Puede instalar clientes de monitoreo como NRPE en los servidores, o usará SNMP, o tal vez ambos?
¿Quién usará los gráficos y quién usará las alertas? ¿Cómo le gustaría que se viera el resultado final? ¿Importa la apariencia de la interfaz (la gente de negocios usará esto o solo el personal técnico?)
¿Cuáles son sus recursos, tanto en términos de tiempo, habilidades y hardware? ¿Tiene al menos una modesta capacidad de secuencias de comandos? ¿Necesita una solución lista para usar?
En mi opinión, la primera regla de alerta y monitoreo debería ser Keep it Simple! Una organización puede vivir o morir en la forma en que alerta y recopila datos, y la mayoría de las veces se complicará por sí sola de todos modos. Comience con lo básico y construya desde allí.
fuente
tl; dr
Piense en los servicios que proporciona su software , envíe alertas cuando estos servicios fallen o cuando aumente el riesgo de falla de estos servicios.
Acuerdos de Nivel de Servicio
La teoría detrás de las estrategias de monitoreo es vincular el monitoreo y las alertas con algún tipo de acuerdo de nivel de servicio . Después de todo, desea ser alertado del hecho de que está perdiendo dinero, no necesariamente de que haya un aumento en la cantidad de conexiones TCP a nji0019.myserver.com. Existen varias herramientas que le darán toneladas de alertas, definirán dependencias entre alertas, pero muchas de estas comprobaciones no son directamente relevantes para el servicio que le brinda a alguien.
Incumplimiento de servicio
Identifique los servicios importantes que proporciona, como la capacidad de servir un sitio web y la capacidad de modificar ese sitio web (por ejemplo, un CMS de algún tipo). Deben verificarse (por ejemplo, controlando que puede obtener la página web y que puede). La falla de estos dos Servicios (usados aquí con una S mayúscula) debería activar una alerta para notificarle.
Si es importante que el sitio responda dentro de un período de tiempo razonable, eso también debería activar alertas. Una especie de "incumplimiento de SLA", por así decirlo.
Aumento del riesgo
Por lo general, existe el riesgo inherente de que falle un Servicio, y con la suficiente frecuencia ese riesgo se mitiga por el hecho de que introduce redundancia, por ejemplo, un segundo servidor o una base de datos esclava, o tarjetas de red adicionales ...
Cuando se pierde esa redundancia, el Servicio aún está bien, pero el riesgo de que el Servicio falle aumenta.
Esta es la segunda razón principal para activar alertas; esa redundancia se ha ido (por ejemplo, que el segundo servidor murió), o que existe un peligro inminente de que el riesgo aumente (por ejemplo, al disco solo le quedan 500 Mb, o la tendencia del disco indica que el disco se llenará en aproximadamente 5 horas).
¿Qué pasa con todos esos indicadores?
Pero check_mk me da 50-60 cheques por host, ¿son todos inútiles?
No. Todo esto no significa que desee deshacerse de la gran cantidad de comprobaciones automáticas que obtiene, por ejemplo, check_mk, pero significa que debe tratar de clasificar cada una de las comprobaciones en qué Servicio (s) podrían verse afectados si algo falla.
¿Qué servicio se vería afectado si la partición / var / se llena? ¿Qué servicio se vería afectado si la interfaz eth0 está inactiva? ... si las conexiones TCP salientes están bloqueadas por algún firewall? ... si el número de hilos supera los 800? ... si la base de datos se cae?
Ejemplo
Tiene 2 servidores web y un servidor de base de datos que sirve a un sitio detrás de un equilibrador de carga que no es de su propiedad (por ejemplo, el ISP). El servicio que proporciona es el puerto 80 en los dos servidores, y tienen enormes cachés que pueden sobrevivir, por ejemplo, el tiempo de inactividad de la base de datos (base de datos en un tercer servidor).
En este escenario, la falla completa de un servidor web no daría lugar a la caída del sitio. Lo que sucedió es que la redundancia desapareció, por lo que el riesgo de falla aumentó. Eso debería desencadenar una alerta.
La falla completa de la base de datos podría no afectar la capacidad de servir el sitio en absoluto, debido a los cachés bien ajustados en su lugar; Esto no afecta el Servicio de servir el sitio web, pero puede afectar a un Servicio diferente, es decir, actualizar el sitio web o aceptar pedidos ...
Cada servicio tendría su propio nivel de servicio que designa lo importante que es restaurar el servicio o evitar interrupciones
Se ágil
Cada vez que reciba una alerta, debe realizar una de las siguientes acciones: - cambiar el sistema que se está monitoreando para solucionar el problema que causó la alerta (por ejemplo, reemplazar la unidad o reconfigurar logrotate o algo así) - cambiar el sistema de monitoreo para evitar que se active la alerta enviado la próxima vez que surge esa situación. (por ejemplo, cambie los niveles de "disco libre" para que el disco pueda llenar hasta el 90% en lugar de solo el 80%)
Mi propia experiencia
Estoy familiarizado con Nagios y su configuración detallada, y desde entonces me he enganchado en el sitio múltiple de Check-mk. Recientemente aprendí que check_mk tiene este concepto de Business Intelligence (desde 1.11) que parece coincidir bien con este pensamiento. Puede definir que las comprobaciones en nagios son parte de un servicio más grande y tienen reglas que definen el estado del "Servicio" como una función del estado de muchas comprobaciones, que se agregan al peor o mejor estado.
fuente
Uno de los puntos más críticos que las empresas olvidan al elegir una solución de monitoreo es que no se trata solo de resolver problemas operativos inmediatos, ¡se trata de los problemas imprevistos del mañana! Quiero decir, por supuesto, resolver problemas inmediatos es importante, pero confía en mí, en muchos casos esta estrategia miope no garantizará la supervivencia de una empresa.
Hay docenas de excelentes soluciones de monitoreo en el mercado. Hacer una lista corta de un pequeño conjunto de soluciones que satisfagan sus requisitos es una tarea larga y difícil, además, encontrar una que se ajuste a su presupuesto es aún más difícil. La parte interesante es encontrar uno que esté alineado con su presente y su futuro . Y no hay un proceso de evaluación para detectar eso, es una cuestión de experiencia + intuición + un factor muy importante: la confianza , que no es algo fácil de hackear .
Como regla general, busque y busque historias de éxito de su conjunto de soluciones de monitoreo preseleccionadas, especialmente si afecta a una empresa de su sector. Pídale al vendedor sus historias de éxito e incluso pídales permiso para hablar con uno de sus clientes. Las empresas que no tienen miedo de este programa muestran que tienen relaciones reales con sus clientes, y no lo ocultan, y esto es algo extremadamente raro de encontrar hoy en día.
Zabbix, Icinga, Pandora FMS, op5, Datadog, New Relic ... todos tienen sus altibajos, pero el verdadero problema es encontrar cuál se adapta mejor a su futuro.
fuente
Si está considerando la monitorización remota del sistema, puede ser una buena idea buscar las ubicaciones reales desde las que se realizan las pruebas. Los problemas de conectividad no son cosa del pasado y si su hardware está sirviendo a un grupo en una región específica, es posible que desee asegurarse de que sus recursos estén disponibles en esa ubicación en particular.
fuente