 |
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. Migración de Nagios a CMC
Las ediciones comerciales crean automáticamente nuevos sitios con Checkmk Micro Core (CMC) como núcleo. Si tu sitio proviene de una versión anterior, se puede convertir retroactivamente de Nagios a CMC. El procedimiento en sí es muy sencillo:
Primero, detén tu site Checkmk:
A continuación, convierte:
Después, no te olvides de reiniciar:
Atención: El estado actual del core (los estados actuales de los hosts y servicios, etc.) NO se transferirá. El estado del sistema se determinará de nuevo en cualquier caso una vez que se haya ejecutado cada check con la nueva configuración. Cualquier host o servicio que no tenga un estado «UP» o «OK», respectivamente, activará una nueva notificación. Si no quieres que esto ocurra, desactiva las notificaciones antes de la conversión, usando el snap-in de Control maestro de la barra lateral. Sin embargo, se mantendrán los tiempos de mantenimiento programados y los comentarios, así como los datos históricos de rendimiento en los RRD.
El historial de eventos (Nagios-Log) se mantendrá en un formato compatible por parte del CMC, pero en una ubicación diferente (var/check_mk/core/history).
El archivo de registros se encuentra en var/check_mk/core/archive.
Si deseas conservar el historial de eventos (por ejemplo, para la disponibilidad), copia los archivos necesarios utilizando la línea de comandos:
1.1. De CMC de vuelta a Nagios
Si descubres que tu configuración aún no es compatible con CMC (consulta los consejos a continuación), puedes volver a Nagios de forma similar a la descrita anteriormente:
No es posible transferir los tiempos de mantenimiento programados, etc., de CMC a Nagios. Sin embargo, Nagios importará su estado anterior a la migración a CMC.
2. Consejos para migrar al CMC
Para que el CMC sea lo más ligero y eficiente posible, y para modernizar algunos componentes importantes, no se han reescrito todas las funciones de Nagios de forma exacta. Esto significa que puede que tengas que modificar algunos elementos de tu configuración.
El CMC, en principio, no puede importar archivos de configuración de Nagios.
Sin embargo, si has escrito a mano partes de los datos de Nagios o utilizas construcciones como «extra_nagios_conf» en el archivo «main.mk», estas no se pueden procesar.
Si siempre has trabajado con la configuración de la interfaz web, no es necesario realizar ninguna modificación.
En las siguientes secciones encontrarás un resumen de todos los items que podrían haberse configurado manualmente en Nagios, pero que no se pueden realizar (o para los que se necesita un procedimiento diferente) en el CMC:
2.1. Procesos auxiliares
El uso del CMC cambia radicalmente la forma en que se recopilan y posteriormente se comprueban los datos. Por lo tanto, al switchear al CMC —especialmente en casos con varios miles de hosts— probablemente sea necesario comprobar y ajustar el número de Checkmk Checkers y Fetchers preconfigurados. La función «Analizar configuración» puede darte una primera indicación al respecto. Sin embargo, te recomendamos encarecidamente que leas el capítulo sobre procesos auxiliares del manual.
Y para todos aquellos que tienen prisa:
Maximum concurrent Checkmk checkers = número de núcleos del procesador de tu servidor
Maximum concurrent Checkmk fetchers = Cada fetcher requiere aproximadamente 50 MB de memoria, así que no dudes en subirlo.
2.2. Gestor de eventos
El CMC no admite ningún alert handler convencional de Nagios. Sin embargo, las ediciones comerciales cuentan con los denominados 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 de servicio
Actualmente, el CMC no admite esta función. Dado que las dependencias de servicio son laboriosas de configurar en Nagios y no resultan muy transparentes para el usuario, no hay planes de implementarlas de esta forma.
2.4. Módulos del gestor de eventos
Livestatus y el procesamiento de datos de rendimiento son parte integral del CMC. No se pueden cargar otros módulos.
2.5. Escalaciones
La escalación de notificaciones ya no se realiza en el core, sino a través de notificaciones basadas en reglas.
2.6. Periodos de tiempo
En cuanto a los periodos de tiempo, algunas de las condiciones de excepción que admite Nagios no son posibles.
Actualmente solo 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, que se usaba para configurar comprobaciones activas en versiones anteriores de Checkmk, ya no existe.
Por supuesto, puedes ejecutar comprobaciones activas con el CMC, pero de una forma algo diferente.
El motivo es que las comprobaciones «legacy_checks» hacen referencia a comandos definidos manualmente en la configuración de Nagios y que, por lo tanto, no están disponibles para el CMC.
En su lugar, puedes usar las comprobaciones «custom_checks», que son más modernas.
Las gestionas con el conjunto de reglas «Integrate Nagios plugins», que encontrarás en «Setup > Services > Other services»; por cierto, también puedes usarlas sin el CMC.
El siguiente ejemplo muestra cómo cambiar una check heredada 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 core de Nagios, por lo que tras la conversión podrás switchear sin problemas entre ambos cores.
2.8. Datos de rendimiento de las comprobaciones de host
El CMC utiliza Smart Ping como estándar para las comprobaciones de host. Esto significa que, tras un cambio desde el core de Nagios:
las comprobaciones del host no proporcionan inicialmente datos de rendimiento, y
las comprobaciones de ping creadas manualmente en hosts sin otras comprobaciones generan datos de rendimiento por defecto.
Si necesitas los datos de rendimiento de ping para un único host o para todos los hosts, te recomendamos que añadas una check activa mediante 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, simplemente —mientras el core está detenido— cambia el nombre de los archivos en los directorios var/pnp4nagios/perfdata/<hostname> que empiezan por _HOST_: de _HOST_* a PING*.
Como alternativa, 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 cambiar el nombre de los RRD, pero debes renunciar a las ventajas de Smart Ping.