Comparaison des versions

Ancienne version 42

changes.mady.by.user Sophie Lepissier

Sauvegardée le

comparé à

Nouvelle version Actuel

changes.mady.by.user Sophie Lepissier

Sauvegardée le

Légende

  • Ces lignes ont été ajoutées. Ce mot a été ajouté.
  • Ces lignes ont été supprimées. Ce mot a été supprimé.
  • La mise en forme a été modifiée.

...

Sv translation
languageen
Remarque

This page is no longer being updated. From BlueMind 4.8, please refer to the new BlueMind documentation

Data explorer

The DataExplorer tab is used to browse the database contents, i.e. the metrics collected.

Info

Please refer to our documentation's page on references for collected metrics to find out more about the metrics collected and their contents.

You can write or generate a query by:

  • writing in the box at the top of the window
  • selecting the relevant indicators using the data browser:
    • DB.RetentionPolicy: the databases you want to analyze. The most relevant is telegraf.autogen which contains the actual data. The other databases (_internal.monitor and chronograf.autogen) contain internal system data.
    • Measurements & Tags: the metrics being looked for
    • Fields: the field(s) required for this data

The graph with the query results is shown at the bottom of the window. Refresh rates and interval settings are shown and can be edited at the top of the page, as well as in the dashboards:


Volet

On this page:

Sommaire
maxLevel3

Related:
Reference des metriques

To look for and analyze a metric:

  1. Select the database telegraf.autogen in the first column
  2. In the search box in the second column ("Measurements & tags"), enter the name of the item you want to analyze – e.g. a BlueMind component – to view what metrics are available for it:
  3. Select a metric by clicking it – e.g. "bm-ysnp-authCount" in this instance

  4. You can navigate within each metric so specify the data you are looking for:

    • datalocation: server name
    • host: host name or IP 
    • meterType: data type, this field is particularly important as it specifies the kind of information contained in this metric 
      • gauge: instant measurement
      • counter: incremental counter
      • distsum: counter-amount data pair
        e.g.:
        • bm-lmtpd.emailSize = (number of emails, total size of emails)
        • bm-lmtpd.emailRecipients = (number of emails, number of recipients)
      • timer: same as distsum but here the amount is always expressed in nanoseconds
    • status: depending on the type of data, the status may be ok/failed (e.g. query successful/failed), success/failure (e.g. authentication successful/failed), etc.
    Astuce

    We recommend that you group data by server by clicking the "Group by host" button which appears when you hover on the "host" line or by opening the submenu:

    This will show host-specific data rather than a server average.

    Depending on the metric being looked at, it may also be relevant to group by status, code or datalocation.

  5. Select the field in the third column according to the data you're looking for. The corresponding graph is then shown:

Useful features/advanced queries

Changing the time interval displayed

This part of the query sets the time interval displayed:

Bloc de code
WHERE time > now() - 7d

This literally translates as: the data whose time is greater than today minus 7 days, i.e. the data from the past 7 days.

change the number of days/hours as desired to increase or decrease the graph's timeframe. 

Evolution of a counter

Counter data is cumulative and therefore increases regularly. This means that its evolution is more relevant than the data itself.

For example, the bm-ysnp.authCount data counts the number of authentications processed: viewing the raw data will only give you, at a given point in time, the amount of data processed since the data collection was set up, which isn't interesting in itself. This figure's evolution over time, however, will give you the number of authentications processed as time passes.

non_negative_difference

To watch how this data evolves, you can use the "non_negative_difference" function which returns the non-negative difference between 2 points in the graph.

To use the authentication example again, the graph below, with no function applied, shows the mean number of authentications processed by the ysnp component in the last 24 hours, by server and by status:

the mean value keeps going up as additional authentications are being processed.

With an interval difference function, the graph returns the number of authentications for each time interval, you can now see how the amount of authentications processed evolves:

A sudden spike of "failed" in the timeline could be the sign of an attack by spammers attempting to use the server to send emails.

non_negative_derivative

Another function returns an evolution graph for field values with un additional setting: non_negative_derivative.

This function also calculates the difference between 2 points, but in addition, it specifies the unit argument.
In the non_negative_difference function, the system calculates an automatic interval based on the duration displayed ("where time...") and the data's grouping ("group by time..."). With the non_negative_derivative function, you can force-set the unit, e.g. a rate per minute, hour, day, etc.

E.g., the query below shows the mean number of connections (mean("count")) per minute (non_negative_derivative(...,1m)) in the last 24h (where time > now() - 1d) for every hour (group by time(1h)):

at 14:00 hours, there was a mean of 1.03 connections per minute, at 15:00 there was 0.5/mn, etc.

Ancre
distsum
distsum
distsum

distsum metrics comprise 2 types of information:

  1. the first digit is a count
  2. the second digit is an amount

As a result it may be a pair such as:

  • bm-lmtpd.emailSize = (number of email, total size of emails)
  • bm-lmtpd.emailRecipients = (number of emails, number of recipients)

Take the emailSize metric, for example: with each save, the system records the number of emails counted for the interval (since the last save) and the total size the emails account for.

This data can be used to calculate an average message size and see whether it evolves abnormally or suddenly.

E.g. you may observe a regular increase in average message size over time, which may be down to better connections, servers or user habits etc. but if over a few days average message size suddenly doubles (or more), there's something wrong and you need to find out what: was a corporate signature added? Does it contain an image whose size hasn't been reduced, which increases the size of messages and as a result server load.

To find out more about InfluxQL queries, please refer to the documentation:

https://docs.influxdata.com/influxdb/v1.6/query_language/

In particular, about fonctions: https://docs.influxdata.com/influxdb/v1.6/query_language/functions/

And grouping by time: https://docs.influxdata.com/influxdb/v1.6/query_language/data_exploration/#advanced-group-by-time-syntax

Doing more with graphs

The DataExplorer graphical tool has limited options. For example, you can't create a stacked chart to view the sum of two line graphs.

To do this, you need to use the Dashboard's graphs (see next section):

Dashboards

The Dashboards tab is used to access to a series of pages where you can group data as desired.

By default, 3 tableaux are preconfigured and shown as examples:

  • JVMs Memory Usage: usage information for each BlueMind component (EAS, Core, milter, ElasticSearch, HPS, etc.) which can help you monitor over-consumption or the absence of data showing that a service has stopped. 
  • Mail insights: number of emails delivered, average message size, number of IMAP processes, etc.
  • Monitoring system status: amount of data collected, database size, etc.
Remarque
titleAutomatic dashboard resetting

BlueMind's default dashboards are reset with every update.

This means that they will be created again if they were deleted and returned to default contents if those have been changed. If you want to customize one of these 3 dashboards, you should clone it (see below) and edit the clone or simply rename the dashboard.

You can add as many dashboards as you like, that way you can have customized views of the data you're interested in by grouping it by type, relevance, module, etc.

Astuce

Dashboards can be duplicated or deleted straight from the main list. When you hover your mouse on a dashboard's row, action buttons pop up at the end of the row:

To create a new dashboard, go to the Dashboard homepage and click "Create dashboard":


The dashboard is created immediately, and an empty view of it opens:

Click "Name this dashboard" to edit the box and enter a name for the dashboard:

To add a graph in the existing area, click

The query editor opens. You can create a query either by typing a command or using the database browser. A view of the graph is shown in real time:

This editor is similar to the DataExplorer's. Please refer to the previous section for metrics search and query building.

The "Visualization" button is used to choose a graphic type and customize it:

Once your graphic has been created, click "Save" in the top right corner of the editor. The graph is saved and added to the area:

Click to add as many graph areas as you like:

In the top right corner of each cell, three buttons are used to:

  • : edit, add comments or download csv data
  • : clone the graph. A new area containing the same graph is added at the end of the dashboard
  • : delete the graph

Clicking the icon opens a menu of possible actions.

Astuce

Graphs can be reorganized by clicking the title area and dragging and dropping them as desired:

Info

There is no "save" button: all changes are saved as they are made.

Alerts

The Alerting tab is used to manage alerts as well as alert history.

Alerts can be shown as scripts or as alert rules.

By default, there are no alert rules on installation, there are however, a number of pre-set scripts which you can modify. You can also add as many scripts as you like.

Avertissement

BlueMind pre-set alerts are important server health alerts, you must pay close attention to them if they are triggered.

Alert rules

  • To create an alert, click
  • To edit an alert, click its name in the list.

Fill in (or edit) the form:

  • Name this alert rule: alert name
  • Alert type: described below
    • Threshold: an alert will be triggered when the data reaches, exceeds or falls below the set value
    • Relative: relative to its own history – an alert will be triggered when value changes exceed set conditions
    • Deadman: an alert will be triggered when no data is detected within the set period
  • Time series: use the navigator to find the relevant series 
    • DB.RetentionPolicy: the databases you want to analyze. The most relevant is telegraf.autogen which contains the actual data. The other databases (_internal.monitor and chronograf.autogen) contain internal system data.
    • Measurements & Tags: the metric being searched for, a box at the top of the column can be used to filter your search by name
    • Fields: the field(s) required for this data
  • Conditions: once you have selected the field, set the conditions according to the type of alert chosen earlier.
    When you type a value, a real-time display of the data collected is shown which can help you set or adjust the value.
    For example in the form below:

    • You want to set up an alert for when the number of connections is more than 2.
    • The graph shows the number of connections over the previous month (green line).
    • The green area at the top highlights the area for which the alert would have been triggered.
    • You can see that your values have always been below, it would be abnormal for them to exceed this value, therefore this threshold seems to be relevant. 
    This can help you set the right value in light of the data's history: above typical values, possible spikes, etc.
    In this other example, an alert will be triggered when there are memory usage spikes every day:
  • Alert handlers: 
    Add alert recipients using the drop down list:
    • post: sends a "post" http alert to the url provided
    • tcp: sends a request via tcp to the address indicated
    • exec: command line to run on the server
    • log: write a message to the indicated log file
    • ...
    In this example, the alert sends an http request, runs a command on the server and writes a message to the dedicated log file:
  • Message: the message to write or send via the handler(s) specified above

Scripts

Scripts are used for advanced alert management. Each alert created as a rule also exists as a script and can be edited using that method.

  • To create a script, click
  • To edit a script, click its name in the list.

For more information on writing scripts, please refer to the product's documentation:

https://docs.influxdata.com/kapacitor/v1.5/tick/

https://www.influxdata.com/blog/tick-script-templates/

Alert history

The Alerting > Alert history sub-menu is used to access the history of alerts triggered:

The history shows the name, level, host and value of the data when the alert was triggered.

Click the host's name to open its dashboard. 

Other tabs

Hosts

The Host List tab shows the list of monitored host servers, with the apps they include:


Clicking a server or an app opens its specific dashboard.

Sv translation
languagede
Remarque

Diese Seite ist nicht mehr aktuell. Ab der Version BlueMind 4.8 finden Sie alle Infos in der neuen Dokumentation

Der Datenexplorer

Unter der Registerkarte DataExplorer können Datenbankdaten, d.h. die Historie der gesammelten Metriken, durchsucht werden.

Info

Im Anhang unserer Dokumentation finden Sie die Referenz der gesammelten Metriken, um mehr über die gesammelten Metriken und deren Inhalt zu erfahren.

Der obere Teil des Fensters dient zum Schreiben oder Erzeugen der Abfrage:

  • entweder durch direktes Schreiben in das dafür vorgesehene Feld;
  • oder durch Auswahl der gewünschten Indikatoren über den Datenbrowser:
    • DB.RetentionPolicy: die Datenbank, die abgefragt werden soll. In diesem Fall interessiert uns hauptsächlich die Datenbank telegraf.autogen, die die betreffenden Daten enthält; die anderen sind Systemdatenbanken, die interne Betriebsdaten enthalten.
    • Measurements & Tags: die gesuchte Metrik
    • fields: das Feld oder die Felder, das/die für diese Daten gewünscht wird/werden.

Die Anzeige im unteren Teil des Fensters zeigt Ihnen die der Abfrage entsprechende Grafik an. Sie unterliegt den Aktualisierungs- und Zeitraumregeln, wie sie oben auf der Seite sowie in den Dashboards definiert sind:

Volet

Auf dieser Seite:

Sommaire
maxLevel3

Verwandt:
Reference des metriques

Eine Metrik suchen und analysieren:

  1. wählen Sie in der 1. Spalte die Datenbank telegraf.autogen
  2. geben Sie in das Suchfeld der zweiten Spalte "Measurements & tags", z.B. den Namen der BlueMind-Komponente ein, um zu sehen, welche Metriken für sie verfügbar sind:
  3. Wählen Sie eine Metrik aus, indem Sie auf ihren Namen klicken - in diesem Beispiel "bm-ysnp-authCount"

  4. Navigieren Sie durch den Teilbaum der Metrik, um die gewünschten Daten zu verfeinern:

    • datalocation: Servername
    • host: Name oder IP des Hosts
    • meterType: Art der Daten. Dieses Feld ist besonders wichtig, da es die Art der in dieser Metrik enthaltenen Informationen angibt
      • gauge: momentane Messung
      • counter: inkrementaler Zähler
      • distsum : Datenpaar, das z. B. aus einem Zähler und einer Menge
        besteht:
        • bm-lmtpd.emailSize = (Anzahl der Emails, Gesamtgröße der Emails)
        • bm-lmtpd.emailRecipients = (Anzahl der Emails, Anzahl der Empfänger)
      • timer: wie distsum, aber die Menge wird immer in Nanosekunden angegeben
    • status: je nach Art der Daten kann es sich um einen ok/failed Status handeln (z.B. erfolgreiche/fehlgeschlagene Anfrage), success/failure (z.B. erfolgreiche/fehlgeschlagene Authentifizierung) usw.
    Astuce

    Generell empfiehlt es sich, die Daten nach Servern zu gruppieren, indem Sie die Schaltfläche "Group by host" wählen, die erscheint, wenn Sie mit der Maus über die Zeile "Host" fahren, oder indem Sie diese Baumstruktur aufklappen:

    Dadurch können die Daten nach Host gruppiert werden, anstatt einen Durchschnitt der Daten von jedem Server zu erhalten.

    Abhängig von den beobachteten Metriken kann es auch relevant sein, die Gruppierung nach status, code oder datalocation zu verwenden.

  5. Wählen Sie das Feld in der 3. Spalte aus, je nachdem, welche endgültigen Daten benötigt werden. Es wird die entsprechende Grafik angezeigt:

Nützliche Funktionen/Verfeinerung der Abfrage

Ändern der angezeigten Dauer

Dieser Teil der Abfrage definiert die anzuzeigende Dauer:

Bloc de code
WHERE time > now() - 7d

In Worten ausgedrückt: Daten, deren Zeit größer ist als heute minus 7 Tage (7d = 7 Tage), d.h. die Daten der letzten 7 Tage

auf die gewünschte Anzahl von Tagen/Stunden ändern, um die Ansicht der Grafik zu vergrößern oder zu verkleinern

Entwicklung eines Zählers

Daten vom Typ counter sind kumulativ und erhöhen sich daher regelmäßig. In diesem Fall ist ihre Entwicklung interessanter als der Wert selbst.

Zum Beispiel zählt bm-ysnp.authCount die Anzahl der verarbeiteten Authentifizierungen: bei Aufrufen der Rohdaten erhalten wir in einem Moment T die Anzahl der vom Server verarbeiteten Authentifizierungen seit Beginn der Sammlung, was an sich keine interessante Zahl ist. Andererseits gibt die Entwicklung dieser Zahl Aufschluss über die Anzahl der verarbeiteten Authentifizierungen im Laufe der Zeit.

non_negative_difference

Um diese Entwicklung zu beobachten, können wir die Funktion"non_negative_difference" verwenden, die die nichtnegative Differenz zwischen 2 Punkten des Diagramms angibt.

Am Beispiel der Anzahl der Authentifizierungen zeigt das folgende Diagramm ohne angewendete Funktion die durchschnittliche Anzahl der von der ysnp-Komponente verarbeiteten Authentifizierungen über die letzten 24 Stunden, nach Server und nach Status:

der Durchschnitt steigt weiter an, da immer mehr Authentifizierungen verarbeitet werden

Unter Verwendung der Intervalldifferenzfunktion gibt das Diagramm die Anzahl der Authentifizierungen für jedes Zeitintervall an, so dass wir sehen können, wie sich die Menge der verarbeiteten Authentifizierungen entwickelt:

Eine starke und anhaltende Spitze in der Kurve des fehlgeschlagenen Status könnte ein Zeichen für einen Angriff von Spammern sein, die versuchen, den Server zum Versenden von E-Mails zu verwenden.

non_negative_derivative

Eine andere Funktion ermöglicht es, die Entwicklungskurve der Daten zu erhalten, aber mit einer zusätzlichen Parametereinstellung: non_negative_derivative.

Diese Funktion bietet ebenfalls die Berechnung der Differenz zwischen 2 Punkten, erlaubt aber zusätzlich die Angabe der Einheit.
Mit der Funktion non_negative_difference berechnet das System eigenständig ein automatisches Intervall entsprechend der angezeigten Dauer ("where time...") und der Gruppierung der Daten ("group by time..."). Mit der Funktion non_negative_derivative können Sie die Einheit erzwingen, um z. B. eine Rate pro Minute, Stunde, Tag usw. zu erhalten.

Die folgende Abfrage zeigt somit die durchschnittliche Anzahl der Verbindungen (mean("count")) pro Minute (non_negative_derivative(...,1m)) während der letzten 24 Stunden (mit time > now() - 1d) für jede Stunde (group by time(1h)):

um 14 Uhr gab es durchschnittlich 1,03 Verbindungen pro Minute, um 15 Uhr waren es 0,5/min usw.

Ancre
distsum
distsum
distsum

Die Metriken vom Typ distsum enthalten 2 Informationen:

  1. die erste Zahl ist ein Konto
  2. die 2. Zahl ist eine Menge

So haben wir z.B. die folgenden Paare:

  • bm-lmtpd.emailSize = (Anzahl der Emails, Gesamtgröße der Emails)
  • bm-lmtpd.emailRecipients = (Anzahl der Emails, Anzahl der Empfänger)

Nehmen wir als Beispiel die Metrik emailSize: Bei jeder Speicherung wird die Anzahl der gezählten E-Mails für den Zeitraum (seit der letzten Speicherung) und die Gesamtgröße, die diese E-Mails darstellten, aufgezeichnet.

Anhand dieser Daten lassen sich Durchschnittswerte für die Größe pro Nachricht ermitteln, um zu sehen, ob eine plötzliche und anormale Entwicklung der durchschnittlichen Größe der Nachrichten stattfindet.
Zum Beispiel ist ein regelmäßiger Anstieg der durchschnittlichen Größe im Laufe der Zeit festzustellen, was auf die Verbesserung der Verbindungen, Server, Benutzergewohnheiten usw. zurückzuführen ist. Wenn sich aber plötzlich, innerhalb weniger Tage, die durchschnittliche Größe der Nachrichten verdoppelt (oder mehr), ist das nicht normal und wir müssen nach dem Grund suchen: Wurde eine Firmenunterschrift gesetzt? Sie kann ein Bild enthalten, das nicht verkleinert wurde und jede Nachricht noch schwerer macht und damit die Belastung der Servern erhöht.

Für weitere Infos zur Abfragesprache InfluxQL lesen Sie bitte die entsprechende Dokumentation:

https://docs.influxdata.com/influxdb/v1.6/query_language/

Siehe insbesondere die Funktionen: https://docs.influxdata.com/influxdb/v1.6/query_language/functions/

Und Gruppierungen nach Zeit: https://docs.influxdata.com/influxdb/v1.6/query_language/data_exploration/#advanced-group-by-time-syntax

Diagramme optimal nutzen

Das Diagrammwerkzeug des DataExplorers bietet nur eingeschränkte Möglichkeiten, es ist z.B. nicht möglich, ein gestapeltes Diagramm zu erstellen, um die Summen von 2 Kurven zu sehen.

Dazu müssen die Dashboard-Kurven aufgerufen werden (siehe unten):

Dashboards

Über die Registerkarte Dashboards können Sie auf die Dashboards zugreifen. Auf diesen Seiten können Sie Daten Ihrer Wahl gruppieren.

Standardmäßig sind 3 Dashboards vorkonfiguriert und als Beispiele angegeben:

  • JVMs Memory Usage: JVMs Speichernutzung; hier finden Sie die Nutzung jeder BlueMind-Komponente (EAS, Core, milter, ElasticSearch, HPS, etc.) und können einen übermäßigen Verbrauch oder im Gegenteil das Fehlen von Daten, die darauf hinweisen, dass ein Dienst gestoppt ist, kontrollieren
  • Mail insights: Messaging-Daten (Anzahl der zugestellten E-Mails, durchschnittliche Nachrichtengröße, Anzahl der IMAP-Prozesse usw.)
  • Monitoring system status: Systemdaten, die das Monitoringtool selbst betreffen (Menge der gesammelten Daten, Größe der Datenbank usw.)
Remarque
titleAutomatisches Zurücksetzen der Standard-Dashboards

Die Standard-Dashboards von BlueMind werden bei jeder Aktualisierung zurückgesetzt.

So werden sie neu erstellt, wenn sie gelöscht wurden, und auf den Standardinhalt zurückgesetzt, wenn sie geändert wurden. Zur Anpassung einer dieser 3 Tabellen ist es daher besser, sie zu klonen (siehe unten) und die Änderungen am Klon vorzunehmen oder die Tabelle einfach umzubenennen.

Sie können so viele Tabellen hinzufügen, wie Sie möchten, um personalisierte Ansichten auf die Daten zu haben, die Sie interessieren, und die Daten nach Typ, Relevanz, Modul usw. gruppieren.

Astuce

Tabellen können direkt in der Hauptliste dupliziert oder gelöscht werden. Wenn Sie die Maus über eine Dashboard-Zeile bewegen, erscheinen die Aktionsschaltflächen am Ende der entsprechenden Zeile:

Um ein neues Dashboard zu erstellen, gehen Sie auf die Startseite der Registerkarte "Dashboard" und klicken Sie auf die Schaltfläche "Dashboard erstellen":

Die Tabelle wird sofort erstellt, es erscheint eine neue leere Ansicht:

Klicken Sie auf "Name this dashboard", um das Feld editierbar zu machen, und geben Sie dann einen Namen für Ihr Dashboard ein:

Um dem bereits vorhandenen Bereich ein Diagramm hinzuzufügen, klicken Sie auf

Es erscheint der Abfrage-Editor, mit dem Sie Ihre Abfrage entweder durch direkte Eingabe oder über den Datenbank-Browser erstellen können, und bietet Ihnen eine Echtzeit-Ansicht des entsprechenden Diagramms:

Dieser Editor ähnelt dem des DataExplorers, für die Suche nach Metriken und die Erstellung von Abfragen können Sie sich auf den vorherigen Abschnitt beziehen.

Über die Schaltfläche "Visualization" können Sie die Art des Diagramms wählen und es anpassen:

Wenn Sie Ihr Diagramm erstellt haben, klicken Sie auf "Speichern" in der oberen rechten Ecke des Editors, um es zu speichern und dem Bereich hinzuzufügen:

Klicken Sie auf , um so viele Grafikbereiche hinzufügen, wie Sie möchten:

Oben rechts in jeder Zelle befinden sich Schaltflächen für verschiedene Vorgänge:

  • : bearbeiten, Anmerkungen hinzufügen oder Daten im csv-Format herunterladen
  • : Diagramm klonen, ein neuer Bereich mit demselben Diagramm wird am Ende des Dashboards hinzugefügt
  • : Diagramm löschen

Klicken Sie auf das gewünschte Symbol, um das Menü der möglichen Aktionen aufzurufen.

Astuce

Diagramme können per Drag-and-Drop neu angeordnet werden, indem Sie auf ihren Titelbereich klicken:

Info

Es gibt keine Schaltfläche zum Speichern von Änderungen: Alle Änderungen werden während des Änderungsvorgangs gespeichert, und es besteht nicht die Gefahr, alle vorgenommenen Arbeiten zu verlieren, wenn das Speichern vergessen wird.

Alarme

Die Registerkarte Alerting ermöglicht den Zugriff auf die Verwaltung von Alarmen sowie auf die Historie der ausgelösten Alarme.

Alarme können in Form von Skripten oder Alarmregeln erfolgen.

Standardmäßig ist bei der Installation keine Alarmregel vorhanden, jedoch sind eine Reihe von Skripten vorkonfiguriert, die Sie nach Belieben ändern und/oder hinzufügen können.

Avertissement

Bei den von BlueMind vorkonfigurierten Alarmen handelt es sich um wichtige Warnungen zum Gesundheitszustand des Servers, denen besondere Aufmerksamkeit gewidmet werden muss, wenn einer von ihnen ausgelöst wird.

Alarme

  • Um einen Alarm zu erstellen, klicken Sie auf die Schaltfläche
  • Um einen Alarm zu bearbeiten, klicken Sie auf seinen Namen in der Liste.

Füllen Sie dann die verschiedenen Teile des Formulars aus (oder korrigieren Sie sie):

  • Name this alert rule: Name des Alarms
  • Alert type:Art des Alarms, Details werden unten definiert
    • Threshold: Schwelle - der Alarm wird ausgelöst, wenn die Daten den eingestellten Wert erreichen, überschreiten oder unterschreiten
    • Relative: bezogen auf die Alarm-Historie – der Alarm wird aufgehoben, wenn eine Wertänderung vorliegt, die die definierten Bedingungen überschreitet
    • Deadman: tot – der Alarm wird ausgelöst, wenn für die eingestellte Zeit keine Werte mehr erkannt werden
  • Time series: Überwachte Datenreihen – verwenden Sie den Browser, um die gewünschte Reihe zu finden
    • DB.RetentionPolicy: die betroffene Datenbank. Uns interessiert in erster Linie die Datenbank telegraf.autogen, die die betreffenden Daten enthält; die anderen Datenbanken sind Systemdatenbanken, die die Daten der Datenbank selbst enthalten.
    • Measurements & Tags: die gesuchte Metrik; ein Feld am oberen Rand der Spalte ermöglicht zur Vereinfachung der Suche das Filtern nach Namen.
    • fields: das Feld oder die Felder, das/die für diese Daten gewünscht wird/werden.
  • Conditions: Nach Auswahl des Felds werden hier die Bedingungen entsprechend dem zuvor gewählten Alarmtyp eingestellt.
    Wenn ein Wert eingegeben wird, bietet das Display eine Echtzeitvorschau der erfassten Daten und ermöglicht möglicherweise die Positionierung oder Anpassung des Wertes.
    Zum Beispiel mit dem folgenden Formular:

    • Ich setze einen Alarm, wenn die Anzahl der Verbindungen 2 überschreitet.
    • Die Grafik zeigt die Anzahl der Verbindungen im vergangenen Monat (grüne Kurve).
    • Der grüne Bereich oben stellt den Bereich dar, in dem der Alarm aufgehoben worden wäre.
    • Ich sehe, dass meine Werte immer darunter lagen. Eine Überschreitung dieses Werts wäre anormal, daher scheint mir der Alarm bei diesem Schwellenwert relevant zu sein
    Somit können Sie Ihren Wert so gut wie möglich entsprechend Ihrer Daten und deren Historie positionieren: über den üblichen Werten, mit oder ohne Peaks usw.
    In diesem zweiten Beispiel wird ein Alarm während der Speicherverbrauchspeaks ausgelöst, die alle paar Tage auftreten:
  • Alert handlers: Manager von auszuführenden Aktionen
    Fügen Sie über die Dropdown-Liste einen oder mehrere Empfänger des Alarms hinzu:
    • post: sendet eine http-Anfrage vom Typ "post" an die angegebene url
    • tcp: Sendet eine Anfrage über das tcp-Protokoll an die angegebene Adresse
    • exec: Befehlszeile zur Ausführung auf dem Server
    • log: schreibt eine Meldung in die vorgesehene Logdatei
    • ...
    Hier sendet der Alarm eine http-Anfrage, startet einen Befehl auf dem Server und schreibt eine Meldung in die dedizierte Log-Datei:
  • Message: die Nachricht, die über den/die oben angegebenen Handler geschrieben oder gesendet werden soll

Die Skripte

Skripte ermöglichen eine verfeinerte Verwaltung von Alarmen. Jeder als Regel angelegte Alarm ist auch als Skript vorhanden und kann so bearbeitet werden.

  • Um ein Skript zu erstellen, klicken Sie auf die Schaltfläche
  • Um ein Skript zu bearbeiten, klicken Sie auf seinen Namen in der Liste.

Weitere Informationen zum Schreiben von Skripten finden Sie in der Produktdokumentation:

https://docs.influxdata.com/kapacitor/v1.5/tick/

https://www.influxdata.com/blog/tick-script-templates/

Alarm-Historie

Das Untermenü Alerting > Alert history bietet Zugriff auf die Historie der ausgelösten Alarme:

Im Verlauf können Sie den Namen, die Ebene, die Zeit, den beteiligten Host und den Wert der Daten bei Aufheben des Alarm sehen.

Ein Klick auf den Hostnamen führt zu dessen Überwachungs-Dashboard.

Andere Registerkarten

Hosts

Die Registerkarte Host List zeigt Ihnen eine Liste der überwachten Host-Server zusammen mit den darin enthaltenen Anwendungen:

Wenn Sie auf einen Server oder eine Anwendung klicken, gelangen Sie zum spezifischen Dashboard für dieses Element.