![]() |
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
Checkmk supporta il concetto di etichette, alle quali puoi assegnare un numero qualsiasi di host. Le etichette e i tag degli host si comportano in modo abbastanza simile:
Le etichette sono "attaccate" agli host allo stesso modo dei tag.
Le etichette possono essere utilizzate come condizioni per le regole allo stesso modo dei tag.
Le etichette vengono create in modo simile ai tag secondo il principio di
key:value
.
Perché c'è un nuovo concetto? Il mondo dell'IT sta cambiando e sta diventando molto più dinamico. I sistemi cloud e container come Amazon Web Services (AWS), Microsoft Azure e Kubernetes creano e cancellano autonomamente quelli che chiamano oggetti, che in Checkmk corrispondono agli host. In queste tecnologie le etichette e i tag giocano un ruolo importante perché creano connessioni tra gli oggetti monitorati e le loro funzioni. I nomi degli host, invece, sono sempre più casuali e privi di significato.
Checkmk è in grado di creare automaticamente questi host dinamici con la configurazione dinamica degli host e di ricevere informazioni sulle etichette/tag già presenti. Queste etichette/tag possono essere utilizzate per le condizioni delle regole, le ricerche, le valutazioni, i dashboard e altre attività.
Ovviamente sorge la domanda: perché non mappare semplicemente queste etichette dinamiche sul concetto esistente di tag dell'host? Questa è una conclusione molto ovvia a prima vista. Tuttavia, i tag dell'host hanno una proprietà molto importante che renderebbe tutto ciò molto difficile e complicato: Checkmk definisce rigidamente quali etichette e gruppi di tag sono presenti. Tutto è ben definito. Ogni host ha esattamente un tag di ogni gruppo. Tutti possono fare affidamento su di esso. Non si possono verificare errori di battitura nell'ortografia dei tag, nemmeno con host che non si attengono allo schema, perché la sua conformità è strettamente controllata da Checkmk. Questo è molto importante e utile in ambienti molto eterogenei con molte migliaia di host gestiti manualmente.
Al contrario, le etichette dinamiche di Kubernetes e Co sono di fatto "libere" e anche se seguono uno schema, questo non è noto a Checkmk. Inoltre potresti monitorare diverse piattaforme, che a loro volta utilizzano le etichette in modi molto diversi.
Per questo motivo è stato introdotto un concetto di etichette Checkmk che si adatta a questa dinamica in crescita. Naturalmente puoi utilizzare le etichette anche se non utilizzi connessioni ad ambienti Cloud.
Per rispondere alla domanda "Quando usare le etichette e quando i tag degli host?", troverai maggiori informazioni nell'articolo sulla strutturazione degli host.
Ecco le caratteristiche delle etichette:
Le etichette non devono essere predefinite da nessuna parte. Non esiste uno schema fisso per le etichette. Tutto è a modulo libero. Tutto è permesso.
Ogni host può avere tutte le etichette che vuoi, che possono essere gestite manualmente, definite tramite regole o create automaticamente.
Le etichette sono strutturate secondo il principio
key:value
. Ogni host può avere un solo valore per chiave, quindi un host che ha l'etichettafoo:bar
non può avere allo stesso tempofoo:bar2
.A differenza dei tag degli host, sia la chiave che il valore - ad eccezione dei due punti (:) - possono contenere qualsiasi carattere.
Non c'è distinzione tra ID e titolo (o nome visualizzato): la chiave dell'etichetta è entrambi allo stesso tempo.
Le etichette hanno i seguenti compiti:
Costituiscono una base per le condizioni delle regole di configurazione, ad esempio: "Tutti gli host con l'etichetta
os:windows
devono essere monitorati allo stesso modo".È molto facile memorizzare informazioni aggiuntive o commenti su un host (ad esempio,
location:RZ 74/123/xyz
) e visualizzarli nelle visualizzazioni, ad esempio.
2. Creare etichette
2.1. Etichette esplicite
Le etichette dell'host possono essere assegnate in diversi modi.
Il primo è semplice: nella pagina delle proprietà dell'host, che viene visualizzata quando crei o modifichi un host nel Setup, puoi assegnare a un host tutte le etichette che vuoi:

Attiva Labels con il checkbox, poi clicca nel campo Add some label, inserisci la definizione dell'etichetta seguendo lo schema key:value
e termina con Invio.
Puoi modificare un'etichetta esistente cliccando sul suo testo o eliminarla con la piccola "x".
![]() |
Sia la chiave che il valore di un'etichetta possono includere qualsiasi carattere, ad eccezione dei due punti ( |
Naturalmente le etichette possono anche essere ereditate da una cartella. Come gli altri attributi, le etichette possono essere presenti nelle sottocartelle o nell'host e poi, se necessario, possono essere sovrascritteindividualmente. Se ad esempio nella cartella viene impostata l'etichetta location:munich
, questa verrà ereditata da tutti gli host della cartella che non abbiano già definito l'etichetta location
. Le altre etichette dell'host rimarranno inalterate.
Le etichette dell'host o della cartella definite esplicitamente appaiono in viola nell'elenco degli host:

2.2. Creare etichette per le regole
Come di consueto in Checkmk, gli attributi possono essere assegnati agli host e ai servizi anche tramite regole. Questo ti renderà indipendente dalla struttura delle cartelle e si applica anche alle etichette. Esiste un set di regole Host labels per questa funzione, che puoi trovare rapidamente tramite una ricerca nel menu di configurazione.
La regola seguente aggiunge l'etichetta hw:real
a tutti gli host della cartella Bavaria
che hanno il tag host Real Hardware
:

Avrai notato che le etichette non possono essere utilizzate nelle condizioni di questa regola: non si tratta di un errore, ma di una scelta intenzionale che evita dipendenze ricorsive e altre anomalie.
Le etichette aggiunte per mezzo delle regole appaiono in rosso nell'host visualizzato, ma non compaiono nell'elenco degli host nel Setup, bensì solo nella visualizzazione dello stato dell'host.
2.3. Etichette generate automaticamente
Il terzo modo in cui è possibile creare le etichette è in modo completamente automatico. Diverse fonti di dati, come gli agenti speciali per il monitoraggio dei sistemi cloud e container, generano automaticamente le etichette. In particolare, vanno citati gli agenti speciali per AWS, Azure e Kubernetes. A volte questi elementi vengono anche chiamati tag nelle rispettive piattaforme e vengono creati in Checkmk come etichette dell'host o del servizio. I rispettivi set di regole forniscono informazioni sufficienti a riguardo.
L'aspetto positivo è che non devi configurare nulla: non appena queste fonti di dati sono attive, vengono generate le etichette corrispondenti.
Nella sezione Etichette dell'host generate automaticamente troverai una panoramica delle etichette che Checkmk genera automaticamente.
2.4. Specificare le etichette tramite un plug-in dell'agente
Un modo semplice per manipolare direttamente le etichette è quello di aggiungere un plug-in dell'agente che, analogamente ai check locali, crea una sezione chiamata labels
. In questo modo puoi assegnare le etichette in modo più dettagliato rispetto alla sola valutazione dell'inventario HW/software, ad esempio in base alle sfumature dell'hardware installato (come le caratteristiche della CPU) o in base ai processi effettivamente in esecuzione (invece del semplice software installato).
L'output delle etichette deve essere formattato come un dizionario Python, come nell'esempio seguente:
<<<labels:sep(0)>>>
{"cpu/vendor": "zilog"}
Evita conflitti con le etichette assegnate automaticamente da Checkmk stesso e da altri plug-in, poiché non è possibile garantire un ordine particolare di valutazione.
2.5. Includere le etichette trovate durante il discovery check
Se hai attivato il discovery check, che è l'opzione predefinita per le nuove installazioni, ti avviserà quando vengono trovate nuove etichette dell'host che non sono ancora state aggiunte alle proprietà dell'host nel Setup:

Hai due opzioni per rispondere a questo avviso: la prima è quella di aggiungere le nuove etichette richiamando la configurazione del servizio per l'host nel Setup e aggiornando la configurazione delle etichette con il menu di configurazione Hosts > Update host labels. Il discovery check sarà quindi di nuovo OK alla prossima esecuzione (con un ritardo massimo di due ore), anche se non hai ancora attivato le modifiche. Se non vuoi aspettare così tanto, puoi anche aggiornare manualmente il servizio immediatamente selezionando Reschedule check nel menu di azione del servizio.
Se l'aggiornamento riguarda molti host contemporaneamente, non vorrai certo visitare la configurazione del servizio per ogni host. La cosa migliore da fare in questo caso è eseguire l'azione massiva per Run bulk service discovery e selezionare Only discover new host labels come modalità - o in alternativa Add unmonitored services and new host labels se vuoi anche cogliere l'opportunità di aggiungere nuovi servizi.
Il secondo modo per rendere verde il discovery check è quello di riconfigurarlo in modo che non ti avverta più della presenza di nuove etichette. Per farlo, vai al set di regole Periodic service discovery e modifica la regola esistente: lì troverai l'opzione Severity of new host labels:

Per impostazione predefinita è impostata su Warning. Scegli OK - do not alert, just display e il controllo diventerà silenzioso.
Le etichette trovate tramite il discovery check sono visualizzate in giallo-ocra.
2.6. Sequenza delle priorità di assegnazione delle etichette
Teoricamente, la stessa etichetta può essere definita con valori diversi in più fonti contemporaneamente. Per questo motivo esiste il seguente ordine di priorità:
Prima di tutto le etichette esplicite, cioè quelle che definisci per l'host o la cartella direttamente nel Setup.
Al secondo posto ci sono le etichette create per mezzo di regole.
All'ultimo posto ci sono le etichette generate automaticamente.
Queste regole di precedenza ti danno il massimo controllo sulle etichette.
3. Etichette per le regole come condizioni
3.1. Condizioni nelle regole
Una funzione importante delle etichette è la stessa delle caratteristiche dell'host: vale a dire il loro utilizzo come condizioni per le regole. Questo è particolarmente utile per le etichette generate automaticamente, perché puoi adattare il tuo monitoraggio in modo completamente automatico in base alle informazioni provenienti da AWS, Azure, Kubernetes e simili.
Aggiungi le condizioni con Add to condition per le etichette dell'host o del servizio. Ora seleziona is o not per formulare una condizione positiva o negativa e poi inserisci l'etichetta nella solita forma key:value
. Fai attenzione all'ortografia esatta, compresa la maiuscola. Poiché le etichette possono essere definite senza specifiche, Checkmk non può riconoscere gli errori di battitura. Tuttavia: Quando digiti un'etichetta, Checkmk suggerisce le etichette esistenti se corrispondono a quelle inserite in precedenza. Nei suggerimenti non viene fatta distinzione tra etichette dell'host e del servizio: vengono proposte tutte le etichette corrispondenti. Presta attenzione all'ortografia corretta, poiché errori di ortografia, capitalizzazione errata e così via faranno sì che la regola non funzioni più.
Tuttavia, la definizione della condizione fa un ulteriore passo avanti: per perfezionare ulteriormente la condizione, hai a disposizione gli operatori booleani Not
, And
e Or
. In questo caso, Not
è l'abbreviazione di And Not
.
Not
significa che la condizione A deve essere soddisfatta e la condizione B non deve essere soddisfatta allo stesso tempo.And
significa che sia la condizione A che la condizione B devono essere soddisfatte allo stesso tempo.Or
significa che la condizione A o la condizione B devono essere soddisfatte, ma che entrambe le condizioni possono essere soddisfatte.
![]() |
Gli operatori vengono processati esattamente in questa priorità - |
Ad esempio, per trovare gli host con l'etichetta cmk/site:today
ma senza l'etichetta cmk/piggyback_source_today:yes
, la condizione potrebbe essere la seguente:

Puoi perfezionare questa condizione con is o not con qualsiasi altra specifica, oppure puoi aggiungere un nuovo gruppo di condizioni con Add to condition, che rende la condizione più complessa da leggere, ma non cambia la valutazione dell'algebra booleana:

![]() |
Se non hai definito né Host tags né Host labels, la regola in questione viene sempre applicata a tutti gli host o servizi. Se hai creato diverse regole, le regole successive potrebbero non essere più valutate, vedi Tipi di analisi delle regole. |
In una regola puoi utilizzare sia le etichette che i tag dell'host, che sono automaticamente collegati tra loro (AND). Pertanto, la regola si applica solo se entrambe le condizioni sono soddisfatte allo stesso tempo.
3.2. Condizioni nelle regole di notifica
Puoi utilizzare le etichette anche come condizioni nelle regole di notifica. L'utilizzo è lo stesso delle altre condizioni, quindi non devi imparare a usarle. Seleziona Match host labels e inserisci semplicemente le etichette che un host o un servizio devono avere per attivare una notifica attraverso questa regola. Anche in questo caso, le etichette multiple sono collegate dall'operazione AND.
4. Etichette nelle visualizzazioni
Finora abbiamo parlato solo delle etichette nell'ambiente di configurazione (o in breve: il Setup). Le etichette sono visibili anche nell'ambiente di monitoraggio, ad esempio nella visualizzazione dello stato dell'host:

Qui puoi vedere le etichette con colori diversi a seconda di come sono state create: etichette esplicite in viola, etichette create per le regole in rosso e etichette create da un discovery check in giallo-ocra.
L'evidenziazione colorata delle etichette non solo risalta visivamente nella visualizzazione, ma è anche pratica in quanto è possibile cliccarci sopra per effettuare una ricerca di tutti gli host con quell'etichetta:

Qui puoi cercare gli host con questa etichetta (utilizzando l'opzione predefinita is) o senza questa etichetta (utilizzando l'opzione is not).
Puoi anche utilizzare gli operatori booleani Not
, And
e Or
nella ricerca dell'etichetta, come descritto nella sezione Condizioni per le regole. Ad esempio, per trovare host Linux che si trovano a Monaco e che non sono server web, il filtro potrebbe avere questo aspetto:

Puoi affinare ulteriormente questo filtro, ad esempio per trovare anche host Windows "senza testa" (con or) e francesi (con and). Puoi inserire le tre nuove righe per questa estensione del filtro direttamente sotto quelle esistenti oppure puoi creare un nuovo gruppo con Add to query, che rende il filtro più complesso da leggere, ma non cambia la valutazione dell'algebra booleana:

![]() |
Se sei interessato a sapere quale sostituzione di parentesi genera Checkmk a partire dai filtri etichetta inseriti, puoi far visualizzare la query Livestatus associata. Per fare ciò, attiva Setup > General > Global settings > Debug Livestatus queries. |
Nella barra dei filtri puoi ovviamente combinare la ricerca delle etichette con gli altri parametri di ricerca disponibili.
5. Etichette di servizio
Anche i servizi possono avere delle etichette, simili a quelle dell'host, ma con alcune piccole differenze:
Non puoi definire esplicitamente le etichette di servizio, che possono essere create solo per mezzo di regole (Service labels) o automaticamente.
Puoi anche formulare delle condizioni con le etichette di servizio. In un set di regole, le etichette di servizio vengono inserite solo se la regola può corrispondere a un servizio.
6. Etichette agenti
Checkmk Cloud e Checkmk MSP includono l'opzione di creazione automatica degli host. A tal fine, l'intera catena di registrazione dell'agente, la creazione dell'host, la scoperta del servizio e l'attivazione delle modifiche viene automatizzata. La creazione dell'host avviene dopo la registrazione.
Questa automazione crea alcune sfide per la strutturazione degli host appena creati. Fino ad ora, il sistema operativo (memorizzato nell'etichetta dell'host cmk/os_family
) poteva essere determinato solo dall'output dell'agente. Tuttavia, per ottenere questo risultato, l'host deve essere già stato creato.
Per questo motivo è stato introdotto il concetto di etichetta agente volatile. Queste etichette vengono inviate durante la registrazione e sono quindi disponibili prima che venga creato il primo agente. Durante la registrazione, puoi utilizzare le etichette dell'agente per determinare se un host deve essere effettivamente creato nel monitoraggio e, in tal caso, per influenzare la cartella dell'host e altri attributi dell'host. Una volta completata la registrazione, non è più possibile accedere alle etichette dell'host.
Durante la registrazione vengono sempre trasferite due etichette agente predefinite:
cmk/os-family
contiene la famiglia del sistema operativo (attualmenteWindows
oLinux
).cmk/hostname-simple
contiene il nome del computer in un modulo abbreviato (cioè senza la parte del dominio).
Puoi assegnare liberamente etichette agente aggiuntive e personalizzate, ad esempio:organizational/department:documentation
.
Agli host registrati automaticamente viene assegnata l'etichetta dell'host cmk/agent_auto_registered:yes
. Non è supportata l'assegnazione diretta di etichette dell'host come risultato di etichette specifiche dell'agente. Tuttavia, hai l'alternativa di registrare gli host in una cartella (temporanea) e poi assegnare le etichette dell'host per tutti gli host in quella cartella.
7. Ulteriori informazioni
7.1. Etichette dell'host generate automaticamente
Tasto | Valori |
---|---|
|
|
|
|
|
Nome dell'account AWS a cui l'host appartiene |
|
Tag degli oggetti AWS |
|
Gruppo di risorse a cui appartiene l'oggetto Azure |
|
Tag degli oggetti Azure |
|
|
|
|
|
Nome del dispositivo SNMP trasmesso, ad es. |
|
Immagine Docker, es. |
|
Nome dell'immagine Docker, ad es. |
|
Versione dell'immagine Docker, ad es. |
|
|
|
Queste etichette vengono emesse per qualsiasi etichetta Kubernetes che sia un'annotazione Kubernetes valida (configurabile tramite la regola Kubernetes ). |
|
|
|
nome del cluster di Kubernetes |
|
nome dell'host del cluster Kubernetes |
|
Cronjob di Kubernetes |
|
Nome del DaemonSet |
|
Nome del deployment |
|
Nome del namespace Kubernetes associato. |
|
Nome del nodo Kubernetes associato. Gli host Checkmk di tipo Pod o Nodo ricevono questa etichetta. |
|
Tipo di oggetto Kubernetes, ad es. |
|
Nome dello StatefulSet |
|
|
|
Tipo di dispositivo Meraki, ad es. |
|
ID della rete a cui appartiene il dispositivo Meraki |
|
ID organizzazione a cui appartiene il dispositivo Meraki |
|
Nome dell'organizzazione a cui appartiene il dispositivo Meraki |
|
|
|
Sistema operativo, riportato dall'agente come |
|
Tipo di sistema operativo, riportato dall'agente come |
|
Nome del sistema operativo, riportato dall'agente come |
|
Piattaforma del sistema operativo, riportata dall'agente come |
|
Versione del sistema operativo, riportata dall'agente come |
|
|
|
|