Kibana Rules

Übersicht

Unter Stack Management > Alerts and Insights > Rules and Connectors werden die momentan aktiven Rules und ihr Zustand angezeigt.

kibana rules overview

Anlegen einer neuen Rule

Name und grundlegende Eigenschaften

Bei der Definition des Names muss darauf geachtet werden, dass dieser mit ct- beginnt, sonst ist eine Ansicht in service.monitor Monitoring und dortige Verknüpfung mit den Benachrichtigungsvorlagen nicht möglich. Je mehr Rules angelegt werden, desto besser und eindeutiger sollte die Benamung ausfallen. Ebenso können Tags vergeben werden, die bei der späteren Suche nach Rules behilflich sind.

Check every

Ausführungshäufigkeit der in der Rule definierten Abfrage

Standardwert: 1 minute

Notify

Definition, wie häufig die Aktion (siehe unten) wiederholt werden soll, wenn die Rule aktiv ist.

Standardwert: Only on status change

create rule name

Typen von Abfragen

Es gibt viele unterschiedliche Abfragen, die auf die verschiedenen Bereiche von Elasticsearch & Kibana abzielen. In unseren Beispielen entscheiden wir uns für die "Elasticsearch query".

create rule types

Elasticsearch Abfrage & Matches

Um die Abfrage zu definieren, muss ein Index oder Alias ausgewählt werden. In dem vorliegenden Beispiel geht es um den Index ct-fme-log, der als Events die Log-Zeilen von Safe FME Flow enthält.

create rule query

Die konkrete Abfrage, die turnusmäßig ausgeführt werden soll, darf frei definiert werden. Die beispielhafte Query fragt nach allen Events, die im Kontext von FME Flow durch Apache Tomcat auf dem Produktions-Server mit einem Syslog-Level von ⇐ 3 vorhanden sind.

Die service.monitor Pipelines übersetzen alle textuellen Log-Level in den Syslog-Standard. Es ist auch möglich, eine Abfrage zu erzeugen, die z.B. [log][level]:"WARNING" abfragt.
Sample elasticquery on ct-fme-log-data
{
  "query": {
    "bool": {
      "must": [
        {"match": {"log.fme.source": "tomcat" }},
        {"match": {"log.fme.file": "catalina" }},
        {"match": {"base.labels.env": "production" }},
        {"range": {"log.syslog.severity.code": {"lte": 3}}}
      ]
    }
  }
}

Abschließend muss definiert werden, wann die Rule "aktiv" werden soll. Da das Vorkommen von Log-Nachrichten mit einem kritischen Level als Auslöser betrachtet werden soll, wird im nächsten Schritt der Wert 0 als Schwellwert für die Aktivierung definiert.

create rule matches

Action (optional)

Actions sind für die Einrichtung der Benachrichtigungsfunktion in service.monitor nicht verpflichtend. In dem unten stehenden Beispiel wurde eine Action definiert, die bei Aktivierung der Rule einen Eintrag in einen Index schreibt, der für die langfristige Speicherung von Ausnahmefällen vorgesehen ist.

create rule action
Inhalt eines Events, der in einem speziellen Index erzeugt wird, um die Ausnahmesituation zu protokollieren
{
  "rule_id": "{{rule.id}}",
  "rule_name": "{{rule.name}}",
  "alert_id": "{{alert.id}}",
  "context_message": "{{context.message}}"
}

Beispiele für Rules

  • Benachrichtige mich, wenn es mehr als n fehlgeschlagene Logins bei Portal for ArcGIS gab

  • Benachrichtige mich, wenn der Plattenplatz für Indizes zu klein wird

  • Benachrichtige mich, wenn ArcGIS Server viele Fehlermeldungen loggt

  • Benachrichtige mich, wenn con terra Produkte keine Log-Daten mehr senden

Queries für diese Beispiele werden hier in Zukunft abrufbar sein.