Tagging

Tags haben mehrere Zwecke, insbesondere zum Markieren von events. Wenn Entitäten mit Tags versehen werden, erbt jedes neue Ereignis, das mit einer getaggten Entität zusammenhängt, deren Tags. Zum Beispiel:

  • bei getaggten Vorlagen - jedes Host-Problem (das von Auslösern aus der Vorlage erstellt wird) erbt die Vorlagen-Tags.
  • bei getaggten Hosts - jedes Host-Problem erbt die Host-Tags.
  • bei getaggten Datenpunkten/Web-Szenarien - jedes Problem eines Datenpunkts/Web-Szenarios erbt die Tags des Datenpunkts/Web-Szenarios.
  • bei getaggten Auslösern - jedes vom Auslöser erstellte Problem erbt die Auslöser-Tags.

Ein Problemereignis erbt alle Tags aus der gesamten Kette von Entitäten - Vorlagen, Hosts, Datenpunkten/Web-Szenarien, Auslösern. Identische tag:value-Kombinationen (nach Auflösung der Makros) werden zu einer zusammengeführt, wodurch Duplikate vermieden werden.

Wiederherstellungsereignisse, die durch ein manuelles Schließen erzeugt werden, enthalten ebenfalls die aufgelösten Ereignis-Tags, die von Vorlagen, Hosts, Datenpunkten/Web-Szenarien und Auslösern geerbt wurden. Diese Tags sind in Benachrichtigungen und über Makros wie {EVENT.RECOVERY.TAGS} und {EVENT.RECOVERY.TAGSJSON} verfügbar.

Benutzerdefinierte Ereignis-Tags bieten mehr Flexibilität. Zum Beispiel:

  • Ereigniskorrelation kann auf Basis von Ereignis-Tags konfiguriert werden.
  • Aktionsbedingungen können auf Basis von Ereignis-Tags konfiguriert werden.
  • Probleme von Datenpunkten können auf Basis von Ereignis-Tags gruppiert werden.
  • Problem-Tags können verwendet werden, um Probleme services zuzuordnen.

Entitäten können mit demselben Tag-Namen, aber unterschiedlichen Tag-Werten versehen werden (zum Beispiel component:memory und component:storage). Ebenso kann eine Entität einen Tag ohne Wert und denselben Tag mit einem Wert haben (zum Beispiel database und database:postgresql). Solche Tags gelten nicht als Duplikate.

Tags bestehen aus einem Tag-Namen und einem Tag-Wert. Beim Taggen von Entitäten können Sie nur den Namen verwenden oder ihn mit einem Wert kombinieren (zum Beispiel mysql, jira, target:mysql, service:jira usw.).

Tags können für verschiedene Entitäten definiert werden:

  • Vorlagen
  • Hosts
  • Datenpunkte
  • Web-Szenarien
  • Auslöser
  • Services
  • Vorlagen-Datenpunkte und -Auslöser
  • Host-, Datenpunkt- und Auslöser-Prototypen

In den Listen Vorlagen, Hosts, Datenpunkte, Auslöser, Web-Szenarien und ihren Prototypen zeigt die Spalte Tags sowohl reguläre als auch geerbte Tags an. Wenn Sie mit der Maus über einen geerbten Tag fahren oder darauf klicken, erscheint ein JavaScript-Tooltip mit dem Text "Inherited tag". Wenn ein geerbter Tag auch als regulärer Tag vorhanden ist, wird je nach Liste, in der er angezeigt wird, ein anderer Tooltip-Text angezeigt (zum Beispiel "Inherited and template tag" in der Liste Vorlagen oder "Inherited and host tag" in der Liste Hosts). An anderen Stellen des Frontends werden reguläre und geerbte Tags zusammen angezeigt (Duplikate werden entfernt), ohne Symbole und ohne zusätzlichen Tooltip-Text.

Beachten Sie die offiziellen Zabbix-Richtlinien für allgemeine Empfehlungen zur Definition von Tags sowie die spezifischen Hinweise für Vorlagen, Datenpunkte, Auslöser und Low-Level-Discovery-Regeln.

Anwendungsfälle

Einige häufige Anwendungsfälle für Tagging sind wie folgt:

  1. Trigger-Ereignisse markieren:

    • Definieren Sie einen Trigger-Tag (zum Beispiel scope:performance).
    • Von diesem Trigger erzeugte Probleme erhalten den Trigger-Tag.

  2. Von Vorlagen geerbte Probleme markieren:

    • Definieren Sie einen Vorlage-Tag (zum Beispiel target:mysql).
    • Von Triggern aus dieser Vorlage erzeugte Probleme erhalten den Vorlage-Tag.

  3. Host-Probleme markieren:

    • Definieren Sie einen Host-Tag (zum Beispiel service:jira).
    • Von Triggern dieses Hosts erzeugte Probleme erhalten den Host-Tag.

  4. Zugehörige Datenpunkte filtern:

    • Definieren Sie einen Datenpunkt-Tag (zum Beispiel component:cpu).
    • In Monitoring > Latest data können Datenpunkte nach dem Tag component:cpu gefiltert werden.

  5. Aus dem Datenpunktwert extrahierte Informationen als Tag-Wert verwenden:

    • Definieren Sie einen Tag mit einem Makro als Tag-Wert (zum Beispiel tag-name:{{ITEM.VALUE<N>}.regsub()} ).
    • In Monitoring > Problems enthalten Probleme den Tag-Wert, der in die aus dem Datenpunktwert extrahierten Daten aufgelöst wird.

  6. Probleme in einer Protokolldatei identifizieren und separat schließen:

    • Definieren Sie einen Trigger-Tag für den Trigger des Log-Monitoring-Datenpunkts, der Werte aus dem Datenpunktwert mithilfe eines Makros extrahiert (zum Beispiel service:{{ITEM.VALUE<N>}.regsub()} ).
    • Richten Sie in der Trigger-Konfiguration Ereigniskorrelation ein:
      • setzen Sie den PROBLEM event generation mode auf "Multiple";
      • setzen Sie OK event closes auf "All problems if tag values match";
      • setzen Sie den Tag für die Übereinstimmung.
    • Von dem Log-Monitoring-Datenpunkt-Trigger erzeugte Probleme erhalten den Trigger-Tag und werden einzeln geschlossen.

  7. Benachrichtigungen filtern:

    • Definieren Sie Trigger-Tags (zum Beispiel scope:security für trigger1 und scope:availability für trigger2).
    • Verwenden Sie Tag-Filter in Aktion-Bedingungen, um Benachrichtigungen nur für die Ereignisse zu erhalten, die den Tag-Daten entsprechen.

  8. Probleme in Benachrichtigungen identifizieren:

    • Definieren Sie Trigger-Tags.
    • Verwenden Sie das Makro {EVENT.TAGS} in der Problembenachrichtigung.
    • Die Problembenachrichtigung enthält die Trigger-Tags, wodurch leichter erkennbar ist, zu welcher Anwendung bzw. welchem Dienst die Benachrichtigung gehört.

  9. Konfigurationsaufgaben durch Verwendung von Vorlage-Tags vereinfachen:

    • Definieren Sie einen Vorlage-Trigger-Tag.
    • Trigger, die aus diesem Vorlage-Trigger erstellt werden, erhalten dessen Tag.

  10. Trigger mit Tags aus Low-Level-Discovery (LLD) erstellen:

    • Definieren Sie einen Trigger-Prototyp-Tag mit einem LLD-Makro im Tag-Namen oder -Wert (zum Beispiel scope:{#FSNAME}).
    • Trigger, die aus dem Trigger-Prototyp erstellt werden, erhalten dessen Tag.

  11. Dienste mithilfe von Service-Tags zuordnen:

    • Definieren Sie Service-Tags.
    • Konfigurieren Sie Service-Aktionen für Dienste mit übereinstimmenden Tags.
    • Verwenden Sie außerdem Service-Tags, um einen Dienst für SLA-Berechnungen mit einer SLA zu verknüpfen.

  12. Dienste mithilfe von Service-Problem-Tags mit Problemen verknüpfen:

    • Definieren Sie einen Problem-Tag in der Service-Konfiguration (zum Beispiel target:mysql).
    • Probleme mit einem übereinstimmenden Tag werden automatisch dem Dienst zugeordnet, und der Dienststatus ändert sich basierend auf den konfigurierten Regeln zur Berechnung des Dienststatus.

  13. Probleme unterdrücken, wenn sich ein Host im Wartungsmodus befindet:

  14. Zugriff für Benutzergruppen gewähren:

Konfiguration

Tags können in einem eigenen Tab definiert werden, zum Beispiel in der Auslöserkonfiguration:

Makrounterstützung

Integrierte Makros und Benutzermakros in Tags werden zum Zeitpunkt des Ereignisses aufgelöst. Bis das Ereignis eingetreten ist, werden diese Makros im Zabbix Frontend als nicht aufgelöst angezeigt.

Makros der Low-Level-Discovery werden während des Discovery-Prozesses aufgelöst.

Die folgenden Makros können in Trigger-Tag-Namen und -Werten verwendet werden:

  • {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} und {HOST.ID} integrierte Makros
  • {INVENTORY.*} integrierte Makros (zum Verweisen auf Host-Inventarwerte von einem oder mehreren Hosts in einem Trigger-Ausdruck)
  • Benutzermakros und Benutzermakros mit Kontext (der Kontext kann Makros der Low-Level-Discovery enthalten)
  • Makros der Low-Level-Discovery (nur in Trigger-Vorlagen-Tags)

Die folgenden Makros können in Tag-Namen und -Werten von Vorlage, Host und Datenpunkt/Web-Szenario verwendet werden:

  • {HOST.HOST}, {HOST.NAME}, {HOST.CONN}, {HOST.DNS}, {HOST.IP}, {HOST.PORT} und {HOST.ID} integrierte Makros
  • {INVENTORY.*} integrierte Makros
  • Benutzermakros
  • Makros der Low-Level-Discovery (nur in Host- und Datenpunkt-Vorlagen-Tags)

Die folgenden Makros können in triggerbasierten Benachrichtigungen verwendet werden:

  • {EVENT.TAGS} und {EVENT.RECOVERY.TAGS} integrierte Makros (diese Makros werden in eine durch Kommas getrennte Liste von Ereignis-Tags oder Wiederherstellungs-Ereignis-Tags aufgelöst)
  • {EVENT.TAGSJSON} und {EVENT.RECOVERY.TAGSJSON} integrierte Makros (diese Makros werden in ein JSON-Array aufgelöst, das Ereignis-Tag-Objekte oder Wiederherstellungs-Ereignis-Tag-Objekte enthält)
Teilzeichenfolgenextraktion in Auslöser-Tags

Die Extraktion von Teilzeichenfolgen wird unterstützt, um den Tag-Namen oder den Tag-Wert mithilfe einer Makro-Funktion zu füllen. Die Funktion wendet einen regulären Ausdruck auf den Wert an, der vom unterstützten Makro zurückgegeben wird. Zum Beispiel:

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

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

Wenn der Tag-Name oder -Wert nach der Makroauflösung mehr als 255 Zeichen umfasst, wird er auf 255 Zeichen gekürzt.

Siehe auch: Verwendung von Makro-Funktionen in Low-Level-Discovery-Makros für das Event-Tagging.

Anzeigen von Ereignis-Tags

Tags, sofern definiert, können bei neuen Ereignissen angezeigt werden in:

Die Reihenfolge und Anzahl der angezeigten Tags wird durch die Filteroptionen Tag-Anzeigepriorität und Tags anzeigen in Monitoring > Probleme oder im Probleme-Dashboard-Widget bestimmt. Beachten Sie, dass maximal drei Tags angezeigt werden können; wenn es mehr Tags gibt, werden beim Überfahren der drei Punkte alle Tags in einem Popup-Fenster angezeigt.