Configurazione dinamica degli host

Attualmente il DCD di Checkmk è dotato di un solo connettore: quello utilizzato per i dati piggyback. Questo connettore è molto universale, poiché il meccanismo del piggyback viene utilizzato da Checkmk in tutte le situazioni in cui la richiesta da parte di un host (solitamente da parte di un agente speciale) fornisce i dati di altri host (solitamente macchine virtuali o oggetti cloud).

Ecco un paio di esempi in cui Checkmk utilizza il piggyback nel monitoraggio:

In tutti questi casi, il monitoraggio recupera automaticamente i dati da altri host (ad esempio, le macchine virtuali) che non vengono contattati direttamente tramite la rete e sui quali non è necessario che venga eseguito l'agente Checkmk. Con il DCD puoi aggiungere e rimuovere automaticamente tali host nel monitoraggio, in modo da riflettere sempre la situazione reale in modo tempestivo.

Per fare ciò, il DCD analizza i dati piggyback esistenti e li confronta con gli host già presenti nel Setup, per poi ricreare gli host mancanti o, rispettivamente, rimuovere quelli ridondanti. Ci sono host che vengono creati automaticamente dal DCD ma che sono ancora modificabili dall'utente nella GUI del Setup.

Per configurazione predefinita, in Checkmk esiste l'utente automazione, che viene creato da Checkmk per abilitare i prelievi automatici. Un utente automazione esistente è obbligatorio anche per la configurazione dinamica degli host.

Se, per qualsiasi motivo, hai cancellato o modificato questo utente nel tuo sistema, devi creare un altro utente con accesso automatizzato all'API. In questo caso apri le impostazioni di base globali tramite Setup > General > Global settings:

Cliccando su Credentials: Use "Checkmk Automation" user accederai alla pagina di modifica della connessione API REST:

Qui puoi inserire un altro utente e i suoi dati di accesso (nome, password) o modificare l'utente di automazione esistente. Non appena avrai salvato le modifiche con Save, l'utente definito verrà utilizzato per l'automazione e potrai continuare con la configurazione dinamica dell'host.

Dopo aver salvato le proprietà del connettore e dopo aver attivato le modifiche, il connettore inizierà automaticamente a funzionare. Questa operazione può essere così rapida che, subito dopo aver attivato le modifiche, vedrai immediatamente come gli host vengono creati nel monitoraggio:

Se ricarichi questa pagina poco dopo, probabilmente queste modifiche saranno già scomparse, perché sono state attivate automaticamente dal DCD. I nuovi host sono già presenti nel monitoraggio e verranno monitorati regolarmente.

Come accennato in precedenza, puoi ovviamente permettere che gli host che "non esistono più" vengano eliminati automaticamente dal monitoraggio del DCD. A prima vista sembra molto logico. Cosa si intenda esattamente per "non esistono più" è però a prima vista un po' più complesso, in quanto ci sono diverse situazioni da considerare. Nella panoramica che segue partiamo dal presupposto che tu abbia attivato l'opzione di cancellazione, altrimenti gli host non verranno mai rimossi automaticamente.

Nota che con la regola Automatic host removal è possibile rimuovere automaticamente tutti gli host. Entrambe le opzioni per la gestione del ciclo di vita funzionano indipendentemente l'una dall'altra, cioè un host viene rimosso se si verifica una delle due condizioni.

Oltre alla questione se gli host debbano essere rimossi automaticamente o meno, nelle proprietà del connettore ci sono altre tre opzioni che influiscono sulla cancellazione, opzioni che abbiamo saltato in precedenza:

La prima impostazione - Prevent host deletion right after initialization - influisce sul riavvio completo del server Checkmk. In questa situazione, i dati piggyback di tutti gli host saranno inizialmente mancanti fino a quando gli host non verranno interrogati per la prima volta. Per evitare l'insensata cancellazione e ricomparsa degli host (che è anche accompagnata da ripetute notifiche per problemi noti), per impostazione predefinita le cancellazioni saranno generalmente rinunciate durante i primi 10 minuti. Questo limite di tempo può essere personalizzato qui.

L'opzione Validity of missing data gestisce la situazione in cui un host, i cui dati di monitoraggio hanno creato automaticamente diversi host, non restituisce dati piggyback. Questo può accadere, ad esempio, quando l'accesso ad AWS e Co. ha smesso di funzionare o anche, naturalmente, se hai rimosso l'agente speciale dalla configurazione. Gli host generati automaticamente rimarranno nel sistema per il tempo impostato prima di essere rimossi dalla configurazione.

L'opzione Validity of outdated data è simile, ma tratta il caso in cui anche se i dati piggyback vengono ricevuti, ma non da alcuni host. Questo è il caso normale se, ad es. le macchine virtuali o i servizi cloud non sono più disponibili. Se vuoi che gli oggetti corrispondenti scompaiano da Checkmk in modo tempestivo, imposta qui un periodo di tempo relativamente breve.

Se vuoi osservare il DCD al lavoro, per ogni voce dell'elenco dei connettori troverai il simbolo che ti porterà alla cronologia delle esecuzioni:

Se per qualche motivo la creazione di un host non riesce, lo vedrai nella cronologia di esecuzione.

Con Setup > General > Audit log si apre una pagina con l'elenco di tutte le modifiche apportate alla GUI di Setup, indipendentemente dal fatto che siano già state attivate o meno. Cerca le voci dell'elenco dell'utente automation. Il DCD lavora con questo account e genera le modifiche in esso: qui puoi seguire quali host il DCD ha creato o rimosso e quando.

Il file di log del DCD è var/log/dcd.log. Ecco un esempio che corrisponde alla descrizione precedente. Qui troverai anche il messaggio di errore che indica che non è stato possibile creare un host specifico: