Aggiornamenti e upgrade

Quando si esegue l'aggiornamento a una versione principale superiore, è necessario passare sempre alla versione principale successiva, senza saltare alcuna versione principale intermedia. Se desideri passare dalla 2.2.0 alla 2.4.0, esegui prima l'aggiornamento alla 2.3.0. Il motivo di questa procedura è semplice: a volte ci sono così tante modifiche tra due versioni principali che saltarne una causerebbe problemi. Utilizza sempre la versione patch più recente quando esegui l'aggiornamento.

Questo vale anche per la versione sorgente. Un aggiornamento dalla 2.2.0p1 alla 2.4.0p24 segue quindi questo percorso:

2.2.0p1 2.2.0p47 2.3.0p45 2.4.0p24

Il comando omd update permette anche un "aggiornamento" a una versione precedente. Questa procedura è pensata solo per i casi di regressione.

Il tuo sistema di monitoraggio può essere esteso in modo abbastanza semplice e comodo utilizzando i pacchetti di estensione Checkmk (MKP). Da un lato, è possibile che alcuni MKP più vecchi non vengano più mantenuti e quindi non siano più compatibili con le versioni più recenti di Checkmk. D'altro canto, continuiamo ad aggiungere nuovi plug-in ed estensioni funzionali a Checkmk, motivo per cui gli MKP a volte diventano obsoleti. Le funzionalità di questi plug-in ed estensioni sono semplicemente fornite da Checkmk stesso come standard.

Per questo motivo, quando ti prepari per un aggiornamento, ti consigliamo vivamente di controllare tutti gli MKP installati. Questo eviterà che pacchetti incompatibili interferiscano con l'aggiornamento o che, dopo l'aggiornamento, si creino servizi duplicati o almeno molto simili.

Per farlo, confronta i tuoi MKP installati con il nostro catalogo dei plugin per i controlli e rimuovi tutti i pacchetti che contengono funzioni ora fornite nativamente da Checkmk. Puoi anche cogliere l'occasione per rimuovere gli MKP che potrebbero essere stati installati solo per una prova. Puoi trovare un elenco nel menu "Setup" alla voce "Maintenance > Extension packages". Dalla riga di comando, puoi visualizzare le estensioni installate con il comando "mkp list". Check l'output di questo comando per individuare le estensioni che non servono più o che non riesci nemmeno a identificare.

Checkmk supporta l'installazione di MKP per una versione più recente di quella attualmente in esecuzione, in preparazione di futuri aggiornamenti. Quando si esegue un aggiornamento, il pacchetto per la versione Checkmk precedente viene disabilitato e quello per la versione successiva viene abilitato. I dettagli sono spiegati nell'articolo sull'uso degli MKP.

Attenzione: se hai apportato modifiche locali a file che originariamente provenivano da MKP, ricompila l'MKP dopo aver aumentato il numero di versione. Durante un aggiornamento, i file che sono stati modificati in altro modo verranno sovrascritti da quelli contenuti nell'MKP.

I file locali ti consentono di personalizzare ed estendere le funzionalità fornite da Checkmk. Questi file si trovano nella parte locale della struttura delle directory dell'istanza, ovvero in ~/local. I file locali possono causare problemi durante l'aggiornamento, poiché potrebbero non corrispondere alla nuova versione di Checkmk.

Poiché Checkmk non è in grado di intercettare e handle le personalizzazioni locali e le estensioni di terze parti durante un aggiornamento, dovresti controllare la tua istanza Checkmk prima di un aggiornamento per verificare se e quali file locali stai utilizzando.

Ottieni una panoramica dei file locali della tua istanza Checkmk eseguendo il seguente comando come utente dell’istanza (dove l'opzione -L assicura che vengano seguiti anche i collegamenti simbolici):

In una nuova installazione di Checkmk, al momento vedrai elencato solo un file chiamato README.TXT. Qualsiasi cosa oltre a questo dovrebbe essere in cima alla tua lista di risoluzione dei problemi nel caso in cui avessi difficoltà con l'aggiornamento.

Idealmente, i file locali sono già completamente impacchettati in MKP. Usa mkp find per identificare i file non impacchettati. Per ulteriori dettagli sulla creazione dei pacchetti, consulta il nostro articolo sui pacchetti di estensione di Checkmk. Una volta impacchettata, ogni estensione può essere disattivata o riattivata come elemento completo.

Non c'è bisogno di ricordarti l'importanza di creare un backup immediatamente prima di qualsiasi aggiornamento, in modo da non rischiare di perdere gran parte della tua cronologia di monitoraggio in caso di errore durante l'aggiornamento. Ciò che è rilevante a questo punto è che un backup regolare può anche tornarti utile per eseguire prove di un aggiornamento in sospeso. Questa pratica ti consente di effettuare il ripristino del backup con un nome alternativo e quindi utilizzare l'istanza newsite per testare l'aggiornamento prima che venga pubblicato:

In alternativa puoi anche copiare la tua istanza tramite omd cp. Per farlo, però, è necessario arrestare l'istanza live per un breve periodo:

Esegui quindi l'aggiornamento prima su questa nuova istanza clonata, ad esempio per verificare che le modifiche locali sopra menzionate siano state apportate nel nuovo ambiente. Se i test con l'istanza clonata hanno avuto esito positivo, di solito è consigliabile eliminarla o almeno arrestarla prima dell'aggiornamento effettivo dell'istanza di produzione per motivi di spazio e performance.

Come descritto nell'introduzione, il primo passo per un aggiornamento è l'installazione della nuova versione desiderata di Checkmk. Questo si ottiene esattamente allo stesso modo dell'installazione iniziale — tuttavia, procederà un po' più rapidamente poiché la maggior parte dei pacchetti richiesti è già stata installata. Nell'esempio seguente installiamo un pacchetto per Ubuntu 24.04 (Noble Numbat):

Nota: durante l'installazione di un pacchetto locale tramite apt install, devi specificare il percorso di download del file .deb.

Puoi visualizzare in qualsiasi momento un elenco delle versioni di Checkmk installate con il comando omd versions:

Una delle versioni elencate è contrassegnata con (default). Questa versione predefinita verrà utilizzata automaticamente durante la creazione di nuove istanze, a meno che non venga specificata un'altra versione con omd -V myversion create .... La versione predefinita attuale può essere interrogata con omd version e può essere modificata con omd setversion:

La versione predefinita non ha alcun ruolo nella gestione delle istanze esistenti. Il comando omd inizia sempre con la versione appropriata all'istanza per cui viene chiamato il comando.

Il comando omd sites fornisce un elenco delle istanze attuali e delle versioni che utilizzano:

Una volta completata l’installazione della nuova versione desiderata, è possibile aggiornare il sito. Per farlo non sono necessari permessi di tipo `root`. Il modo migliore per farlo è come utente dell’istanza:

Assicurati che l'istanza sia stata arrestata:

L'aggiornamento — che in pratica significa switchare a una versione diversa — ora può essere eseguito semplicemente con il comando omd update:

Se è disponibile più di una versione di destinazione, si aprirà un elenco di selezione:

Nella box di dialogo seguente, conferma l'aggiornamento selezionato alla nuova versione:

Per sicurezza, quando esegui un upgrade da una versione della Comunità Checkmk a una delle edizioni commerciali contemporaneamente all'aggiornamento della versione, ti verrà ricordato nuovamente questo fatto:

Una parte importante dell'aggiornamento è l'aggiornamento dei file di configurazione forniti in origine. In questo caso, le modifiche che l'utente potrebbe aver apportato a questi file non verranno semplicemente ignorate, ma verranno invece unite. Questo funziona in modo molto simile ai sistemi di controllo delle versioni che cercano di unire le modifiche apportate a un singolo file contemporaneamente da più sviluppatori.

Occasionalmente — quando le modifiche interessano la stessa posizione nel file — ciò non funziona e si verifica un conflitto. Come risolvere tali conflitti verrà spiegato più avanti.

L'aggiornamento fornisce un elenco di tutti i file e le directory modificati (abbreviato nell'esempio seguente):

Se viene visualizzata la riga Completed verifying site configuration evidenziata nell'output sopra, l'istanza è stata switchata alla nuova versione:

… e poi puoi iniziare:

Lo sviluppo del software consiste ovviamente in modifiche. Poiché lavoriamo sempre attivamente per mantenere Checkmk al passo con i tempi, a volte è inevitabile eliminare il superfluo e apportare modifiche che si rivelano incompatibili. Ciò significa che durante l'aggiornamento potrebbe essere necessario adattare la tua configurazione, o almeno controllarla.

Un tipico esempio di una situazione del genere è dato dai nuovi plug-in di controllo che sostituiscono quelli esistenti. Se utilizzi uno dei plug-in interessati, sarà necessaria una nuova scoperta del servizio sull'host interessato.

Una panoramica di tutte le modifiche in Checkmk, inclusa una funzione di ricerca, è disponibile online nel nostro Werks.

Ancora più pratica, però, è la funzione di ricerca integrata in Checkmk. Dopo aver effettuato l'accesso all'istanza, troverai un link evidenziato in rosso nella parte superiore del menu "Help" con il numero di modifiche incompatibili e non ancora confermate:

Checkmk ha traccia delle modifiche incompatibili avvenute durante l'aggiornamento alla versione attuale e ti chiede di esaminarle e poi dare la conferma:

Se apri questa pagina tramite il link rosso nel menu "Help", vedrai solo i "Werk" (cioè le modifiche) per i quali è necessario intervenire e che sono quindi contrassegnati con "Incompatible - TODO". Puoi richiamare ogni Werk singolarmente, effettuare la visualizzazione, confermarlo con un clic del mouse — e ridurre così progressivamente il numero di modifiche incompatibili in sospeso. Inoltre, la voce di menu "Help > Change log (works)" ti dà accesso alla cronologia completa delle modifiche nella versione principale attuale.

Sei curioso di sapere cosa succede esattamente "dietro le quinte" di un aggiornamento? Oppure sono comparsi conflitti di dati durante l'esecuzione di "omd update"? In tal caso, ecco qualche approfondimento.

Durante l'esecuzione di omd update vengono eseguite tre azioni:

Vuoi automatizzare gli aggiornamenti software di Checkmk? All'inizio potresti avere difficoltà con le risposte interattive di omd update. C'è una soluzione semplice per questo scenario. Il comando ha delle opzioni pensate appositamente per l'uso negli script:

I valori possibili per --conflict= sono:

Di seguito trovi un esempio del comando completo per un aggiornamento automatico alla versione 2.4.0p24.cre di mysite:

Grazie all'&& prima di omd start, il riavvio dell'istanza verrà impedito se l'omd update viene interrotto da un errore. Sostituisci && con un punto e virgola (;) se vuoi che il riavvio venga tentato anche in una situazione del genere.

Se sei certo che sul server sia in esecuzione una sola istanza Checkmk, il nome da utilizzare in un shell script può essere semplicemente inserito in una variabile:

Questo permette alla riga sopra di essere indipendente dal nome dell’istanza. Ad esempio, un piccolo shell script potrebbe essere simile a questo:

Il motivo tecnico dell'approccio di aggiornamento descritto sopra risiede nei protocolli utilizzati: L'istanza centrale accede ai dati sulle istanze remote principalmente tramite lettura tramite Livestatus e, nel caso di un Setup centrale, con accesso in scrittura aggiuntivo tramite un'API HTTP non pubblica. In entrambe le situazioni, le nuove versioni introducono veri e propri superset dei protocolli utilizzati. Pertanto, un'istanza centrale più vecchia utilizza solo un vero sottoinsieme delle funzionalità delle istanze remote più recenti. Se l'istanza centrale venisse aggiornata per prima, potrebbe inviare chiamate API o richieste Livestatus alle istanze remote che queste ultime non sono ancora in grado di "comprendere".

La differenza massima di una versione principale deriva ancora una volta dal fatto che la rimozione delle interfacce è accompagnata da un periodo di grazia di esattamente una versione.

Per facilitare questi aggiornamenti graduali, Checkmk offre la possibilità di memorizzare pacchetti di estensione con lo stesso nome in versioni diverse — ad esempio, una che corrisponde all'istanza centrale più vecchia e una che corrisponde alle istanze remote più recenti. Per ogni istanza verrà attivata la versione appropriata. I dettagli sono descritti nell'articolo sui pacchetti di estensione (MKP).

Con l'estensione delle istanze-viewer, queste possono essere aggiornate solo dopo le istanze remote di cui visualizzano i dati. Se un'istanza-viewer mostra solo i dati delle istanze remote, può essere aggiornata non appena queste vengono aggiornate. Se, invece, mostra anche i dati dell'istanza centrale, l'aggiornamento dell'istanza-viewer può avvenire solo per ultimo.

Questo capitolo tratta principalmente l'aggiornamento a Checkmk Pro dall'. Puoi anche passare a Checkmk Ultimate in un unico passaggio, ma in questo caso fai riferimento anche alle note nella sezione seguente.

Poiché le edizioni commerciali dispongono di numerosi moduli e funzionalità aggiuntivi, ci sono alcuni aspetti da tenere a mente dopo qualsiasi aggiornamento. Il punto cruciale è che quando si creano nuove istanze in Comunità Checkmk o in una delle edizioni commerciali, vengono impostate diverse impostazioni predefinite.

Per quanto riguarda il nucleo di monitoraggio e il sistema di notifica, non ci sono differenze tra Checkmk Pro e Checkmk Ultimate. A seconda dell'obiettivo del deployment, spesso utilizzerai il set di funzionalità più ampio solo quando aggiungi nuovi host. In alcuni casi, tuttavia, è comunque consigliabile rivedere le impostazioni esistenti.

Per una panoramica completa delle funzionalità aggiuntive, consulta l'articolo su Checkmk Ultimate.

Tieni presente che negli ambienti distribuiti, l'aggiornamento della versione deve sempre essere eseguito prima che possa seguire l'aggiornamento dell'edizione. Una sequenza diversa o un crossgrade (aggiornamento della versione e dell'edizione in un'unica azione) non è supportato. Come procedura generale, consigliamo l'aggiornamento offline, in cui puoi passare da qualsiasi edizione inferiore a qualsiasi edizione superiore.

Per due scenari di aggiornamento richiesti frequentemente (da Comunità Checkmk a Checkmk Pro e da Checkmk Pro a Checkmk Ultimate), è possibile un'operazione mista per un periodo di tempo limitato.

In preparazione al downgrade da Checkmk Ultimate a Checkmk Pro, devi apportare almeno le seguenti modifiche:

Inoltre, alcuni servizi cloud e dashboard non saranno più disponibili. Di conseguenza, dovrai ripulire i servizi scomparsi.

Se con Checkmk Ultimate utilizzavi il plug-in Grafana dal "Grafana Store", dovrai sostituirlo con uno installato dall'archivio zip.

Una panoramica delle differenze tra Checkmk Ultimate e Checkmk Pro è fornita dall'articolo su Checkmk Ultimate.

Per prepararti al downgrade da Checkmk Pro a Comunità Checkmk, dovrai apportare almeno le seguenti modifiche:

Inoltre, alcune dashboard, impostazioni dei grafici, plug-in di notifica e special agents non saranno più disponibili. Con l'articolo su Checkmk Pro puoi determinare quante funzionalità di Checkmk Pro andranno perse in caso di downgrade a Comunità Checkmk e dove potrebbe essere necessario apportare ulteriori modifiche.

Gli scenari di downgrade presentati nelle due sezioni precedenti possono essere eseguiti anche in ambienti distribuiti. Tieni presente che negli ambienti distribuiti, l’aggiornamento della versione deve sempre essere eseguito prima che possa seguire il downgrade dell’edizione. Una sequenza diversa o un crossgrade (aggiornamento della versione e downgrade dell’edizione in un’unica operazione) non è supportato.

Non esiste uno scenario di downgrade in cui Checkmk supporti un'operazione mista tra edizioni diverse. Per questo motivo, ti consigliamo vivamente di eseguire il downgrade dell'edizione offline. Per farlo, procedi come segue:

Naturalmente, puoi aspettare che tutte le istanze siano state sottoposte al downgrade prima di riavviarle, il che ridurrà in parte il numero di notifiche generate.

La disinstallazione delle versioni di Checkmk non più necessarie viene eseguita utilizzando il gestore di pacchetti del sistema operativo. Per farlo, inserisci il nome del pacchetto installato, non il nome del file RPM/DEB originale.
Importante: elimina solo le versioni di Checkmk che non vengono più utilizzate da nessuna istanza!

Le istanze Checkmk che non servono più possono essere semplicemente rimesse con omd rm (cancellando così anche tutti i dati!):

Usa quanto segue per identificare quali pacchetti sono stati installati:

La disinstallazione viene eseguita con dpkg --purge:

Ecco come identificare quali pacchetti Checkmk vengono utilizzati nei sistemi basati su RPM:

L'eliminazione viene eseguita con rpm -e: