Actualizaciones y ampliaciones

Al actualizar a una versión mayor, siempre debes actualizar paso a paso a través de las versiones intermedias disponibles hasta llegar a la versión de destino, y no saltarte ninguna versión intermedia. Por ejemplo, si quieres actualizar de la versión 2.1.0 a la versión 2.3.0, primero actualiza a la versión intermedia 2.2.0. La razón de este procedimiento es sencilla: a veces simplemente hay tantos cambios entre dos versiones mayores que saltarse versiones puede causar problemas.

El comando omd update también permite una "actualización" a una versión inferior. Este procedimiento sólo está previsto para las regresiones. Tras una actualización de este tipo en sentido inverso, serán necesarios muchos ajustes para que la configuración y el entorno de ejecución vuelvan a ser compatibles, especialmente, pero no sólo, en el caso de una "actualización" a una versión principal inferior. Por tanto, desaconsejamos encarecidamente este procedimiento y, además, dejaremos de prestar asistencia en el caso de una actualización a una versión inferior.

Tu sistema de monitorización puede ampliarse de forma bastante fácil y cómoda utilizando los paquetes de ampliación de Checkmk (MKP). Por un lado, es posible que algunos MKP antiguos ya no reciban mantenimiento y, por tanto, dejen de ser compatibles con las versiones más recientes de Checkmk. Por otro lado, seguimos añadiendo nuevos Plugin y ampliaciones funcionales a Checkmk, por lo que a veces los MKP se quedan obsoletos. La funcionalidad de esos Plugin y ampliaciones simplemente la proporciona el propio Checkmk de serie.

Por esta razón, cuando te prepares para una actualización, es muy recomendable que revises todos los MKP instalados. Así evitarás que paquetes incompatibles interfieran con la actualización, o que se produzcan servicios duplicados o al menos muy similares tras la actualización.

Para ello, comprueba los MKP que tienes instalados con nuestro Catálogo de Plugins de Checkmk y elimina los paquetes que contengan funciones que ahora proporciona Checkmk de forma nativa. También puedes aprovechar esta oportunidad para eliminar MKP que quizá sólo se hayan instalado para una prueba. Encontrarás una lista en el menú Setup, en Maintenance > Extension packages. En la línea de comandos, puedes mostrar las extensiones instaladas con el comando mkp list. Comprueba la salida de este comando para ver si hay extensiones que ya no necesites o que ni siquiera puedas identificar.

Checkmk admite la instalación de MKPs para una versión más reciente que la que se está ejecutando en ese momento, como preparación para futuras actualizaciones. Al realizar una actualización, se desactiva el paquete de la versión inferior de Checkmk y se activa el paquete de la versión superior. Los detalles se explican en el artículo sobre el uso de MKPs.

Precaución:Si has realizado cambios locales en archivos que originalmente procedían de MKPs, vuelve a empaquetar el MKP después de aumentar el número de versión. Durante una actualización, los archivos que hayan sido modificados de otro modo serán sobrescritos por los que contenga el MKP.

Los archivos locales te permiten personalizar y ampliar la funcionalidad proporcionada por Checkmk. Estos archivos se encuentran en la parte local de la estructura del directorio del site, es decir, en ~/local. Los archivos locales pueden causar problemas al actualizar, ya que es posible que dejen de coincidir con la nueva versión de Checkmk.

Puesto que no es posible que Checkmk intercepte y gestione las personalizaciones locales y cualquier extensión de terceros durante una actualización, debes comprobar tu site de Checkmk antes de una actualización para ver si utilizas archivos locales y cuáles.

Obtén una visión general de los archivos locales de tu sitio Checkmk ejecutando el siguiente comando como usuario del site (donde la opción -L garantiza que también se sigan los enlaces simbólicos):

En una instalación nueva de Checkmk, actualmente sólo verás en la lista un archivo llamado README.TXT. Cualquier cosa más allá de eso debería estar en lo alto de tu lista de solución de problemas en caso de que tengas problemas de actualización.

Lo ideal es que los archivos locales ya estén completamente empaquetados en MKPs. Utiliza mkp find para identificar los archivos sin empaquetar. Para más detalles sobre la creación de paquetes, consulta nuestro artículo sobre paquetes de extensiones Checkmk. Una vez empaquetada, cada extensión puede desactivarse o reactivarse como un elemento completo.

