Aggiornamenti e upgrade

Quando si esegue l'aggiornamento a una versione maggiore, è sempre necessario eseguire l'aggiornamento passo dopo passo attraverso tutte le versioni intermedie disponibili fino a raggiungere la versione desiderata, senza saltare le versioni intermedie. Ad esempio, se vuoi aggiornare dalla versione 2.1.0 alla versione 2.3.0, aggiorna prima alla versione intermedia 2.2.0. Il motivo di questa procedura è semplice: a volte ci sono semplicemente così tanti cambiamenti tra due versioni maggiori che saltare le versioni può causare problemi.

Il comando omd update consente anche un "aggiornamento" a una versione inferiore. Questa procedura è prevista solo per le regressioni. Dopo un tale aggiornamento in senso inverso, saranno necessari molti aggiustamenti per rendere la configurazione e l'ambiente di esecuzione nuovamente compatibili, soprattutto, ma non solo, nel caso di un "aggiornamento" a una versione principale inferiore. Per questo motivo sconsigliamo vivamente questa procedura e non forniremo più supporto nel caso di un aggiornamento a una versione inferiore.

Il tuo sistema di monitoraggio può essere ampliato in modo semplice e comodo utilizzando i pacchetti di estensione di 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. Dall'altro lato, continuiamo ad aggiungere nuovi plug-in ed estensioni funzionali a Checkmk, motivo per cui gli MKP a volte diventano obsoleti. La funzionalità di questi plug-in ed estensioni è semplicemente fornita da Checkmk stesso come standard.

Per questo motivo, quando ti prepari a un aggiornamento, ti consigliamo vivamente di rivedere tutti gli MKP installati, per evitare che pacchetti incompatibili interferiscano con l'aggiornamento o che, dopo l'aggiornamento, si verifichino servizi duplicati o comunque molto simili.

A tal fine, controlla i tuoi MKP installati con il nostro Catalogo dei plug-in di controllo e rimuovi tutti i pacchetti che contengono funzioni che ora sono fornite in modo nativo da Checkmk. Puoi anche cogliere l'occasione per rimuovere gli MKP che potrebbero essere stati installati solo per un test-in controllo. Un elenco si trova nel menu Setup alla voce Maintenance > Extension packages. Alla riga di comando, puoi visualizzare le estensioni installate con il comando mkp list. Controlla l'output di questo comando per verificare la presenza di estensioni che non sono più necessarie o che non riesci nemmeno a identificare.

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

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

I file locali ti permettono di personalizzare ed estendere le funzionalità fornite da Checkmk. Questi file si trovano nella parte locale della struttura della directory del sito, cioè in ~/local. I file locali possono causare problemi al momento dell'aggiornamento, poiché potrebbero non corrispondere più alla nuova versione di Checkmk.

Poiché Checkmk non è in grado di intercettare e gestire le personalizzazioni locali e le estensioni di terze parti durante l'aggiornamento, è necessario controllare il proprio sito Checkmk prima di un aggiornamento per verificare se e quali file locali si stanno utilizzando.

Ottieni una panoramica dei file locali del tuo sito Checkmk eseguendo il seguente comando come utente dell'istanza Checkmk (dove l'opzione -L assicura che vengano seguiti anche i link simbolici):

In un'installazione di nuova pertinenza di Checkmk, al momento vedrai elencato solo un file chiamato README.TXT. Qualsiasi cosa al di là di questo dovrebbe essere in top list per la risoluzione dei problemi in caso di problemi di 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 estensioni 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 cronologia di monitoraggio in caso di guasto durante l'aggiornamento. Ciò che è importante a questo punto è che un backup regolare può essere utile anche per eseguire dei test su un aggiornamento in corso. Questa pratica ti permette di ripristinare il backup con un nome alternativo e di utilizzare il sito newsite per testare l'aggiornamento prima che diventi operativo:

In alternativa, puoi anche copiare il tuo sito tramite omd cp. Per questo, però, è necessario interrompere il sito live per un breve periodo:

Se i test con il sito clonato sono andati a buon fine, di solito vorrai eliminarlo o almeno interromperlo prima dell' aggiornamento del sito di produzione per motivi di spazio e di prestazioni.

Come descritto nell'introduzione, il primo passo da compiere con un aggiornamento è l'installazione della nuova versione di Checkmk desiderata. Questa operazione si svolge esattamente come l'installazione iniziale, ma procederà in modo più rapido poiché la maggior parte dei pacchetti dipendenti sono già stati installati. Nell'esempio seguente stiamo installando il pacchetto per Ubuntu 22.04 (Jammy Jellyfish):

