6 Etichettatura

Panoramica

I tag sono costituiti da un nome del tag e da un valore del tag. Quando si assegnano tag alle entità, è possibile usare solo il nome oppure abbinarlo a un valore (ad esempio, mysql, jira, target:mysql, service:jira, ecc.).

I tag possono essere definiti per varie entità:

  • Template
  • Host
  • Item
  • Scenari web
  • Trigger
  • Servizi
  • Item e trigger di template
  • Prototipi di host, item e trigger

Negli elenchi Templates, Hosts, Items, Triggers, Web scenarios e nei relativi prototipi, la colonna Tags mostra sia i tag normali sia quelli ereditati. Passando il puntatore sopra un tag ereditato o facendovi clic, viene visualizzato un tooltip JavaScript con il testo "Inherited tag". Se un tag ereditato esiste anche come tag normale, viene mostrato un testo del tooltip diverso a seconda dell'elenco in cui appare (ad esempio, "Inherited and template tag" nell'elenco templates oppure "Inherited and host tag" nell'elenco hosts). Negli altri punti del frontend i tag normali ed ereditati vengono visualizzati insieme (i duplicati vengono rimossi), senza icone e senza testo aggiuntivo nel tooltip.

Fare riferimento alle linee guida ufficiali di Zabbix per le raccomandazioni generali sulla definizione dei tag, insieme alle indicazioni specifiche per templates, items, triggers e regole di low-level discovery.

I tag hanno molteplici scopi, in particolare quello di contrassegnare gli eventi. Quando alle entità vengono assegnati tag, qualsiasi nuovo evento correlato a un'entità con tag ne erediterà i tag. Ad esempio:

  • con template con tag, qualsiasi problema del host (creato dai trigger del template) erediterà i tag del template.
  • con host con tag, qualsiasi problema del host erediterà i tag del host.
  • con item/scenari web con tag, qualsiasi problema di item/scenario web erediterà i tag dell'item/dello scenario web.
  • con trigger con tag, qualsiasi problema creato dal trigger erediterà i tag del trigger.

Un evento di problema eredita tutti i tag dall'intera catena di entità: template, host, item/scenari web, trigger. Le combinazioni tag:value identiche (dopo la risoluzione delle macro) vengono unite in una sola, evitando così duplicazioni.

Gli eventi di ripristino generati da una chiusura manuale includono anch'essi i tag evento risolti ereditati da template, host, item/scenari web e trigger. Questi tag sono disponibili nelle notifiche e tramite macro come {EVENT.RECOVERY.TAGS} e {EVENT.RECOVERY.TAGSJSON}.

I tag evento personalizzati offrono maggiore flessibilità. Ad esempio:

  • la correlazione degli eventi può essere configurata in base ai tag evento.
  • le condizioni delle azioni possono essere configurate in base ai tag evento.
  • i problemi degli item possono essere raggruppati in base ai tag evento.
  • i tag dei problemi possono essere usati per mappare i problemi ai servizi.

Alle entità possono essere assegnati tag con lo stesso nome ma con valori diversi (ad esempio, component:memory e component:storage). Allo stesso modo, un'entità può avere un tag senza valore e lo stesso tag con un valore (ad esempio, database e database:postgresql). Tali tag non sono considerati duplicati.

Casi d'uso

Alcuni casi d'uso comuni per l'uso dei tag sono i seguenti:

  1. Contrassegnare gli eventi dei trigger:

    • Definire un tag del trigger (ad esempio, scope:performance).
    • I problemi creati da questo trigger avranno il tag del trigger.

  2. Contrassegnare i problemi ereditati dal template:

    • Definire un tag del template (ad esempio, target:mysql).
    • I problemi creati dai trigger di questo template avranno il tag del template.

  3. Contrassegnare i problemi del host:

    • Definire un tag del host (ad esempio, service:jira).
    • I problemi creati dai trigger di questo host avranno il tag del host.

  4. Filtrare gli item correlati:

    • Definire un tag dell'item (ad esempio, component:cpu).
    • In Monitoring > Latest data, gli item possono essere filtrati tramite il tag component:cpu.

  5. Utilizzare le informazioni estratte dal valore dell'item come valore del tag:

    • Definire un tag con una macro come valore del tag (ad esempio, tag-name:{{ITEM.VALUE<N>}.regsub()} ).
    • In Monitoring > Problems, i problemi avranno il valore del tag risolto nei dati estratti dal valore dell'item.

  6. Identificare i problemi in un file di log e chiuderli separatamente:

    • Definire un tag del trigger per il trigger dell'item di monitoraggio log che estrarrà valori dal valore dell'item usando una macro (ad esempio, service:{{ITEM.VALUE<N>}.regsub()} ).
    • Nella configurazione del trigger, configurare la correlazione degli eventi:
      • impostare PROBLEM event generation mode su "Multiple";
      • impostare OK event closes su "All problems if tag values match";
      • impostare il tag per la corrispondenza.
    • I problemi creati dal trigger dell'item log avranno il tag del trigger e verranno chiusi singolarmente.

  7. Filtrare le notifiche:

    • Definire tag dei trigger (ad esempio, scope:security per trigger1 e scope:availability per trigger2).
    • Utilizzare il filtraggio per tag nelle condizioni dell'azione per ricevere notifiche solo sugli eventi che corrispondono ai dati dei tag.

  8. Identificare i problemi nelle notifiche:

    • Definire tag dei trigger.
    • Utilizzare la macro {EVENT.TAGS} nella notifica del problema.
    • La notifica del problema conterrà i tag del trigger, rendendo più semplice identificare a quale applicazione/servizio appartiene la notifica.

  9. Semplificare le attività di configurazione utilizzando i tag del template:

    • Definire un tag del trigger del template.
    • I trigger creati da questo trigger del template avranno il suo tag.

  10. Creare trigger con tag dal low-level discovery (LLD):

    • Definire un tag del prototipo di trigger con una macro LLD nel nome o nel valore del tag (ad esempio, scope:{#FSNAME}).
    • I trigger creati dal prototipo di trigger avranno il suo tag.

  11. Associare i servizi usando i tag di servizio:

    • Definire i tag di servizio.
    • Configurare le azioni di servizio per i servizi con tag corrispondenti.
    • Inoltre, utilizzare i tag di servizio per collegare un servizio a un SLA per i calcoli SLA.

  12. Collegare i servizi ai problemi usando i tag problema del servizio:

    • Definire un tag problema nella configurazione del servizio (ad esempio, target:mysql).
    • I problemi con un tag corrispondente saranno automaticamente correlati al servizio e lo stato del servizio cambierà in base alle regole configurate per il calcolo dello stato del servizio.

  13. Sopprimere i problemi quando un host è in modalità di manutenzione:

  14. Concedere l'accesso ai gruppi utenti:

Configurazione

I tag possono essere definiti in una scheda dedicata, ad esempio nella configurazione del trigger:

Supporto macro

Le macro integrate e le macro utente nei tag vengono risolte al momento dell'evento. Fino a quando l'evento non si è verificato, queste macro saranno mostrate nel frontend di Zabbix come non risolte.

Le macro di low-level discovery vengono risolte durante il processo di discovery.

Le seguenti macro possono essere utilizzate nei nomi e nei valori dei tag dei trigger:

  • macro integrate {ITEM.VALUE}, {ITEM.VALUE.AGE}, {ITEM.VALUE.DATE}, {ITEM.VALUE.TIME}, {ITEM.VALUE.TIMESTAMP}, {ITEM.LASTVALUE}, {ITEM.LASTVALUE.AGE}, {ITEM.LASTVALUE.DATE}, {ITEM.LASTVALUE.TIME}, {ITEM.LASTVALUE.TIMESTAMP}, {HOST.HOST}, {HOST.NAME}, {HOST.CONN}, {HOST.DNS}, {HOST.IP}, {HOST.PORT} e {HOST.ID}
  • macro integrate {INVENTORY.*} (per fare riferimento ai valori dell'inventario host da uno o più host in un'espressione trigger)
  • macro utente e macro utente con contesto (il contesto può includere macro di low-level discovery)
  • macro di low-level discovery (solo nei tag dei prototipi di trigger)

Le seguenti macro possono essere utilizzate nei nomi e nei valori dei tag di template, host e item/scenari web:

  • macro integrate {HOST.HOST}, {HOST.NAME}, {HOST.CONN}, {HOST.DNS}, {HOST.IP}, {HOST.PORT} e {HOST.ID}
  • macro integrate {INVENTORY.*}
  • macro utente
  • macro di low-level discovery (solo nei tag dei prototipi di host e item)

Le seguenti macro possono essere utilizzate nelle notifiche basate su trigger:

  • macro integrate {EVENT.TAGS} e {EVENT.RECOVERY.TAGS} (queste macro verranno risolte in un elenco di tag evento o tag evento di ripristino separati da virgole)
  • macro integrate {EVENT.TAGSJSON} e {EVENT.RECOVERY.TAGSJSON} (queste macro verranno risolte in un array JSON contenente oggetti tag evento o oggetti tag evento di ripristino)
Estrazione di sottostringhe nei tag dei trigger

L'estrazione di sottostringhe è supportata per popolare il nome o il valore del tag, utilizzando una funzione di macro. La funzione applica un'espressione regolare al valore ottenuto dalla macro supportata. Per esempio:

{{ITEM.VALUE}.regsub(pattern, output)}
{{ITEM.VALUE}.iregsub(pattern, output)}

{{#LLDMACRO}.regsub(pattern, output)}
{{#LLDMACRO}.iregsub(pattern, output)}

Se il nome o il valore del tag supera i 255 caratteri dopo la risoluzione della macro, verrà troncato a 255 caratteri.

Vedi anche: utilizzo delle funzioni macro nelle macro di low-level discovery per il tagging degli eventi.

Visualizzazione dei tag evento

I tag, se definiti, possono essere visualizzati con i nuovi eventi in:

L'ordine e il numero dei tag visualizzati sono determinati dalle opzioni di filtro Tag display priority e Show tags in Monitoring > Problems o nel widget dashboard Problems. Si noti che è possibile visualizzare un massimo di tre tag; se sono presenti più tag, passando il cursore sui tre puntini vengono mostrati tutti i tag in una finestra pop-up.