Aggiornamento alla versione {current-major}

Gli aggiornamenti di Checkmk devono sempre essere eseguiti dall'ultima versione patch della versione di partenza all'ultima versione patch della versione di destinazione. Un aggiornamento dalla 2.3.0p1 alla 2.4.0p24 segue quindi questo percorso:

2.3.0p1 2.3.0p45 2.4.0p24

Non è possibile saltare le versioni principali. Se vuoi aggiornare dalla 2.2.0 alla 2.4.0, esegui prima un aggiornamento alla versione 2.3.0.

Come per qualsiasi aggiornamento di un software di produzione, dovresti verificare che i tuoi backup siano aggiornati prima di eseguire l'aggiornamento di Checkmk.

Questo ti riguarda? Sì.

Cosa dovrai fare? Se crei i tuoi backup automaticamente tramite Setup > Maintenance > Backups, controlla lì che i tuoi backup siano aggiornati e che le richieste di backup più recenti siano state completate senza errori.

Per ulteriori informazioni, consulta gli articoli sui backup e sul backup e il ripristino delle istanze.

Checkmk 2.4.0 richiede risorse di sistema leggermente superiori rispetto a 2.3.0. È quindi consigliabile verificare, prima dell'aggiornamento, quale capacità libera abbiano ancora i server utilizzati per Checkmk.

Questo ti riguarda? Sì, ma la misura in cui sei interessato dipende fortemente da come utilizzi Checkmk.

Cosa dovrai fare? Assicurati che ci sia sufficiente capacità libera disponibile. Per informazioni sui cambiamenti previsti nell'utilizzo delle risorse hardware, consulta la tabella seguente:

Alcune distribuzioni obsolete non saranno più supportate nella versione Checkmk 2.4.0.

Questo ti riguarda? Questo ti riguarda se una delle seguenti distribuzioni Linux — ancora supportate in 2.3.0 — è installata sul tuo server Checkmk:

Checkmk 2.4.0 utilizza nuove funzionalità JavaScript che non sono disponibili nei browser meno recenti. Quali browser sono supportati e in quali versioni è indicato nei Requisiti di sistema.

Questo ti riguarda? Di solito sui sistemi desktop gli aggiornamenti automatici all'ultima versione sono già abilitati.

Cosa devi fare? Check la versione del browser che stai utilizzando e, se necessario, effettua l'installazione di una versione più recente. Se utilizzi computer a scheda singola, smart TV o soluzioni di digital signage per visualizzare i dashboard e non hai il controllo sul browser di sistema, verifica che tutti i dashboard necessari vengano visualizzati correttamente prima di effettuare l'aggiornamento. Se necessario, contatta il produttore dell'hardware per gli aggiornamenti.

Fino alla versione Checkmk 2.2.0, ogni utente automazione poteva effettuare l'accesso con un nome utente e una password passati tramite parametri GET. Questa opzione è stata limitata a partire dalla versione Checkmk 2.3.0 e verrà completamente rimossa nella versione 2.5.0 (Werk #16223). A medio termine, dovrai quindi modificare i tuoi script per passare all'autenticazione tramite header HTTP.

Inizialmente, 2.3.0 rendeva configurabile l'opzione di accesso tramite il parametro GET. Tuttavia, l'impostazione globale Enable automation user authentication via HTTP parameters inizialmente utilizzava on come impostazione predefinita. In Checkmk 2.4.0 l'impostazione predefinita ora cambia in off.

Questo ti riguarda? Questa modifica riguarda principalmente gli utenti che visualizzano i dashboard utilizzando computer a scheda singola, smart TV o soluzioni di digital signage senza una tastiera collegata.

Cosa devi fare? Se utilizzi il login automatico tramite parametri GET, devi modificare l'impostazione globale Automation user authentication via HTTP parameters in on. Poiché l'opzione di login tramite parametri GET verrà completamente rimossa con Checkmk 2.5.0, dovresti switchare il login di tali dashboard su Basic Auth (ad esempio, tramite un'estensione del browser).

Checkmk 2.3.0 è l'ultima versione che supporta ntopng nelle versioni 5.x e 6.x (Werk #16483). Con Checkmk 2.4.0 , il supporto per ntopng 5.x viene interrotto e sarà supportato solo ntopng 6.x.

Questo ti riguarda? Questa modifica riguarda gli utenti delle edizioni commerciali che utilizzano l'integrazione con ntopng.

Cosa dovrai fare? Aggiorna le tue installazioni di ntopng alla versione 6.x prima di aggiornare Checkmk all'2.4.0

Se per un host sono configurati agenti speciali, in Checkmk 2.4.0 verranno eseguiti tutti questi agenti speciali. Nelle versioni precedenti veniva eseguito solo un agente speciale, ovvero il primo nell'ordine alfabetico.

Questo ti riguarda? Questa modifica è rilevante solo per gli host nelle cui proprietà l'attributo Checkmk agent / API integrations è impostato su API integrations if configured, else Checkmk agent.

È possibile che tu abbia inavvertitamente creato regole che hanno assegnato agli host più special agents del necessario. Queste regole aggiuntive venivano precedentemente ignorate se si trovavano in ordine alfabetico dopo la prima. Esempio: hai creato regole per agent_acme e regole per agent_cyberdyne e hai assegnato queste regole agli stessi host a causa di una piccola svista. In Checkmk 2.4.0 ora per questi host verranno eseguiti non solo agent_acme ma anche agent_cyberdyne.

L'2.4.0e di Checkmk aggiorna Python alla versione 3.12.3. Questo aggiornamento influisce sui moduli installati in un'istanza Checkmk. In molti casi, i moduli installati successivamente sono incompatibili con Python 3.12.3. Nel peggiore dei casi, i moduli obsoleti sovrascrivono le funzionalità dei moduli forniti da Checkmk.

Questo ti riguarda? Questo vale per te se nel tuo sito sono stati installati moduli Python. Questo può verificarsi, ad esempio, se in precedenza hai installato moduli Python per special agents o plug-in di controllo basati su agenti che hai scritto tu stesso o ottenuto dall'Exchange.

Anche l’uso dell’active check check_sql per il monitoraggio dei database Oracle richiede un’attenta valutazione: Fino alla versione Checkmk 2.3.0 p27 era necessario installare il modulo oracledb per poter utilizzare questo check. A partire dalla versione 2.3.0 p28 questo modulo è fornito con Checkmk (Werk #17370).

Per scoprire se i moduli Python sono stati installati nella tua istanza, cerca le directory dist-info e egg-info:

Se il risultato della ricerca non è un elenco vuoto, dovrai intervenire.

I file locali ti permettono di personalizzare ed estendere le funzionalità fornite da Checkmk. Questi file si trovano nella parte locale della struttura delle directory dell'istanza, cioè in ~/local e possono trovarsi in pacchetti di estensione o semplicemente "sparsi qua e là". I file locali possono causare problemi durante un aggiornamento se non corrispondono più alla nuova versione di Checkmk.

Questo ti riguarda? Poiché Checkmk non è in grado di garantire completamente la compatibilità degli adattamenti locali durante un aggiornamento, dovresti controllare la tua istanza Checkmk prima di un aggiornamento per verificare se vengono utilizzati file locali, quali sono e come sono organizzati.

Per prima cosa, usa mkp list per cercare i pacchetti di estensione (MKP) presenti nell'istanza.

Usa anche mkp find per ottenere una panoramica dei file locali non inclusi in pacchetti nella tua istanza Checkmk.

Se l'output di uno o entrambi questi comandi non è vuoto, dovrai intervenire.

In Checkmk 2.3.0 alcune interfacce di programmazione (API) che erano state definite ad hoc nelle versioni precedenti sono già state sostituite da altre versionate e ben specificate. Le API precedenti potevano continuare a essere utilizzate in parallelo. Con Checkmk 2.4.0 non vengono prese ulteriori misure per mantenere la compatibilità con le vecchie API (Werk #17201). Ciò significa che i plug-in che utilizzano le vecchie API non funzioneranno più con Checkmk 2.4.0.

Questo ti riguarda? Il tema delle API ti riguarda se hai esteso i plug-in di controllo forniti con Checkmk con plug-in scritti da te e/o se utilizzi plug-in provenienti da altre fonti.

Gli endpoint o i parametri deprecati dell'API REST di Checkmk sono contrassegnati nella documentazione dell'API con il simbolo .

Questo ti riguarda? Potrebbe riguardarti se, ad esempio, utilizzi l'API REST di Checkmk nei tuoi script.

Cosa devi fare? Apri la documentazione dell'API REST all'indirizzo Help > Developer Resources > REST API documentation. Cerca Deprecated nel browser sulla pagina, check se stai utilizzando elementi deprecati nei tuoi script e sostituiscili prima di aggiornare. Nella documentazione dell'API REST troverai solitamente le istruzioni su come sostituire le funzioni che non esistono più nella nuova versione.

Come in ogni versione di Checkmk, anche nell'attuale versione 2.4.0 sono presenti modifiche al software che potrebbero avere ripercussioni sulla tua installazione di Checkmk — in Checkmk queste sono organizzate e documentate in quello che chiamiamo Checkmk Werks. Una cosiddetta modifica incompatibile richiede che tu apporti modifiche manuali per consentire alle funzioni esistenti di continuare a funzionare come al solito e/o per poter utilizzare le nuove funzioni.

Questo riguarda anche te? In generale, ci saranno modifiche incompatibili che interesseranno anche la tua installazione di Checkmk, ma è impossibile fare un'affermazione generale. In questo articolo abbiamo raccolto le questioni che riguardano tutte o quasi tutte le installazioni di Checkmk. In ogni caso potrebbero esserci ulteriori modifiche rilevanti per te, ad esempio nei controlli che utilizzi nella tua installazione.

Cosa dovrai fare? Dopo ogni aggiornamento — comprese le versioni patch — Checkmk ti mostrerà il numero e il contenuto delle modifiche incompatibili e ti chiederà di controllarle e prenderne nota. Prima di eseguire l'aggiornamento è il momento giusto per verificare se ci sono modifiche rispetto alla versione 2.3.0 che potrebbero avere un impatto sull'aggiornamento. Poiché Checkmk 2.3.0 , tali Werks non vengono più trasferiti, ma vengono eliminati durante l'aggiornamento dopo aver approvato un dialogo di conferma (Werk #15292).

È inoltre consigliabile avere una panoramica delle modifiche incompatibili nella versione 2.4.0 prima dell'aggiornamento: Apri l'elenco dei Werks sul sito web di Checkmk. Nella descrizione di un Werk troverai informazioni su cosa potrebbe essere necessario fare per rendere la modifica compatibile.

Dopo aver eseguito l'aggiornamento, il numero e il contenuto delle modifiche incompatibili verranno visualizzati nell'interfaccia di Checkmk e ti verrà chiesto di controllarle e prenderne nota. I link ti aiutano a controllare, così puoi scoprire con pochi clic se stai utilizzando un componente interessato. Se è certo che un Werk non ha alcun impatto o se hai apportato le modifiche richieste, conferma il Werk con Acknowledge.

In questa sezione descriviamo le migliori pratiche che seguiamo anche quando aggiorniamo grandi ambienti Checkmk. Queste non sono certamente obbligatorie in ogni ambiente, ma possono semplificarti il processo di aggiornamento.

Esistono due diverse procedure per eseguire un aggiornamento di tutte le istanze incluse in un monitoraggio distribuito:

In particolare, se desideri effettuare l'aggiornamento mentre il sistema è in esecuzione, ti consigliamo di leggere le note contenute nell'articolo generale su Aggiornamenti e Upgrade.

Non è cambiato nulla di fondamentale nell'aggiornamento effettivo del software in Checkmk 2.4.0 , cioè installi la nuova versione, esegui l'aggiornamento dell'istanza Checkmk, risolvi eventuali conflitti e controlli e confermi le modifiche incompatibili.

Esegui la procedura di aggiornamento come descritto nell'articolo su Aggiornamenti e Upgrade.

L'interfaccia utente (GUI) di Checkmk, che è stata completamente riprogettata con la versione 2.0.0, non ha subito modifiche sostanziali nella versione 2.4.0. Le procedure generali, che già conosci dalle versioni 2.0.0 a 2.3.0, possono essere utilizzate così come sono anche in 2.4.0. Tuttavia, menu, voci di menu, simboli e altri dettagli sono stati modificati per rendere disponibili nuove funzionalità e per migliorare quelle esistenti.

Presenteremo queste modifiche negli articoli di questo manuale, mentre nella Guida per principianti troverai un'introduzione dettagliata, che include gli elementi più importanti dell'interfaccia utente.

Come per ogni versione principale, Checkmk 2.4.0 introduce una serie completamente nuova di plug-in di controllo. Se non utilizzi il "discovery check", ovvero l'aggiornamento automatico della configurazione del servizio tramite la scoperta periodica dei servizi, dovrai cercare i servizi su un numero piuttosto elevato di host.

Se i tuoi host sono organizzati in modo adeguato (ad es. in cartelle), in genere puoi utilizzare la funzione "Bulk discovery" per questo scopo. Questa funzione si trova in "Setup > Hosts > Hosts" e poi nel menu "Hosts > Run bulk service discovery".

In alcuni casi, è stato necessario rimuovere alcuni plug-in di controllo o farli switchare a nuove API.

Questo ti riguarda? Il rischio di essere interessato è presente se monitori hardware con un ciclo di vita molto lungo, specialmente con special agents. Durante i preparativi per l'aggiornamento da 2.3.0 a 2.4.0, ad esempio, abbiamo notato gli special agents per molti dispositivi NetApp, che abbiamo dovuto switchare dalla ZAPI, ormai fuori produzione, alla più moderna API REST (Werk #16767). Per motivi di licenza, abbiamo dovuto spostare l'agente per Dell PowerConnect in un pacchetto separato disponibile nell'Exchange (Werk #15359).

Cosa dovrai fare? Se i servizi scompaiono dopo l'aggiornamento, cerca nei Werks il produttore dei prodotti monitorati. Nella maggior parte dei casi, dovrai switchare alle nuove API o, in rari casi, utilizzare pacchetti dall'Exchange per effettuare il monitoraggio di un componente hardware o software specifico.

Questo ti riguarda? Questo vale solo se hai effettuato esplicitamente l'installazione di moduli Python per special agents o plug-in di controllo basati su agenti che hai scritto tu stesso o ottenuto dall'Exchange e li hai rimossi durante la preparazione all'aggiornamento.

A partire dalla versione 2.3.0, Checkmk contiene già un nuovo active check per le connessioni HTTP e i certificati. Il controllo "Check HTTP web service" si trova alla pagina Setup > Services > HTTP, TCP, Email, …​ nella box "Networking". Il nuovo active check offre performance significativamente migliori, è più robusto e più facile da configurare rispetto al precedente Check HTTP service. Inoltre, ora è possibile effettuare il monitoraggio di diverse cose contemporaneamente con una singola regola, ad esempio il codice di risposta HTTP, il tempo di risposta e la validità del certificato.

In Checkmk 2.4.0 alcune opzioni poco utilizzate del vecchio check sono state aggiunte al nuovo check per facilitare la migrazione. Inoltre, forniamo uno script di migrazione che effettua la mappatura delle chiamate esistenti e dei servizi risultanti in rapporto 1:1. Usa questo script per convertire i servizi dal vecchio al nuovo active check, poiché con Checkmk 2.5.0 non è possibile configurare nuove regole per il vecchio check. In seguito verrà completamente rimosso.

Una volta completata la migrazione, puoi ottenere significativi vantaggi in termini di performance unendo più regole, consentendo a una singola esecuzione del check di produrre più output, riducendo così l'overhead sulla CPU. In molti casi puoi anche generare più servizi utilizzando una singola regola nel nuovo check.

Informazioni generali sul nuovo check sono disponibili nei due Werks #15514 e #15515. Il Werk #17725 descrive lo script di migrazione. Un articolo dettagliato sul blog spiega i dettagli delle possibilità, dei limiti e delle best practice per preparare e seguire la migrazione.

Se ti imbatti in applicazioni in cui il nuovo check non può sostituire quello vecchio, puoi visualizzare la riga di comando utilizzata allo stesso modo della procedura descritta qui. Avrai quindi la possibilità di richiamare il vecchio check o un check_http installato a livello di sistema tramite Setup > Other services > Integrate Nagios plugins.

Il termine scheda di gestione indica schede plug-in separate o funzionalità BIOS estese (Baseboard Management Controller/BMC, Management Engine/ME, Lights Out Management/LOM) per il monitoraggio e la gestione dell'hardware oltre al sistema operativo installato.

Fino alla versione Checkmk 2.4.0, le schede di gestione possono essere configurate in due modi: Come proprietà dell'host o come host separato. Poiché la configurabilità come proprietà dell'host è molto limitata, in futuro questa opzione non sarà più disponibile.

Il supporto per le schede di gestione compatibili con Redfish è stato aggiunto e migliorato durante il ciclo di vita di Checkmk 2.3.0 , inizialmente come MKP opzionale (Werk #16589). In Checkmk 2.4.0 , il monitoraggio Redfish è parte integrante del software (Werk #17404). Trovi ulteriori informazioni di base e possibili alternative nell'articolo del blog "Monitoraggio delle schede di gestione".