No hace falta que te recordemos la importancia de crear una copia de seguridad inmediatamente antes de cualquier actualización, para que no te arriesgues a perder demasiado de tu historial de monitorización en caso de que se produzca un fallo durante la actualización. Lo relevante en este punto es que una copia de seguridad regular también puede servirte para realizar pruebas de una actualización pendiente. Esta práctica te permite restaurar la copia de seguridad con un nombre alternativo, y luego utilizar el site newsite para probar la actualización antes de que se ponga en marcha:

Alternativamente, también puedes copiar tu site a través de omd cp. Para ello, sin embargo, es necesario detener un site activo durante un breve periodo de tiempo:

A continuación, ejecuta primero la actualización en este nuevo sitio clonado, por ejemplo, para comprobar que los cambios locales mencionados anteriormente se han realizado en el nuevo entorno. Si las pruebas con el sitio clonado han sido satisfactorias, normalmente querrás eliminarlo o, al menos, detenerlo antes de la actualización real del sitio de producción por motivos de espacio y rendimiento.

Como se ha descrito en la introducción, el primer paso de una actualización es la instalación de la nueva versión deseada de Checkmk. Esto se hace exactamente igual que en la instalación inicial, aunque será algo más rápido, ya que la mayoría de los paquetes dependientes ya están instalados. En el siguiente ejemplo instalamos el paquete para Ubuntu 22.04 (Jammy Jellyfish):

Nota: Cuando instales un paquete local a través de apt install, tienes que indicar la ruta de acceso al archivo .deb.

En cualquier momento puedes ver una lista de las versiones de Checkmk que tienes instaladas con el comando omd versions:

Una de estas versiones de la lista se marca con (default). Esta versión por defecto se utilizará automáticamente al crear nuevos sites, siempre que no se especifique otra versión con omd -V myversion create mysite. La versión por defecto actual puede consultarse con omd version, y puede modificarse con omd setversion:

La versión por defecto no desempeña ningún papel cuando se gestionan sitios existentes. El comando omd siempre se inicia con la versión adecuada al site para el que se llama al comando.

El comando omd sites proporciona una lista de los sites actuales y de las versiones que utilizan:

Una vez instalada la nueva versión deseada, se puede actualizar el site. Para ello no es necesario ningún permiso root. La mejor forma de hacerlo es como usuario del site:

Asegúrate de que el site se ha detenido:

La actualización -de hecho, el cambio a una versión diferente- puede realizarse ahora simplemente con el comando omd update:

Si hay más de una versión de destino disponible, se abrirá una lista de selección:

En la siguiente caja de diálogo, confirma la actualización seleccionada a la nueva versión:

Para mayor seguridad, cuando realices una actualización de edición de un Checkmk edición Raw a una de las ediciones comerciales al mismo tiempo que la actualización de versión, se te volverá a recordar este hecho:

Una parte importante de una actualización es el refresco de los archivos de configuración proporcionados originalmente. En este caso, los cambios que posiblemente haya realizado el usuario en estos archivos no se descartarán sin más, sino que se agruparán. Esto funciona de forma muy parecida a los sistemas de control de versiones, que intentan amalgamar los cambios realizados en un único archivo simultáneamente por varios desarrolladores.

Ocasionalmente -cuando los cambios afectan a la misma ubicación en el archivo- eso no funcionará, y se producirá un conflicto. Más adelante se explicará cómo resolver esos conflictos.

La actualización proporciona una lista de todos los archivos y directorios modificados (abreviada en el siguiente ejemplo):

Si aparece la línea Completed verifying site configuration resaltada en la salida anterior, el site se ha cambiado a la nueva versión:

... y ya puede iniciarse:

El desarrollo de software consiste, por supuesto, en cambios. Como siempre estamos trabajando activamente para mantener Checkmk moderno, a veces es inevitable recortar peso muerto y hacer cambios que resultan ser incompatibles. Eso significa que al actualizar posiblemente sea necesario adaptar tu configuración, o al menos deberías comprobarlo.

Un ejemplo típico de esta situación es el de los nuevos check plugin que sustituyen a los plugins existentes. Si utilizas uno de los plugins afectados, será necesario un nuevo descubrimiento de servicios en el host afectado.

Puedes encontrar una Vista general de todos los cambios en Checkmk, incluida una función de búsqueda, en nuestros Werks.

Sin embargo, es aún más práctica la función de búsqueda integrada en Checkmk. Después de iniciar sesión en el site, encontrarás un enlace resaltado en rojo en la parte superior del menú Help con el número de cambios incompatibles y aún no confirmados:

Checkmk realiza un seguimiento de los cambios incompatibles que se produjeron durante la actualización a la versión actual y te pide que los revises y, a continuación, los reconozcas:

Si abres esta página a través del enlace rojo del menú Help, sólo verás los "Werk" (es decir, los cambios) para los que hay que hacer algo y que, por tanto, están marcados con Incompatible - TODO. Puedes llamar a cada Werk individualmente, verlo y confirmarlo con un clic del ratón, y así reducir sucesivamente el número de cambios incompatibles abiertos. Además, el elemento de menú Help > Change log (works) te da acceso al historial completo de cambios de la versión principal actual.

¿Tienes curiosidad por saber qué ocurre exactamente "bajo el capó" de una actualización? ¿O han aparecido conflictos de datos cuando se está ejecutando omd update? Si es así, aquí tienes más información.

Durante omd update tienen lugar tres acciones:

¿Te gustaría automatizar las actualizaciones de software de Checkmk? Al principio puedes tener dificultades con las respuestas interactivas de omd update. Hay una solución sencilla para este caso: el comando tiene opciones que han sido especialmente concebidas para su uso en scripts:

Los valores posibles para --conflict= son:

A continuación se muestra un ejemplo del comando completo para una actualización automatizada a la versión 2.3.0p1.cee de mysite:

Mediante el && antes de omd start se impedirá el reinicio del site si el omd update es abortado por un error. Sustituye el && por un punto y coma (;) si definitivamente debe intentarse un inicio incluso en tal situación.

Si estás seguro de que sólo se está ejecutando un único site Checkmk en el servidor, el nombre que se utilizará en un script shell se puede atrapar simplemente en una variable:

Esto permite que la línea anterior sea independiente del nombre del site. Por ejemplo, un pequeño script shell podría tener este aspecto:

La razón técnica del enfoque de actualización descrito anteriormente reside en los protocolos utilizados: el site central accede a los datos de los sites remotos principalmente mediante lectura a través de Livestatus, y en el caso de una configuración central, con acceso de escritura adicional a través de una API HTTP no pública. En ambas situaciones, se da el caso de que las nuevas versiones introducen verdaderos superconjuntos de los protocolos utilizados. Así, un site central antiguo sólo utiliza un verdadero subconjunto de la funcionalidad de los sites remotos más recientes. Si el site central se actualizara primero, podría emitir llamadas a la API o solicitudes de Livestatus a los sites remotos que éstos aún no "entienden".

La diferencia de versión máxima de una versión principal se debe de nuevo al hecho de que la eliminación de interfaces va acompañada de un periodo de gracia de exactamente una versión. Por ejemplo, la web API ya no se utilizaba internamente en Checkmk 2.1.0, pero su eliminación no se produjo hasta la versión 2.2.0. Por este motivo, un site central 2.1.0 funciona con sites remotos 2.2.0, pero un site central 2.0.0 no funcionará con sites remotos 2.2.0.

Para facilitar estas actualizaciones escalonadas, Checkmk ofrece la posibilidad de almacenar paquetes de extensión con el mismo nombre en diferentes versiones: una que coincida con el site central más antiguo y otra con los sites remotos más recientes, por ejemplo. La versión adecuada se activará para cada site. Los detalles se describen en el artículo sobre paquetes de extensión (MKP).

Con la extensión de sitios del visor, los sitios del visor sólo podrán actualizarse después de los sitios cuyos datos muestran. Si un sitio del visor sólo muestra datos de sitios remotos, podrá actualizarse en cuanto éstos se actualicen. Si, por el contrario, también muestra datos del site central, la actualización del visor sólo podrá producirse en último lugar.

Este capítulo trata principalmente de una actualización a Checkmk Enterprise. También puedes actualizar a Checkmk Cloud en un solo paso, pero en este caso, consulta también las notas de la siguiente sección.

Como las ediciones comerciales tienen bastantes módulos y funciones adicionales, hay algunas cosas que debes tener en cuenta después de cualquier actualización. El punto crucial es que al crear nuevos sites en Checkmk Raw o en una de las ediciones comerciales, se establecen configuraciones predeterminadas diferentes.

En lo que respecta al núcleo de monitorización y al sistema de notificaciones, no hay diferencias entre Checkmk Enterprise y Checkmk Cloud. Dependiendo del enfoque de la implantación, a menudo utilizarás el conjunto de funciones más amplio sólo cuando añadas nuevos host. En algunos lugares, sin embargo, sigue siendo recomendable revisar la configuración existente.

Para una Vista general completa de la funcionalidad adicional, consulta el artículo sobre Checkmk Cloud.

Ten en cuenta que, en entornos distribuidos, siempre debe realizarse primero la actualización de la versión , antes de que pueda seguir la actualización de la edición. No se admite una secuencia diferente ni una actualización cruzada (actualización de la versión y actualización de la edición en una sola acción). Como procedimiento general, recomendamos la actualización sin conexión, en la que puedes saltar de cualquier edición inferior a cualquier edición superior.

Para dos escenarios de actualización solicitados con frecuencia(Checkmk Raw a Checkmk Enterprise y Checkmk Enterprise a Checkmk Cloud), es posible el funcionamiento mixto durante un periodo de tiempo limitado. Mientras que la actualización sin conexión funciona con todas las versiones, los dos escenarios en línea requieren al menos Checkmk 2.2.0p23.

Para preparar la migración de Checkmk Cloud a Checkmk Enterprise, debes realizar al menos los siguientes cambios:

Además, algunos servicios en la nube y dashboards dejarán de estar disponibles, por lo que tendrás que limpiar los servicios desaparecidos.

Si en Checkmk Cloud utilizabas el Plugin de Grafana de la "Tienda de Grafana", tendrás que sustituirlo por uno instalado desde el archivo zip.

Vista general de las diferencias entre Checkmk Cloud y Checkmk Enterprise en el artículo Checkmk Cloud.

Para preparar la migración de Checkmk Enterprise a Checkmk Raw, tendrás que hacer al menos los siguientes cambios:

Además, algunos dashboards, configuraciones de gráficos, plugins de notificación y agentes especiales dejarán de estar disponibles. Con el artículo Checkmk Enterprise puedes determinar cuánta funcionalidad de Checkmk Enterprise se perderá en caso de pasar a Checkmk Raw y dónde puede que tengas que hacer más ajustes.

Los escenarios de downgrade presentados en las dos secciones anteriores también pueden llevarse a cabo en entornos distribuidos. Ten en cuenta que, en los entornos distribuidos, siempre debe realizarse primero la actualización de la versión antes de poder realizar el downgrade de la edición. No se admite una secuencia diferente ni un crossgrade (actualización de la versión y downgrade de la edición en una sola acción).

No existe ningún escenario de downgrade en el que Checkmk admita una operación mixta entre ediciones diferentes. Por este motivo, te recomendamos encarecidamente que realices el downgrade de edición sin conexión. Para ello, procede del siguiente modo:

Por supuesto, puedes esperar hasta que todos los sites hayan sido degradados antes de reiniciarlos, lo que reducirá en cierta medida el número de notificaciones generadas.

La desinstalación de las versiones de Checkmk que ya no son necesarias se realiza mediante el administrador de paquetes del sistema operativo. Para ello, introduce el nombre del paquete instalado, no el nombre del archivo RPM/DEB original.
Importante: ¡Sólo elimina las versiones de Checkmk que ya no utilice ningún site!

Los sitios Checkmk que ya no son necesarios pueden eliminarse simplemente con omd rm (¡borrando así también todos los datos!):

He aquí cómo identificar qué paquetes Checkmk se están utilizando en sistemas basados en RPM:

El borrado se realiza con rpm -e:

Utiliza lo siguiente para identificar qué paquetes están instalados:

La desinstalación se realiza con dpkg --purge: