 |
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. Introduzione
Negli ambienti cloud e container è sempre più comune che gli host monitorati appaiano e scompaiano automaticamente. Mantenere l'ambiente di monitoraggio aggiornato manualmente non è più un'opzione praticabile. Tuttavia, anche le infrastrutture classiche come i cluster VMware possono essere molto dinamiche e, anche se in questo caso la manutenzione manuale non è fattibile, è comunque possibile mantenere l'ambiente di monitoraggio aggiornato manualmente.
Le edizioni commerciali di Checkmk ti supportano
con uno strumento intelligente: la gestione dinamica degli host.
La gestione dinamica degli host utilizza le informazioni provenienti dal monitoraggio di Amazon Web Services (AWS), Microsoft Azure, Kubernetes, VMware ESXi e altre fonti per aggiungere automaticamente gli host al monitoraggio, nonché per eliminarli quando non sono più necessari.
La gestione dinamica degli host è generica e non si limita alla creazione di host. Costituisce la base per future estensioni di Checkmk che adatteranno dinamicamente la configurazione. A questo scopo, la gestione dinamica degli host funziona con le connessioni. Ogni connessione può recuperare informazioni da un tipo specifico di fonte e dispone di una propria configurazione specifica a questo scopo.
Il Dynamic Configuration Daemon (DCD) è il componente software che fornisce la gestione dinamica degli host. L'architettura software del DCD è stata completamente riprogettata nella versione 2.4.0 di Checkmk per soddisfare i requisiti di ambienti di grandi dimensioni e altamente dinamici e garantire un'elaborazione stabile e sicura. La raccolta di informazioni dalle connessioni configurate è ora disaccoppiata dalle modifiche di configurazione risultanti in Checkmk. Le modifiche di configurazione in sospeso sono organizzate in code ed elaborate in sequenza in cicli, il che garantisce un'elaborazione stabile e sicura. Le impostazioni della gestione degli host ti offrono opzioni per personalizzare i cicli di elaborazione. Per ulteriori informazioni, consulta il capitolo Configurazione.
2. Tipi di connessione
Configurando una connessione nella gestione dinamica degli host, puoi aggiungere automaticamente gli host al monitoraggio e anche eliminarli di nuovo automaticamente, in modo da avere sempre un quadro della situazione in tempo reale. Per farlo, la gestione dinamica degli host analizza i dati esistenti, confronta quali host sono già presenti nell'ambiente di configurazione e crea gli host mancanti o elimina quelli che non sono più presenti. Successivamente, viene eseguito (facoltativamente) un'operazione di scoperta del servizio sugli host e, infine, le modifiche vengono attivate in modo che lo stato attuale sia visibile nell'ambiente di monitoraggio.
2.1. Connessione piggyback
La connessione piggyback viene utilizzata per valutare — com'è ovvio — i dati piggyback. Questo tipo di connessione può essere utilizzato universalmente in Checkmk, poiché il meccanismo piggyback viene utilizzato da Checkmk in tutte le situazioni in cui una query a un host (di solito tramite un special agent) fornisce dati su altri host (di solito macchine virtuali o oggetti cloud).
Checkmk utilizza il piggyback, ad esempio, per monitorare Proxmox, Docker, VMware ESXi e gli hyperscaler AWS, Azure e GCP. In tutti questi casi, il monitoraggio recupera automaticamente i dati da altri host, come le macchine virtuali (VM), che non sono direttamente accessibili tramite la rete e sui quali non è necessario che sia in esecuzione alcun agente Checkmk. Puoi includere automaticamente tali host nel monitoraggio e anche eliminarli nuovamente. Gli host creati automaticamente possono comunque essere modificati manualmente nella GUI di Setup.
L'unico requisito per utilizzare una connessione piggyback sono i dati piggyback. Li avrai sempre a disposizione se hai configurato il monitoraggio per AWS, Azure e altri come descritto nel manuale.
Puoi anche verificare facilmente la presenza dei dati piggyback dalla riga di comando, poiché questi dati vengono creati da Checkmk nella directory ~/tmp/check_mk/piggyback/:
Se questa directory non è vuota, in questo sito sono stati generati dati piggyback.
2.2. Connessione OpenTelemetry
Checkmk 2.4.0 offre in 
Checkmk Ultimate un supporto sperimentale per l'elaborazione delle metriche OpenTelemetry.
A tal fine, un Collettore OpenTelemetry in Checkmk raccoglie i dati delle metriche che il collector riceve tramite il protocollo OpenTelemetry (OTLP) o recupera tramite un endpoint Prometheus.
Durante la configurazione del collector, vengono impostate anche delle regole per generare nomi host per Checkmk dai dati.
Una volta configurato, il collector inizia a raccogliere i dati e li memorizza nell'istanza Checkmk con nomi di file che corrispondono ai nomi host.
Il Setup di OpenTelemetry, compreso il Collettore OpenTelemetry, è descritto nell'articolo Monitoraggio delle metriche OpenTelemetry.
I dati OpenTelemetry sono sempre disponibili nell'istanza se il Collettore OpenTelemetry è stato configurato correttamente. Puoi verificarlo tramite la riga di comando, poiché i dati OpenTelemetry sono memorizzati nella directory ~/tmp/check_mk/otel_collector/:
Se questa directory non è vuota, significa che in questa istanza sono stati generati dati OpenTelemetry.
3. Configurazione della connessione
Apri la pagina di gestione dinamica degli host all'indirizzo Setup > Hosts > Dynamic host management:
Crea una nuova connessione utilizzando Add connection.
3.1. Proprietà generali
La prima parte della configurazione è l'General properties:
Come spesso accade, qui assegni un ID univoco e un titolo a questa connessione.
In "Site" devi selezionare l'istanza Checkmk in cui vengono generati i dati.
Con "Generated" si intende l'istanza in cui i dati vengono memorizzati nella directory ~/tmp/check_mk/ per il rispettivo tipo di connessione.
Nella maggior parte dei casi, la memorizzazione dei dati è gestita da un special agent.
Poiché i dati possono essere elaborati solo localmente su un sito specifico, la connessione deve essere assegnata a quel sito. In un monitoraggio distribuito con configurazione centrale, devi quindi specificare l'istanza su cui i dati — che si tratti di dati piggyback o provenienti da altre fonti — devono essere raccolti e successivamente elaborati. Qui non si determina su quale istanza devono essere creati gli host. Questo lo specifichi nell'Host attributes to sete utilizzando l'attributo host Basic settings: Monitored on site. La connessione viene quindi assegnata all'host.
3.2. Proprietà di una connessione piggyback
La seconda parte riguarda le proprietà della connessione (Connection properties). Dato che ci sono parecchie cose da configurare qui, esamineremo le opzioni una per una.
Per una connessione piggyback, seleziona Piggyback data come Connector type.
Con Restrict source hosts puoi limitare questa connessione a host specifici come sorgenti. Di solito si tratta degli host per i quali è stato configurato un special agent. La gestione dinamica degli host è attiva solo per questi host. La restrizione va inserita nel campo di immissione corrispondente, il cui contenuto viene interpretato come un'espressione regolare. Una volta modificato il primo campo di immissione, quello successivo si aprirà automaticamente, il che significa che puoi specificare più espressioni regolari.
Con l'Sync interval, puoi determinare la frequenza con cui la connessione deve cercare nuovi host. Se hai mantenuto l'intervallo di controllo regolare di un minuto, non ha senso farlo molto più frequentemente, poiché i dati possono cambiare al massimo una volta al minuto. In ambienti più dinamici, puoi impostare sia l'intervallo di controllo che l'intervallo di connessione su valori significativamente più piccoli. Tuttavia, ciò comporta anche un maggiore utilizzo della CPU sul server Checkmk.
Deve esserci almeno una voce in Piggyback creation options. Puoi anche aggiungerne altre usando Add new entry:
Questa sezione riguarda le proprietà degli host generati automaticamente, per i quali puoi specificare due cose importanti: La cartella in cui devono essere creati gli host (Create hosts in) e quali attributi dell'host devono essere impostati. Sono preimpostati quattro attributi importanti, che di solito sono utili per gli host piggybacked:
Nessun monitoraggio tramite SNMP.
Nessun agente Checkmk sull'host stesso (i dati arrivano tramite piggyback).
I dati piggyback sono sempre previsti (e se mancano si verifica un errore).
Gli host non hanno un indirizzo IP.
Se vuoi utilizzare i dati piggyback su un altro sito, attiva l'opzione Add attribute e poi l'opzione Basic settings: Monitored on site e specifica l'istanza desiderata.
Solo se attivi la checkbox in "Delete vanished hosts" gli host verranno nuovamente eliminati se sono scomparsi nel tuo ambiente dinamico. Se non vuoi creare automaticamente tutti gli host piggyback, puoi limitare questa operazione con l'opzione "Only add matching hosts" utilizzando un'espressione regolare.
Nella terza e ultima parte delle proprietà di connessione, puoi specificare che venga eseguita la scoperta del servizio sugli host generati automaticamente attivando la checkbox in Service discovery:
Le restanti tre opzioni riguardano l’eliminazione degli host creati automaticamente, un tema spiegato in dettaglio in un capitolo a parte.
L'opzione Prevent host deletion after initialization comporta un riavvio completo del server Checkmk stesso. In questa situazione, i dati di tutti gli host inizialmente mancheranno finché non saranno stati interrogati per la prima volta. Per evitare l'eliminazione e la ricomparsa inutili degli host (che è anche accompagnata da notifiche ripetute di problemi già noti), l'eliminazione non viene generalmente eseguita durante i primi 10 minuti per impostazione predefinita. Puoi impostare questo tempo qui.
L'opzione Validity of missing data si occupa del caso in cui un host, sulla base dei cui dati di monitoraggio sono stati creati automaticamente diversi host, non fornisca più dati piggyback. Questo può verificarsi, ad esempio, se l'accesso ad AWS e simili non funziona più. O, naturalmente, se hai rimosso l'special agent dalla configurazione. Gli host generati automaticamente rimarranno quindi nel sistema per il tempo impostato prima di essere eliminati dalla GUI di Setup.
L'opzione "Validity of outdated data" è simile, ma riguarda il caso in cui i dati continuano ad arrivare, ma non più per alcuni host. Questo è il caso normale quando, ad esempio, le macchine virtuali o i servizi cloud non sono più disponibili. Se vuoi che gli oggetti corrispondenti scompaiano prontamente da Checkmk, imposta qui un periodo di tempo adeguatamente breve.
3.3. Proprietà di una connessione OpenTelemetry
Le opzioni per creare una connessione piggyback e una connessione OpenTelemetry, che possono essere configurate in Checkmk Ultimate, sono quasi identiche. Forniremo quindi una rapida panoramica delle proprietà di una connessione OpenTelemetry.
Per una connessione OpenTelemetry, seleziona "Opentelemetry collector data" come "Connector type".
Usa "Sync interval" per determinare la frequenza con cui la connessione deve cercare nuovi host.
In Open telemetry hosts creation options, specifica la cartella in cui devono essere creati gli host (Create hosts in) e quali attributi host devono essere impostati. Due attributi sono preimpostati:
Per il monitoraggio vengono utilizzati solo i dati forniti tramite le integrazioni API.
Gli host non hanno un indirizzo IP.
Solo se attivi la checkbox in "Delete vanished hosts" gli host verranno nuovamente eliminati se sono scomparsi nel tuo ambiente dinamico. Se non vuoi che tutti gli host vengano creati automaticamente, puoi limitare questa operazione con l'opzione "Only add matching hosts" utilizzando un'espressione regolare.
Selezionando la casella in "Service discovery", specifichi che la scoperta del servizio venga eseguita sugli host generati automaticamente. Tuttavia, questo porta al risultato desiderato solo se è configurato uno speciale agent per OpenTelemetry.
Le ultime due opzioni, Prevent host deletion after initialization e Validity of outdated data, influiscono sull'eliminazione degli host creati automaticamente. Queste opzioni funzionano come descritto nella sezione dedicata alla connessione piggyback. L'eliminazione degli host creati automaticamente è spiegata in dettaglio in un capitolo a parte.
3.4. Salvataggio della connessione
Una volta salvata, la connessione apparirà nell'elenco delle connessioni. Tuttavia, potrà essere eseguita solo dopo che le modifiche saranno state attivate. Solo allora la connessione inizierà a funzionare.
Pertanto, non lasciarti confondere dal messaggio che appare inizialmente nella colonna "Status
" dopo il salvataggio:
Connection 'my_connection' isn’t found: consider activating changes
3.5. Attivazione della connessione
Dopo aver salvato le proprietà della connessione e attivato le modifiche, la connessione inizierà automaticamente a funzionare. Se sono già disponibili dati per questa connessione e ti aspetti che vengano generati gli host corrispondenti, vedrai presto una voce corrispondente nell'elenco sotto "Recent processing cycles", che potrebbe apparire più o meno così:
Nell'immagine di esempio, puoi vedere che questa esecuzione è quasi completata e che alla fine verranno creati almeno 50 host. Se aggiorni questa pagina poco dopo, queste modifiche saranno probabilmente già state attivate automaticamente dalla gestione dinamica degli host. Il risultato dell'elaborazione dell'esempio sopra riportato sarà quindi simile a questo:
I nuovi host saranno quindi già in monitoraggio e verranno sottoposti a monitoraggio regolare.
L'elenco "Recent processing cycles" mostrerà i cicli su un periodo di tempo più lungo che hanno effettivamente portato a delle modifiche.
I cicli della connessione che non hanno portato ad alcuna modifica verranno nascosti dopo pochi secondi.
Per effettuare la visualizzazione, clicca sul simbolo dell'orologio 
nella colonna "Actions", che ti porterà alla "Execution history of this connection" (Cronologia delle esecuzioni).
3.6. Azioni per una connessione
Per ogni connessione, l'elenco delle connessioni nella colonna "Actions" mostra dei simboli per eseguire delle azioni:
Alcune dei seguenti simboli vengono visualizzati solo per una connessione attivata:
| Simbolo | Azione |
|---|---|
|
Apre la connessione per modificarla. |
|
Clona la connessione e la apre per la modifica. |
|
Visualizza un elenco degli host creati da questa connessione. |
|
Visualizza la cronologia di esecuzione della connessione. |
|
Visualizza lo stato della gestione dinamica degli host, ovvero i cicli di elaborazione correnti. |
|
Esegue la connessione senza attendere il ciclo di processo successivo. |
|
Mostra come creare la connessione con l'API REST di Checkmk. |
|
Elimina la connessione dopo la conferma. |
4. Eliminazione automatica degli host
Come accennato sopra, gli host che "non esistono più" possono essere eliminati automaticamente dal monitoraggio tramite la gestione dinamica degli host. A prima vista, sembra molto logico, tuttavia, il significato esatto di "non esiste più" è un po' più complesso se ci si riflette, poiché ci sono diversi casi alternativi da considerare.
Nella seguente panoramica daremo per scontato che tu abbia attivato l'opzione su Delete vanished hosts per la connessione. In caso contrario, gli host non verranno mai eliminati automaticamente.
| Situazione | Cosa succede? |
|---|---|
Viene rimossa una connessione. |
Se disattivi una connessione (tramite do not activate this connection nell'General properties) o la elimini completamente, tutti gli host creati da questa connessione vengono mantenuti. Se necessario, devi eliminarli manualmente. |
Un host piggyback non viene più sottoposto a monitoraggio. |
Se elimini dal monitoraggio un host piggyback che utilizzi per monitorare il tuo ambiente cloud o container, ovviamente non genererà più dati piggyback. In questo caso, gli host piggyback generati automaticamente vengono eliminati automaticamente dopo un'ora per impostazione predefinita. Puoi modificare questo periodo utilizzando l'opzione "Validity of missing data". |
Un host piggybacked non è raggiungibile. |
Se il tuo ambiente cloud non è disponibile e il servizio Check_MK che lo interroga restituisce l'errore "CRIT", gli host generati automaticamente rimangono in monitoraggio a tempo indeterminato. In questo caso non c'è alcun timeout di un'ora! |
Un host creato automaticamente non è più incluso nei dati. |
Questo è praticamente la norma in un ambiente cloud/container. In questo caso, per impostazione predefinita l'host viene automaticamente cancellato dopo un minuto. Puoi regolare il periodo di tempo utilizzando l'opzione Validity of outdated data. |
Il server Checkmk stesso viene arrestato. |
L'arresto di tutto il monitoraggio fa sì che i dati diventino obsoleti, ma gli host esistenti non vengono ovviamente eliminati di conseguenza. Lo stesso vale quando il server Checkmk viene eseguito in modalità di riavvio (il che causa temporaneamente la perdita di tutti i dati, poiché questi sono memorizzati nel disco RAM). |
Tieni presente che con la regola "Automatic host removal" è possibile che tutti gli host vengano eliminati automaticamente. Entrambe le opzioni per la gestione del ciclo di vita funzionano indipendentemente l'una dall'altra, ovvero un host viene eliminato se viene soddisfatta una delle due condizioni.
5. Configurazione
Le impostazioni di Host Manager ti permettono di personalizzare i cicli di elaborazione della gestione dinamica degli host. Puoi accedere al dialogo tramite Setup > Hosts > Dynamic host management > Host manager settings:
Le impostazioni predefinite qui sono già selezionate in modo tale da funzionare bene anche in ambienti più grandi ed estremamente dinamici. Tuttavia, se il tuo ambiente subisce molte modifiche ogni minuto, queste creeranno un certo carico sul tuo server Checkmk. Per controllare meglio questo carico, con Checkmk 2.4.0 sono state introdotte le impostazioni di Host manager settings.
Cosa fanno esattamente le singole opzioni è già descritto in modo molto dettagliato nell'aiuto in linea e quindi non verrà ripetuto qui. Di seguito descriviamo le tre aree e quali sono le loro funzioni.
Host processing consiste nel trovare e assegnare dati specifici per host tra quelli disponibili. Questo risponde a domande come: sono stati trovati nuovi dati? E bisogna creare degli host per questi dati? Se devi prendere regolarmente un gran numero di decisioni di questo tipo, potrebbe essere utile aumentare le pause tra le esecuzioni per dare tempo sufficiente al processo delle code.
In qualità di amministratore di Checkmk, probabilmente hai già molta familiarità con la funzione Activate changes. Questa azione determina come e quando la gestione dinamica degli host deve attivare le modifiche e quanto tempo può impiegare per farlo.
Anche la funzione Service discovery non sarà più un grande mistero per te. Tuttavia, a seconda dell'ambiente di monitoraggio, alcuni host in più potrebbero essere in attesa di un rilevamento massivo nella gestione dinamica degli host. In una situazione del genere, consulta l'aiuto in linea dettagliato in modo da poter intervenire in modo tempestivo e mirato in caso di ritardi nel processo di gestione dinamica degli host.
L'ultima opzione del gruppo (Do not monitor hosts without discovered services) è stata introdotta per gestire una situazione particolare. In pratica è necessaria solo se le modifiche in sospeso vengono spesso forzate senza una previa scoperta del servizio. Questa opzione va attivata con cautela. Tuttavia, se è necessaria, potrebbe essere un indicatore del fatto che le opzioni precedenti non sono state configurate in modo ottimale, oppure che il server Checkmk non riesce più a gestire il carico generato dalla gestione dinamica degli host.
6. Diagnosi
6.1. Cronologia delle esecuzioni
Se vuoi vedere il DCD all'opera, troverai il simbolo dell'orologio nell'elenco delle connessioni per ogni voce,
che ti porterà alla cronologia delle esecuzioni:
Se, per qualsiasi motivo, la creazione di un host fallisce, questo sarà visibile nella cronologia delle esecuzioni.
6.2. Il file di log del DCD
Il file di log del DCD è ~/var/log/dcd.log.
Ecco un esempio che corrisponde all'illustrazione precedente:
2025-08-21 11:46:18,962 [20] [cmk.dcd.Manager] 1 batches arrived 50, last activated is reset
2025-08-21 11:46:19,059 [20] [cmk.dcd.Manager] Batches: {281} = Create: 0 Edit: 0 Delete: 0 Discover: 0
2025-08-21 11:46:19,059 [20] [cmk.dcd.Manager] Skip batches {281}7. File e directory
| Percorso del file | Funzione |
|---|---|
|
È qui che vengono generati i dati piggyback. Viene creata una sottodirectory per ogni host piggyback contenuto nei dati piggyback. |
|
Qui è dove vengono generati i dati OpenTelemetry. Viene creata una sottodirectory per ogni host. I file creati lì sono in formato JSON. |
|
File di log del Dynamic Configuration Daemon (DCD). |