Monitoring avec ELK

1. Introduction

1.1. Commençons par un peu de terminologie

Le monitoring est l’anglicisme du terme surveillance. Dans les domaines techniques, on parle aussi de supervision. En informatique, la supervision est l’activité de surveillance du bon fonctionnement d’un système, d’une application etc.

Il existe de nombreux logiciels de supervision, qu’ils soient payants comme Patrol, ou libres comme Nagios. La supervision est historiquement une activité principalement effectuée par les exploitants en production. Or, depuis quelques années, les responsables d’applications réalisent également une supervision fonctionnelle de leurs applications.

Nous allons nous intéresser dans la suite de cette présentation à cette activité de supervision fonctionnelle. Dans cette catégorie, il n’existe pas, à ma connaissance, de logiciel, car chaque application a ses spécificités.

 

1.2. Principe de la surveillance et choix d’ELK

Pour faire de la surveillance, il est nécessaire d’acquérir des données (mesures), et de les mettre en forme dans une Interface Homme Machine.

Or, la société Elastic fournit une combinaison de logiciels constituant la suite « Elastic », anciennement nommée « ELK », celle-ci étant constituée des logiciels Elasticsearch, Logstash et Kibana. Le but d’ELK étant de rechercher, analyser et visualiser, en toute fiabilité et sécurité, ainsi qu’en temps réel, des données issues de n’importe quelle source et sous n’importe quel format.

La multitude de sources de données, de transformations, de recherches et de mises en forme font de la suite « Elastic » un outil idéal à la surveillance.

2. Détails de la suite « Elastic » / « ELK »

2.1. Elasticsearch

Elasticsearch est un moteur de recherche. Il permet de stocker des données totalement indexées et ainsi d’effectuer une recherche en mode « full text » (technique de recherche qui consiste pour le moteur de recherche à examiner tous les mots de chaque document enregistré et à essayer de les faire correspondre à ceux fournis par l’utilisateur) – ce qui est normale,  puisque Elasticseach s’appuie sur Lucene, une bibliothèque open source, de la fondation Apache écrite en Java.

On peut également citer le projet Solr de la fondation Apache, qui s’appuie également sur la bibliothèque Lucene.

 

2.2. Logstash/Beats

Logstash/Beats peut être vue comme un ETL (Extract Transform Load).

2.2.1. Logstash

Logstash étant un pipeline (tuyaux) qui intègre et traite simultanément des données provenant d’une multitude de sources, puis les transforme et les envoie vers le(s) système(s) de stockage de son choix.

Données en entrée issues de diverses sources : beats (solution privilégiée par Elastic et qui sera présentée ci-dessous), applications web, bases de données etc.
Filtres Logstash
Données en sortie vers différents systèmes de stockage :
un moteur de recherche (Elasticsearch), une base de données, un outil de monitoring

Logstash possède une bibliothèque de filtres qui sont consultables depuis le site de la société Elastic : https://www.elastic.co/guide/en/logstash/current/filter-plugins.html

Ci-dessous quelques exemples de filtres :

Plugin Description
anonymize Replaces field values with a consistent hash
cidr Checks IP addresses against a list of network blocks
cipher Applies or removes a cipher to an event
csv Parses comma-separated value data into individual fields
date Parses dates from fields to use as the Logstash timestamp for an event
elapsed Calculates the elapsed time between a pair of events
elasticsearch Copies fields from previous log events in Elasticsearch to current events
grok Parses unstructured event data into fields
i18n Removes special characters from a field
jdbc_streaming Enrich events with your database data
json Parses JSON events
metrics Aggregates metrics
mutate Performs mutations on fields

Remarque : les filtres logstash sont des plugins développés en langage Ruby, qui est le même langage utilisé pour développer logstash.

Zoom sur le plugin / filtre grok :

Grok est un filtre permettant d’éclater une chaine de caractère dans différents champs, afin de faciliter les recherches sur les valeurs contenues par ces champs. Grok s’appuie sur une description de la chaine de caractères à éclater. La syntaxe de Grok est de la forme %{SYNTAX:SEMANTIC} dans laquelle  SYNTAX est la zone d’origine et SEMANTIC le champ à alimenter.

On le code ainsi :
filter{ grok { match => {"message", "(?<log_date>%{TIMESTAMP_ISO8601}) %{GREEDYDATA:classLevel} - <eventId=%{GREEDYDATA:eventId}> <%{GREEDYDATA:libelleService}> <%{GREEDYDATA:kvdata}>"} } }

Ainsi, le contenu du champ « message » sera éclaté dans les champs : log_date, classLevel, eventId, libelleService et kvdata.

Ci-dessous le contenu du champ message qui a été éclaté :

2.2.2.  Beats

Beats est la plateforme regroupant des solutions légères de transfert des données provenant de toutes vos machines vers la machine hébergeant Logstash.

Souvent, l’information est disséminée sur plusieurs machines (logs sur plusieurs serveurs), un composant comme FILEBEAT va permettre de récupérer et centraliser les données issues des fichiers de logs de tous mes serveurs de production vers mon serveur de supervision. Par conséquent, FILEBEAT doit être installé sur tous les serveurs générant des logs. Pas d’inquiétude, car FILEBEAT a été conçu pour ne pas saturer les serveurs. De plus, il gère un système de pointeur afin de n’envoyer que les nouvelles données.

La figure ci-dessous illustre le fonctionnement de FILEBEAT et de LOGSTASH.

En résumé des précédents paragraphes, nous avons vu que la société Elastic fournit un ETL (Logstash/Beats) permettant d’acquérir et de mettre en forme nos données et un moteur de recherche permettant de stocker nos données de manière indexées pour nous permettre des recherches « full text ».

Il nous reste à voir comment mettre en forme les données dans le but de superviser une application avec Kibana.

2.3. Kibana

Kibana est l’interface graphique (IHM) permettant d’explorer et mettre en forme les données stockées dans ElasticSearch.

La première fonction de Kibana est « Discover ». Celle-ci permet de saisir une requête de recherche au format Lucene. Un guide de construction des requêtes est disponible à l’adresse : https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-query-string-query.html#query-string-syntax

Voici un exemple de recherche :

Nous souhaitons réaliser une surveillance de nos services exposés à des partenaires. En effet, des SLA (service-level agreement) ou « accords de niveau de service » ont été définis entre un responsable d’application et ses partenaires ou clients. Autrement dit, il s’agit de clauses basées sur un contrat définissant les objectifs précis attendus, et le niveau de service que souhaite obtenir un client de la part de son fournisseur, et fixe les responsabilités.

Le temps de réponse des services faisant partie des SLA, c’est une donnée que nous souhaitons superviser.

Nous savons qu’il est indiqué dans les logs applicatives de nos services :

  • L’heure de déclenchement,
  • L’identifiant du service,
  • L’identifiant de l’appelant,
  • Le statut du service,
  • Le temps de réponse (qui est en fait le temps de traitement),
  • Le nombre d’éléments retournés.

La requête suivante permet de faire une recherche :

  • Sur la log des services avec le filtre eventId:”MUT-CALL-TREATMENT”
  • Et de ne garder que la liste des services à idService:(“LDIT” OR “ADIT” OR “ATTR” OR “PPAC” OR “LDDT” OR “LTRD” OR “RDDI” OR “PTEC”)

Une notion très importante dans l’utilisation de Kibana est la période de sélection des données. Ci-dessus nous sommes sur la journée (Today). Il faut cliquer sur la période (Today) pour sélectionner une autre période :

Voici un autre exemple de recherche pour le partenaire GRDF sur le service LDIT :

Une autre fonction importante de Kibana est  « Visualize ».

Si la vue « Discover » nous permet d’afficher les données brutes d’une recherche, « Visualize » nous permet de les mettre en forme.

Ainsi dans l’exemple suivant, nous affichons les 80 et 100 percentiles du temps de réponses de l’appel du service LDIT par le partenaire de notre client.

Les temps de réponse récupérés précédemment ne sont pas des temps de réponse mais des temps de traitement. Je sais que les points d’entrées de mon application sont des serveurs Web Apache. Or, les logs access de mes serveurs contiennent le temps de réponse en microseconde  :

  • LogFormat “%h %v %u %t \”%r\” %>s %b \”%{Referer}i\” \”%{User-Agent}i\” %D”
  • %D = The time taken to serve the request, in microseconds.

J’ai donc paramétré Logstash pour éclater la chaine de caractères de mes logs access afin de mettre le dernier champ dans la variable « responsetime » :
grok { match => { "message" => "%{COMBINEDAPACHELOG}+%{GREEDYDATA:responsetime}" } }

mutate {
convert => [“response”, “integer”]
convert => [“bytes”, “integer”]
convert => [“responsetime”, “float”]
}

Voici un exemple de ligne d’un access.log qui a été éclatée :

Remarque : Je peux identifier le fichier (file) et le serveur (host) d’où proviennent les informations.

Voici la vue « Discover » avec : La date de déclenchement, l’url d’accès, le code http de réponse et le temps de réponse :

Les Access Log sont fournies en standard avec Apache. Je n’ai eu aucun développement spécifique mis à part le paramétrage de Logstash pour réaliser la surveillance du temps de réponse de mes services.

Kibana permet de sauvegarder ses recherches « Discover » ou « Visualize ». Une fonction « Dashboard » permettant de rappeler nos sauvegardes afin d’avoir plusieurs vues sur nos différentes surveillances :

La dernière fonction de Kibana « Settings » permet de paramétrer Kibana.

Il serait trop long de détailler cette fonction que je vous laisse découvrir par vous-même.

3. Conclusion

La surveillance d’une application dont les données sont situées sur plusieurs machines peut-être rapidement et facilement mis en place à l’aide du trio de logiciels Elasticsearch, Logstash et Kibana.
Les données sont extraites, transformées et chargées à l’aide de plugins/filtres.
Le moteur de recherche permet d’indexer nos données à la volée et de faire de l’interrogation « full text » comme un moteur de recherche du Web.
L’interface homme machine permet à n’importe quel utilisateur d’exécuter ses requêtes et de les mettre en forme afin de réaliser sa surveillance.

Leave a Reply

Your email address will not be published. Required fields are marked *