 |
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. Migrazione da Nagios a CMC
Le edizioni commerciali creano automaticamente nuove istanze con Checkmk Micro Core (CMC) come core. Se la tua istanza proviene da una versione precedente, può essere convertita a posteriori da Nagios a CMC. La procedura è molto semplice:
Per prima cosa, ferma la tua istanza Checkmk:
Quindi converti:
Dopodiché, non dimenticare di riavviare:
Attenzione: lo stato attuale del core (lo stato attuale di host e servizi, ecc.) NON verrà trasferito. Lo stato del sistema verrà comunque determinato ex novo una volta che ogni check sarà stato eseguito con la nuova configurazione. Qualsiasi host o servizio che non abbia uno stato "UP" o "OK" attiverà una nuova notifica. Se non lo desideri, disattiva le notifiche prima della conversione — utilizzando lo snap-in di controllo master nella barra laterale. I tempi di manutenzione programmata e i commenti, così come i dati storici sulle prestazioni negli RRD, verranno comunque trasferiti.
La cronologia degli eventi (Nagios-Log) verrà mantenuta in un formato compatibile dal CMC, ma in una posizione diversa (var/check_mk/core/history).
L'archivio dei log si trova in var/check_mk/core/archive.
Se desideri trasferire la cronologia degli eventi (ad es. per motivi di disponibilità), copia i file necessari utilizzando la riga di comando:
1.1. Da CMC a Nagios
Se dovessi scoprire che la tua configurazione non è ancora compatibile con CMC (vedi sotto per alcuni suggerimenti), puoi tornare a Nagios in modo simile a quanto descritto sopra:
Non è possibile trasferire da CMC a Nagios i tempi di manutenzione programmati, ecc. Nagios importerà tuttavia il suo stato precedente alla migrazione a CMC.
2. Consigli per la migrazione al CMC
Per mantenere il CMC il più snello ed efficiente possibile e per modernizzare alcuni componenti importanti, non tutte le funzioni di Nagios sono state riscritte alla lettera. Questo significa che potrebbe essere necessario modificare alcuni elementi della tua configurazione.
Il CMC non è in grado di importare i file di configurazione di Nagios.
Se tuttavia hai scritto a mano parti dei dati di Nagios o utilizzi costruzioni come extra_nagios_conf nel file main.mk, queste non possono essere elaborate.
Se hai sempre lavorato con il Setup dell'interfaccia web, non è necessaria alcuna modifica.
Nelle sezioni seguenti troverai un riepilogo di tutti gli elementi che potrebbero essere stati configurati manualmente in Nagios, ma che non possono essere realizzati (o per i quali è necessaria una procedura diversa) nel CMC:
2.1. Processi ausiliari
L'utilizzo del CMC cambia radicalmente il modo in cui i dati vengono raccolti e successivamente controllati. Pertanto, quando si passa al CMC - specialmente per istanze con diverse migliaia di host - è probabilmente necessario verificare e regolare il numero di Checkmk Checker e Fetcher preimpostati. La funzione Analizza configurazione può fornire una prima indicazione in merito. Tuttavia, ti consigliamo vivamente di leggere il capitolo sui processi ausiliari nel manuale.
E per tutti quelli che vanno di fretta:
Maximum concurrent Checkmk checkers = numero di core del processore sul tuo server
Maximum concurrent Checkmk fetchers = Ogni fetcher richiede circa 50 MB di memoria - quindi sentiti libero di aumentare il valore.
2.2. Gestore di eventi
Il CMC non supporta il gestore di eventi convenzionale di Nagios. Le edizioni commerciali dispongono tuttavia dei cosiddetti gestori di avvisi per questa funzione, che sono notevolmente più flessibili. Possono essere configurati tramite Setup > Events > Alert handlers.
2.3. Dipendenze dei servizi
Al momento questa funzione non è supportata dal CMC. Poiché le dipendenze dei servizi sono laboriose da configurare in Nagios e non sono molto trasparenti per l'utente, non è prevista la loro implementazione in questo modulo.
2.4. Moduli broker di eventi
Livestatus e l'elaborazione dei dati sulle prestazioni sono parte integrante del CMC. Non è possibile caricare altri moduli.
2.5. Escalation
L'escalation delle notifiche non viene più gestita nel core, ma tramite notifiche rule-based.
2.6. Periodi di tempo
Per quanto riguarda i periodi di tempo, alcune delle condizioni di eccezione supportate da Nagios non sono possibili.
Attualmente è supportato solo il formato YYY-MM-DD, ad esempio 1970-12-18, ma non un formato come february -2.
Con Setup > General > Time periods è tuttavia possibile importare file di calendario in formato iCal.
2.7. Variabile di configurazione legacy_checks
La variabile di configurazione legacy_checks, utilizzata per configurare gli active checks nelle versioni precedenti di Checkmk, non esiste più.
Naturalmente puoi eseguire active checks con il CMC, ma in una forma leggermente diversa.
Il motivo è che le variabili di configurazione legacy_checks fanno riferimento a comandi definiti manualmente nella configurazione di Nagios e che di conseguenza non sono disponibili per il CMC.
Al loro posto puoi utilizzare le più moderne variabili di configurazione custom_checks.
Queste si gestiscono con il set di regole Integrate Nagios plugins, che trovi in Setup > Services > Other services — e, tra l’altro, puoi utilizzarle anche senza il CMC.
L'esempio seguente mostra come modificare un check legacy esistente …
# 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 ),
]… nel nuovo formato di 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 )]Il nuovo metodo funziona anche con un core Nagios, quindi dopo la conversione puoi switchare senza problemi da un core all'altro.
2.8. Dati sulla performance dai controlli host
Il CMC utilizza lo Smart Ping come standard per i controlli host. Ciò significa che dopo il passaggio dal core Nagios:
i controlli host inizialmente non forniscono dati sulla performance, e
i controlli ping creati manualmente sugli host senza altri controlli generano dati sulla performance per impostazione predefinita.
Se hai bisogno dei dati sulla performance del ping per un singolo host o per tutti gli host, ti consigliamo di aggiungere un active check tramite ping per gli host desiderati con il set di regole "Check hosts with PING (ICMP Echo Request)".
Se desideri mantenere i database Round Robin (RRD) esistenti, puoi semplicemente — mentre il core è fermo — rinominare i file nelle directory var/pnp4nagios/perfdata/<hostname> che iniziano con _HOST_: da _HOST_* a PING*.
In alternativa, con il set di regole Host check command puoi disattivare Smart Ping e sostituirlo con un ping convenzionale che funziona internamente come al solito con check_icmp.
In questo caso non è necessario rinominare gli RRD, ma dovrai comunque rinunciare ai vantaggi di Smart Ping.