Alerting

L’envoie d’alertes permet de se baser sur les données reçus par elasticsearch (ES), afin de prévenir la personne concerné d’un problème. Cela répond à un besoin de picasoft de connaître l’état de ses services sans avoir à effectuer une veille active.

La solution pour l’envoie d’alerte qui a été choisi est elastalert. C’est un service extérieur à elasticsearch, utilisant sa propre base de donnée, et fonctionnant grâce à l’envoie de requête à ES pour évaluer ses métriques.

Elastalert propose un plugin permettant de gérer directement la création et la modification des règles depuis Kibana. Il marche par la création de fichiers de règles. Chaque fichier de règle correspond à une alerte spécifique.

  • Attention:
    Il est possible qu’à l’ajout d’une nouvelle il faille redémarer Elasalert pour qu’elle soit bien prise en compte. Pour cela, sur la machine dans laquelle il est instalé, lancer: “docker-compose restart elastalert”.

Documentation complète

Pour créer une règle, on peut utiliser le module elastalert directement présent sur kibana. Ce module permet à la fois d’enregistrer la règle sur la machine, et de faire une requête afin qu’elle soit prise en compte par la base de donnée de elastalert.

Note: il est possible de créer une règle directement sur la machine dans le dossier rules du docker elasalert. il faut toutefois faire ensuite un POST pour que cette règle soit chargée par l’instance.

On crée une nouvelle règle en cliquant sur create rule. On peut alors nommer la règle (veiller à donner des noms Linux friendly). Le corps de la règle peut alors être créer (cf partie suivante). En cliquant sur save, la règle est ajoutée, et immédiatement utilisée.

En sélectionnant cette règle, on peut soit l’éditer, soit la supprimer.

Le corps d’une règle est divisé en plusieurs partie. (index, type, filter, alert)

index:

c’est l’index sur lequel on va utiliser la règle. C’est à dire que notre règle va se déclencher sous certaines conditions pour cet index.

index: metricbeat-*

Les types:

Ils permettent de définir le type de l’alert, qui va nous permettre de repérer différents comportement d’un index. Par exemple, on peut repérer des pics d’activité, des modification d’un champs, déclencher l’alerte à partir d’une certaine fréquence d’apparition …

Les différents types

Ils permettent de choisir quand une règle va être envoyé, par exemple,

Par exemple pour tester si l’index métricbeat n’est plus reçu (par exemple si metricbeat est down). On peut utiliser FlatLine, avec un seuil (threshold), et la période pendant laquelle l’indice est resté en dessous du seuil (timeframe). Ce qui nous donne une règle de ce type:

index: metricbeat-*
type: flatline
threshold: 10
timeframe:
  seconds: 10

Les filtres:

A la différence des types, qui permettent de définir une règle général sur ce qui est surveillé, les filtres permettent d’isoler un champs spécifique de l’index. L’idée est de pouvoir définir que le type de règle spécifié va se déclencher pour une valeur donnée d’un ou plusieurs champs. Doc officielle

Syntax:

filter:
- query:
    query_string:
      query: "username: bob"
- query:
    query_string:
      query: "_type: login_logs"
- query:
    query_string:
      query: "field: value OR otherfield: othervalue"
- query:
    query_string:
       query: "this: that AND these: those"

Par exemple, voici le filtre le plus simple, qui match un champs de l’index avec une String:

filter:
- term:
    name_field: "bob"
- term:
    _type: "login_logs"

Un filtre intéressant peu aussi être le range, qui permet définir la plage a partir de laquelle une alerte va être levé, pour un champs numérique:

filter:
- range:
    status_code:
      from: 500
      to: 599

note: Le type any permet d’alerter pour chaque nouvelle entrée de l’index considéré. Il permet donc de n’utiliser que le filtre pour son alerte.

Pour plus de filtres, se reporter à la documentation officielle.

Les alertes:

Ce champ permet dedéfinir la méthode pour alerter. La seule méthode testé pour le moment est l’alerte par mail. Voila la configuration qui permet d’utiliser le compte alert du serveur mail de picasoft:

alert:
- "email"

from_addr: "alert"
email: 
  - "ges.mathieu+trash@etu.utc.fr"
  - "touzeau.alexandre+trash@etu.utc.fr"
smtp_host: "mail.picasoft.net" 
smtp_port: 587
smtp_auth_file: "../smtp_auth_file.yaml"

le champ “from_addr” donne l’utilisateur avec lequel le mail est envoyé (le @<ip> est ajouté par elastalert).

Le champ email (le second), permet de définir les mails auquels seront envoyés l’alerte.

Le champ “smtpauthfile” renvoie vers un fichier yaml dans lequel le user et le password du mail sont indiqués.

note: si le TLS est activé sur le serveur mail, il faut ajouter smtp_ssl: true

(a tester $ref pour renvoyer vers un fichier de mail)

Normalement, elastalert comporte une fonction de test, mais cette dernière ne marche pas. Pour tester une règle préalablement ajouté via kibana, il faut donc lancer une instance d’elasalert grace à la commande:

python -m elastalert.elastalert --config /opt/elastalert/config.yaml --rule /opt/elastalert/rules/<rule_to_test>.yaml --debug

Note: –debug permet d’afficher tous les logs, et de n’afficher les alertes que dans la console ( pas d’envoi). Pour tester le bon fonctionnement de l’envoie d’une alerte, on peut enlever –debug, ou le remplacer par –verbose

Le lancement de ce test peut se faire via un docker exec par exemple.

  • txs/infra/monitoring_p20/monitoring_es/utilisation/alerting.txt
  • de qduchemi