Actualización a la versión 2.3.0

Como con cualquier actualización del software de producción, debes comprobar que tus copias de seguridad están actualizadas antes de realizar la actualización de Checkmk.

¿Estote afecta? Sí.

¿Qué tendrás que hacer?Si creas tus copias de seguridad automáticamente a través de Setup > Maintenance > Backups, comprueba allí que tus copias de seguridad están actualizadas y que los trabajos de copia de seguridad más recientes se han completado sin errores.

Para más información, consulta los artículos sobre Copias de seguridad y sobre Copia de seguridad y restauración de sites.

Checkmk 2.3.0 requiere unos recursos del sistema ligeramente superiores a los de 2.2.0. Por tanto, es aconsejable averiguar antes de actualizar qué capacidad libre tienen todavía los servidores utilizados para Checkmk.

¿Esto te afecta?Sí, pero el grado en que te afecta depende en gran medida de cómo utilices Checkmk. Sólo la actualización del intérprete de Python de la versión 3.11 a la 3.12 produce un aumento de la carga de la CPU en el rango porcentual de un solo dígito. Además -dependiendo de la proporción con respecto al número total de comprobaciones- las comprobaciones más exhaustivas en 2.3.0, especialmente en el área de la nube, pueden producir una carga adicional adicional, de modo que cabe esperar un total de un 10-15 % (en casos extremos alrededor de un 20 %) más de carga de la CPU.

Asegúrate de que hay suficiente capacidad libre disponible. Como regla general: si la carga de la CPU es inferior al número de núcleos del procesador x 0,8 y la carga de la CPU es inferior al 70 %, no cabe esperar problemas.Si uno o ambos valores son superiores, crea suficiente capacidad libre, por ejemplo desactivando los sitios de prueba en el mismo servidor o trasladando los host a otros sitios.

Algunas distribuciones obsoletas dejarán de ser compatibles con la versión de Checkmk 2.3.0.

¿Te afecta esto?Te afectará si en tu servidor Checkmk está instalada alguna de las siguientes distribuciones de Linux, que aún se admiten en 2.2.0:

¿Qué tendrás que hacer?Antes de actualizar Checkmk, realiza primero una actualización de la versión de la distribución de Linux. Asegúrate de que la versión de la distribución de Linux de destino de Checkmk es 2.2.0 y de que es compatible con 2.3.0. Puedes averiguar qué versiones de la distribución de Linux son compatibles con Checkmk en la matriz de actualización de 2.3.0 y en la página de descarga una vez que hayas seleccionado la versión de Checkmk y tu distribución de Linux.

Poco después del lanzamiento de Ubuntu 24.04 LTS, proporcionaremos los paquetes Checkmk 2.2.0 y 2.3.0 para esta versión de distribución. Esto te permitirá primero actualizar a la última versión de parche de Checkmk 2.2.0, luego actualizar de Ubuntu 23.10 STS a 24.04 LTS y finalmente actualizar a la última versión de parche de Checkmk 2.3.0.

Con la versión de Checkmk 2.3.0 (y 2.2.0p21) en SUSE Linux Enterprise Server 15 Service Pack 3 y 4, la dependencia del entorno de ejecución del lenguaje de programación PHP pasa de la versión 7 a la 8.

¿Te afecta?Sí, como usuario de SLES 15 SP3/SP4. La actualización es algo más compleja, ya que hay que desactivar las fuentes de paquetes para la versión 7 obsoleta y activarlas para la nueva versión 8.

¿Qué tendrás que hacer?Si, además de las aplicaciones Checkmk de tu servidor, utilizas el lenguaje de programación PHP, asegúrate de que pueden manejar PHP 8 sin problemas. A continuación, prepara los orígenes de paquetes para la actualización a 2.2.0p21 (o superior), que es obligatoria para la instalación de Checkmk 2.3.0, como se describe en el Werk nº 16025.

Checkmk 2.3.0 utiliza nuevas funciones de JavaScript que no están disponibles en navegadores antiguos. En las notas de la release puedes consultar qué navegadores son compatibles y en qué versiones.

¿Te afecta esto?Normalmente tendrás activadas las actualizaciones automáticas a la última versión en los sistemas de escritorio.

¿Qué tendrás que hacer?Comprueba la versión del navegador que utilizas e instala un navegador más reciente si es necesario. Si utilizas ordenadores monoplaca, Smart TV o soluciones de señalización digital para mostrar dashboards y no tienes control sobre el navegador del sistema, comprueba que los dashboards necesarios se muestran correctamente antes de actualizar. Si es necesario, ponte en contacto con el fabricante del hardware para obtener actualizaciones.

Por primera vez, Checkmk 2.3.0 proporciona OpenSSL en la versión 3.0 en lugar de la anterior 1.1. Este cambio afecta a casi todos los componentes que utilizan Secure Socket Layer o Seguridad de nivel de transporte.

¿Te afecta?Como OpenSSL 3 ya se utiliza ampliamente, apenas cabe esperar sorpresas. Pueden surgir problemas -especialmente con los checks activos- si se van a establecer conexiones con dispositivos que esperan cifrados antiguos o intentan renegociarlos. Suele tratarse de dispositivos de red antiguos (conmutadores, impresoras...) que ya no reciben actualizaciones. En algunos casos, se ven afectados servicios de distribuciones de Linux o versiones de Unix más antiguas, que aún reciben actualizaciones.

Qué tendrás que hacerSi es posible, intenta averiguar de antemano qué dispositivos son susceptibles de tener problemas. Unos buenos indicadores para ello son la antigüedad y el tiempo que hace que se instalaron las actualizaciones. Prueba estos dispositivos con Checkmk 2.3.0. Si se producen problemas, tienes dos opciones:

Con Checkmk 2.3.0, Checkmk MSP ha cambiado su base de Checkmk Enterprise a Checkmk Cloud. Esto no sólo significa que Checkmk MSP recibe la gama ampliada de funciones de Checkmk Cloud, sino también que la gestión de licencias se alinea con la de Checkmk Cloud.

¿Te afecta?Esto sólo afecta a los usuarios de Checkmk MSP, otras formas de monitorización distribuida no se ven afectadas.

¿Qué tendrás que hacer?La actualización de un Checkmk MSP a 2.3.0 sigue el procedimiento general en entornos distribuidos con configuración distribuida. Sin embargo, hay que asegurarse de que el site central pueda seguir transfiriendo la información de licencia en Checkmk 2.2.0 a los sites remotos ya actualizados en Checkmk 2.3.0.

Como los cambios necesarios sólo se implementan en Checkmk 2.2.0p17(Werk #16193), debes actualizar el site central al menos a esta versión. De este modo se garantiza la transferencia de la información de licencia. Los sites remotos pueden entonces actualizarse a 2.3.0 y, finalmente, al site central.

Independientemente del requisito mínimo para 2.2.0p17 mencionado aquí, te recomendamos que primero actualices todos los sites implicados a la última versión de parche disponible de 2.2.0 y sólo después inicies la actualización a 2.3.0.

Checkmk 2.3.0 ya no crea firmas SHA1 para los paquetes de agentes. La verificación de firmas SHA256 se introdujo con Checkmk 2.2.0p8. Para que las actualizaciones de agentes a la versión 2.3.0 se produzcan automáticamente, los agentes deben actualizarse primero a la versión 2.2.0p8 o superior.

¿Esto te afecta?Esto te afecta si realizas actualizaciones automáticas de agentes pero de vez en cuando te saltas versiones de parche del agente. También te afecta si tu distribución utiliza imágenes preparadas del sistema operativo que incluyen el actualizador de agentes Checkmk y confían en la instalación/actualización automática.

¿Qué tendrás que hacer?Asegúrate de que todos los agentes que vayan a actualizarse automáticamente se hayan actualizado al menos a la versión 2.2.0p8. En concreto, verifica las imágenes preparadas del sistema operativo y actualiza el agente existente a la versión 2.2.0p8 o superior. Y si estás trabajando actualmente en la actualización de agentes, ya puedes añadir ahora el certificado proporcionado por el Agent bakery, por si fuera necesario más adelante.

Algunos Plugin que estaban marcados como obsoletos han sido eliminados y pueden requerir una instalación manual si es necesario: Werk #16359

El soporte oficial para el agente Checkmk en Windows Server 2008 y Windows 7 por parte de Checkmk GmbH ya finalizó con el lanzamiento de Checkmk 2.2.0. No obstante, el funcionamiento en Windows Server 2008 R2 y Windows 7 seguía siendo posible sin restricciones. Con 2.3.0, hay que aceptar las restricciones: la opción anterior de suministrar un entorno de ejecución Python 3.4 para los agentes Windows mediante la regla Agent bakery ya no está disponible en 2.3.0.

¿Esto te afecta?Esperemos que no: La interrupción sólo te afecta si utilizas plugins de agente escritos en Python en Windows Server 2008 R2 o Windows 7 (ambos con fin de vida útil ya en 2020). Las versiones actuales de Python funcionan en todas las versiones más recientes de Windows. En todas las versiones de Windows incluso más antiguas -como Windows Server 2008 R1 o Windows Vista- ya no se podrá utilizar el agente en la versión 2.2.0.

¿Qué tendrás que hacer?Si quieres seguir monitorizando estos sistemas Windows, deberás proporcionar tú mismo el entorno de ejecución para los plugins de agente que requieran Python: Instala Python 3.4 manualmente en los sistemas afectados. Para estos sistemas, normalmente establece en Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Windows modules > Install Python runtime environment el ajuste Install Python runtime environment > Installation en Never install Python with the agent. Ten en cuenta que no podemos garantizar la compatibilidad con sistemas Windows tan antiguos y que ya no probamos nuevas versiones de agente en las versiones de parche.

mod_auth_mellon es un módulo de software para Apache que proporciona servicios para autentificar mediante el Lenguaje de Marcado de Aserción Segura (SAML). La conexión a los servicios de autentificación SAML era posible en Checkmk 2.2.0 de dos formas: A nivel de Apache con mod_auth_mellon (la única opción compatible hasta la versión 2.1.0) o en las ediciones comerciales de Checkmk la autentificación SAML integrada. Con la versión 2.3.0 mod_auth_mellon` ya no se suministra con el software de Checkmk.

¿Esto te afecta?Esto te afecta si utilizas la autenticación SAML con mod_auth_mellon.

¿Qué tendrás que hacer?Los usuarios de las ediciones comerciales deben cambiar la autenticación SAML a la solución integrada en Checkmk antes de actualizar a 2.3.0.

Si utilizas Checkmk Raw, ya puedes instalar mod_auth_mellon en todo el sistema antes de la actualización siguiendo las instrucciones de la página del proyecto. A continuación, cambia la línea para cargar el módulo en el archivo de configuración ~/etc/apache/conf.d/auth.conf por la ruta de instalación en todo el sistema. El directorio de instalación puede variar en función de la distribución utilizada:

Reinicia tu site tras realizar el cambio. Por último, comprueba -aún en 2.2.0- si la autenticación SAML sigue funcionando. Si es así, no cabe esperar dificultades tras la actualización.

Checkmk 2.3.0 actualiza Python de 3.11 a 3.12. Esta actualización afecta a los módulos instalados en un site de Checkmk. En muchos casos, los módulos instalados posteriormente son incompatibles con Python 3.12. En el peor de los casos, los módulos obsoletos sobrescriben la funcionalidad de los módulos suministrados por Checkmk.

¿Esto te afecta?Esto sólo te afectará cuando hayas instalado explícitamente módulos Python para agentes especiales o plugins de agente que hayas escrito tú mismo u obtenido de la Bolsa. Si no estás seguro, realiza la comprobación que se describe en la siguiente sección.

¿Qué tienes que hacer?En primer lugar, averigua si hay módulos Python instalados en el site y, en caso afirmativo, identifícalos. Para ello, busca los directorios dist-info y egg-info:

Anota los módulos instalados y luego desinstálalos:

A continuación te explicamos cómo tratar los módulos de Python desinstalados tras la actualización.

El agente especial de Prometheus ofrecía kube-state-metrics como fuente de datos, cuyos checks ya no se admiten. Desde entonces, se han sustituido por homólogos mejorados en el agente de Kubernetes (ver Werk #14572). Además, en las reglas Prometheus y Alertmanager, la especificación de la dirección IP/nombre del host, puerto y prefijo de la ruta se ha sustituido por un único campo de entrada Custom URL (ver Werk #14573).

En ambos casos, el método antiguo seguía funcionando en 2.2.0. Para utilizarlo en 2.3.0, sin embargo, debes haber cambiado tu configuración al nuevo método.

Los archivos locales te permiten personalizar y ampliar la funcionalidad proporcionada por Checkmk. Estos archivos se encuentran en la parte local de la estructura de directorios del site, es decir, en ~/local y pueden estar ubicados en paquetes de extensión o simplemente "por ahí". Los archivos locales pueden causar problemas durante una actualización si ya no coinciden con la nueva versión de Checkmk.

¿Esto te afecta?Como no es posible que Checkmk garantice totalmente la compatibilidad de las adaptaciones locales durante una actualización, debes comprobar tu site de Checkmk antes de una actualización para ver si se utilizan archivos locales, cuáles son y cómo están organizados.

¿Qué tendrás que hacer?

En Checkmk 2.3.0 se han reconstruido algunas interfaces de programación internas (API). Algunas API definidas previamente ad hoc se han sustituido por otras bien especificadas. Además, la API Check que ya estaba marcada como obsoleta en 2.0.0 se ha eliminado definitivamente.

¿Te afecta?El tema de las API te afecta si has ampliado las comprobaciones suministradas con Checkmk con tus propias comprobaciones escritas por ti y/o si utilizas Plugin de otras fuentes.

¿Qué tendrás que hacer?Comprueba la funcionalidad de las extensiones que hayas escrito tú mismo y las de proveedores de terceros. Dado que las nuevas API pueden utilizarse en paralelo a las antiguas durante Checkmk 2.3.0 y que los cambios en las API existentes podrían ser pequeños, la mayoría de las extensiones seguirán siendo utilizables sin modificaciones. Si es necesario realizar cambios, te recomendamos migrar a las nuevas API, que estarán disponibles a partir de Checkmk 2.4.0 y sustituirán por completo a las antiguas.

Los endpoints o parámetros obsoletos de la API-REST de Checkmk están marcados en la documentación de la API con el icono .

¿Estote afecta? Esto puede afectarte si utilizas la API-REST de Checkmk en tus propios scripts, por ejemplo.

¿Qué tendrás que hacer?Abre la documentación de la API-REST con Help > Developer Resources > REST API documentation. Busca Deprecated en el navegador de la página, comprueba si estás utilizando elementos obsoletos en tus scripts y sustitúyelos antes de actualizar. En la documentación de la API-REST, normalmente encontrarás instrucciones sobre cómo sustituir las funciones que ya no existen en la nueva versión.

Como en todas las versiones de Checkmk, también hay cambios en el software de la versión actual 2.3.0 que pueden repercutir en tu instalación de Checkmk -en Checkmk están organizados y documentados en lo que denominamos nuestros Checkmk Werks-. Un cambio denominado incompatible requiere que hagas modificaciones manuales para que las funciones existentes sigan funcionando como siempre y/o para poder utilizar las nuevas funciones.

¿Te afecta?En general, habrá cambios incompatibles que también afectarán a tu instalación de Checkmk, sin embargo es imposible hacer una afirmación general. En este artículo hemos recopilado aquellos aspectos que se aplican a todas o a la mayoría de las instalaciones de Checkmk. En cualquier caso, puede haber cambios adicionales que sean relevantes para ti, por ejemplo en los checks que utilizas en tu instalación.

¿Qué tendrás que hacer?Tras cada actualización -incluidas las versiones de parche- Checkmk te mostrará el número y el contenido de los cambios incompatibles y te pedirá que los compruebes y tomes nota de ellos. Antes de realizar la actualización es el momento adecuado para comprobar si hay cambios de la versión 2.2.0 que puedan afectar a la actualización. Desde Checkmk 2.3.0, esos Werks ya no se arrastran, sino que se eliminan durante la actualización tras aprobar un diálogo de confirmación(Werk #15292).

También es una buena idea obtener una visión general de los cambios incompatibles en la versión 2.3.0 antes de la actualización: abre la lista de Werks en el sitio web de Checkmk. En la descripción de un Werk, encontrarás información sobre lo que puedes necesitar hacer para que el cambio sea compatible.

Después de realizar la actualización, el número y el contenido de los cambios incompatibles se mostrarán en la interfaz de Checkmk y se te pedirá que los compruebes y tomes nota de ellos. Los enlaces te ayudarán a comprobarlo para que puedas averiguar con unos pocos clics si estás utilizando un componente afectado. Si es seguro que un Werk no tiene ningún impacto o que has realizado los cambios necesarios, confírmalo con Acknowledge.

En esta sección describimos las mejores prácticas que seguimos incluso cuando actualizamos grandes entornos Checkmk. Desde luego, no son obligatorias en todos los entornos, pero pueden facilitarte el proceso de actualización.

Hay dos procedimientos diferentes para realizar una actualización de todos los sites incluidos en una monitorización distribuida:

En particular, si quieres actualizar mientras el sistema está en funcionamiento, debes leer las notas del artículo general sobre Actualizaciones y mejoras.

Nada fundamental ha cambiado con la actualización real del software en Checkmk 2.3.0, es decir, instalas la nueva versión, realizas la actualización del site de Checkmk, rectificas los posibles conflictos y compruebas y confirmas los cambios incompatibles.

Realiza el procedimiento de actualización como se describe en el artículo sobre Actualizaciones y mejoras.

La interfaz de usuario (GUI) de Checkmk, que se rediseñó por completo con la versión 2.0.0, no ha sufrido cambios fundamentales en la versión 2.3.0. Los procedimientos generales, con los que ya estás familiarizado de las versiones 2.0.0 y 2.2.0, también se pueden utilizar tal y como están en 2.3.0. Sin embargo, los menús, elementos de menú, iconos y otros detalles se han modificado para que haya nuevas funciones disponibles - y para mejorar las existentes.

Presentaremos estos cambios en los artículos de este Manual de usuario - y en la Guía para principiantes encontrarás una introducción detallada, que incluye los elementos más importantes de la interfaz de usuario.

Como en cada versión mayor, Checkmk 2.3.0 introduce todo un nuevo conjunto de check plugins. Si no utilizas la "comprobación de descubrimiento", es decir, la actualización automática de la configuración de servicios mediante el descubrimiento de servicios periódico, tendrás que buscar servicios en un buen número de hosts.

Si tus hosts están organizados como corresponde (por ejemplo, en carpetas), generalmente puedes utilizar para ello la función Bulk discovery. Esta función se encuentra en Setup > Hosts > Hosts y luego en el menú Hosts > Run bulk service discovery.

Se ha cambiado el comportamiento del parámetro de la línea de comandos --trust-cert del comando cmk-update-agent. Antes se comprobaba toda la cadena de certificados y se confiaba en el certificado autofirmado más alto encontrado en la jerarquía, que suele ser el raíz o un certificado intermedio. A partir de Checkmk 2.3.0, sólo se importa y se confía en el certificado del servidor.

¿Te afecta?Esto sólo te afecta si confías en --trust-cert al registrar hosts para actualizaciones automáticas de agentes y no proporcionas un certificado a través de Agent bakery. En este caso, desde Checkmk 2.3.0 los hosts ya pierden la posición de confianza cuando caduca el certificado del servidor, los hosts registrados con Checkmk 2.2.0 sólo cuando caducan los certificados raíz o intermedio.

¿Qué tendrás que hacer?Recomendamos proporcionar los certificados correctos a través de la Agent bakery inmediatamente después de la actualización a 2.3.0 y actualizar todos los agentes para garantizar un comportamiento coherente para todos los host que utilicen el actualizador de agentes.

¿Esto te afecta?Esto sólo te afectará si has instalado explícitamente módulos Python para agentes especiales o plugins de check plugin basados en agentes que hayas escrito tú mismo u obtenido de la Bolsa y los has eliminado en el transcurso de la preparación para la actualización.

¿Qué tendrás que hacer?En primer lugar, averigua si los módulos desinstalados anteriormente ya se han entregado con la nueva versión de Checkmk, por ejemplo:

Si el módulo ya se ha encontrado, márcalo como no necesario en tus notas. Instala la última versión de los módulos que no se hayan incluido:

A continuación, comprueba los check plugin o agentes especiales que dependen de los módulos de Python instalados en el site.

Hasta Checkmk 2.2.0, el agente de Windows dependía del adicional de Windows: Estado y rendimiento de las interfaces de red para transmitir correctamente el estado de las interfaces de red. Sin el Plugin, el estado siempre era "up". A partir de Checkmk 2.3.0, el agente puede transmitir el estado correcto por sí solo(Werk #15839).

¿Esto te afecta?Dependiendo del grado en que hayas distribuido el Plugin y de si has desactivado la monitorización del estado de las interfaces de red para los host sin Plugin, esto puede afectarte. Los host que no hayan utilizado previamente un Plugin y cuyas interfaces de red estuvieran incluidas en la monitorización cambiarán muchas interfaces de arriba a abajo, lo que provocará el estado CRIT y activará las notificaciones.

¿Qué tendrás que hacer?Comprobar si el estado determinado para las interfaces de red afectadas es el deseado. A continuación, vuelve a realizar el descubrimiento de servicios para los hosts afectados. Aprovecha para aplicar primero las recomendaciones del artículo del blog Monitorización de redes con Checkmk: 3 reglas para gobernarlos a todos, al menos para tus hosts Windows. Para Windows, los ajustes mencionados deben realizarse en la regla Network interfaces on Windows.

Con Checkmk Cloud y Checkmk MSP con configuración distribuida, a veces la información de licencia no se sincroniza con los sites remotos durante la actualización.

¿Estote afecta? Si necesitas una visión completa de la carga de tu licencia inmediatamente después de la actualización, puede que te afecte. Comprueba el estado de la licencia e inicia la sincronización manualmente si es necesario.

¿Qué tendrás que hacer?En Setup > General > Distributed Monitoring, echa un vistazo a la visión general de los sitios remotos y busca los sitios marcados con License state: trial. Para forzar una sincronización inmediata para estos sitios, comprueba la licencia en Setup > Licensing o guarda la configuración de la licencia. Si se olvida este paso, los datos de la licencia suelen sincronizarse en segundo plano en los siete días siguientes a la actualización.

Checkmk 2.3.0 contiene un nuevo check activo para conexiones HTTP y certificados, que tiene un rendimiento significativamente mejor, es más robusto y más fácil de configurar que el anterior Check HTTP service. Además, ahora es posible monitorizar varias cosas a la vez con una sola regla, por ejemplo el código de respuesta HTTP, el tiempo de respuesta y la validez del certificado.

El nuevo Check HTTP web service se encuentra en la caja Networking, debajo de Setup > Services > HTTP, TCP, Email, …​. A medio plazo, sustituirá por completo al antiguo Check HTTP service, que puedes encontrar en la misma página. Por este motivo, te recomendamos que dejes de utilizar el anterior check (interno: check_http) al crear nuevos host y que migres gradualmente los host existentes al nuevo check (interno: check_httpv2).

Se proporcionará un script de migración más adelante en el ciclo de vida de Checkmk 2.3.0. Sin embargo, una migración totalmente automatizada tiende a ser difícil, porque con muchos hosts hay que agrupar reglas de dos checks para beneficiarse de la eficacia mejorada.

Puedes encontrar más información en los dos Werk #15514 y #15515.

El legado Check HTTP service contenía una funcionalidad básica para comprobar certificados, y el nuevo Check HTTP web service mencionado en la sección anterior la mejora aún más. Sin embargo, ambos tienen algunas cosas en común: en primer lugar, sólo son aplicables cuando se utiliza un certificado en un endpoint HTTPS, y también carecen de la opción de un examen detallado de los certificados, por ejemplo para los Nombres Alternativos del Sujeto del Certificado contenidos o la autoridad emisora.

Hemos implementado las peticiones de usuario resultantes con el nuevo Check certificates (interno: check_cert). Todos los ajustes para el nuevo check se encuentran también en Setup > Services > HTTP, TCP, Email, …​ en la caja Networking..

Puedes encontrar más información en el Werk #15516.

A partir de la versión 2.3.0 de Checkmk, sólo serán compatibles las APIs bien especificadas para programar plugins de check, agentes especiales, gráficos, etc. Los cambios afectan a la estructura del directorio, al reconocimiento de los plugins(Discovery en lugar de Registry) y, por supuesto, a las funciones y objetos de las propias APIs. Puedes encontrar una vista general de los cambios más importantes en el Werk #16259.

Como las API anteriores ya no son compatibles con Checkmk 2.4.0, todos los Plugin que utilicen las API anteriores deben migrar a las nuevas API antes de la actualización a 2.4.0.

Hay disponible un nuevo plugin de agente para la monitorización de Microsoft SQL Server con Checkmk 2.3.0. Puedes encontrarlo en Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Microsoft SQL Server (Linux, Windows). Éste está implementado en Rust y, a largo plazo, sustituirá al anterior escrito en VBScript. El nuevo plugin se ejecuta en Linux y Windows en la plataforma x86/64. También ofrece una mayor flexibilidad mediante la monitorización local y remota en Windows y la monitorización remota en Linux. Por supuesto, puedes monitorizar una base de datos MS SQL que se ejecute localmente en Linux utilizando la interfaz TCP/IP.

La configurabilidad se ha mejorado notablemente, por lo que ahora puedes elegir qué secciones se van a comprobar y añadir tus propias sentencias SQL. Además, puedes supervisar bases de datos en distintos hosts utilizando un único Plugin. Para que esto quede claro, se puede utilizar el mecanismo piggyback para asignar bases de datos a otros hosts. Toda la configuración se realiza mediante un archivo YAML. Las opciones estables están disponibles a través de las reglas de Agent bakery. Otros ajustes, que nos reservamos el derecho a modificar, se pueden configurar utilizando un editor de texto. Encontrarás más detalles en el Werk #15842.

Con la introducción del nuevo plugin de agente, comienza la eliminación del antiguo plugin de agente Microsoft SQL Server (Windows). En Checkmk 2.3.0 sólo recibirás información sobre el uso de un conjunto de reglas obsoleto. A partir de 2.4.0 ya no será posible crear nuevas reglas y con 2.5.0 probablemente se eliminará el antiguo plugin de Checkmk. Encontrarás más información en el Werk #15844.

El término tarjeta de gestión hace referencia a tarjetas Plugin independientes o a funciones ampliadas de la BIOS (Baseboard Management Controller/BMC, Management Engine/ME, Lights Out Management/LOM) para la monitorización y gestión del hardware, además del sistema operativo instalado.

Hasta Checkmk 2.3.0, las tarjetas de gestión pueden configurarse de dos formas: Como propiedad de un host o como host independiente. Como la configurabilidad como propiedad de un host es muy limitada, en el futuro esta opción dejará de estar disponible. La compatibilidad con las placas de administración compatibles con Redfish se añadirá y mejorará durante el ciclo de vida de Checkmk 2.3.0, inicialmente como MKP opcional(Werk #16589). Explicamos información de fondo y alternativas adicionales en el artículo del blog Monitorización de las placas de administración.

Hasta Checkmk 2.2.0, todos los usuarios de automatización podían iniciar sesión con un nombre de usuario y una contraseña pasados a través del parámetro GET. Esta opción se reducirá a partir de Checkmk 2.3.0 y, finalmente, se eliminará por completo(Werk #16223). Por tanto, a medio plazo, deberás cambiar tus scripts a la autenticación a través de cabeceras HTTP.

En primer lugar, 2.3.0 hace configurable la opción de iniciar sesión mediante el parámetro GET. Sin embargo, la configuración global Enable automation user authentication via HTTP parameters utilizará inicialmente enabled como valor predeterminado. En Checkmk 2.4.0, el valor predeterminado cambiará entonces a disabled. Finalmente, la opción de iniciar sesión mediante el parámetro GET se eliminará por completo en Checkmk 2.5.0.

Checkmk 2.3.0 será la última versión compatible con ntopng en las versiones 5.x y 6.x(Werk #16483). Con Checkmk 2.4.0, se dejará de dar soporte a ntopng 5.x y sólo se dará soporte a ntopng 6.x. Por tanto, actualiza tus instalaciones de ntopng a 6.x durante el ciclo de vida de Checkmk 2.3.0.