Monitorización de OpenShift

Dado que los clústeres de OpenShift también pueden sufrir cambios importantes muy rápidamente en cuanto al número y la ubicación de los componentes individuales, te recomendamos crear un site de Checkmk independiente para realizar la monitorización de un entorno de OpenShift. Este se puede conectar al site central como de costumbre mediante el procedimiento de monitorización distribuida.

Checkmk realiza la monitorización de tus clústeres de OpenShift de dos maneras:

En primer lugar, debes configurar un namespace y una cuenta de servicio para Checkmk en tu clúster de OpenShift. La forma más rápida de hacerlo es a través de la CLI de OpenShift (oc, para abreviar).

En el siguiente ejemplo, llamaremos a esta namespace checkmk-monitoring. Si quieres o necesitas elegir un nombre diferente, también tendrás que hacer este cambio al crear la cuenta de servicio.

La cuenta de servicio, junto con su rol asociado y el denominado RoleBinding, se puede crear especificando nuestro archivo YAML ya preparado y publicado en GitHub. Check su contenido y, a continuación, ejecuta el siguiente comando:

Como alternativa, puedes descargar primero este archivo YAML, personalizarlo según tus necesidades y, a continuación, aplicar oc apply -f a esta copia local del archivo.

Con la herramienta de línea de comandos oc ahora también puedes leer toda la información de tu clúster, que normalmente tendrás que especificar para configurar el agente especial. Si has cambiado el nombre de la cuenta de servicio o el namespace, debes editar esta información tal y como se describe para los siguientes comandos.

Lo mejor es guardar la contraseña (token) de la cuenta de servicio en el almacén de contraseñas de Checkmk. Esta es la opción más segura, ya que te permite separar el almacenamiento y el uso de la contraseña de forma organizada. Como alternativa, puedes introducir la contraseña directamente en texto sin formato al crear la regla (ver más abajo).

Para añadir la contraseña al almacén de contraseñas de Checkmk, ve a Setup > General > Passwords > Add password. En nuestro ejemplo, usamos My OpenShift Token como ID y título:

Para que Checkmk confíe en la cadena de certificados de la cuenta de servicio, tendrás que almacenarla en Checkmk. Copia todo lo que hay aquí —incluidas las líneas que contienen BEGIN CERTIFICATE y END CERTIFICATE— y añade el certificado en el Menú de configuración, en «Setup > General > Global settings > Site management > Trusted certificate authorities for SSL»:

Crea un nuevo host en Checkmk como de costumbre y asígnale un nombre, por ejemplo, «myopenshiftclusterhost». Tal y como sugieren el título y el nombre del host, este host se utiliza para recopilar los datos piggyback y también para realizar el mapeo de todos los servicios y métricas a nivel de clúster. Dado que este host recibe datos exclusivamente a través del agente especial, en las propiedades del host asegúrate de establecer la opción «IP address family» en «No IP». Confirma toda esta configuración pulsando el botón «Save & view folder».

Para garantizar la separación entre objetos de diferentes clústeres de Kubernetes, suele ser conveniente crear una carpeta por clúster a través de Setup > Hosts > Add folder, en la que la administración dinámica del host pueda crear automáticamente todos los hosts de un clúster. Sin embargo, crear y usar dicha carpeta es opcional.

A continuación, configura una conexión para los datos piggyback entrantes. Para ello, ve a Setup > Hosts > Dynamic host management > Add connection. Primero introduce un título y, a continuación, en «Connection Properties», haz clic en «show more».

El siguiente paso, muy importante, es introducir el host piggyback creado anteriormente en «Restrict source hosts».

A continuación, en «Piggyback creation options», haz clic en «Add new element» y, en «Create hosts in», selecciona la carpeta creada anteriormente.

Puedes dejar los atributos predeterminados en «Host attributes to set» tal y como están. Estos garantizan que Checkmk solo acepte los datos piggyback de los hosts creados automáticamente y no intente hacer ping a estos ni acceder a ellos a través de SNMP, por ejemplo.

En un entorno OpenShift, donde los objetos monitorizables y monitorizados van y vienen continuamente, suele recomendarse habilitar también la opción Automatically delete hosts without piggyback data. Qué hace exactamente esta opción y en qué circunstancias se eliminan realmente los hosts se explica en el capítulo sobre la eliminación automática de hosts del artículo sobre la administración dinámica del host.

Por último, activa la opción «Discover services during creation».

La sección «Connection Properties» de esta nueva conexión podría tener el siguiente aspecto:

Por defecto, Checkmk realiza un descubrimiento de servicios cada dos horas y muestra el resultado de este descubrimiento en el servicio «Check_MK Discovery». Puedes encontrar esta configuración en el conjunto de reglas «Periodic service discovery». En el contexto de OpenShift, recomendamos crear una regla con la etiqueta «cmk/kubernetes:yes» para todos los hosts. Esto se debe a que cada host que representa objetos de Kubernetes recibe automáticamente esta etiqueta de Checkmk. En este caso, deberías elegir un intervalo más corto que dos horas para el descubrimiento de servicios y activar también la opción «Automatically update service configuration». Los ajustes de la siguiente captura de pantalla son solo ejemplos. Tendrás que decidir qué es lo más adecuado para tus clústeres caso por caso.

Para restringir esta regla a todos los hosts de tu clúster, en «Host labels» (Configuración de reglas) simplemente introduce «cmk/kubernetes:yes» en el campo «Conditions» (Label del host). Sin embargo, si también quieres crear reglas diferentes para distintos clústeres, solo tienes que usar aquí la etiqueta específica del clúster correspondiente. Estas etiquetas siempre tienen el formato «cmk/kubernetes/cluster:mycluster».

Ahora que ya se han creado todos los requisitos previos en el clúster y en Checkmk, puedes centrarte en la configuración del agente especial. Puedes acceder a ella a través de Setup > Agents > VM, cloud, container > Kubernetes. Crea una nueva regla con Add rule.

En primer lugar, debes asignar un nombre al clúster que se va a realizar la monitorización. Este nombre se puede especificar libremente según se desee. Se utiliza para asignar un nombre único a todos los objetos que provienen de este clúster específico. Por ejemplo, si introduces aquí mycluster, los nombres de los hosts de todos los pods de este clúster comenzarán posteriormente por pod_mycluster. La siguiente parte del nombre del host será entonces siempre el namespace en el que existe este objeto de Kubernetes. Por ejemplo, el nombre del host de un pod podría ser entonces pod_mycluster_kube-system_svclb-traefik-8bgw7.

En Token, selecciona ahora la entrada creada anteriormente en el almacén de contraseñas de Checkmk.

En API server connection > Endpoint, Checkmk te pide ahora que introduzcas la URL a través de la cual se puede contactar con tu servidor API de Kubernetes. El puerto solo es necesario si el servicio no se proporciona a través de un host virtual. Aquí, introduce la dirección que determinaste en la sección Obtener el endpoint de la API de Kubernetes.

Si hasta ahora has seguido estas instrucciones paso a paso y has —tal y como se ha descrito anteriormente— depositado el certificado CA de tu clúster en Checkmk, entonces, en «SSL certificate verification», selecciona «Verify the certificate».

Activa la opción «Enrich with usage data», selecciona «Use data from OpenShift» en el menú siguiente e introduce el «Prometheus API endpoint» que determinaste en la sección «Recuperar el endpoint de la API de Prometheus».

La lista que aparece en «Collect information about…​» te permite seleccionar qué objetos de tu clúster deben ser objeto de monitorización. Esta lista incluye los objetos más relevantes. Si también decides realizar la monitorización del «Pods of CronJobs», consulta la ayuda en línea de esta opción.

Las dos selecciones siguientes te permiten acotar aún más los objetos que se van a monitorizar. Si solo te interesan los objetos de determinados espacios de nombres, configúralo en consecuencia en «Monitor namespaces». Aquí puedes introducir espacios de nombres concretos que se vayan a monitorizar o excluir explícitamente espacios de nombres concretos de la monitorización.

La opción «Cluster resource aggregation» te permite designar nodos que no proporcionan recursos para la carga de trabajo de tu clúster. Estos nodos deben excluirse del cálculo de los recursos disponibles. De lo contrario, existe el riesgo de que no se detecten cuellos de botella en la capacidad. Por lo tanto, por defecto excluimos del cálculo los nodos control-plane y infra.

Como última opción, puedes importar las llamadas anotaciones de Kubernetes. En Checkmk, estas anotaciones se convierten en host labels y, por lo tanto, pueden utilizarse posteriormente como condiciones en las reglas. Utiliza expresiones regulares para especificar qué anotaciones deben importarse. Consulta de nuevo la ayuda en línea detallada en este punto.

Nota: La opción «Import all valid annotations» se incluye aquí solo para completar la información. No recomendamos importar todas las anotaciones de una sola vez, ya que esto puede generar una gran cantidad de etiquetas inútiles en Checkmk.

Importante: En «Conditions > Explicit hosts» debes introducir ahora el host creado anteriormente:

A continuación, guarda la regla y realiza un descubrimiento de servicios para este host. Los primeros servicios a nivel de clúster aparecerán aquí de inmediato:

Ahora activa todos los cambios que has realizado y deja que la administración dinámica del host se encargue del trabajo a partir de ahora. Esto generará todos los hosts para tus objetos de Kubernetes en un periodo de tiempo corto.

Las ediciones comerciales de Checkmk incluyen seis paneles integrados para Kubernetes. Para poder interpretar estos paneles, es necesario tener instalado y configurado nuestro Colector del clúster. Concretamente, estos paneles se llaman:

El punto de entrada es siempre el dashboard de Kubernetes, al que puedes acceder a través de Monitor > Applications > Kubernetes:

En el panel de control de Kubernetes, todos tus clústeres de monitorización aparecen en la parte izquierda. Esta lista de clústeres es también tu punto de entrada para profundizar en los dashboards. Al hacer clic en el nombre de un clúster, accederás al dashboard de Kubernetes Cluster correspondiente al clúster seleccionado. En el dashboard de Kubernetes Cluster, al hacer clic en el nombre correspondiente, accederás a los demás dashboards dependientes del contexto:

La monitorización de OpenShift con Checkmk también admite el inventario de HW/SW. Por ejemplo, en el dashboard del clúster anterior, al hacer clic en el nombre del ID del clúster (aquí: mycluster) accederás al inventario del clúster.

De la misma manera, es decir, en los otros dashboards a través de las cajas con los nombres de identificación de los objetos, se puede mostrar el inventario de HW/SW de cada objeto respectivo. El siguiente ejemplo muestra el inventario de HW/SW de un pod:

Si has usado nuestro archivo YAML predeterminado para crear la cuenta de servicio, también puedes eliminarla de la siguiente manera: