Aggiornamento alla versione 2.4.0

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

Questo ti riguarda?Sì.

Se crei i tuoi backup automaticamente tramite Setup > Maintenance > Backups, controlla che i tuoi backup siano aggiornati e che le ultime richieste di backup siano state completate senza errori.

Per maggiori informazioni, consulta gli articoli sui backup e sul backup e ripristino dei siti.

Checkmk 2.3.0 richiede risorse di sistema leggermente superiori a quelle di 2.2.0. Per questo motivo, prima di effettuare l'aggiornamento, è consigliabile verificare la capacità libera dei server Checkmk.

Sì, ma l'entità dell'impatto dipende molto dall'uso che fai di Checkmk. Solo l'aggiornamento dell'interprete Python dalla versione 3.11 alla 3.12 comporta un aumento del carico della CPU a una cifra percentuale. Inoltre, a seconda della proporzione rispetto al numero totale di controlli, i controlli più approfonditi di 2.3.0, soprattutto nell'area cloud, possono comportare un ulteriore carico aggiuntivo, per cui ci si può aspettare un totale del 10-15 % (in casi estremi circa il 20 %) di carico della CPU in più.

Comeregola generale: se il carico della CPU è inferiore al numero di core del processore x 0,8 e l'utilizzo della CPU è inferiore al 70%, non ci sono problemi. Se uno o entrambi i valori sono superiori, crea una capacità libera sufficiente, ad esempio disattivando i siti di prova sullo stesso server o spostando gli host su altri siti.

Alcune distribuzioni obsolete non saranno più supportate dalla versione di Checkmk 2.3.0.

Questo ti riguardase sul tuo server Checkmk è installata una delle seguenti distribuzioni Linux, ancora supportate in 2.2.0:

Prima di aggiornare Checkmk, esegui un aggiornamento della versione della distribuzione Linux. Assicurati che la versione di destinazione della distribuzione Linux di Checkmk sia 2.2.0 e che 2.3.0 sia supportata. Puoi scoprire quali versioni della distribuzione Linux supporta Checkmk nella matrice di aggiornamento per 2.3.0 e sulla pagina di download dopo aver selezionato la versione di Checkmk e la tua distribuzione Linux.

Poco dopo il rilascio di Ubuntu 24.04 LTS, forniremo i pacchetti Checkmk 2.2.0 e 2.3.0 per questa versione della distribuzione. In questo modo potrai prima aggiornare all'ultima versione patch di Checkmk 2.2.0, poi aggiornare da Ubuntu 23.10 STS a 24.04 LTS e infine aggiornare all'ultima versione patch di Checkmk 2.3.0.

Con la versione di Checkmk 2.3.0 (e 2.2.0p21) sui server Checkmk Enterprise 15 Service Pack 3 e 4, la dipendenza dall'ambiente di esecuzione del linguaggio di programmazione PHP è passata dalla versione 7 alla versione 8. Questo ti riguarda?

Sì,se sei un utente di SLES 15 SP3/SP4. L'aggiornamento è un po' più complesso, in quanto le fonti dei pacchetti per la versione 7, ormai obsoleta, devono essere disattivate e attivate per la nuova versione 8.

Se,oltre a Checkmk, sul tuo server ci sono applicazioni che utilizzano il linguaggio di programmazione PHP, assicurati che possano gestire PHP 8 senza problemi. Quindi prepara i sorgenti dei pacchetti per l'aggiornamento a 2.2.0p21 (o superiore), che è obbligatorio per l'installazione di Checkmk 2.3.0, come descritto in Werk #16025.

Checkmk 2.3.0 utilizza nuove funzioni JavaScript che non sono disponibili nei browser più vecchi. I browser supportati nelle varie versioni sono riportati nelle note di rilascio.

Di solitosuisistemi desktop sono abilitati gli aggiornamenti automatici all'ultima versione.

Cosa devi fare?Controlla la versione del browser che stai utilizzando e, se necessario, installane uno più recente. Se utilizzi Single Board Computer, Smart TV o soluzioni di Digital Signage per visualizzare i dashboard e non hai alcun controllo sul browser del sistema, verifica che i dashboard richiesti siano visualizzati correttamente prima di aggiornare. Se necessario, contatta il produttore dell'hardware per ottenere gli aggiornamenti.

Per la prima volta, Checkmk 2.3.0 fornisce OpenSSL nella versione 3.0 invece della precedente 1.1. Questo cambiamento riguarda quasi tutti i componenti che utilizzano Secure Socket Layer o Transport Level Security.

PoichéOpenSSL 3 è ormai ampiamente utilizzato, non c'è da aspettarsi alcuna sorpresa. Possono verificarsi problemi - soprattutto con gli active check - se si stabiliscono connessioni a dispositivi che si aspettano vecchi cifrari o che tentano la rinegoziazione. Di solito si tratta di vecchi dispositivi di rete (switch, stampanti...) che non ricevono più aggiornamenti. In alcuni casi, sono interessati i servizi delle vecchie distribuzioni Linux o delle versioni Unix, che vengono ancora forniti con gli aggiornamenti.

Cosa devi fareSe possibile, cerca di scoprire in anticipo quali sono i dispositivi che potrebbero avere problemi. Buoni indicatori a questo proposito sono l'età e il tempo trascorso dall'installazione degli aggiornamenti. Testa questi dispositivi con Checkmk 2.3.0. Se si verificano problemi, hai due opzioni:

Con Checkmk 2.3.0, Checkmk MSP ha cambiato la sua base da Checkmk Enterprise a Checkmk Cloud. Ciò significa non solo che Checkmk MSP riceve la gamma estesa di funzioni di Checkmk Cloud, ma anche che la gestione delle licenze è allineata a quella di Checkmk Cloud.

Questo riguardasolo gli utenti di Checkmk MSP, gli altri moduli di monitoraggio distribuito non sono interessati.

Cosa devi fare? L'aggiornamento di un'istanza Checkmk MSP a 2.3.0 segue la procedura generale degli ambienti distribuiti con configurazione distribuita. Tuttavia, è necessario assicurarsi che l'istanza centrale possa ancora trasferire le informazioni sulla licenza disponibili su Checkmk 2.2.0 alle istanze remote già aggiornate su Checkmk 2.3.0.

Poiché le modifiche necessarie sono implementate solo nell'istanza Checkmk 2.2.0p17(Werk #16193), è necessario aggiornare il sito centrale almeno a questa versione, in modo da garantire il trasferimento delle informazioni sulla licenza. I siti remoti possono quindi essere aggiornati a 2.3.0 e infine al sito centrale.

Indipendentemente dai requisiti minimi per 2.2.0p17 qui menzionati, ti consigliamo di aggiornare prima tutti i siti coinvolti all'ultima versione patch disponibile di 2.2.0 e solo dopo iniziare l'aggiornamento a 2.3.0.

L'agente Checkmk 2.3.0 non crea più le firme SHA1 per i pacchetti degli agenti. La verifica delle firme SHA256 è stata introdotta con l'agente Checkmk 2.2.0p8. Affinché gli aggiornamenti dell'agente alla versione 2.3.0 avvengano automaticamente, gli agenti devono prima essere aggiornati alla versione 2.2.0p8 o superiore.

Questo ti riguardase esegui l'aggiornamento automatico dell'agente ma occasionalmente salti le versioni patch dell'agente. Ti riguarda anche se il tuo deployment utilizza immagini del sistema operativo preparate che includono Checkmk Agent Updater e si affidano all'installazione/aggiornamento automatico.

Cosa devi fare?Assicurati che tutti gli agenti che devono essere aggiornati automaticamente siano stati aggiornati almeno alla versione 2.2.0p8. In particolare, verifica le immagini del sistema operativo preparate e aggiorna l'agente esistente alla versione 2.2.0p8 o superiore. Inoltre, se stai lavorando agli aggiornamenti dell'agente, puoi aggiungere già ora il certificato fornito dall'agent bakery, se sarà necessario in seguito.

Alcuni plug-in che erano stati contrassegnati come deprecati sono stati rimossi e, se necessario, potrebbero richiedere un'installazione manuale: Werk #16359

Il supporto ufficiale per l'agente Checkmk in Windows Server 2008 e Windows 7 da parte di Checkmk GmbH era già terminato con il rilascio di Checkmk 2.2.0. Tuttavia, l'operatività in Windows Server 2008 R2 e Windows 7 era ancora possibile senza restrizioni. Con 2.3.0, le restrizioni devono essere accettate: la precedente opzione di fornire un ambiente di esecuzione Python 3.4 per gli agenti Windows tramite la regola agent bakery non è più disponibile in 2.3.0.

Questo ti riguarda?Speriamo di no: L'interruzione del servizio riguarda solo se utilizzi plug-in dell'agente scritti in Python su Windows Server 2008 R2 o Windows 7 (entrambi a fine vita già nel 2020). Le versioni attuali di Python funzionano su tutte le versioni di Windows più recenti. Su tutte le versioni di Windows ancora più vecchie, come Windows Server 2008 R1 o Windows Vista, l'agente non può più essere utilizzato nella versione 2.2.0.

Sevuoi continuare a monitorare questi sistemi Windows, devi fornire tu stesso l'ambiente di esecuzione per i plug-in dell'agente che richiedono Python: installa Python 3.4 manualmente sui sistemi interessati. Per questi sistemi, di solito imposta Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Windows modules > Install Python runtime environment l'impostazione Install Python runtime environment > Installation su Never install Python with the agent. Nota che non possiamo garantire il supporto per questi vecchi sistemi Windows e non testiamo più le nuove versioni dell'agente nelle patch release.

mod_auth_mellon è un modulo software per Apache che fornisce servizi di autenticazione tramite il Secure Assertion Markup Language (SAML). La connessione ai servizi di autenticazione SAML era possibile in Checkmk 2.2.0 in due modi: a livello di Apache con mod_auth_mellon (l'unica opzione supportata fino alla versione 2.1.0) o nelle edizioni commerciali di Checkmk l'autenticazione SAML integrata. Con la versione 2.3.0 mod_auth_mellon` non viene più fornito con il software Checkmk.

Questo ti riguarda?Questo ti riguarda se utilizzi l'autenticazione SAML con mod_auth_mellon.

Gliutenti delle edizioni commerciali devono switchare l'autenticazione SAML alla soluzione integrata in Checkmk prima di aggiornare a 2.3.0.

Se utilizzi Checkmk Raw, puoi già installare mod_auth_mellon a livello di sistema prima dell'aggiornamento seguendo le istruzioni riportate nella pagina del progetto. Cambia quindi la riga per il caricamento del modulo nel file di configurazione ~/etc/apache/conf.d/auth.conf con il percorso di installazione a livello di sistema. La directory di installazione può variare a seconda della distribuzione utilizzata:

Riavvia il sito dopo aver apportato la modifica. Infine, verifica - sempre all'indirizzo 2.2.0- se l'autenticazione SAML continua a funzionare. Se è così, non ci sono problemi da aspettarsi dopo l'aggiornamento.

Checkmk 2.3.0 aggiorna Python dalla versione 3.11 alla 3.12. Questo aggiornamento riguarda i moduli installati su un'istanza Checkmk. In molti casi, i moduli post-installati sono incompatibili con Python 3.12. Nel peggiore dei casi, i moduli obsoleti sovrascrivono le funzionalità dei moduli forniti da Checkmk.

Questo ti riguarda?Questo ti riguarda solo se hai installato moduli Python per agenti speciali o plug-in di controllo basati su agenti che hai scritto tu stesso o che hai ottenuto da Exchange. Se non sei sicuro, esegui la verifica descritta nella sezione seguente.

Per prima cosa,scopri se nel sito sono installati dei moduli Python e, in caso affermativo, identificali. A tal fine, cerca le directory dist-info e egg-info. Prendi nota dei moduli installati e dei loro nomi:

Prendi nota dei moduli installati e poi disinstallali:

Puoi scoprire come gestire i moduli Python disinstallati dopo l'aggiornamento qui di seguito.

L'agente speciale Prometheus offriva kube-state-metrics come origine dati, i cui controlli non sono più supportati. Questi sono stati sostituiti da controparti migliorate nell'agente Kubernetes (vedi Werk #14572). Inoltre, nelle regole Prometheus e Alertmanager, la specificazione dell'indirizzo IP/nome host, della porta e del prefisso del percorso è stata sostituita da un unico campo di input Custom URL (vedi Werk #14573).

In entrambi i casi, il vecchio metodo ha continuato a funzionare in 2.2.0. Per utilizzarlo in 2.3.0, tuttavia, devi aver cambiato la tua configurazione con il nuovo metodo.

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

PoichéCheckmk non è in grado di garantire completamente la compatibilità degli adattamenti locali durante un aggiornamento, dovresti controllare il tuo sito Checkmk prima di un aggiornamento per verificare se i file locali sono utilizzati, quali sono e come sono organizzati.

Cosa devi fare?

In Checkmk 2.3.0 sono state ricostruite alcune interfacce di programmazione interne (API). Alcune API precedentemente definite ad hoc sono state sostituite da altre ben specificate. Inoltre, l'API Check già segnalata come deprecata in 2.0.0 è stata definitivamente rimossa.

Il tema delle APItiriguarda se hai esteso i controlli forniti con Checkmk con controlli scritti da te e/o se utilizzi plug-in di controllo provenienti da altre fonti.

Cosa devi fare?Controlla la funzionalità delle estensioni che hai scritto tu stesso e di quelle di provider di terze parti. Poiché le nuove API possono essere utilizzate parallelamente alle vecchie durante Checkmk 2.3.0 e le modifiche alle API esistenti potrebbero essere minime, la maggior parte delle estensioni continuerà a essere utilizzabile senza modifiche. Se sono necessarie delle modifiche, ti consigliamo di migrare alle nuove API, che saranno disponibili a partire da Checkmk 2.4.0 e sostituiranno completamente le vecchie API.

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

Questopotrebberiguardartise utilizzi l'API REST di Checkmk, ad esempio nei tuoi script.

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

Come in ogni versione di Checkmk, anche nell'attuale versione di 2.3.0 ci sono modifiche al software che possono avere ripercussioni sulla tua installazione di Checkmk - in Checkmk queste sono organizzate e documentate in quelli che chiamiamo i nostri Checkmk Werk. Una cosiddetta modifica incompatibile richiede che tu apporti delle modifiche manuali per permettere alle funzioni esistenti di continuare a funzionare come al solito e/o per poter utilizzare le nuove funzioni.

In generale,cisaranno modifiche incompatibili che interesseranno anche la tua installazione Checkmk, ma è impossibile fare un'affermazione generale. In questo articolo abbiamo raccolto i problemi che si applicano a tutte o alla maggior parte delle installazioni Checkmk. In ogni caso, potrebbero esserci ulteriori modifiche che ti riguardano, ad esempio nei controlli che utilizzi nella tua installazione.

Dopo ogni aggiornamento - comprese le patch release - 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 la presenza di eventuali modifiche della versione 2.2.0 che potrebbero avere un impatto sull'aggiornamento. Da Checkmk 2.3.0, tali Werk non vengono più riportati, ma vengono eliminati durante l'aggiornamento dopo l'approvazione di una finestra di dialogo di conferma(Werk #15292).

È anche una buona idea avere una panoramica delle modifiche incompatibili nella versione 2.3.0 prima dell' aggiornamento: apri l'elenco dei Werk sul sito web di Checkmk. Nella descrizione di un Werk, troverai informazioni su ciò che potrebbe essere necessario fare per rendere la modifica compatibile.

Dopo aver effettuato l'aggiornamento, il numero e il contenuto delle modifiche incompatibili saranno visualizzati nell'interfaccia di Checkmk e ti verrà chiesto di controllarle e di prenderne nota. I link ti aiutano a verificare in modo da 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, confermalo con Acknowledge.

In questa sezione descriviamo le best practices che seguiamo anche quando aggiorniamo ambienti Checkmk di grandi dimensioni. Sicuramente non sono obbligatorie per tutti gli ambienti, ma possono rendere il processo di aggiornamento più semplice per te.

Esistono due procedure diverse per eseguire un aggiornamento di tutti i siti inclusi in un monitoraggio distribuito:

In particolare, se vuoi aggiornare mentre il sistema è in funzione, devi leggere le note dell'articolo generale su Aggiornamenti e upgrade.

Per quanto riguarda l'aggiornamento vero e proprio del software in Checkmk 2.3.0, non è cambiato nulla di fondamentale: si installa la nuova versione, si esegue l'aggiornamento dell'istanza Checkmk, si correggono eventuali conflitti e si controllano e confermano le modifiche incompatibili.

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

L'interfaccia utente di Checkmk (GUI), che è stata completamente ridisegnata con la versione 2.0.0, non è stata modificata in modo sostanziale nella versione 2.3.0. Le procedure generali, che già conosci dalle versioni 2.0.0 e 2.2.0, possono essere utilizzate anche nella versione 2.3.0. Tuttavia, i menu, le voci di menu, le icone e altri dettagli sono stati modificati per rendere disponibili nuove funzionalità e per migliorare quelle esistenti.

Questi cambiamenti sono presentati negli articoli di questa Guida per l'utente, mentre nella Guida per principianti troverai un'introduzione dettagliata che include gli elementi più importanti dell'interfaccia utente.

Come ogni versione principale, Checkmk 2.3.0 introduce una serie di nuovi plug-in di controllo. Se non utilizzi il "discovery check", cioè l'aggiornamento automatico della configurazione dei servizi tramite il periodo di check periodico, dovrai cercare i servizi su un certo numero di host.

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

Il comportamento del parametro della riga di comando --trust-cert del comando cmk-update-agent è stato modificato. In precedenza, veniva controllata l'intera catena di certificati e veniva considerato attendibile il certificato self-signed più alto trovato nella gerarchia; di solito si trattava del certificato root o di un certificato intermedio. Da Checkmk 2.3.0, viene importato e considerato attendibile solo il certificato del server.

Questo ti riguarda?Questo ti riguarda solo se ti affidi a --trust-cert quando registri gli host per l'aggiornamento automatico dell'agente e non fornisci un certificato tramite l'Agent Bakery. In questo caso, gli host registrati con Checkmk 2.3.0 perdono la posizione di fiducia quando il certificato del server scade, mentre quelli registrati con Checkmk 2.2.0 solo quando scadono i certificati root o intermedi.

Siconsiglia di fornire i certificati corretti tramite l'agent bakery subito dopo l'aggiornamento a 2.3.0 e di aggiornare tutti gli agenti per garantire un comportamento coerente per tutti gli host che utilizzano l'aggiornamento dell'agente.

Questo ti riguardasolo se hai installato esplicitamente moduli Python per special agent o plug-in di controllo basati sull'agente che hai scritto tu stesso o ottenuto da Exchange e li hai rimossi durante la preparazione dell'aggiornamento.

Cosa dovrai fare?Innanzitutto scopri se i moduli precedentemente disinstallati sono già stati forniti con la nuova versione di Checkmk, ad esempio:

Se il modulo è già stato trovato, segnalo come non necessario nelle note. Installa l'ultima versione dei moduli non inclusi:

Quindi testa i plug-in di controllo o gli agenti speciali che si basano sui moduli Python installati nel sito.

Fino a Checkmk 2.2.0, l'agente per Windows si basava sul modulo aggiuntivo Windows: State and Performance of Network Interfaces per trasmettere correttamente lo stato delle interfacce di rete. Senza il plug-in, lo stato era sempre attivo. A partire da Checkmk 2.3.0, l'agente può trasmettere lo stato corretto da solo(Werk #15839).

A seconda di quanto hai distribuito il plug-in e se hai disattivato il monitoraggio dello stato delle interfacce di rete per gli host senza plug-in,questopotrebbe riguardarti. Gli host che non hanno utilizzato il plug-in in precedenza e le cui interfacce di rete sono state incluse nel monitoraggio cambieranno molte interfacce da up a down, ottenendo lo stato CRIT e attivando le notifiche.

Cosa devi fare?Controlla se lo stato determinato per le interfacce di rete interessate è quello desiderato, quindi effettua nuovamente la scoperta del servizio per gli host interessati. Cogli l'occasione per mettere in pratica le raccomandazioni dell'articolo del blog Monitoraggio della rete con Checkmk: 3 regole per governare tutti, almeno per i tuoi host Windows. Per Windows, le impostazioni di cui sopra devono essere effettuate nella regola Network interfaces on Windows.

Con Checkmk Cloud e Checkmk MSP con istanza distribuita, a volte le informazioni sulla licenza non vengono sincronizzate con le istanze remote in Checkmk.

Se hai bisogno di una panoramica completa sull'utilizzo delle licenze subito dopo l'aggiornamento,questopotrebbe riguardarti. Controlla lo stato delle licenze e avvia la sincronizzazione manualmente se necessario.

Cosa devi fare?Alla voce Setup > General > Distributed Monitoring, dai un'occhiata alla panoramica dei siti remoti e cerca i siti contrassegnati da License state: trial. Per forzare la sincronizzazione immediata di questi siti, controlla la licenza alla voce Setup > Licensing o salva le impostazioni della licenza. Se questo passaggio viene dimenticato, i dati della licenza vengono solitamente sincronizzati in background entro sette giorni dall'aggiornamento.

Checkmk 2.3.0 contiene un nuovo active check per le connessioni HTTP e i certificati, che è molto più performante, robusto e facile da configurare rispetto al precedente Check HTTP service. Inoltre, ora è possibile monitorare più cose contemporaneamente con un'unica regola, ad esempio il codice di risposta HTTP, il tempo di risposta e la validità del certificato.

Il nuovo Check HTTP web service si trova nel box Networking sotto Setup > Services > HTTP, TCP, Email, …​. A medio termine, questo sostituirà completamente il vecchio Check HTTP service, che si trova nella stessa pagina. Per questo motivo, ti consigliamo di non utilizzare più il controllo precedente (interno: check_http) quando crei nuovi host e di migrare gradualmente gli host esistenti al nuovo controllo (interno: check_httpv2).

Uno script di migrazione verrà fornito più avanti nel ciclo di vita di Checkmk 2.3.0. Tuttavia, una migrazione completamente automatizzata tende a essere difficile, perché con molti host è necessario unire le regole di due controlli per poter beneficiare della maggiore efficienza.

Ulteriori informazioni sono disponibili nei due Werk #15514 e #15515.

Il precedente Check HTTP service conteneva una funzionalità di base per la verifica dei certificati e il nuovo Check HTTP web service menzionato nella sezione precedente la migliora ulteriormente. Tuttavia, entrambi hanno alcuni punti in comune: prima di tutto, sono applicabili solo quando un certificato è utilizzato in un endpoint HTTPS e mancano anche dell'opzione di un esame dettagliato dei certificati, ad esempio per i nomi alternativi dei soggetti del certificato contenuti o per l'autorità emittente.

Abbiamo implementato le richieste dell'utente con il nuovo Check certificates (interno: check_cert). Tutte le impostazioni per il nuovo controllo si trovano anche sotto Setup > Services > HTTP, TCP, Email, …​ nel box Networking..

Ulteriori informazioni sono disponibili nella Werk #15516.

Dopo la versione di Checkmk 2.3.0 saranno supportate solo le API ben specificate per la programmazione dei plug-in dell'agente Checkmk, degli agenti speciali, dei grafici, ecc. Le modifiche riguardano la struttura della directory, il riconoscimento dei plug-in(Discovery invece di Registry) e naturalmente le funzioni e gli oggetti delle API stesse. Una panoramica dei principali cambiamenti è disponibile nel Werk #16259.

Poiché le API precedenti non sono più supportate da Checkmk 2.4.0, tutti i plug-in che utilizzano le API precedenti devono essere migrati alle nuove API prima dell'aggiornamento a 2.4.0.

È disponibile un nuovo plug-in dell'agente per il monitoraggio di Microsoft SQL Server con Checkmk 2.3.0. Puoi trovarlo all'indirizzo Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Microsoft SQL Server (Linux, Windows). Questo plug-in è stato implementato in Rust e a lungo termine sostituirà quello precedente scritto in VBScript. Il nuovo plug-in funziona in Linux e Windows sulla piattaforma di monitoraggio x86/64. Offre inoltre una maggiore flessibilità grazie al monitoraggio locale e remoto in Windows e al monitoraggio remoto in Linux. Naturalmente, puoi monitorare un database MS SQL in esecuzione locale in Linux utilizzando l'interfaccia TCP/IP.

La configurabilità è stata notevolmente migliorata: ora puoi scegliere quali sezioni devono essere controllate e aggiungere le tue istruzioni SQL. Inoltre, puoi monitorare database su host diversi utilizzando un unico plug-in. Per essere chiari, il meccanismo di piggyback può essere utilizzato per assegnare i database ad altri host. Tutta la configurazione avviene tramite un file YAML. Le opzioni stabili sono disponibili tramite le regole dell'agent bakery. Altre impostazioni, che ci riserviamo di modificare, possono essere configurate utilizzando un editor di testo. I dettagli sono disponibili nel Werk #15842.

Con l'introduzione del nuovo plug-in dell'agente, inizia la deprecazione del vecchio plug-in dell'agente Microsoft SQL Server (Windows). In Checkmk 2.3.0 riceverai solo informazioni sull'uso di un set di regole obsoleto. A partire da 2.4.0 non sarà più possibile creare nuove regole e con 2.5.0 il vecchio plug-in sarà probabilmente rimosso da Checkmk. Ulteriori informazioni sono disponibili nel Werk #15844.

Il termine scheda di gestione indica schede plug-in separate o funzionalità estese del BIOS (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 a Checkmk 2.3.0, le schede di gestione possono essere configurate in due modi: Poiché la configurabilità come proprietà di un host è molto limitata, in futuro questa opzione non sarà più disponibile. Il supporto per le schede di gestione compatibili con Redfish sarà aggiunto e migliorato durante l'host lifecycle di Checkmk 2.3.0, inizialmente come MKP opzionale(Werk #16589). Ti spieghiamo ulteriori informazioni di base e alternative nell'articolo del blog Monitoraggio delle schede di gestione.

Fino a Checkmk 2.2.0, ogni utente dell'automazione poteva essere autenticato con un nome utente e una password passati tramite il parametro GET. Questa opzione sarà ridotta a partire da Checkmk 2.3.0 e infine rimossa completamente(Werk #16223). A medio termine, dovrai quindi switchare i tuoi script all'autenticazione tramite header http.

Innanzitutto, 2.3.0 rende configurabile l'opzione di login tramite il parametro GET. Tuttavia, l'impostazione globale Enable automation user authentication via HTTP parameters utilizzerà inizialmente enabled come predefinito. In Checkmk 2.4.0, il default cambierà in disabled. Infine, l'opzione di login tramite il parametro GET sarà completamente rimossa in Checkmk 2.5.0.

Checkmk 2.3.0 sarà l'ultima versione a supportare ntopng nelle versioni 5.x e 6.x(Werk #16483). Con Checkmk 2.4.0, il supporto per ntopng 5.x sarà interrotto e sarà supportato solo ntopng 6.x. Pertanto, aggiorna le tue installazioni di ntopng alla versione 6.x durante il ciclo di vita di Checkmk 2.3.0.