 |
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
Il meccanismo piggyback è in uso fin dagli albori di Checkmk, come parte del monitoraggio di VMware. Ecco una situazione in cui è necessario interrogare i dati da un host specifico perché si trovano solo su quell'host (ad esempio, da un sistema host ESX o dal vCenter), ma nel monitoraggio i dati si riferiscono a un host completamente diverso (una macchina virtuale, per esempio).
Questo non è possibile con il normale meccanismo di Checkmk, poiché esso assegna automaticamente i dati e i servizi che recupera da un host. Sarebbe inoltre molto poco pratico per il monitoraggio se tutte le informazioni relative a tutte le VM apparissero sempre direttamente sull'host ESX o addirittura sul vCenter.
Il termine "piggyback" descrive il processo mediante il quale i dati di monitoraggio per l'host B vengono "agganciati" (per così dire) ai dati interrogati dall'host A.
Oggigiorno il piggyback viene utilizzato in molti altri plug-in di monitoraggio, ad esempio quando si effettua il monitoraggio
Oltre agli ambienti di virtualizzazione, il meccanismo piggyback può essere utilizzato anche per il monitoraggio dei dispositivi mobili o per il monitoraggio climatico nel data center (MQTT). Poiché le interfacce di interrogazione sono molto semplici, è molto facile utilizzare il meccanismo piggyback autonomamente. Puoi utilizzarlo, ad esempio, quando implementi i tuoi plug-in di controllo per effettuare la mappatura dei dati da una fonte dati a qualsiasi altro host.
2. Il principio del piggyback
Il principio di base del piggyback funziona come mostrato nel diagramma seguente: L'host A non solo dispone dei propri dati di monitoraggio, ma anche di quelli provenienti da altri host — o, più in generale, da altri oggetti. Ad esempio, un host ESX registra lo stato e molte metriche attuali per ciascuna delle sue macchine virtuali (VM). Questo host A viene chiamato host piggyback.
Se Checkmk ora recupera i dati di monitoraggio da A nei suoi regolari intervalli di un minuto — sia dal normale agente Checkmk che da un special agent tramite l’API del produttore — nella risposta riceve anche dati di segnalazione contrassegnati in modo speciale dagli altri host/oggetti B, C e così via. Questi dati piggyback vengono poi inseriti in file sul server Checkmk per essere elaborati in seguito. Gli host B, C e così via vengono chiamati host piggybacked.
Se Checkmk richiede in seguito i dati di monitoraggio da B o C, questi sono già presenti nei file locali e possono essere elaborati direttamente senza dover interrogare un agente:
È anche possibile e utile combinare il monitoraggio normale e il piggybacking. Prendiamo di nuovo l'esempio di VMware: Potresti aver installato un agente Checkmk nella tua VM B che valuta le informazioni locali della VM che non sono note all'host ESX (ad esempio, i processi in esecuzione nella VM). In questo caso non solo verrà interrogato l'agente, ma i suoi dati verranno anche combinati con i dati piggyback ricevuti dall'host A:
3. Il piggyback nella pratica
3.1. Configurazione del piggyback
Prima la buona notizia: il meccanismo piggyback spesso funziona in modo completamente automatico:
Se durante l'interrogazione di A vengono rilevati dati piggyback relativi ad altri host, questi vengono automaticamente salvati per una valutazione successiva.
Se durante l'interrogazione di B vengono trovati dati piggyback provenienti da un altro host, questi verranno utilizzati automaticamente.
Tuttavia — come al solito in Checkmk — tutto è configurabile. In particolare, nelle proprietà di un host (come l’host B), nella box “Monitoring agents” puoi impostare come deve reagire ai dati piggyback esistenti o mancanti:
L'impostazione predefinita è "Use piggyback data from other hosts if present". Se disponibili, vengono utilizzati i dati piggyback, mentre se non ce ne sono l'host utilizza semplicemente i propri dati di monitoraggio.
Con l'impostazione "Always use and expect piggyback data" si forza l'elaborazione dei dati piggyback. Se i dati mancano o sono obsoleti, il servizio Check_MK emetterà un avviso.
E con Never use piggyback data qualsiasi dato piggyback trovato viene semplicemente ignorato — un'impostazione di cui avrai bisogno solo in casi eccezionali.
3.2. Gli host devono essere presenti
Ovviamente, affinché un host possa elaborare i dati piggyback, l’host stesso deve essere presente nel monitoraggio. Nell’esempio di ESX questo significa che devi avere anche le tue VM come host in Checkmk, in modo che siano effettivamente monitorate.
Nelle edizioni commerciali,
puoi automatizzare questo processo utilizzando la gestione dinamica degli host e creare automaticamente gli host per i quali sono disponibili dati piggyback.
3.3. Nomi degli host e loro assegnazioni
Negli schemi sopra riportati era in qualche modo logico che i dati relativi all'oggetto B fossero assegnati all'host B nel monitoraggio. Ma come funziona esattamente?
Con il meccanismo 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 esempio, il nome della macchina virtuale. Alcuni plug-in — come Docker — offrono anche diverse opzioni su cosa utilizzare come nome.
 |
I dati piggyback provenienti da host i cui nomi iniziano con un punto non vengono elaborati in Checkmk.
Questo vale, ad esempio, per nomi come |
Affinché la mappatura funzioni correttamente, il nome dell'host corrispondente in Checkmk deve ovviamente 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?
Sono inadatti, ad esempio, i nomi degli host piggybacked che consistono solo di un punto o iniziano con un punto, come .myhostname, poiché questi non vengono elaborati in Checkmk.
Esiste un set di regole speciale Host name translation for piggybacked hosts, che puoi trovare nel menu di configurazione sotto Setup > Agents > Agent access rules.
Per configurare una ridenominazione dovrai fare due cose:
Crea una regola e imposta la condizione per accedere all'host piggyback, ovvero l'host A.
Creare un valore di assegnazione del nome adeguato nella regola.
Ecco un esempio del valore in una regola.
Per prima cosa, la parte del dominio dei nomi host viene rimossa con Convert FQHN.
Poi, tutti i nomi host dai dati piggyback vengono convertiti in lettere minuscole.
Infine, i due host vm0815 e vm081 vengono convertiti negli host Checkmk mylnxserver07 e mylnxserver08:
Più flessibile è il metodo che utilizza le espressioni regolari, disponibile alla voce Multiple regular expressions. Questo è utile se è necessario rinominare molti host e se la rinominazione viene effettuata secondo uno schema specifico. Procedi come segue:
Attiva l'opzione Multiple regular expressions.
Aggiungi una voce di traduzione con il pulsante Add expression: appariranno due campi.
Nel primo campo — Regular expression — inserisci un'espressione regolare che corrisponda al nome originale dell'oggetto e che contenga almeno un sottogruppo, ovvero una sottoespressione racchiusa tra parentesi. Per una buona spiegazione di questi gruppi, consulta l'articolo sulle espressioni regolari.
In Replacement specifica uno schema per il nome host di destinazione desiderato in cui i valori "catturati" con i sottogruppi saranno sostituiti da
\1,\2, ecc.
Un esempio di espressione regolare potrebbe essere, ad esempio, vm(.*)-local.
Il valore sostitutivo myvm\1 tradurrebbe quindi il nome vmharri-local in myvmharri.
3.4. Dati piggyback obsoleti
Se la tua rete cambia, anche i dati piggyback potrebbero cambiare. Questo solleva nuove domande. Come reagisce il monitoraggio se un host non è accessibile? Cosa succede se i dati piggyback diventano obsoleti, ad esempio perché l'oggetto non è più disponibile temporaneamente - o addirittura permanentemente? Tutti i dati piggyback vengono trattati allo stesso modo o ci sono delle differenze? Come per molti altri temi in Checkmk, anche in questo caso il comportamento dipende dalle impostazioni e quindi dalle regole. Con la regola Processing of piggybacked host data, che trovi sotto Setup > Agents > Agent access rules, puoi impostare varie opzioni.
Nella sezione Processing of piggybacked host data inserisci i dettagli effettivamente rilevanti per l'elaborazione dei dati piggyback.
Checkmk semplifica il tuo lavoro nella gestione dei dati piggyback. Tra le altre cose, rimuove automaticamente tutti gli host/oggetti per i quali nessun dato piggyback viene (o non viene più) fornito da un host piggyback. Con l'opzione Keep hosts while piggyback source sends piggyback data only for other hosts specifichi il tempo dopo il quale i file interessati con dati piggyback vengono eliminati. Assicurati che questo periodo sia almeno pari all'intervallo di check per gli host piggyback.
Usa le due opzioni in "Set period how long outdated piggyback data is treated as valid" per definire per quanto tempo i dati piggyback esistenti debbano essere considerati validi se l'host non fornisce più nuovi dati. Una volta scaduto il periodo definito, i servizi basati sui dati piggyback vengono visualizzati come in stallo. Puoi anche definire lo stato del servizio "Check_MK" durante questo periodo. Puoi usare questa opzione per evitare avvisi inutili, specialmente se ci sono ripetute interruzioni di connessione di breve durata.
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 piggyback nell'opzione Explicit hosts in Conditions.
4. La tecnologia alla base di questo processo
4.1. Trasporto dei dati piggyback
Come descritto sopra, i dati piggyback vengono trasportati anche ad altri host insieme all'output dell'agente dall'host piggyback. L'output dell'agente Checkmk è in un semplice formato testuale.
La novità è che nell'output è consentita una riga che inizia con <<<< e termina con >>>>.
In mezzo c'è un nome host.
Tutti gli ulteriori dati di monitoraggio a partire 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:
<<<<316-VM-MGM>>>>
<<<esx_vsphere_vm>>>
config.datastoreUrl url /vmfs/volumes/55b643e1-3f344a10-68eb-90b11c00ff94|uncommitted 12472944334|name EQLSAS-DS-04|type VMFS|accessible true|capacity 1099243192320|freeSpace 620699320320
config.hardware.memoryMB 4096
config.hardware.numCPU 2
config.hardware.numCoresPerSocket 2
guest.toolsVersion 9537
guest.toolsVersionStatus guestToolsCurrent
guestHeartbeatStatus green
name 316-VM-MGM
...
<<<<>>>>Per terminare questa assegnazione devi usare una riga con il contenuto <<<<>>>>.
Qualsiasi output successivo appartiene di nuovo all'host piggyback.
Durante l'elaborazione dell'output dell'agente Checkmk, Checkmk estrae le parti destinate ad altri host e le colloca in file sotto ~/tmp/check_mk/piggyback.
Sotto questa directory c'è una sottodirectory per ogni host piggyback (ad esempio, per ogni VM) — cioè, se ci atteniamo al nostro esempio con il nome B.
In questa sottodirectory ci sarà quindi un file separato con i dati effettivi di ogni host piggyback.
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.
|
Se sei curioso di sapere come sono fatti i dati piggyback, cerca l'output dell'agente di monitoraggio dagli host del tuo sito di monitoraggio nella directory |
Il comando cmk-piggyback list sources restituisce un elenco di tutti gli host piggyback che hanno fornito dati per altri host.
Il suo equivalente è cmk-piggyback list piggybacked, che mostra un elenco di tutti gli host piggyback (indipendentemente dal fatto che siano già inclusi nel monitoraggio).
Il comando cmk-piggyback offre anche opzioni aggiuntive per osservare il trattamento dei dati piggyback nel monitoraggio.
Ad esempio, con cmk-piggyback track puoi visualizzare tutti i dati piggyback in arrivo.
Puoi usare cmk-piggyback create-sections per creare dati piggyback di esempio.
4.2. Dati piggyback orfani
Se lavori in un ambiente in cui gli host cambiano automaticamente l'host piggyback, ti consigliamo di utilizzare la gestione dinamica degli host. Se non puoi o non vuoi utilizzare la gestione dinamica degli 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 trattarsi di un errore, ad esempio perché un nome non ha una corrispondenza esatta.
Il comando cmk-piggyback list orphans ti mostra tutti gli oggetti per i quali sono disponibili dati piggyback, ma per i quali non esiste alcun host nel monitoraggio.
Viene visualizzato un elenco con una riga per ogni host piggyback non monitorato trovato:
Questo output è "pulito" e può, ad esempio, essere processato in uno script.
4.3. Piggyback nel monitoraggio distribuito
Nel monitoraggio distribuito, puoi organizzare i tuoi dati piggyback in base alle tue strutture operative. Ciò significa che i dati piggyback che affluiscono nel monitoraggio tramite un host possono essere assegnati a un altro host per la valutazione, anche tra istanze diverse. I dati piggyback vengono inoltrati tramite l'istanza centrale.
Per impostazione predefinita, i dati piggyback vengono sempre elaborati nell'istanza in cui vengono rilevati, e i dati vengono automaticamente assegnati all'host su cui arrivano. Puoi modificare questo comportamento tramite le proprietà dell'host.
Seleziona qui l'istanza alternativa desiderata — che si tratti dell'istanza centrale o di un'istanza remota su cui vuoi effettuare il monitoraggio dei dati piggyback. Quanto segue vale anche per gli host sull'«istanza nuova»: gli host devono essere presenti.
Per ridurre il carico sull'istanza centrale, puoi in alternativa trasferire i dati piggyback da un'istanza remota a un'altra direttamente, cioè senza coinvolgere l'istanza centrale. Ulteriori informazioni su questa connessione peer-to-peer sono disponibili nell'articolo Monitoraggio distribuito.
5. File e directory
5.1. Percorsi dei file sul server Checkmk
| Percorso | Descrizione |
|---|---|
|
Posizione di archiviazione per i dati piggyback |
|
Directory per i dati piggyback dell'host B |
|
File con i dati piggyback dall'Host A per l'Host B |
|
Meta-informazioni relative agli host che generano i dati piggyback |
|
Output dell'agente dall'Host A — inclusi eventuali dati piggyback esistenti in formato grezzo |
|
Script helper con strumenti di analisi per le funzionalità piggyback. Visualizza le informazioni sul suo utilizzo con |