1. Introducción
Checkmk incluye un amplio módulo para la monitorización de Microsoft Azure, que consiste en un conector a Azure y una completa colección de check plugins que recuperan y evalúan diversas métricas y estados para ti.
Además de la información general sobre los costes en los que incurre tu entorno Azure y el estado actual de los servicios Azure en tu región, puedes monitorizar los siguientes productos Azure con todas las ediciones de Checkmk:
Con Checkmk Cloud también puedes incluir los siguientes productos en tu sistema de monitorización:
Puedes encontrar una lista completa de todos los check plugin disponibles para la monitorización de Microsoft Azure en nuestro Catálogo de check plugin y describimos cómo incluir tus clústeres AKS (Azure Kubernetes Service) en Checkmk en el artículo Monitorización de Kubernetes.
 |
This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved. |
2. Preparar Azure para Checkmk
2.1. Crear la aplicación
Para monitorizar Azure con Checkmk, necesitarás tu ID de suscripción y tu ID de inquilino (también conocido como "ID de directorio").
En primer lugar, registra la monitorización de Checkmk como una app para que puedas trabajar con la API de Azure. La opción para ello se encuentra en el portal de Azure en Microsoft Entra ID > Manage > App registrations > New registration:
Asigna un nombre de tu elección. En el ejemplo utilizamos my-check-mk-app. Este nombre es sólo informativo. La referencia a la app en sí se hace en realidad a través de un UUID que verás en un paso posterior. No es necesario que cambies nada en la sección Supported account types. La configuración de Redirect URI es opcional.
Tras la creación, selecciona la nueva app de la lista de apps. Si no aparece en la lista, consulta Selecciona My apps en All apps. En los detalles de la app también encontrarás el Application (client) ID que necesitarás más adelante. El Object-ID no es necesario.
2.2. Asignar permisos a la app
Para que tu nueva app tenga derechos de acceso a los datos de monitorización, debes asignarlos aquí. A la izquierda de la página principal de navegación, selecciona el item All resources y, a continuación, selecciona Subscriptions:
En la navegación de esta página ve a Access Control (IAM) y selecciona Add, y Add role assignment:
Ahora, en rol introduce Reader, en Assign access to selecciona el valor Azure AD user, group, or service principal, e introduce el nombre de tu nueva app en la opción Select:
2.3. Crear una clave para la app
Ahora necesitas una clave (un secreto) con la que Checkmk pueda iniciar sesión en la API. Puedes crear una clave en la configuración de la app, en Certificates & secrets. Simplemente haz clic en New client secret en la sección Client secrets.
En la siguiente ventana, Microsoft quiere que introduzcas un nombre de tu elección en el campo Description. Aquí hemos elegido my-check-mk-key. No olvides seleccionar el marco temporal correcto para tus necesidades en la opción Expires.
La configuración en Azure ya está completa, y ahora deberías tener los cuatro datos siguientes:
Tu ID de suscripción
Tu ID de inquilino (también conocido como "ID de directorio").
El ID de la aplicación (ID de cliente) para la app my-check-mk-app
El secreto de la clave my-check-mk-key para esta app
Si no tienes a mano tu ID de inquilino, encuéntralo pasando el ratón sobre tu nombre de inicio de sesión en el tooltip de Directory:
Puedes ver el ID de suscripción, por ejemplo en Cost Management + Billing bajo My subscriptions.Nota: Actualmente Microsoft no muestra este ID como un hash, sino como un nombre legible por humanos. Puedes utilizar este nombre de nuevo estilo de la forma habitual.
3. Configuración de la monitorización básica en Checkmk
3.1. Crear un host para Azure
Aunque no estés tratando con un host físico en Azure, crea un host para tu directorio de Azure en Checkmk. El nombre del host puedes definirlo a voluntad.Importante: como Azure es un servicio y, por tanto, no tiene dirección IP ni nombre DNS (el agente especial realiza el acceso por sí mismo), debes configurar el IP address family en No IP.
Es mejor guardar con Save & Finish en este punto, porque, por supuesto, el descubrimiento de servicios aún no puede funcionar.
3.2. Configurar el agente de Azure
Como Azure no se puede consultar a través del agente Checkmk normal, ahora debes configurar el agente especialde Azure, que también se conoce como programa de fuente de datos. En esta situación, Checkmk no contacta con el host de destino a través del puerto TCP 6556 como es habitual, sino que llama a una utilidad que se comunica con el sistema de destino a través de la API específica de la aplicación de Azure.
Para ello, en Setup > Agents > VM, Cloud, Container > Microsoft Azure crea una regla cuyas condiciones se apliquen exclusivamente al host Azure que acabas de crear. Allí encontrarás los campos de entrada para los ID y el secreto:
Aquí también puedes seleccionar los grupos de recursos o recursos que quieres monitorizar. Si no has marcado explicitly specified groups, todos los grupos de recursos se monitorizan automáticamente.
3.3. Probando
Si ahora realizas un descubrimiento de servicios en el host Azure, sólo debería detectarse un único servicio llamado Azure Agent Info:
Si el acceso a la API no funciona (debido a un ID incorrecto o a malos permisos, por ejemplo), aparecerá un mensaje de error de la API de Azure en el texto de estado de Azure Agent Info:
3.4. Hacer que los grupos de recursos estén disponibles como hosts
Para mayor claridad, la monitorización de Azure en Checkmk se ha diseñado de modo que cada grupo de recursos de Azure esté representado por un host lógico (por así decirlo) en Checkmk. Esto se hace con la ayuda de un procedimiento piggyback. Este piggyback tomará los datos del host de Azure utilizando agentes especiales, y dentro de Checkmk los redirigirá a estos hosts de grupos de recursos.
Los hosts de grupos de recursos no aparecen automáticamente en Checkmk. Coloca estos hosts manualmente u opcionalmente con el daemon de configuración dinámica (DCD). Importante: al hacerlo, los nombres de los hosts deben coincidir exactamente con los nombres de los grupos de recursos, ¡y esto también distingue entre mayúsculas y minúsculas! Si no estás seguro de la ortografía exacta de los nombres de los grupos, puedes hacerlo directamente desde el servicio Azure Agent Info en el host Azure.
Por cierto, con el script auxiliar find_piggy_orphans del directorio de tesoros encontrarás todos los host piggyback de los que existen datos, pero que aún no se han creado como host en Checkmk:
OMD[mysite]:~$ share/doc/check_mk/treasures/find_piggy_orphans
Glastonbury
WoodstockConfigura los host del grupo del recurso sin dirección IP (análogo al host Azure), y selecciona No API integrations, no Checkmk agent como agente y Always use and expect piggyback data como piggyback.
Si ahora realizas un descubrimiento de servicios en uno de estos hosts de grupo de recursos, verás que hay servicios adicionales que se refieren específicamente a este grupo de recursos:
 |
Si quieres elegir libremente los nombres de los hosts de los grupos de recursos, con la regla Setup > Agents > Access to Agents > Hostname translation for piggybacked hosts puedes definir una conversión de grupos de recursos en hosts. |
4. Configuración avanzada
4.1. Máquinas virtuales (VM)
Cuando utilizas Azure para monitorizar máquinas virtuales que sirven simultáneamente como hosts normales en Checkmk, puedes asignar los servicios de Azure asociados a esas máquinas virtuales directamente a los hosts de la máquina virtual en Checkmk, en lugar de a los hosts del grupo de recursos.
Para ello, en la regla de Azure, en la opción Map data relating to VMs, selecciona la configuración Map data to the VM itself. Para que esto funcione, el host Checkmk de la VM en monitorización debe tener exactamente el mismo nombre que la VM correspondiente en Azure.
4.2. Costes de monitorización
La regla Microsoft Azure está preconfigurada para que Checkmk también monitorice todos los costes incurridos en tu entorno Azure. En concreto, los servicios muestran los costes incurridos el día anterior. De este modo, puedes determinar rápidamente si se han producido cambios.
Se crean varios servicios para obtener una mejor visión general de dónde se han producido exactamente los costes y poder establecer umbrales específicos. Los costes totales a nivel de tu directorio de Azure se muestran para el host de Azure que hayas creado en primer lugar. Además, se crean servicios para cada host que represente un grupo de recursos. En ambos niveles, Checkmk genera un servicio para los costes por el denominado "proveedor de recursos" (por ejemplo, microsoft.compute y microsoft.network). El servicio Costs Summary muestra entonces la suma total para el grupo de recursos o para todo el directorio de Azure.
Puedes utilizar la regla Azure Usage Details (Costs) para definir umbrales individuales para todos estos servicios.
Si no deseas monitorizar los costes, debes desactivar la opción Usage Details en la regla Microsoft Azure.
4.3. Límite de tarifa para consultas API
Actualmente, las consultas a la API que Checkmk necesita para la monitorización de Azure (a diferencia de AWS) son gratuitas; sin embargo, existe un límite en el número de consultas permitidas por periodo de tiempo (el "Límite de tarifa"). Por ID de aplicación, el límite es de 12.000 peticiones de lectura por hora.
Debido a la estructura de la API, Checkmk requiere al menos una o más consultas por recurso solicitado, por lo que el número total de consultas aumenta linealmente con el número de recursos monitorizados. Si se alcanza o supera el límite de consultas, la consulta falla con un código HTTP 429 (demasiadas solicitudes), y el servicio Check_MK para el host Azure se marca como CRIT.
Este límite de consultas es el resultado del llamado algoritmo "token bucket" de Azure. Todo comienza con que tienes un "crédito" de 12.000 consultas restantes -cada consulta consume una de ellas-. Simultáneamente se añaden al crédito 3,33 consultas por segundo. La salida del servicio Azure Agent Info te permite ver cuántas consultas quedan actualmente.
Concretamente, esto significa que
Si tu tasa de consultas es suficientemente baja, las consultas disponibles son siempre algo menos de 12.000.
Si tu tasa es demasiado alta, el crédito bajará lentamente hasta 0 y entonces se producirán errores esporádicos en la consulta.
En este caso, puedes reducir la tasa de sondeo consultando menos grupos de recursos o recursos de sondeo, o reduciendo el intervalo de comprobación del Check_MK check activo en el host Azure. Esto es posible con la regla Normal check interval for service checks.
Para que puedas reaccionar a tiempo, el servicio Azure Agent Info monitoriza el número de consultas restantes y te avisa con antelación. Por defecto, para las consultas restantes el umbral de advertencia es del 50 %, y el umbral crítico está en el 25 %.
5. Cuadros de mando
Para iniciarte cómodamente en la monitorización de Azure, Checkmk Cloud incluye los dos dashboards integrados, Azure VM instances y Azure storage accounts. Ambos pueden encontrarse como elementos de menú en la monitorización, en Monitor > Cloud.
Para que te hagas una idea más clara, a continuación te mostramos dos ejemplos de cómo están estructurados estos dashboards. En primer lugar, el dashboard de las instancias VM, en el que puedes comparar el estado actual en la parte izquierda y el historial cronológico de las métricas más importantes en la parte derecha:
El dashboard de las cuentas de almacenamiento tiene una estructura muy similar. En la parte izquierda, encontrarás los datos actuales de los respectivos cubos. En la derecha, las métricas más importantes se muestran de nuevo cronológicamente:
