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 usted.
Además de la información general sobre los costes en los que incurre su entorno Azure y el estado actual de Azure en su región, puede supervisar los siguientes productos Azure con todas las ediciones de Checkmk:
Con el Checkmk Cloud Edition también puede incluir los siguientes productos en su sistema de monitorización:
Puede 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 sus 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. Preparación de Azure para Checkmk
2.1. Creación de la aplicación
Para monitorizar Azure con Checkmk, necesitará su ID de suscripción y su ID de inquilino (también conocido como "ID de directorio").
En primer lugar, registre la monitorización de Checkmk como una app para poder trabajar con la API de Azure. La opción para ello se encuentra en el portal de Azure en Azure Active Directory > App registrations > New registration:
Asigna un nombre de tu elección. En el ejemplo usamos 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 necesitas cambiar nada en la sección Supported account types. Configurar Redirect URI es opcional.
Tras la creación, selecciona la nueva aplicación de la lista de aplicaciones. Si no aparece en la lista, consulta Seleccionar 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. Asignación de permisos a la aplicación
Para que su nueva app tenga derechos de acceso a los datos de monitorización, debe asignarlos aquí. En la parte izquierda de la página principal de navegación seleccione el item All resources, y a continuación seleccione Subscriptions:
En la navegación de esta página vaya a Access Control (IAM) y seleccione Add, y Add role assignment:
Ahora, en rol introduzca Reader, en Assign access to seleccione el valor Azure AD user, group, or service principal, e introduzca el nombre de su nueva app en la opción Select:
2.3. Crear una clave para la aplicación
Ahora necesita una clave (un secreto) con la que Checkmk pueda iniciar sesión en la API. Puede crear una clave en la configuración de la app, en Certificates & secrets. Simplemente haga clic en New client secret en la sección Client secrets.
En la siguiente ventana, Microsoft quiere que introduzca un nombre de su elección en el campo Description. Aquí hemos elegido my-check-mk-key. No olvide seleccionar el marco temporal correcto para sus necesidades en la opción Expires.
La configuración en Azure ya está completa, y ahora deberías tener los siguientes cuatro datos:
Su ID de suscripción
Su ID de inquilino (también conocido como "ID de directorio").
El ID de aplicación (ID de cliente) para la aplicación my-check-mk-app.
El secreto de la clave my-check-mk-key para esta aplicación.
Si no tienes a mano tu ID de inquilino, encuéntralo pasando el ratón por encima de tu nombre de inicio de sesión en el tooltip de Directory:
Puede ver el ID de suscripción - por ejemplo en Cost Management + Billing bajo My subscriptions.Nota: Hoy en día Microsoft no muestra este ID como un hash, sino como un nombre legible por humanos. Puede utilizar este nombre de nuevo estilo de la forma habitual.
3. Configuración de la monitorización en Checkmk
3.1. Creación de un host para Azure
Aunque no esté tratando con un host físico en Azure, cree un host para su directorio Azure en Checkmk. El nombre del host puede definirlo a voluntad. Importante: Dado que Azure es un servicio y, por tanto, no tiene dirección IP ni nombre DNS (el agente especial realiza el acceso por sí mismo), debe configurar IP address family en No IP.
Es mejor guardar con Save & Finish en este punto, porque por supuesto el descubrimiento de servicios no puede funcionar todavía.
3.2. Configuración del agente de Azure
Dado que Azure no se puede consultar a través del agente Checkmk normal, ahora debe configurar el agente especialde Azure, que también se conoce como programa de origen de datos. En esta situación, Checkmk no se pone en contacto 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 cree una regla cuyas condiciones se apliquen exclusivamente al host Azure que acaba de crear. Allí encontrará los campos de entrada para los ID y el secreto:
Aquí también puede seleccionar los grupos de recursos o recursos que desea monitorizar. Si no ha marcado explicitly specified groups, todos los grupos de recursos se monitorizan automáticamente.
3.3. Prueba de
Si ahora realiza 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 permisos incorrectos, 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 para 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. Coloque 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á seguro de la ortografía exacta de los nombres de los grupos, puede 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á todos los hosts piggyback para 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
WoodstockConfigure los host del grupo del recurso sin dirección IP (análogo al host Azure), y seleccione No API integrations, no Checkmk agent como agente y Always use and expect piggyback data como piggyback.
Si ahora realiza un descubrimiento de servicios en uno de estos hosts de grupo de recursos, descubrirá que hay servicios adicionales relacionados específicamente con este grupo de recursos:
Consejo: Si desea 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 puede definir una conversión de grupos de recursos a hosts.
3.5. Máquinas virtuales (VM)
Cuando utilice Azure para monitorizar máquinas virtuales que sirvan simultáneamente como host normal en Checkmk, puede utilizar los servicios de Azure asociados a esas máquinas virtuales en lugar de los hosts de grupo de recursos asociados directamente a los hosts de máquinas virtuales en Checkmk.
Para ello, en la regla de Azure, en la opción Map data relating to VMs, seleccione 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.
3.6. Límite de velocidad 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 velocidad"). Por ID de aplicación, el límite es de 12.000 solicitudes 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 que se monitorizan. 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 tasa 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 3,33 consultas por segundo al crédito. La salida del servicio Azure Agent Info te permite ver cuántas consultas quedan actualmente.
Concretamente, esto significa que
Si su tasa de consultas es suficientemente baja, las consultas disponibles son siempre algo menos de 12.000.
Si su tasa es demasiado alta, el crédito bajará lentamente hasta 0 y se producirán errores esporádicos en la consulta.
En este caso, puede reducir la tasa de sondeo consultando menos grupos de recursos o recursos de sondeo, o reduciendo el intervalo de comprobación del check activo Check_MK en el host Azure. Esto es posible con la regla Normal check interval for service checks.
Para que pueda reaccionar a tiempo, el servicio Azure Agent Info monitoriza el número de consultas restantes y le 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 %.
4. Dashboards
Para comenzar cómodamente con la monitorización de Azure, Checkmk Cloud Edition incluye dos dashboards integrados, Azure VM instances y Azure storage accounts. Ambos se pueden encontrar como elementos de menú en la monitorización en Monitor > Cloud.
Para ofrecer una impresión más clara, a continuación se muestran dos ejemplos de cómo están estructurados estos dashboards. En primer lugar, el dashboard de las instancias VM, en el que se puede comparar el estado actual en el lado izquierdo y el historial cronológico de las métricas más importantes en el lado derecho:
El dashboard para las cuentas de almacenamiento tiene una estructura muy similar. En la parte izquierda, encontrará los datos actuales de los respectivos buckets. En la derecha, las métricas más importantes se muestran de nuevo cronológicamente:
