 |
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 nuovi siti con Checkmk Micro Core (CMC) come core. Se il tuo sito proviene da un'edizione precedente, può essere convertito retroattivamente da Nagios a CMC. La procedura è molto semplice:
Per prima cosa, arresta la tua istanza Checkmk:
OMD[mysite]:~$ omd stopPoi convertire:
OMD[mysite]:~$ omd config set CORE cmcSuccessivamente, non dimenticare di riavviare:
OMD[mysite]:~$ omd startAttenzione: Lo stato attuale del core (gli stati attuali degli host e dei servizi, ecc.) NON verrà riportato. Lo stato del sistema sarà comunque determinato di recente una volta che ogni controllo sarà stato eseguito con la nuova configurazione. Ogni host o servizio che non ha uno stato UP, o rispettivamente OK, farà scattare una nuova notifica. Se questo non è desiderato, disattiva le notifiche prima della conversione - con lo snap-in di controllo Master della barra laterale. Itempi di manutenzione programmata e i commenti, e allo stesso modo i dati storici sulle prestazioni negli RRD, saranno comunque riportati.
La cronologia degli eventi (Nagios-Log) sarà 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 riportare la cronologia degli eventi (ad es. per la disponibilità), copia i file necessari utilizzando la riga di comando:
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. Dal CMC a Nagios
Se dovessi scoprire che la tua configurazione non è ancora compatibile con il CMC (vedi sotto per i suggerimenti), puoi riconvertirti a Nagios in modo simile a quanto descritto sopra:
OMD[mysite]:~$ omd config set CORE nagiosNon è possibile effettuare il carryover dei tempi di manutenzione programmata, ecc. da CMC a Nagios, ma Nagios importerà il suo vecchio stato prima della migrazione a CMC.
2. Suggerimenti 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 1:1. 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 però hai scritto a mano alcune parti dei dati di Nagios o utilizzi costruzioni come extra_nagios_conf nel file main.mk, queste non possono essere processate. 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 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 della CMC cambia radicalmente il modo in cui i dati vengono raccolti e successivamente controllati. Pertanto, quando si passa alla CMC - soprattutto per le istanze con diverse migliaia di host - è probabilmente necessario controllare e regolare il numero di Checkmk Checker e fetcher preimpostati. La funzione di configurazione Analyze può fornire una prima indicazione in merito. Tuttavia, consigliamo vivamente di leggere il capitolo Processi ausiliari del manuale.
E per tutti coloro 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 non esitare ad aumentarla.
2.2. Gestore di eventi
Il CMC non supporta alcun gestore di eventi convenzionale di Nagios. Le edizioni commerciali, tuttavia, dispongono dei cosiddetti gestori di avvisi per questa funzione, che sono decisamente più flessibili. Possono essere configurati tramite Setup > Events > Alert handlers.
2.3. Dipendenze dai servizi
Al momento questo modulo non è supportato dal CMC. Poiché le dipendenze dai servizi sono laboriose da configurare in Nagios e non sono molto trasparenti per l'utente, non è prevista la loro implementazione.
2.4. Moduli del broker di eventi
Livestatus e il processo dei dati sulle prestazioni sono parte integrante del CMC. Altri moduli non possono essere caricati.
2.5. Escalation
L'escalation delle notifiche non avviene più nel core, bensì tramite notifiche rule-based.
2.6. Periodi di tempo
Per quanto riguarda i periodi di tempo, alcune condizioni di eccezione supportate da Nagios non sono possibili. Attualmente è supportato solo il formato YYY-MM-DD, ad es. 1970-12-18, ma non un formato come february -2. Con Setup > General > Time periods c'è comunque la possibilità di importare file di calendario in formato iCal.
2.7. Variabile di configurazione legacy_checks
La variabile di configurazione legacy_checks utilizzata per configurare i check attivi nelle vecchie versioni di Checkmk non esiste più. È naturalmente possibile eseguire i check attivi con il CMC, ma con un modulo un po' diverso.
Il motivo è che legacy_checks si riferisce a comandi definiti manualmente nella configurazione di Nagios e che di conseguenza non sono disponibili per la CMC. Al posto di questi puoi usare il più moderno custom_checks. Puoi gestirli con il set di regole Integrate Nagios plugins, che puoi trovare in Setup > Services > Other services- e tra l'altro puoi usarli anche senza la CMC.
Il seguente esempio mostra come modificare un controllo 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 da un core all'altro senza problemi.
2.8. Dati sulle prestazioni dei controlli sugli host
Il CMC utilizza lo Smart Ping come standard per i controlli dell'host. Questo significa che dopo il passaggio dal core Nagios:
all'inizio i controlli dell'host non forniscono dati sulle prestazioni, e
i controlli ping creati manualmente sugli host senza altri controlli generano dati sulle prestazioni per impostazione predefinita.
Se hai bisogno dei dati sulle prestazioni 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 devi rinunciare ai vantaggi di Smart Ping.