 |
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. |
1. Migrar de Nagios a la CMC
Las ediciones comerciales crean automáticamente nuevos sites con el Checkmk Micro Core (CMC ) como núcleo. Si tu site procede de una versión anterior, se puede convertir retrospectivamente de Nagios a CMC. El procedimiento en sí es muy sencillo:
Primero, detén tu site Checkmk:
OMD[mysite]:~$ omd stopA continuación, conviértelo:
OMD[mysite]:~$ omd config set CORE cmcDespués, no olvides reiniciar:
OMD[mysite]:~$ omd startAtención: El estado actual del núcleo (los estados actuales de hosts y servicios, etc.) NO se transferirá. En cualquier caso, el estado del sistema se determinará de nuevo una vez que se haya ejecutado cada check con la nueva configuración. Cualquier host o servicio que no tenga un estado UP, o respectivamente OK, activará una nueva notificación. Si no quieres que esto ocurra, desactiva las notificaciones antes de la conversión, con el snap-in de Control maestro de la barra lateral. Sin embargo, se transferiránlos tiempos de inactividad programados y los comentarios, así como los datos históricos de rendimiento de los RRD.
La CMC mantendrá el historial de eventos (Nagios-Log) en un formato compatible, pero en una ubicación diferente (var/check_mk/core/history). El archivo de logs se encuentra en var/check_mk/core/archive. Si deseas transferir el historial de eventos (por ejemplo, para la disponibilidad), copia los archivos necesarios utilizando la línea de comandos:
OMD[mysite]:~$ cp var/nagios/nagios.log var/check_mk/core/history
OMD[mysite]:~$ mkdir -p var/check_mk/core/archive && [[ -e var/nagios/archive/ ]] && cp var/nagios/archive/ var/check_mk/core/archive1.1. De la CMC a Nagios
Si descubres que tu configuración aún no es compatible con la CMC ( más adelante encontrarás consejos), puedes volver a convertirla a Nagios de forma similar a la descripción anterior:
OMD[mysite]:~$ omd config set CORE nagiosNo es posible transferir los tiempos de mantenimiento programados, etc. de la CMC a Nagios, pero Nagios importará su estado anterior a la migración a la CMC.
2. Consejos para migrar a la CMC
Para mantener la CMC lo más delgada y eficiente posible, y modernizar algunos componentes importantes, no todas las funciones de Nagios se han reescrito 1:1. Esto significa que puede ser necesario modificar algunos elementos de tu configuración.
Fundamentalmente, la CMC no puede importar archivos de configuración de Nagios. Sin embargo, si has escrito partes de los datos de Nagios a mano, o utilizas construcciones como extra_nagios_conf en el archivo main.mk, éstas no se pueden procesar. Si siempre has trabajado con la configuración de la interfaz web, no es necesaria ninguna modificación.
En las siguientes secciones encontrarás un resumen de todos los items que se podrían haber configurado manualmente en Nagios, pero que no se pueden realizar (o para los que se necesita un procedimiento diferente) en la CMC:
2.1. Procesos auxiliares
El uso de la CMC cambia fundamentalmente la forma en que se recopilan los datos y se comprueban posteriormente. Por lo tanto, al cambiar a la CMC -especialmente en instancias con varios miles de host- probablemente sea necesario comprobar y ajustar el número de Checkmk Checker y fetcher preestablecidos. La función de configuración Analizar puede proporcionar una indicación inicial al respecto. Sin embargo, recomendamos encarecidamente leer el capítulo Procesos auxiliares del manual.
Y para todos aquellos que tengan prisa
Maximum concurrent Checkmk checkers = número de núcleos de procesador de tu servidor
Maximum concurrent Checkmk fetchers = cada fetcher requiere aproximadamente 50 MB de memoria, así que no dudes en aumentarla.
2.2. Gestor de eventos
La CMC no admite ningún manejador de eventos convencional de Nagios. Sin embargo, las ediciones comerciales disponen de los llamados alert handlers para esta función, que son notablemente más flexibles. Se pueden configurar a través de Setup > Events > Alert handlers.
2.3. Dependencias del servicio
En la actualidad, la CMC no admite esta función. Como las dependencias de servicio son laboriosas de configurar en Nagios, y no son muy transparentes para el usuario, no hay planes para implementarlas de esta forma.
2.4. Módulos del corredor de eventos
Livestatus y el proceso de datos de rendimiento son parte integrante de la CMC. No se pueden cargar otros módulos.
2.5. Escalaciones
El escalado de notificaciones ya no se realiza en el núcleo, sino mediante notificaciones basadas en reglas.
2.6. Periodos de tiempo
Para los periodos de tiempo no son posibles algunas de las condiciones de excepción que admite Nagios. Actualmente sólo se admite el formato YYY-MM-DD, por ejemplo 1970-12-18, pero no un formato como february -2. Sin embargo, con Setup > General > Time periods existe la posibilidad de importar archivos de calendario en formato iCal.
2.7. Variable de configuración legacy_checks
La variable de configuración legacy_checks utilizada para configurar los checks activos en versiones anteriores de Checkmk ya no existe. Naturalmente, puedes ejecutar checks activos con la CMC, pero de forma algo diferente.
El motivo es que legacy_checks se refiere a comandos que se definen manualmente en la configuración de Nagios y que, por tanto, no están disponibles para la CMC. En lugar de éstos, puedes utilizar los más modernos custom_checks. Éstos se gestionan con el conjunto de reglas Integrate Nagios plugins, que puedes encontrar en Setup > Services > Other services- y, por cierto, también puedes utilizarlos sin la CMC.
El siguiente ejemplo muestra cómo cambiar un check heredado existente ...
# Definition of the Nagios command
extra_nagios_conf += r"""
define command {
command_name check-my-foo
command_line $USER1$/check_foo -H $HOSTADDRESS$ -w $ARG1$ -c $ARG2$
}
"""
# Create service definition
legacy_checks += [
(( "check-my-foo!20!40", "FOO", True), [ "foohost", "othertag" ], ALL_HOSTS ),
]... al nuevo formato de custom_checks:
custom_checks += [
({
'command_name': 'check-my-foo',
'service_description': 'FOO',
'command_line': 'check_foo -H $HOSTADDRESS$ -w 20 -c 40',
'has_perfdata': True,
},
[ "foohost", "othertag" ],
ALL_HOSTS )]El nuevo método también funciona con un núcleo Nagios, de modo que tras la conversión puedes alternar entre ambos núcleos sin problemas.
2.8. Datos de rendimiento de los checks de host
La CMC utiliza el Smart Ping como estándar para las comprobaciones de host, lo que significa que tras un cambio del núcleo Nagios:
las comprobaciones de host al principio no proporcionan datos de rendimiento, y
los checks de ping creados manualmente en hosts sin otros checks generan datos de rendimiento por defecto.
Si necesitas los datos de rendimiento de ping para un único host, o para todos, te recomendamos que añadas un check activo por ping para los hosts deseados con el conjunto de reglas Check hosts with PING (ICMP Echo Request).
Si deseas mantener las bases de datos Round Robin (RRD) existentes, puedes simplemente -mientras el núcleo está parado- renombrar los archivos de los directorios var/pnp4nagios/perfdata/<hostname> que empiezan por _HOST_: de _HOST_* a PING*.
Alternativamente, con el conjunto de reglas Host Check Command puedes desactivar Smart Ping y sustituirlo por un ping convencional que funcione internamente como de costumbre con check_icmp. En este caso no necesitas renombrar las RRD, pero sin embargo debes renunciar a las ventajas de Smart Ping.