Monitorización de Microsoft Azure

Primero, registra una aplicación en Azure. Checkmk utilizará esta aplicación para leer los datos deseados de Azure. Encontrarás la opción para ello en el portal de Azure, en «(All services > Identity > Identity management > ) App registrations». También puedes usar la búsqueda del portal e introducir «App registrations». Una vez en la página, debes hacer clic en «New registration».

Asigna un nombre identificativo de tu elección. En el ejemplo, usamos my-checkmk-app. Sin embargo, este nombre es solo a título informativo. En su lugar, la referencia a la aplicación se realiza a través del identificador de la aplicación, que verás en el siguiente paso. No es necesario que cambies nada en la sección Supported account types y el campo Redirect URI debe permanecer vacío. Confirma tus entradas haciendo clic en Register.

Una vez creada la aplicación, deberías ver una vista general de esta nueva aplicación. Si no es así, encontrarás la nueva aplicación en la lista de todas las «App registrations» descritas anteriormente en la pestaña «All applications». En los detalles de la aplicación, encontrarás ahora tanto el «Application (client) ID» como el «Directory (tenant) ID», que deberás introducir más adelante en Checkmk.

A continuación, también necesitarás un secreto de cliente con el que Checkmk pueda iniciar sesión en la API de Azure. Para generar dicho secreto, haz clic en «Certificates & secrets» en la vista general de la aplicación, luego en la pestaña «Client secrets» y, por último, en «New client secret».

Esto abre el diálogo «Add a client secret». Asigna cualquier nombre y selecciona durante cuánto tiempo debe ser válido el secreto. Si más adelante activas la opción «App Registrations» en la regla del agente especial, recibirás un práctico servicio que te recordará cuándo está a punto de terminar este periodo de validez. Confirma el diálogo haciendo clic en «Add».

Ahora es importante que copies inmediatamente el contenido de «Value» en este nuevo secreto, ya que, tras un tiempo, solo se mostrarán los tres primeros caracteres de dichos secretos en el portal de Azure.

Debes conceder a la aplicación permisos de API adicionales si quieres realizar la monitorización de los siguientes servicios con Checkmk:

Empieza a asignar los permisos en la Vista general de tu nueva aplicación, que aún deberías tener abierta de la sección anterior.

Haz clic en «API permissions» y luego en «Add a permission.» En el diálogo que se abre, debes buscar y hacer clic en «Microsoft Graph». A continuación, selecciona «Application permissions» e introduce «Directory.Read.All» en el campo de búsqueda. Marca la checkbox correspondiente y haz clic en «Add permissions». Para este permiso (Admin consent required) se requiere el consentimiento adicional de un administrador de tu entorno de Azure. Si no ves el botón «Grant admin consent» encima de la lista de permisos concedidos, debes ponerte en contacto con el administrador responsable.

Para que Checkmk pueda acceder a los datos de monitorización a través de la nueva aplicación, debes asignarle un rol a nivel de suscripción. Para ello, selecciona «All services» en el menú de navegación principal de la izquierda y, a continuación, en «General», la entrada «Subscriptions». De nuevo, puedes usar la función de búsqueda del portal si no encuentras el botón correspondiente.

Si tienes varias suscripciones, ahora tendrás que hacer clic en el nombre de la suscripción que deseas supervisar. A continuación, se te redirigirá a una página de Vista general de tu suscripción. Anota aquí el Subscription ID. Tendrás que introducirlo más tarde en la regla del agente especial.

A continuación, haz clic en Access Control (IAM), luego en Add y, por último, en Add role assignment:

Ahora selecciona el rol llamado «Reader» y con el «Type» «BuiltInRole». Como hay más de 100 roles en total con la palabra «Reader» en su nombre, es importante tener cuidado aquí. A continuación, haz clic en «Next» para ir a la pestaña «Members».

Haz clic aquí en «+ Select members.»

En el diálogo «Select members», escribe el nombre de la aplicación tal y como la creaste anteriormente en el campo de búsqueda, selecciona esta aplicación y haz clic en «Select.» Tras dos clics más en «Review + assign», la configuración en el portal de Azure habrá finalizado.

Aunque en Azure no estés trabajando con un host físico, crea un host para tu directorio de Azure en Checkmk. Puedes definir el nombre del host como quieras. Importante: Como Azure es un servicio y, por lo tanto, no tiene una dirección IP ni un nombre DNS (el agente especial se encarga del acceso), debes configurar el IP address family en No IP.

Lo mejor es guardar con Save & view folder en este momento, ya que, por supuesto, el descubrimiento de servicios aún no puede funcionar.

Dado que Azure no se puede consultar a través del agente Checkmk habitual, ahora debes configurar el agente especial de Azure. En esta situación, Checkmk no establece contacto con el host de destino a través del puerto TCP 6556 como de costumbre, 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 de 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 los recursos que deseas supervisar. Si no has marcado «explicitly specified groups», todos los grupos de recursos se realizan automáticamente.

Si ahora realizas el descubrimiento de servicios en el host de Azure, debería detectarse al menos el servicio llamado Azure Agent Info:

Si el acceso a la API no funciona (debido a un ID incorrecto, permisos inadecuados o un secreto de cliente erróneo, como en el ejemplo siguiente), aparecerá el mensaje de error correspondiente en el texto de estado de Azure Agent Info:

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 del mecanismo piggyback. Este piggyback tomará datos del host de Azure utilizando agentes especiales y, dentro de Checkmk, los redirigirá a estos hosts de grupos de recursos.

Los hosts de los grupos de recursos no aparecen automáticamente en Checkmk. Añade estos hosts manualmente o, si lo prefieres, mediante la administración dinámica del host. Importante: al hacerlo, los nombres de los hosts deben coincidir exactamente con los nombres de los grupos de recursos, ¡y hay que tener en cuenta las 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 de Azure.

Configura los hosts del grupo de recursos sin una dirección IP (análogo al host de 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 del grupo de recursos, verás que hay servicios adicionales que se relacionan específicamente con este grupo de recursos:

Cuando usas Azure para la monitorización de máquinas virtuales que también actúan como tus hosts normales en Checkmk, puedes asignar los servicios de Azure asociados a esas máquinas virtuales directamente a los hosts de las máquinas virtuales 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 de Checkmk de la VM en la monitorización debe tener exactamente el mismo nombre que la VM correspondiente en Azure.

La regla «Microsoft Azure» está preconfigurada para que Checkmk también realice la monitorización de todos los costes incurridos en tu entorno de Azure. Concretamente, los servicios muestran los costes incurridos el día anterior. De esta forma, puedes determinar rápidamente si ha habido algún cambio.

Se crean varios servicios para obtener una mejor vista general de dónde se han incurrido exactamente los costes y para poder establecer umbrales específicos. Los costes totales a nivel de tu directorio de Azure se muestran para el host de Azure que creaste primero. Además, se crean servicios para cada host que representa un grupo de recursos. En ambos niveles, Checkmk genera un servicio para los costes por cada «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 usar la regla Azure Usage Details (Costs) para definir umbrales individuales para todos estos servicios.

Si no quieres realizar la monitorización de los costes, debes desactivar la opción Usage Details en la regla Microsoft Azure.

Por defecto, Checkmk importa todas las etiquetas de tu entorno de Azure y las convierte en etiquetas de host y de servicio. La asignación funciona como se espera. Las etiquetas asociadas a un grupo de recursos se asignan en Checkmk al host que representa ese grupo de recursos, y las etiquetas de una máquina virtual se convierten en host labels para esa máquina virtual.

A todas las etiquetas creadas de esta manera se les asigna el prefijo cmk/azure/. Además, se sustituyen los caracteres y valores que darían lugar a etiquetas inválidas en Checkmk. Los valores vacíos (es decir, el campo Value en Azure) se sustituyen por true y los dos puntos dentro del nombre o valor se sustituyen por un guión bajo.

La opción «Filter tags imported as host/service labels» te permite controlar la importación de tags desde Azure. Si marcas la checkbox aquí, puedes impedir por completo la importación con Do not import tags. Si seleccionas Filter valid tags by key pattern aquí, puedes introducir una expresión regular en el campo siguiente. Checkmk generará entonces solo labels a partir de los tags que tengan una coincidencia con esta expresión regular.

Actualmente, las consultas a la API que Checkmk necesita para la monitorización de Azure (a diferencia de AWS) son gratuitas; sin embargo, hay un límite en el número de consultas permitidas por periodo de tiempo (el «límite de throttling»). A día de hoy, las consultas a la API que Checkmk requiere para la monitorización son gratuitas con Azure (a diferencia de AWS). Sin embargo, hay un límite en el número de consultas por periodo de tiempo («límites de throttling»).

Debido a la estructura de la API, Checkmk requiere al menos una o más consultas por cada recurso solicitado. Por lo tanto, el número total de consultas varía linealmente con el número de recursos que se realizan tareas de monitorización en ellos. Si se alcanza o se supera el límite de consultas, la consulta falla con un código HTTP 429 (demasiadas solicitudes) y el servicio de «Check_MK» del host de Azure se marca como «CRIT».

Este límite se debe al algoritmo de Azure conocido como «token bucket». Todo empieza con un «crédito» de 250 consultas restantes: cada consulta consume una de ellas. Al mismo tiempo, se añaden 25 consultas por segundo al crédito. La salida del servicio Azure Agent Info te permite ver cuántas consultas quedan actualmente.

En concreto, esto significa que:

En este caso, puedes reducir la tasa de sondeo consultando menos grupos de recursos o recursos de sondeo, o reduciendo el intervalo de check de la comprobación activa de Check_MK en el host de Azure. Esto es posible con la regla Normal check interval for service checks.

Para que puedas reaccionar a tiempo, el servicio Azure Agent Info realiza la monitorización del número de consultas restantes. De forma predeterminada, no hay ningún umbral establecido. Puedes configurarlos tú mismo en la regla Azure Agent Info.

El artículo «Comprender cómo Azure Resource Manager limita las solicitudes» en Microsoft Learn lo explica con más detalle.