Nota: quando installi un pacchetto locale tramite apt install, devi indicare il percorso del file .deb.

Un elenco delle versioni di Checkmk installate può essere visualizzato in qualsiasi momento con il comando omd versions:

Una di queste versioni elencate è contrassegnata con (default). Questa versione predefinita verrà utilizzata automaticamente quando si creano nuovi siti, a patto che non venga specificata un'altra versione con omd -V myversion create mysite. 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 dei siti esistenti. Il comando omd inizia sempre con la versione appropriata al sito per il quale viene chiamato.

Il comando omd sites fornisce un elenco dei siti attuali e delle versioni utilizzate:

Una volta installata la nuova versione desiderata, è possibile aggiornare il sito. Non sono necessari i permessi di root. Il modo migliore per farlo è come utente dell'istanza:

Assicurati che il sito sia stato interrotto:

L'aggiornamento, ovvero lo switch a una versione diversa, può essere eseguito semplicemente con il comando omd update:

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

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

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

Una parte importante di un aggiornamento è il refresh dei file di configurazione originariamente forniti. In questo caso, le modifiche eventualmente apportate a questi file dall'utente non verranno semplicemente scartate, ma verranno unificate. Questo funziona in modo molto simile ai file system di controllo delle versioni che cercano di unire le modifiche apportate a un singolo file contemporaneamente da più sviluppatori.

A volte, quando le modifiche riguardano la stessa posizione del file, questo non funziona e si verifica un conflitto. Il modo in cui puoi risolvere questi conflitti sarà spiegato più avanti.

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

Se viene visualizzata la riga Completed verifying site configuration evidenziata nell'output precedente, il sito è stato switchato alla nuova versione:

... e può essere avviato:

Lo sviluppo di un software comporta ovviamente delle modifiche. Poiché lavoriamo sempre attivamente per mantenere Checkmk moderno, a volte è inevitabile tagliare i pesi morti e apportare modifiche che si rivelano incompatibili. Ciò significa che durante l'aggiornamento potrebbe essere necessario adattare la tua configurazione, o almeno verificarla.

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

Una panoramica di tutte le modifiche apportate a Checkmk, compresa una funzione di ricerca, è disponibile online nei nostri Werk.

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

Checkmk tiene traccia delle modifiche incompatibili avvenute durante l'aggiornamento alla versione corrente e ti chiede di esaminarle e confermarle:

Se apri questa pagina tramite il link rosso nel menu Help, vedrai solo i "Werk" (cioè le modifiche) per le quali è necessario fare qualcosa e che sono quindi contrassegnate da Incompatible - TODO. Puoi richiamare ogni Werk singolarmente, visualizzarlo e confermarlo con un clic del mouse, riducendo così progressivamente il numero di modifiche incompatibili aperte. Inoltre, la voce di menu Help > Change log (works) ti dà accesso alla cronologia completa delle modifiche della versione principale corrente.

Sei curioso di sapere cosa succede esattamente "sotto il cofano" di un aggiornamento o hai riscontrato dei conflitti di dati durante l'esecuzione di omd update? In tal caso, ecco qualche approfondimento.

Durante l'aggiornamento di omd update avvengono tre azioni:

Vuoi automatizzare gli aggiornamenti del software di Checkmk? All'inizio potresti avere delle difficoltà con le risposte interattive di omd update. C'è una soluzione semplice per questo scenario: il comando ha delle opzioni che sono state concepite appositamente per essere utilizzate negli script:

I valori possibili per --conflict= sono:

Di seguito è riportato un esempio di comando completo per un aggiornamento automatico alla versione 2.3.0p1.cee di mysite:

Attraverso && prima di omd start si eviterà il riavvio del sito se omd update viene interrotto da un errore. Sostituisci && con un punto e virgola (;) se l'avvio deve essere tentato anche in questa situazione.

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

In questo modo, la riga precedente è indipendente dal nome del sito. Ad esempio, un piccolo script di shell potrebbe essere simile a questo:

La ragione tecnica dell'approccio all'aggiornamento descritto in precedenza risiede nei protocolli utilizzati: il sito centrale accede ai dati dei siti remoti principalmente in lettura tramite Livestatus e, nel caso di una configurazione centrale, con un ulteriore accesso in scrittura tramite un'API HTTP non pubblica. In entrambe le situazioni, le nuove versioni introducono dei veri e propri superset dei protocolli utilizzati. Pertanto, un sito centrale più vecchio utilizza solo un vero e proprio sottoinsieme delle funzionalità dei siti remoti più recenti. Se il sito centrale venisse aggiornato per primo, potrebbe effettuare chiamate API o richieste Livestatus ai siti remoti che questi non "capiscono" ancora.

La differenza massima di una versione principale deriva ancora una volta dal fatto che la rimozione delle interfacce è accompagnata da un periodo di tolleranza di una versione esatta. Ad esempio, l'API web non era più utilizzata internamente dall'istanza Checkmk 2.1.0, ma la sua rimozione non è avvenuta fino alla versione 2.2.0. Per questo motivo, un sito centrale 2.1.0 funziona con i siti remoti 2.2.0, ma un sito centrale 2.0.0 non funzionerà con i siti remoti 2.2.0.

Per facilitare questi aggiornamenti graduali, Checkmk offre la possibilità di memorizzare pacchetti di estensione con lo stesso nome in versioni diverse - una corrispondente al sito centrale più vecchio, una ai siti remoti più recenti - per esempio. La versione appropriata verrà attivata per ogni sito. I dettagli sono descritti nell'articolo sui pacchetti di estensione (MKP).

Con l'estensione dei siti visualizzatori, i siti visualizzatori possono essere aggiornati solo dopo i siti di cui visualizzano i dati. Se un sito visualizzatore mostra solo i dati dei siti remoti, può essere aggiornato non appena questi vengono aggiornati. Se invece mostra anche i dati del sito centrale, l'aggiornamento del visualizzatore può avvenire solo per ultimo.

Questo capitolo tratta principalmente l'aggiornamento a Checkmk Enterprise. Puoi anche effettuare l'aggiornamento a Checkmk Cloud in un unico passaggio, ma in questo caso fai riferimento alle note della sezione seguente.

Poiché le edizioni commerciali hanno molti moduli e funzionalità aggiuntive, ci sono alcune cose da tenere a mente dopo qualsiasi aggiornamento. Il punto cruciale è che quando si creano nuovi siti in Checkmk Raw 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 Enterprise e Checkmk Cloud. A seconda del focus del deployment, spesso si utilizzerà il set di funzionalità più ampio solo quando si aggiungono nuovi host. In alcuni casi, tuttavia, è consigliabile rivedere le impostazioni esistenti.

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

Tieni presente che negli ambienti distribuiti l'aggiornamento della versione deve essere sempre eseguito per primo prima di procedere all'aggiornamento dell'edizione. Non è supportata una sequenza diversa o un crossgrade (aggiornamento della versione e aggiornamento dell'edizione in un'unica azione). Come procedura generale, ti consigliamo l'aggiornamento offline, in cui puoi passare da un'edizione inferiore a un'edizione superiore.

Per due scenari di aggiornamento frequentemente richiesti(da Checkmk Raw a Checkmk Enterprise e da Checkmk Enterprise a Checkmk Cloud), l'operazione mista è possibile per un periodo di tempo limitato. Mentre l'aggiornamento offline funziona con tutte le versioni, i due scenari online richiedono almeno Checkmk 2.2.0p23.

Per preparare il downgrade da Checkmk Cloud a Checkmk Enterprise, devi apportare almeno le seguenti modifiche:

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

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

Una panoramica delle differenze tra Checkmk Cloud e Checkmk Enterprise è fornita dall'articolo Checkmk Cloud.

Per preparare il downgrade da Checkmk Enterprise a Checkmk Raw, dovrai apportare almeno le seguenti modifiche:

Inoltre, alcune dashboard, le impostazioni dei grafici, i plug-in dell'agente e gli agenti speciali non sono più disponibili. Con l'articolo Checkmk Enterprise puoi determinare quante funzionalità di Checkmk Enterprise andranno perse in caso di downgrade a Checkmk Raw e dove è necessario apportare ulteriori modifiche.

Gli scenari di downgrade presentati nelle due sezioni precedenti possono essere eseguiti anche in ambienti distribuiti. Nota che negli ambienti distribuiti, l'aggiornamento della versione deve sempre essere eseguito per primo prima cosa prima che possa seguire il downgrade dell'edizione. Non è supportata una sequenza diversa o un crossgrade (aggiornamento della versione e downgrade dell'edizione in un'unica azione).

Non esiste uno scenario di downgrade in cui Checkmk supporta 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 tutti i siti siano stati declassati prima di riavviarli, in modo da ridurre il numero di notifiche generate.

La disinstallazione delle versioni di Checkmk non più necessarie si effettua 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 nessun sito!

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

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

L'eliminazione viene eseguita con rpm -e:

Utilizza la seguente procedura per identificare i pacchetti installati:

La disinstallazione viene eseguita con dpkg --purge: