Pour rechercher et analyser une métrique :

1. sélectionner la base de données telegraf.autogen en 1ère colonne
2. dans le champs de recherche de la seconde colonne "Measurements & tags", taper par exemple le nom du composant BlueMind afin de voir quelles métriques sont disponibles pour celui-ci :
   
3. Sélectionner une métrique en cliquant sur son nom - ici par exemple "bm-ysnp-authCount"

4. Vous pouvez naviguer dans la sous-arborescence de la métrique afin d'affiner la donnée voulue :

   • datalocation : nom du serveur
   • host : nom ou IP de l'hôte
   • meterType : le type de donnée, ce champs est particulièrement important car il vous indique la nature des informations contenues dans cette métrique
     
     • gauge : mesure instantanée
     • counter : compteur à incrémentation
     • distsum : couple de données comportant un compteur et une quantité
       par exemple :
       • bm-lmtpd.emailSize = (nombre d'emails , taille totale des emails)
       • bm-lmtpd.emailRecipients = (nombre d'emails , nombre de destinataires)
     • timer : identique au distsum mais la quantité est ici toujours exprimée en nanosecondes
   • status : selon le type de données il peut s'agir d'un statut ok/failed (requête aboutie/échouée par exemple), success/failure (authentification réussie/échouée par exemple), etc.

   Astuce

   Il est en général conseillé de regrouper les données par serveur en sélectionnant le bouton "Group by host" qui apparaît au survol de la ligne "host" ou en dépliant cette arborescence : Cela permet de regrouper les données selon l'hôte au lieu d'obtenir une moyenne des données de chaque serveur. Selon la métrique observée, il pourra être pertinent d'utiliser aussi le regroupement par status, code ou encore par datalocation.

5. Choisir le champs dans la 3ème colonne, en fonction de la donnée finale voulue. Le graphique correspondant est alors affiché :
   

Fonctions utiles/affinage de la requête

Modifier la durée affichée

Cette partie de la requête définit la durée à afficher :

WHERE time > now() - 7d

Elle signifie de façon littérale : les données dont le temps est supérieur à aujourd'hui moins 7 jours (7d = 7 days), soit les données des 7 derniers jours

changer pour le nombre de jours/heures désiré afin d'augmenter ou raccourcir la vision du graphique

Évolution d'un compteur

Les données de type counter sont cumulatives et augmentent donc régulièrement. Dans ce cas c'est leur évolution qui est plus intéressante que la valeur elle-même.

Par exemple la donnée bm-ysnp.authCount compte le nombre d'authentifications traitées : en consultant la donnée brute on aura à un instant T le nombre d'authentifications traitées par le serveur depuis le début de la mise en place de la collecte, cela n'est pas un chiffre intéressant en soi. En revanche l'évolution de ce chiffre nous donnera le nombre d'authentifications traitées au fur et à mesure que le temps passe.

non_negative_difference

Pour observer cette évolution on pourra utiliser la fonction "non_negative_difference" qui donne la différence non négative entre 2 points du graphique.

En reprenant l'exemple du nombre d'authentifications, le graphique suivant sans fonction appliquée, montre le nombre moyen d'authentifications traitées par le composant ysnp sur les dernières 24h, par serveur et par statut :

la moyenne ne cesse de croître, au fur et à mesure que de nouvelles authentifications sont traitées

En utilisant la fonction de différence par intervalles, le graphique donne alors le nombre d'authentification pour chaque intervalle de temps, on voit donc à présent de quelle façon la quantité d'authentifications traitées évolue :

Un fort et soutenu pic d'augmentation de la courbe du statut "failed" pourrait être le signe d'une attaque de spammeurs essayant d'utiliser le serveur pour envoyer des mails.

non_negative_derivative

Une autre fonction permet d'obtenir la courbe d'évolution d'une donnée mais en apportant un paramétrage supplémentaire : non_negative_derivative.

Cette fonction propose elle aussi le calcul de la différence entre 2 points, mais elle permet en plus de préciser l'unité.
En effet avec la fonction non_negative_difference le système calcule lui-même un intervalle automatique en fonction de la durée affichée ("where time...") et du regroupement des données ("group by time..."). Avec la fonction non_negative_derivative vous pouvez forcer l'unité afin, par exemple, d'obtenir un taux par minute, heure, jour, etc.

Ainsi, la requête ci-dessous présente le nombre moyen de connexions (mean("count")) par minute (non_negative_derivative(...,1m)) lors des dernières 24h (where time > now() - 1d) pour chaque heure (group by time(1h)) :

à 14h il y avait en moyenne 1.03 connexions par minute, à 15h il y en avait 0.5/mn, etc.

Ancre
distsum distsum

Les distsum

Les métriques de type distsum comportent 2 informations :

1. le 1er nombre est un compte
2. le 2ème nombre est une quantité

Ainsi, on a par exemple les couples suivants :

• bm-lmtpd.emailSize = (nombre d'emails , taille totale des emails)
• bm-lmtpd.emailRecipients = (nombre d'emails , nombre de destinataires)

Prenons par exemple la métrique emailSize : à chaque enregistrement, le système va enregistrer le nombre d'emails comptés pour la période (depuis le dernier enregistrement) et la taille totale que ces emails ont représenté.

Ces données permettent d'établir des moyennes de taille par message et ainsi voir si la taille moyenne des messages évolue de façon brutale et anormale.
Par exemple on pourra constater une augmentation régulière de la taille moyenne au cours du temps, qui peut être imputée à l'amélioration des connexions, des serveurs, des habitudes des utilisateurs, etc. mais si tout d'un coup, en l'espace de quelques jours la taille moyenne des messages double (ou plus), cela n'est pas normal, il faudra en chercher la raison : une signature d'entreprise a-t-elle été positionnée ? Celle-ci contient peut-être une image dont on aurait oublié de diminuer la taille et qui alourdit d'autant chaque message et, par là, la charge des serveurs.

Liens utiles

Pour aller plus loin dans le langage de requêtes InfluxQL, se reporter à la documentation dédiée :

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

Voir en particulier les fonctions : https://docs.influxdata.com/influxdb/v1.6/query_language/functions/

Et les regroupements par temps : https://docs.influxdata.com/influxdb/v1.6/query_language/data_exploration/#advanced-group-by-time-syntax

Aller plus loin avec les graphiques

L'outil graphique du DataExplorer propose des options limitées, il est par exemple impossible de créer un graphe empilé afin de voir les sommes de 2 courbes.

Pour faire cela, il faut passer par les courbes des tableaux de bord (voir plus bas) :

Les tableaux de bord

L'onglet Dashboards vous permet d'accéder aux tableaux de bord. Il s'agit de pages vous permettant de regrouper les données de votre choix.

Par défaut 3 tableaux de bords sont pré-configurés et donnés pour exemples :

• JVMs Memory Usage : utilisation mémoire des JVMs, vous retrouvez ici l'utilisation de chaque composant BlueMind (EAS, Core, milter, ElasticSearch, HPS, etc.) et pouvez contrôler une sur-consommation ou au contraire l'absence de données indiquant qu'un service est arrêté
• Mail insights : données de la messagerie (nombre d'emails délivrés, taille moyenne des messages, nombre de processus IMAP, etc.)
• Monitoring system status : données système concernant l'outil de monitoring lui-même (quantité de données collectées, taille de la base de données, etc.)

Vous pouvez rajouter autant de tableaux que vous le souhaitez afin d'avoir des vues personnalisées sur les données qui vous intéressent, en regroupant les données par type, par pertinence, par module, etc.

Pour créer un nouveau tableau de bord, rendez-vous à l'accueil de l'onglet Dashboard et cliquez sur le bouton "Create dashboard" :

Le tableau est aussitôt créé, une nouvelle vue vide est présentée :

Cliquez sur "Name this dashboard" pour que le champ devienne éditable, saisissez alors un nom pour votre tableau :

Pour ajouter un graphique dans la zone déjà présente, cliquez sur

L'éditeur de requête apparaît, vous permettant de créer votre requête soit par saisie directe soit grâce au navigateur de base de données, et vous propose une vue en temps réel du graphique correspondant :

Cet éditeur est similaire à celui du DataExplorer, vous pouvez vous référez à la section précédente pour la recherche de métriques et la construction des requêtes.

Le bouton " Visualization " vous permet de choisir le type de graphique souhaité et de personnaliser celui-ci :

Une fois votre graphique créé, cliquez sur "Save" en haut à droite de l'éditeur pour le sauvegarder et l'ajouter à la zone :

Cliquez sur pour ajouter autant de zones de graphiques que vous le souhaitez :

En haut à droite de chaque cellule, des boutons vous permettent :

• : éditer, ajouter des annotations ou télécharger les données au format csv
• : clôner le graphique, une nouvelle zone avec le même graphique est ajoutée en fin de tableau de bord
• : supprimer le graphique

Cliquer sur l'icône souhaitée pour faire apparaître le menu des actions possibles.

Les alertes

L'onglet Alerting permet d'accéder à la gestion des alertes ainsi qu'à l'historique des alertes levées.

Les alertes peuvent se présenter sous forme de scripts ou de règles d'alertes.

Par défaut aucune règle d'alerte n'est présente à l'installation, en revanche un certain nombre de scripts sont pré-configurés, vous pouvez les modifier et/ou en rajouter autant que vous le souhaitez.

Les alertes

• Pour créer une alerte, cliquer sur le bouton
• Pour modifier une alerte, cliquer sur son nom dans la liste.

Remplissez (ou corriger) ensuite les différentes parties du formulaire :

• Name this alert rule : nom de l'alerte
• Alert type : le type d'alerte, les détails seront définis plus bas
  
  • Threshold : seuil – l'alerte sera levée lorsque les données atteindront, dépasseront ou diminueront en deçà de la valeur définie
  • Relative : relatif à son propre historique – l'alerte sera levée lorsqu'il y aura un changement de valeur dépassant les conditions définies
  • Deadman : mort – l'alerte sera levée lorsque plus aucune valeur ne sera détectée pendant le temps défini
• Time series : série de données surveillée – utilisez le navigateur pour trouver la série souhaitée
  • DB.RetentionPolicy : la base de données concernée. Celle qui nous intéresse en priorité est la base telegraf.autogen qui contient les données concernées, les autres bases de données sont des bases système contenant les données de la base elle-même.
  • Measurements & Tags : la métrique recherchée, un champ en haut de colonne permet de filtrer sur le nom pour une recherche plus facile
  • Fields : le ou les champs souhaités pour cette donnée
• Conditions : une fois le champ sélectionné, fixez ici les conditions en fonction du type d'alerte choisi précédemment
  Lorsqu'une valeur est saisie, l'affichage propose un aperçu en temps réel des données collectées, permettant éventuellement de positionner ou d'ajuster la valeur.
  Par exemple avec le formulaire ci-dessous :
  
  
  • Je paramètre une alerte lorsque le nombre de connexion dépasse 2.
  • Le graphique montre le nombre de connexion sur le mois précédent (courbe verte).
  • La zone verte en haut représente la zone dans laquelle l'alerte aurait été levée.
  • Je peux constater que mes valeurs ont toujours été en dessous, il serait anormal qu'elles le dépassent donc l'alerte me semble pertinente à ce seuil
  Ainsi, vous pouvez positionner votre valeur au mieux en fonction de votre donnée et son historique : au dessus des valeurs habituelles, comprenant les pics ou non, etc.
  Dans ce second exemple, une alerte sera levée lors des pics de consommation de mémoire qui arrivent tous les quelques jours :
  
• Alert handlers : gestionnaires d'actions à réaliser
  Ajouter grâce à la liste déroulante un ou plusieurs destinataires de l'alerte :
  • post : envoie une requête http de type "post" à l'url donnée
  • tcp : envoie une requête via le protocole tcp à l'adresse indiquée
  • exec : ligne de commande à exécuter sur le serveur
  • log : écrire un message dans le fichier log désigné
  • ...
  Ici, l'alerte envoie une requête http, lance une commande sur le serveur et écrit un message dans le fichier log dédié :
  
• Message : le message à écrire ou envoyer via le(s) gestionnaire(s) spécifié(s) ci-dessus
  

Les scripts

Les scripts permettent une gestion plus fine et experte des alertes. Chaque alerte créée sous forme de règle est aussi présente sous forme de script et peut être éditée de cette façon.

• Pour créer un script, cliquer sur le bouton
• Pour modifier un script, cliquer sur son nom dans la liste.

Pour plus d'information sur l'écriture de scripts, vous pouvez vous référer à la documentation produit :

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

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

Historique des alertes

Le sous-menu Alerting > Alert history permet d'accéder à l'historique des alertes levées :

L'historique permet de voir le nom, le niveau, l'heure, l'hôte concerné et la valeur de la donnée lors de la levée de l'alerte.

Un clic sur le nom d'hôte mène au tableau de bord de supervision de celui-ci.

Autres onglets

Les hôtes

L'onglet Host List vous présente la liste des serveurs hôtes surveillés, avec les applications qu'ils comprennent :

Un clic sur un serveur ou sur une application vous mène au tableau de bord spécifique de cet élément.

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:

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.

Useful links

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.

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.

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.

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.

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.