Ajuste preciso de la monitorización

La monitorización solo es realmente útil si es precisa. El mayor obstáculo para que tus compañeros (y probablemente tú mismo) la acepten son los falsos positivos —o, en pocas palabras, las Falsas alarmas.

Hemos visto cómo algunos principiantes en Checkmk han añadido muchos sistemas a la monitorización en poco tiempo, quizá porque es muy fácil hacerlo en Checkmk. Cuando poco después activaron las notificaciones para todos los usuarios, sus compañeros se vieron inundados con cientos de correos electrónicos al día, y al cabo de solo unos días su entusiasmo por la monitorización quedó prácticamente destruido.

Aunque Checkmk se esfuerza mucho por definir valores por defecto adecuados y sólidos para todos los ajustes posibles, simplemente no puede saber con suficiente precisión cómo deberían estar las cosas en tu entorno de TI en condiciones normales. Por lo tanto, se requiere un poco de trabajo manual por tu parte para lograr un ajuste preciso en la monitorización hasta que no se envíe ni una sola Falsa alarma. Aparte de eso, Checkmk también detectará bastantes problemas reales que ni tú ni tus compañeros habéis sospechado aún. Estos también deben solucionarse primero adecuadamente —¡en la realidad, no en la monitorización!

El siguiente principio ha demostrado su eficacia: primero la calidad, luego la cantidad; o, en otras palabras:

En las siguientes secciones sobre configuración, te mostraremos qué opciones de ajuste preciso tienes —para que todo lo que no cause problemas aparezca en verde— y cómo controlar cualquier caída ocasional.

Antes de empezar a configurar, primero debemos echar un vistazo rápido a los ajustes de los hosts y los servicios en Checkmk. Dado que Checkmk se desarrolló para entornos grandes y complejos, esto se hace mediante reglas. Este concepto es muy potente y también ofrece muchas ventajas para entornos más pequeños.

La idea básica es que no especifiques explícitamente cada parámetro de cada servicio, sino que implementes algo como:
«En todos los servidores Oracle de producción, los sistemas de archivos con el prefijo /var/ora/ que estén al 90 % de su capacidad recibirán el aviso WARN y, al 95 %, recibirán el aviso CRIT ».

Una regla así puede establecer umbrales para miles de sistemas de archivos con una sola acción. Al mismo tiempo, también documenta muy claramente qué directivas de monitorización se aplican en tu empresa.

Partiendo de una regla básica, puedes definir excepciones para casos individuales por separado. Una regla adecuada podría ser algo así:
«En el servidor Oracle srvora123, el sistema de archivos /var/ora/db01/, cuando esté lleno al 96 %, será WARN, y al 98 % será CRIT ».
Esta regla de excepción se configura en Checkmk de la misma manera que la regla básica.

Cada regla tiene la misma estructura. Siempre consta de una condición y un valor. También puedes añadir una descripción y un comentario para documentar el propósito de la regla.

Las reglas se organizan en conjuntos de reglas. Para cada tipo de parámetro, Checkmk tiene preparado un conjunto de reglas adecuado, por lo que puedes elegir entre varios cientos de conjuntos de reglas. Por ejemplo, hay uno llamado «Filesystems (used space and growth)» que establece los umbrales para todos los servicios que realizan la monitorización de sistemas de archivos. Para implementar el ejemplo anterior, tendrías que configurar la regla básica y la regla de excepción de este conjunto de reglas. Para determinar qué umbrales son válidos para un sistema de archivos concreto, Checkmk revisa secuencialmente todas las reglas válidas para la comprobación. La primera regla a la que se aplica la condición establece el valor —en este caso, el porcentaje en el que la comprobación del sistema de archivos pasa a ser «WARN» o «CRIT».

Tienes varias opciones para acceder a los conjuntos de reglas en Checkmk.

Por un lado, puedes encontrar los conjuntos de reglas en el menú «Setup» (Configuración > Reglas), bajo los temas de los objetos para los que existen conjuntos de reglas (Hosts, Services y Agents) en diferentes categorías. Por ejemplo, para los servicios hay las siguientes entradas de conjuntos de reglas: Service monitoring rules, Discovery rules, Enforced services, HTTP, TCP, Email, …​ y Other Services. Si seleccionas una de estas entradas, los conjuntos de reglas asociados aparecerán en la página principal. Pueden ser solo unas pocas o muchísimas, como en el caso de Service monitoring rules. Por eso, tienes la posibilidad de filtrar en la página de resultados, en el campo «Filter» de la barra de menú.

Si no estás seguro de en qué categoría se encuentra el conjunto de reglas, también puedes buscar entre todas las reglas de una sola vez, ya sea utilizando el campo de búsqueda del Menú de configuración o abriendo la página de búsqueda de reglas a través de Setup > General > Rule search. Seguiremos esta última ruta en la siguiente sección, en la que presentaremos el proceso de creación de reglas.

Dada la gran cantidad de conjuntos de reglas disponibles, no siempre es fácil encontrar el adecuado, con o sin búsqueda. Sin embargo, hay otra forma de acceder a las reglas adecuadas para un servicio existente. En una vista de tabla que incluya el servicio, haz clic en la opción de menú y selecciona la entrada Parameters for this service:

Aparecerá una página desde la que podrás acceder a todos los conjuntos de reglas de este servicio:

En la primera caja titulada «Check origin and parameters», la entrada «Filesystems (used space and growth)» te lleva directamente al conjunto de reglas para los umbrales de monitorización del sistema de archivos. Sin embargo, puedes ver en la Vista general que Checkmk ya ha establecido valores por defecto, por lo que solo necesitas crear una regla si quieres modificar esos valores por defecto.

¿Cómo es una regla en la práctica? La mejor manera de empezar es formular la regla que quieres implementar en una frase, así: En todos los servidores Oracle de producción, los tablespaces DW20 y DW30 que estén al 90 % de su capacidad tendrán el estado «WARN» y, al 95 %, el estado «CRIT».

A continuación, puedes buscar un conjunto de reglas adecuado; en este ejemplo, mediante la búsqueda de reglas: Setup > General > Rule search. Esto abre una página en la que puedes buscar «Oracle» o «tablespace» (sin distinción entre mayúsculas y minúsculas) y encontrar todos los conjuntos de reglas que contengan este texto en su nombre o en su descripción (no se muestra aquí):

El conjunto de reglas «Oracle tablespaces» se encuentra en dos categorías. El número que sigue al título (aquí, en todas partes, «0») indica el número de reglas que ya se han creado a partir de este conjunto de reglas.

En este ejemplo, no queremos la configuración de servicio forzada. Por lo tanto, haz clic en el nombre de la categoría «Service monitoring rules» para abrir la página de vista general del conjunto de reglas:

Este conjunto de reglas aún no contiene ninguna regla. Puedes crear la primera regla con el botón «Add rule». Al crear —y posteriormente realizar una edición— de esta regla, se abre un formulario con tres cajas: «Rule properties», «Value» y «Conditions». Vamos a ver cada uno de ellos por separado.

En la caja «Rule properties», todas las entradas son opcionales. Además de los textos informativos, aquí también tienes la opción de desactivar temporalmente una regla. Esto es práctico porque a veces puedes evitar borrar y volver a crear una regla si temporalmente no la necesitas.

Lo que encontrarás en la caja «Value» depende, en cada caso concreto, del contenido de lo que se está regulando:

Como puedes ver, puede haber bastantes parámetros. El ejemplo muestra un caso típico: cada parámetro individual se puede activar mediante una checkbox, y la regla solo se aplicará a ese parámetro. Puedes, por ejemplo, dejar que otro parámetro se determine mediante una regla diferente si eso simplifica tu configuración. En este ejemplo, solo se definirán los valores umbrales para el porcentaje de espacio libre en el tablespace.

La caja «Conditions» para establecer las condiciones parece un poco más confusa a primera vista:

En este ejemplo solo veremos los parámetros que necesitamos absolutamente para definir esta regla específica:

Con «Folder» (Ruta de acceso) se especifica en qué carpeta debe aplicarse la regla. Por ejemplo, si cambias la ruta predeterminada Main por Windows, la nueva regla se aplicará solo a los hosts ubicados directamente en la carpeta Windows o en subcarpetas de esta.

Los Host tags son una característica muy importante en Checkmk, por lo que les dedicaremos una sección aparte justo después de esta sección. En este punto, utiliza una de las etiquetas del host predefinidas para especificar que la regla solo se aplique a los sistemas productivos. Primero selecciona el grupo de tags de host Criticality de la lista, luego haz clic en Add tag condition y selecciona el valor Productive system.

En este ejemplo son muy importantes las condiciones «Explicit tablespaces», que restringen la regla a servicios muy específicos. Aquí hay dos puntos importantes:

Una vez completadas todas las entradas de la definición, guarda la regla con Save. Tras guardar, habrá exactamente una nueva regla en el conjunto de reglas:

Comprueba los valores de umbral para la monitorización de los sistemas de archivos y ajústalos si es necesario. Ya hemos mostrado brevemente los valores por defecto más arriba, en la búsqueda de reglas.

Por defecto, Checkmk toma los umbrales del 80 % para WARN y del 90 % para CRIT para el nivel de llenado de los sistemas de archivos. Ahora bien, el 80 % de un disco duro de 2 terabytes son, al fin y al cabo, 400 gigabytes; quizá sea un margen un poco excesivo para una advertencia. Así que aquí tienes algunos consejos sobre el tema de los sistemas de archivos:

Algunos servidores se reinician periódicamente, ya sea para aplicar parches o simplemente porque así debe ser. Puedes evitar falsas alarmas en estos momentos.

En Checkmk Community, primero defines un periodo de tiempo que cubra las horas en las que se reinicia el sistema. Puedes averiguar cómo hacerlo en el artículo sobre periodos de tiempo. A continuación, crea una regla en cada uno de los conjuntos de reglas «Notification period for hosts» y «Notification period for services» para los hosts afectados y selecciona allí el periodo de tiempo definido anteriormente. La segunda regla para los servicios es necesaria para que cualquier servicio que entre en «CRIT» durante este tiempo no active una notificación. Si se producen problemas dentro de este intervalo de tiempo —y también se resuelven dentro del mismo intervalo— no se activará ninguna notificación.

En las ediciones comerciales hay tiempos de mantenimiento programados regularmente para este fin que puedes configurar para cualquier host afectado.

No siempre es un problema que un ordenador esté apagado. Las impresoras son un ejemplo clásico. La monitorización con Checkmk tiene mucho sentido; algunos usuarios incluso organizan el reabastecimiento de tóner usando Checkmk. Por regla general, sin embargo, apagar una impresora antes de la hora de cierre no es un problema. Sin embargo, no tiene ningún sentido que, en ese momento, Checkmk envíe una notificación porque el host correspondiente a la impresora ha pasado a «DOWN».

Puedes indicarle a Checkmk que está perfectamente OK que un host se apague. Para ello, busca el conjunto de reglas «Host check command», crea una nueva regla y establece su valor en «Always assume host to be up»:

En la caja «Conditions», asegúrate de que esta regla solo se aplique a los hosts adecuados, dependiendo de la estructura que hayas elegido. Por ejemplo, puedes definir un tag del host y usarlo aquí, o puedes establecer la regla para una carpeta en la que se encuentren todas las impresoras.

Ahora, todas las impresoras se mostrarán siempre como «UP», independientemente de cuál sea su estado real.

Sin embargo, los servicios de la impresora seguirán checkándose, y cualquier timeout agotado daría lugar a un estado «CRIT». Para evitar esto también, configura una regla para los hosts afectados en el conjunto de reglas «Status of the Checkmk services», en la que establezcas los tiempos de timeout y los problemas de conexión en «OK» respectivamente:

Si realizas la monitorización de un switch con Checkmk, verás que, durante la configuración del servicio, se crea automáticamente un servicio para cada puerto del switch que esté UP en ese momento. Esta es una configuración predeterminada sensata para conmutadores centrales y de distribución, es decir, aquellos a los que solo están conectados dispositivos de infraestructura o servidores. Sin embargo, en el caso de los conmutadores a los que están conectados dispositivos finales, como estaciones de trabajo o impresoras, esto da lugar, por un lado, a notificaciones continuas si un puerto se desconecta y, por otro, a que se detecten continuamente nuevos servicios porque se activa un puerto que antes no estaba supervisado.

Hay dos enfoques que han demostrado su eficacia en estas situaciones. En primer lugar, puedes restringir la monitorización a los puertos uplink. Para ello, crea una regla para los servicios desactivados que excluya los demás puertos de la monitorización.

Sin embargo, el segundo método es mucho más interesante. Con este método supervisas todos los puertos, pero permites que el estado «DOWN» sea válido. La ventaja es que dispondrás de monitorización de errores de transmisión incluso para los puertos a los que están conectados dispositivos finales y, de este modo, podrás detectar muy rápidamente cables de parche defectuosos o errores en la negociación automática. Para implementar esta función, necesitas dos reglas:

El primer conjunto de reglas, «Network interface and switch port discovery», define las condiciones bajo las cuales se deben realizar la monitorización de los puertos del switch. Crea una regla para los switches deseados y selecciona si se deben detectar interfaces individuales (Configure discovery of single interfaces) o grupos (Configure grouping of interfaces). A continuación, en «Conditions for this rule to apply > Match port states», activa «2 - down» además de «1 - up»:

En la configuración de servicios de los switches, ahora también aparecerán los puertos en estado DOWN, y podrás añadirlos a la lista de servicios supervisados.

Antes de activar el cambio, aún necesitarás la segunda regla que garantiza que este estado se evalúe como «OK». Este conjunto de reglas se llama «Network interfaces and switch ports». Crea una nueva regla y activa la opción «Operational state», desactiva «Ignore the operational state» debajo de ella y, a continuación, activa los estados «1 - up» y «2 - down» para «Allowed operational states» (y cualquier otro estado que sea necesario).

Para algunos servicios que simplemente no se pueden configurar de forma fiable como «OK», es mejor no realizar la monitorización en absoluto. En este caso, podrías simplemente eliminar manualmente los servicios de la monitorización para los hosts afectados en el descubrimiento de servicios (en la página Services of host) configurándolos como «Disabled» o «Undecided». Sin embargo, este método es engorroso y propenso a errores.

Es mucho mejor definir reglas según las cuales determinados servicios no se realicen de forma sistemática tareas de monitorización. Para ello existe el conjunto de reglas «Disabled services». Aquí puedes, por ejemplo, crear una regla y especificar en la condición que los sistemas de archivos con el punto de montaje /var/test/ no se realicen tareas de monitorización por definición.

Puedes leer más información al respecto en el artículo sobre la configuración de servicios.

A menudo se generan notificaciones esporádicas debido a valores umbral en métricas de utilización —como la carga de la CPU— que solo se superan durante un breve periodo de tiempo. Por regla general, estos picos breves no suponen un problema y no deberían ser detectados por el sistema de monitorización.

Por este motivo, muchos check plugins tienen en su configuración la opción de promediar sus métricas durante un periodo de tiempo más largo antes de aplicar los umbrales. Un ejemplo de esto es el conjunto de reglas para la carga de la CPU en sistemas que no son Unix, llamado «CPU utilization for simple devices». Para ello existe el parámetro «Averaging for total CPU utilization»:

Si lo activas e introduces «15», la carga de la CPU se promediará primero durante un periodo de 15 minutos y solo después se aplicarán los valores de umbral a este valor promedio.

Cuando nada más funciona y los servicios siguen conectándose de vez en cuando a WARN o CRIT durante un solo intervalo de check —es decir, durante un minuto—, hay un último método para evitar falsas alarmas: el conjunto de reglas Maximum number of check attempts for service.

Si creas una regla en ese conjunto de reglas y estableces su valor en, por ejemplo, 3, un servicio que pasa de OK a WARN, por ejemplo, aún no activará una notificación y no se mostrará como un problema en Overview. El estado intermedio en el que se encontrará ahora el servicio se denomina soft state. Solo cuando el estado siga sin ser OK durante tres comprobaciones consecutivas —lo que supone una duración total de poco más de dos minutos— se notificará un problema persistente. Solo un hard state activará una notificación.

Hay que reconocer que esta no es una solución muy atractiva. Siempre debes intentar llegar al fondo de cualquier problema, pero a veces las cosas son como son, y con el número de intentos de check al menos tienes una forma viable de sortear este tipo de situaciones.

En cualquier centro de datos, el trabajo es constante, por lo que la lista de servicios de monitorización nunca se mantiene estática. Para asegurarte de que no se te escapa nada, Checkmk configura automáticamente un servicio especial en cada host; este servicio se conoce como «Check_MK Discovery»:

Por defecto, cada dos horas este servicio checkea si se han encontrado nuevos servicios —que aún no están sujetos a monitorización— o si se han eliminado servicios existentes. Si es así, el servicio pasa a «WARN». A continuación, puedes acceder al servicio de descubrimiento de servicios (en la página Services of host) y actualizar la lista de servicios a su estado actual.

Encontrarás información detallada sobre esta check de descubrimiento en el artículo sobre la configuración de servicios. Allí también podrás aprender cómo añadir automáticamente servicios no supervisados, lo que facilita mucho el trabajo en una configuración grande.

Continuar con varios usuarios