Meccanismo di piggyback

Prima le buone notizie: il meccanismo di piggyback funziona spesso in modo completamente automatico:

Tuttavia, come sempre in Checkmk, tutto è configurabile: a nome host, nelle proprietà di un host (ad esempio l'host B) nel box Monitoring agents puoi impostare come reagire ai dati piggyback esistenti o mancanti:

L'impostazione predefinita è Use piggyback data from other hosts if present. Se sono disponibili, vengono utilizzati i dati piggyback; se non ci sono, l'host utilizza i propri dati di monitoraggio.

Con l'impostazione Always use and expect piggyback data si forza il processo dei dati piggyback: se i dati sono mancanti o obsoleti, il servizio Check_MK emette un avviso.

Con Never use piggyback data, invece, tutti i dati piggyback trovati vengono semplicemente ignorati: un'impostazione che ti servirà solo in casi eccezionali.

Naturalmente, affinché un host possa processare i dati piggyback, l'host stesso deve essere presente nel monitoraggio. Nell'esempio di ESX, ciò significa che le tue macchine virtuali devono essere presenti come host in Checkmk in modo da essere effettivamente monitorate.

Nelle edizioni commerciali, puoi automatizzare questo processo utilizzando la configurazione dinamica e creare automaticamente gli host per i quali sono disponibili i dati piggyback.

Negli schemi precedenti era in qualche modo logico che i dati dell'oggetto B fossero assegnati all'host B nel monitoraggio. Ma come funziona esattamente?

Con il meccanismo del piggyback l'assegnazione utilizza sempre un nome. L'agente (speciale) scrive un nome di oggetto per ogni set di dati piggyback. Nel caso di ESX, ad es. il nome della macchina virtuale. Alcuni plug-in, come Docker, hanno anche diverse opzioni per il nome da utilizzare.

Nota: i dati piggyback provenienti da host il cui nome inizia con un punto non vengono processati da Checkmk. Questo vale, ad esempio, per nomi come ., .hostname o .hostname.domain.com. Per includere questi host nel monitoraggio, i nomi host devono essere modificati come descritto.

Affinché la mappatura funzioni correttamente, il nome host corrispondente in Checkmk deve essere identico, comprese le maiuscole e le minuscole.

Ma cosa succede se i nomi degli oggetti nei dati piggyback sono inappropriati o indesiderati per il monitoraggio? Ad esempio, i nomi degli host piggyback che sono composti solo da un punto o che iniziano con un punto, come .myhostname, non vengono processati da Checkmk. Esiste un set di regole speciale Hostname translation for piggybacked hosts, che puoi trovare nel menu di configurazione alla voce Setup > Agents > Agent access rules.

Per configurare una rinominazione dovrai fare due cose:

Ecco un esempio di valore in una regola. Vengono configurate due cose: innanzitutto, tutti i nomi host dei dati piggyback vengono convertiti in lettere minuscole. Poi i due host vm0815 o vm0816 vengono convertiti anche in mylnxserver07 o mylnxserver08 dell'host Checkmk:

Più flessibile è il metodo che utilizza le espressioni regolari che si trova in Multiple regular expressions. Questo metodo è utile se è necessario rinominare molti host e farlo secondo uno schema specifico. Procedi come segue:

Un esempio di espressione regolare potrebbe essere, ad esempio, vm(.*)-local. Il valore sostitutivo myvm\1 tradurrebbe il nome vmharri-local in myvmharri.

Se la tua rete cambia, anche i dati piggyback possono cambiare. Questo solleva nuove questioni: come reagisce il monitoraggio se un host non è accessibile? Cosa succede se i dati piggyback diventano obsoleti, ad esempio perché l'oggetto non è temporaneamente - o addirittura permanentemente - più disponibile? Tutti i dati piggyback vengono trattati allo stesso modo o ci sono delle differenze? Come per molti altri temi di Checkmk, anche in questo caso il comportamento è una questione di regole e quindi di impostazioni. Con la regola Processing of piggybacked host data, che puoi trovare sotto Setup > Agents > Agent access rules, puoi impostare diverse opzioni.

Nella sezione Processing of piggybacked host data puoi inserire i dettagli più interessanti per il processo dei dati piggyback.

Checkmk ti facilita il lavoro nella gestione dei dati piggyback. Tra le altre cose, rimuove automaticamente tutti gli host/oggetti per i quali un host sorgente non fornisce (o non fornisce più) dati piggyback. Con l'opzione Keep hosts while piggyback source sends piggyback data only for other hosts puoi specificare il periodo di tempo dopo il quale i file interessati con i dati piggyback vengono eliminati. Assicurati che questo periodo sia almeno pari all'intervallo di tempo del controllo degli host piggyback.

Utilizza le due opzioni in Set period how long outdated piggyback data is treated as valid per definire per quanto tempo i dati piggyback esistenti devono essere considerati ancora validi se l'host non fornisce più nuovi dati. Allo scadere del periodo definito, i servizi basati sui dati piggyback vengono visualizzati come in stallo. Definisci anche lo stato del servizio Check_MK durante questo periodo. Puoi utilizzarlo per evitare avvisi inutili, soprattutto se si verificano ripetute interruzioni di connessione a breve termine.

Una volta definita la gestione dei dati piggyback in generale, puoi definire una gestione separata (secondo lo stesso schema) per i singoli host in Exceptions for piggybacked hosts utilizzando le opzioni descritte.

Infine, devi sempre specificare il nome dell'host di origine nell'opzione Explicit hosts del programma Conditions.

Come descritto in precedenza, i dati piggyback vengono trasportati ad altri host con l'output dell'agente dall'host di origine. L'output dell'agente Checkmk è un semplice formato testuale che viene mostrato nell 'articolo sugli agenti di monitoraggio.

La novità è che nell'output è consentita una riga che inizia con <<<< e termina con >>>>. In mezzo c'è il nome host. Tutti gli altri dati di monitoraggio che iniziano da questa riga vengono quindi assegnati a questo host. Ecco un esempio di estratto che assegna la sezione <<<esx_vsphere_vm>>> all'host 316-VM-MGM:

Una riga con il contenuto <<<<>>>> può essere utilizzata per terminare l'assegnazione. Qualsiasi altro output appartiene quindi nuovamente all'host di origine.

Durante il processo di elaborazione dell'output dell'agente Checkmk estrae le parti destinate ad altri host e le inserisce nei file sotto ~/tmp/check_mk/piggyback. Al di sotto di questa c'è una sottodirectory per ogni host di destinazione (ad esempio, per ogni VM) - se ci atteniamo al nostro esempio con il nome B. In questa sottodirectory ci sarà un file separato con i dati effettivi di ogni host di origine. I loro nomi sarebbero A nel nostro esempio. Perché è così complicato? Beh, un host può effettivamente ricevere dati piggyback da più host, quindi un singolo file non sarebbe sufficiente.

Suggerimento: se sei curioso di sapere come appaiono i dati piggyback, consulta l'output dell'agente di monitoraggio degli host del tuo sito nella directory ~/tmp/check_mk/cache. Di seguito troverai una panoramica di tutti i file e le directory coinvolte.

Se lavori in un ambiente di configurazione in cui gli host cambiano automaticamente l'host di origine, ti consigliamo di utilizzare la configurazione dinamica dell'host. Se non puoi o non vuoi utilizzare la configurazione dinamica dell'host, ad esempio perché le macchine virtuali vengono spostate manualmente, potresti ricevere dati piggyback da un host che non hai nemmeno creato in Checkmk. Questo potrebbe essere intenzionale, ma potrebbe anche essere un errore, ad es. perché un nome non ha una corrispondenza esatta.

Nei "Tesori" troverai uno script chiamato find_piggy_orphans con il quale Checkmk può cercare i dati piggyback per i quali non c'è alcun host in monitoraggio. Basta chiamare questo script senza alcun argomento. Lo script produrrà un elenco con una riga - ordinata per nome - per ogni host piggyback non monitorato trovato:

Questo output è "pulito" e può essere processato, ad esempio, in uno script.

Si noti che attualmente negli ambienti distribuiti l'host sorgente e gli host piggyback devono essere monitorati nello stesso sito, semplicemente perché, per motivi di efficienza, la trasmissione dei dati tra gli host avviene tramite lo scambio di file locali eseguito attraverso la directory ~/tmp/check_mk.