Dashboard on Zwindler's Reflection

Des visualiations ultra personnalisés sur Kibana avec Vega

Mon, 03 Jan 2022 07:00:00 +0000

Et si on faisait un nuage de points avec Kibana ?

Si vous me suivez sur les réseaux sociaux que je fréquente (Twitter et LinkedIn) vous ne pouvez pas avoir loupé le fait que je participe à l’organisation du sondage annuel sur les salaires dans la tech Girondine de l’association Okiwi. (OUI, je vous ai bassiné avec ça, mais c’est pour la bonne cause :chatpotté:).

Aujourd’hui, j’en parle pas, promis ;-p (ou alors, juste un tout petit mini lien ?).

Cet article est juste un retour d’expérience suite à un problème que j’ai eu, dans le cadre de ce sondage.

Frédéric Camblor m’a fait remarquer que pour visualiser les différents types de salaires en fonction de certaines catégories, un nuage de points pouvait être une visualisation efficace.

Or, pas de bol, on ne peut pas nativement faire ce type de visualisation dans Kibana… Et vous allez voir que la solution est tout sauf triviale…

Déjà, comment le savoir ?

Pour en avoir le coeur net, j’ai épluché toutes les possibilités offertes par la page “Visualisation” de mon Kibana.

D’abord, il y a Lens, a priori c’est relativement récent car ça ne me disait rien, mais c’est une façon assez pratique, user friendly et intuitive de créer des visualisations.

On drag’n’drop la métrique qu’on veut représenter et Kibana nous propose une ou plusieurs visualisation avec un type d’aggregation (count, avg, median) déterminé automatiquement.

Pour l’avoir utilisé pour la première fois pour le sondage des salaires de cette année, c’est hyper bien pensé et j’ai gagné beaucoup de temps par rapport à l’ancien éditeur de visualisation.

Bravo Elastic pour ça.

Ensuite, il y a l’ancienne façon de faire des visualisations, et là encore, pas de nuage de points…

Enfin, il y a les TSVB mais c’est pour les timeseries (donc là ça va pas le faire), et… Vega…

C’est quoi, Vega ?

Nouveauté dans Kibana 6.2 : vous pouvez désormais construire des visualisations riches Vega et Vega-Lite avec vos données Elasticsearch.

Vega-Lite is a high-level grammar of interactive graphics. It provides a concise, declarative JSON syntax to create an expressive range of visualizations for data analysis and presentation. – https://vega.github.io/vega-lite/

Grosso modo, pour tout ce que Kibana ne propose pas nativement comme type de visualisation, on vous propose de vous orienter vers le langage Vega, qui permet de déclarer, en JSON, des graphiques assez complexes et spécifiques à votre besoin.

Cool ! Reste plus qu’à trovuer comment ça fonctionne ce biniou, et surtout, comment ça s’interface avec les données dans mon ElasticSearch…

La première chose que j’ai cherché, c’est donc des exemples de nuages de points en Vega. Sauf que… je n’avais aucune idée de comment dire “nuages de points” en anglais (la recherche en Français n’ayant rien donné). Et non, ce n’est pas “cloud dots”…

Une fois que je savais que c’était un “bubble chart”, c’était tout de suite beaucoup plus simple ;-) et j’ai trouvé un tuto qui commençait à ressembler à ce que je voulais faire (même si au final ce que j’ai fais ne ressemble pas du tout).

Bubble Chart in Kibana with Vega

Ca ressemble à quoi, Vega ?

Si vous cliquez sur “Custom Visualization”, vous allez tomber sur cette page dans votre Kibana :

A gauche, un aperçu de ce que vous êtes en train de faire, et à droite, le code JSON associé.

Il y a pas mal de gloubiboulga mais vous allez vite vous rendre compte que c’est surtout des commentaires pour vous aider à comprendre ce que vous êtes censé écrire pour que ça fonctionne.

Si vous enlevez tous les commentaires, vous devriez tomber sur ça :

{
 $schema: https://vega.github.io/schema/vega-lite/v5.json
 title: Event counts from all indexes
 data: {
 url: {
 %context%: true
 %timefield%: @timestamp
 index: _all
 body: {
 aggs: {
 time_buckets: {
 date_histogram: {
 field: @timestamp
 interval: {%autointerval%: true}
 extended_bounds: {
 min: {%timefilter%: "min"}
 max: {%timefilter%: "max"}
 }
 min_doc_count: 0
 }
 }
 }
 size: 0
 }
 }
 format: {property: "aggregations.time_buckets.buckets"}
 }
 mark: line
 encoding: {
 x: {
 field: key
 type: temporal
 axis: {title: false}
 }
 y: {
 field: doc_count
 type: quantitative
 axis: {title: "Document count"}
 }
 }
}

La difficulté de faire du Vega dans Kibana a été pour moi que je découvrais 2 choses en même temps :

requêter elastic depuis Kibana avec des notions d’aggregations, buckets, etc que je ne maitrisais pas du tout
découvrir le langage Vega

Choisir l’index

La première chose qu’on remarque, c’est que les données récupérées d’ElasticSearch et donné à manger à Kibana proviennent de TOUS nos index car on a la ligne index: _all.

 data: {
 url: {
 %context%: true
 %timefield%: @timestamp
 index: _all

Clairement, ça va pas le faire ;-) du coup on restreint à l’index qui nous intéresse (okiwi-2022 dans mon cas)

Requêter Elastic avec des aggrégations

Le deuxième gros morceau à comprendre, c’est la partie interrogation de notre ElasticSearch

 body: {
 aggs: {
 time_buckets: {
 date_histogram: {
 field: @timestamp
 interval: {%autointerval%: true}
 extended_bounds: {
 min: {%timefilter%: "min"}
 max: {%timefilter%: "max"}
 }
 min_doc_count: 0
 }
 }
 }
 size: 0
 }

Ici, l’exemple fait un graphique en fonction du temps (x-axis). Les données sont regroupées avec une aggrégation de type date_histogram, avec un intervalle automatique et en se basant sur le timestamp de nos entrée dans ElasticSearch.

Ce que j’ai mis un bon moment à comprendre (car la doc est pas ouf non plus et j’ai perdu beaucoup de temps dessus) c’est qu’on a pas forcément BESOIN de faire des aggrégations.

Les aggregations possibles, si vous, vous en avez besoin, sont disponibles ici

Typiquement, dans mon cas, je ne voulais pas afficher un point (genre la moyenne) pour un groupe de personne de mon sondage, mais bien un point par personne !

Requêter Elastic sans aggrégation

Pas besoin d’aggrégation donc…

Il m’a fallu un bon moment pour trouver car tous les exemples que j’ai trouvé sur Internet passaient TOUS par des aggrégations préalables, mais j’ai fini par trouver comment juste faire une requête à ElasticSearch depuis Kibana de la façon suivante (depuis les “Dev Tools” ou bien un cURL) :

GET okiwi-2022/_search
{
 "size": 10,
 "_source": ["Nombre d'années d'expérience", "Salaire *partie fixe BRUT* (€) annuel (ex_ 30000)_ ", "Type d'entreprise"]
}

Ici, je requête l’index okiwi-2022 et je lui demande 10 résultats contenant les propriétés “Nombre d’années d’expérience”, “Salaire partie fixe BRUT (€) annuel (ex_ 30000)_ “, “Type d’entreprise” de mes documents.

Une fois que je savais ça, j’ai juste testé dans Vega

 body: {
 "size": 1000,
 "_source": ["Nombre d'années d'expérience", "Salaire *partie fixe BRUT* (€) annuel (ex_ 30000)_ ", "Type d'entreprise"]
 }

Bon ok, ça marchait toujours pas 😭😭😭 mais j’avais progressé.

La blague, c’est que le JSON renvoyé par Elasticsearch est un poil différent en fonction du fait que vous utilisiez ou non une aggregation.

Dans le premier cas, les données sont encapsulées dans aggregations.time_buckets.buckets, d’où la ligne suivante, en dessous du bloc “data”

format: {property: "aggregations.time_buckets.buckets"}

Dans le cas où vous avez une requête sans aggrégation, il suffit “juste” de remplacer par

format: {property: "hits.hits"}

Le graphique en lui même

OK, maintenant, on a les données, on peut faire du Vega purement cosmétique.

La première chose que j’ai voulu changer, c’est que dans l’exemple donné quand on créé le graphique, on a des traits. Or, moi je veux des points.

Ca, c’est géré par la ligne :

 mark: line

On remplace ça par :

 mark: {"type": "point"}

Et puis pour que le graphique soit plus “user friendly”, on peut activer les tooltips pour voir les détails du point quand on passe la souris dessus

 mark: {"type": "point", "tooltip": true}

Et puis comme les points sont trop petits (30 de base), on peut grossir un peu

 mark: {"type": "point", "tooltip": true, size: 80}

Les axes

Normalement notre graphique est pété depuis nos premières modifs car l’exemple donné par Kibana se base sur des axes temporels et des données récupérées depuis une aggrégation et qu’on a viré tout ça.

Il est donc grand temps de rebosser sur les axes et surtout où on place nos points (en fonction de quels axes).

Cette partie est gérée par le bloc encoding

 encoding: {
 x: {
 field: key
 type: temporal
 axis: {title: false}
 }
 y: {
 field: doc_count
 type: quantitative
 axis: {title: "Document count"}
 }
 }

Dans mon exemple, je veux afficher le salaire des gens en fonction de leur expérience. Mon axe des X est donc le nombre d’années d’expérience et celui des y est donc le salaire.

 x: {
 field: "_source.Nombre d'années d'expérience"
 type: "quantitative"
 axis: {title: "Années d'expériences"}
 }
 y: {
 field: "_source.Salaire *partie fixe BRUT* (€) annuel (ex_ 30000)_ "
 type: quantitative
 axis: {title: "Salaire brut"}
 }

Pour faire joli, je leur ai donné un titre avec axis: {title: ""}, c’est quand même plus sympa que le nom dégueulasse que j’ai importé du google forms en CSV ;-). Dans les deux cas, mes axes sont “quantitatifs” et non plus “temporels”. La documentation Vega sur les axes est disponible ici

Une fois que tout ça est fait, ça devrait donner un truc qui ressemble grosso modo à ça (la requête à droite est pas la bonne mais le résultat est le même):

Rendre ça joli

On n’est plus très loin de ce que Frédéric m’a proposé en début d’aticle. Reste maintenant à discriminer visuellement les données en fonction du type de société dans laquelle le salarié est embauché.

Pour ça, on va changer la forme ET la couleur du point en fonction d’une 3ème donnée : son type d’entreprise.

Bon, je vais le dire tout de suite, j’ai passé pas mal de temps sur cette partie et je ne suis pas réussi à faire ce que je voulais malgré plusieurs essais…

La méthode pour faire ça est d’utiliser les valeurs shape et color dans encoding. Là où Vega est plutôt malin, c’est que si vous mettez la même valeur comme field dans shape et color, les deux sont “merge” dans la légende, comme le montre cet exemple de la doc de Vega

https://vega.github.io/vega-lite/docs/scale.html#ordinal

 shape: {"field": "_source.Type d'entreprise", "type": "nominal"}
 color: {"field": "_source.Type d'entreprise", "type": "nominal"}

Sauf que les couleurs choisies par Kibana (qui utilise sa propre scale) sont plus que bof…

En relisant la doc, on voit qu’on devrait pouvoir choisir notre propre scale

The range of an ordinal scale can be an array of desired output values, which are directly mapped to elements in the domain. Both domain and range array can be re-ordered to specify the order and mapping between the domain and the output range. For ordinal color scales, a custom scheme can be set as well.

Sauf que tous mes tests se sont révélés être des échecs :-( Au mieux, j’ai réussi à le faire, mais en pétant la légende.

 color: {mark: {"type": "point", "tooltip": true, size: 60}
 "type": "nominal",
 "scale": {
 domain: ["Association", "ESN/SSII", "Editeur", "Entreprise non numérique", "Public"]
 range: ["rgb(230,230,31)", "rgb(255,0,0)", "rgb(0,191,0)", "rgb(31,31,255)", "rgb(191,31,191)"]
 }

Conclusion

Ce “besoin” de faire un graphique non prévu “out of the box” dans Kibana m’aura permi de découvrir plusieurs choses. D’abord, les différentes façon de requêter ElasticSearch car je n’avais jamais eu besoin de le faire (au delà de sortir les documents entier avec un bête index/_search sans filtres).

Ensuite, j’ai réussi à faire un graphique approchant de ce que je voulais faire.

Et enfin, ça m’a surtout permis de voir que je pouvais totalement me passer de Kibana pour faire des visulisations jolies.

Car beaucoup de gens qui font du Vega utilisent tout simplement une URL pointant vers un CSV et c’est totalement suffisant pour afficher des graphiques sur Internet… On perd le côté interactif bien sûr, mais pour les cas où j’ai besoin de quelque chose de simple, ça me suffira largement.

Mise à jour mars 2026 : le serveur Kibana a été décommissionné. Les dashboards interactifs ne sont plus disponibles. Les captures d’écran et les exports de données sont consultables dans l’article dédié à la décommission.

Have fun :-)

Sources

Découvrir Prometheus et Grafana par l’exemple

Mon, 13 Apr 2020 06:40:00 +0000

Grafana et Prometheus

Ça fait plusieurs articles que je vous parle de Prometheus et de Grafana, notamment pour l’installer. Mais je n’avais pas encore pris le temps de faire un article pour vous montrer comment les utiliser (et pourquoi ces deux outils sont géniaux) !

Typiquement, ça va nous permettre de réaliser ce genre de dashboard, qui permettra aux équipes (production, dev, voire même équipes fonctionnelles) de voir en un coup d’œil si tout va bien ou au contraire, ce qui va mal.

Un cas utile

Et tant qu’à présenter les outils, je me suis dis que j’allais utiliser un des exemples que j’avais eu à mettre en place dans la vraie vie : tester que mes déploiements Kubernetes respectent bien l’anti-affinité.

Cet exemple est volontairement “un peu complexe”, car il a vocation à vous permettre d’appréhender d’un seul coup plusieurs concepts qui seront utiles pour bien débuter dans Grafana et Prometheus. Notamment, la sélection de la bonne métrique, le langage PromQL, l’ajout de variables dans les dashboards, etc.

Note : Pour ceux qui ne l’ont pas, dans l’orchestrateur de containers Kubernetes, il est possible d’indiquer à l’outil que 2 replicas d’une même application (pour la redondance) ne doivent pas être exécutée sur la même ressource. Ça permet entre autre de garantir qu’il n’y a pas un SPOF au niveau de l’hôte qui exécute les containers alors qu’on croit avoir une application redondante.

Trouver les métriques dans Prometheus

Je vais partir du principe que vous avez déjà une plateforme opérationnelle, équipée d’un Prometheus et d’un Grafana. Si ce n’est pas le cas, je vous invite à faire une rapide recherche sur votre moteur de recherche préféré ou de consulter mes précédents articles sur le sujet.

La première étape avant de commencer à essayer de monter de beaux dashboards consiste à chercher la métrique qui nous intéresse. Car, il faut bien l’admettre, généralement Prometheus en collecte BEAUCOUP !

Rien que Prometheus lui même expose et stocke plus de 700 métriques

On va donc se connecter sur notre serveur Prometheus, puis requêter l’ensemble des métriques disponibles pour en trouver une qui permette de répondre simplement à notre problème. Pour reprendre l’exemple que j’ai choisi, je veux :

pour tous les Pods
m’assurer que plusieurs Pods d’un même déploiement ne sont pas exécuté sur le même serveur

Pour ça, j’ai donc besoin d’avoir une métrique qui me permettre d’avoir tous les Pods, un information sur le Deploiement concerné, ainsi que le Node sur lequel le Pod est exécuté.

container_last_seen

Il y a probablement plusieurs façon de répondre à cette interrogation, mais une des solutions qui marchent plutôt bien pour moi est d’utiliser la métrique container_last_seen.

En recherchant des métriques dans la console de Prometheus, j’ai pu remarquer que cette métrique donne, pour tous les containers, la date à laquelle il a été vu pour la dernière fois, ainsi qu’un certain nombre d’information sur chaque container.

On valide sur un cas particulier

Pour vérifier que la métrique que je vous indique répond bien à notre problème, je vous propose de tester avec un exemple.

La requête PromQL suivante permet d’afficher les containers responsable de la résolution DNS interne de mon Kubernetes (déployé dans le namespace kube-system) :

container_last_seen{container_name=~".*dns.*",namespace=~"kube-system"}
container_last_seen{[...],container_name="dns",instance="node1",namespace="kube-system",pod_name="coredns-xxxxxxxx-yyyyy",[...]} 1577569793
container_last_seen{[...],container_name="dns",instance="node2",namespace="kube-system",pod_name="coredns-xxxxxxxx-zzzzz",[...]} 1577566730
container_last_seen{[...],container_name="dns",instance="node3",namespace="kube-system",pod_name="coredns-xxxxxxxx-aaaaa",[...]} 1577569313

Pour ceux qui débutent en PromQL, il s’agit du langage de requêtage de Prometheus, et qui permet entre autre de filtrer les timeseries affichées en fonction de critères (listés dans la partie entre les accolades).

Dans les résultats de la requête, on a bien :

le nom de notre Deployment (container_name)
le nom de l’hôte qui héberge le container (instance)
le nom du Pod (pod_name)
le namespace

Créer notre visualisation dans Grafana

Maintenant qu’on a trouvé la métriques qui nous intéresse, on peut aller dans Grafana et créer un nouveau Dashboard

Puis un nouveau Panel dans notre Dashboard fraîchement créé :

A partir de là, on pourrait directement afficher les données de notre métrique, mais ça ne serait pas très informatif. On serait noyé sous une masse de conteneurs, chacun avec leurs variables.

Bref, on va devoir restreindre tout ça, notamment via des variables, pour que ça devienne exploitable !

Il y en a beaucoup trop

Dans la capture que j’ai faite juste avant, j’ai quand même été obligé de restreindre à un seul namespace, pour ne pas noyer Prometheus et Grafana. Et encore, c’est (toujours) parfaitement inexploitable.

Clairement, on ne va pas vouloir se contenter d’une sélection “statique” des namespaces, au risque de devoir faire un graphique par namespace Kubernetes (et vous en avez peut être beaucoup).

On va donc récupérer la liste des namespaces disponibles dans Prometheus et l’afficher dans une liste déroulante dans notre Dashboard. Cette liste permettra de filtrer les données par namespace pour ne pas faire planter Prometheus.

Les variables dans le Dashboard

Pour se faire, on va devoir de nouveau trouver la valeur la plus adaptée dans notre source de données Prometheus.

Je ne vais pas vous faire retourner dans Prometheus pour ça, celle que moi j’utilise, c’est celle ci :

kube_namespace_labels{namespace!~"kube-.*|default"}

Cette requête PromQL permet de lister l’ensemble des namespaces présents dans votre cluster Kubernetes, puis, entre les accolades, de filtrer pour retirer les namespaces respectant les regexp “kube-.*” et “default”.

Pour autant, on est pas encore complètement sorti d’affaire puisqu’on doit maintenant récupérer uniquement la partie rouge dans ma capture d’écran, qui est la liste des noms des namespaces.

Arrive alors Grafana, qui fournit une fonction supplémentaire label_values, et qui permet, à partir d’une liste des timeseries Prometheus, de récupérer la valeur d’un seul champ de la timeserie :

label_values(kube_namespace_labels{namespace!~"kube-.*|default"},namespace)

Et tant qu’a y être, on va également se garder sous le coude une autre requête, quasiment identique, mais qui va nous permettre d’avoir la liste des déploiements présents dans votre cluster pour un (ou plusieurs) namespaces donnés :

label_values(kube_deployment_labels{namespace=~"$k8snamespace"}, deployment)

A partir de là, je peux ajouter des Variables dans mon Dashboard. Pour le faire, on doit cliquer sur la roue crantée en haut à droite de notre Dashboard :

Puis ouvrir le menu “Variables” et ajouter les variables

A partir du moment où votre source de données et votre requête est entrée dans les champs Data source et query, Grafana va vous donner un aperçu des valeurs qui seront disponibles (tout en bas du formulaire). Un bon moyen de vérifier que tout est bon avant de passer à l’étape suivante.

Dans le dashboard, nos variables apparaissent !

On sauvegarde et on retourne dans notre Dashboard.

Si tout s’est bien passé, on a maintenant, en haut de notre Dashboard, plusieurs variables avec des menus déroulant pour les sélectionner.

Mais ce n’est pas magique pour autant…

Point un peu pénible, on va devoir maintenant modifier toutes nos visualisations (graphiques) pour prendre en compte le fait qu’on ajoute une variable.

Je ne saurai donc que trop vous conseiller de bien réfléchir à comment vous allez variabiliser vos Dashboard avant d’avoir trop de visualisation statiques…

Ajout de la variable dans notre visualisation

On va donc ajouter la variable de manière à rendre nos graphiques dynamiques en fonction des valeurs sélectionnées dans le Dashboard, en modifiant la requête précédente par celle ci :

container_last_seen{namespace=~"$k8snamespace",container_name=~"$k8sdeployment.*",container_name!="POD"}

Qu’est ce qui a changé ?

Déjà, votre requête devrait répondre beaucoup plus vite ! Et pour cause, on vient non seulement de restreindre à un seul namespace (celui correspondant à la variable Grafana $k8snamespace et non plus la valeur fixe “kube-system”) mais aussi à un seul Deployment donné (via $k8sdeployment).

Note: on a également dégagé les containers s’appelant “POD”, qui vont fausser les statistiques.

Pour autant, notre graphique n’est toujours pas exploitable… On voit bien qu’il existe 2 Pods pour mon Deployment, et si on cherche bien on pourra voir dans la timeserie sur quel Node chaque replica tourne, mais c’est fastidieux…

La valeur de chaque timeserie monte de manière constante. C’est normal, c’est un « uptime »

Compter le nombre de Pod par Node

On va s’en sortir en tirant parti d’une autre variable présente dans nos timeseries (qu’on a justement remarqué plus haut) : instance, ainsi que d’une fonction d’aggrégation du PromQL : count.

Cette variable permet, dans notre requête de savoir sur quel Node Kubernetes se situe notre Pod.

Voilà ce qu’on obtiendra en modifiant la requête de notre visualisation :

count(container_last_seen{namespace=~"$k8snamespace",container_name=~"$k8sdeployment.*",container_name!="POD"}) by (instance)

Avec restriction sur le déploiement

Là, c’est encore fastidieux, mais on commence à entrevoir la réponse à notre question initiale. Dans les derniers graphiques, les couleurs représentent les Nodes Kubernetes, et la valeur numérique le nombre de Pods qui tournent dessus pour un Namespace donné. On voit donc que globalement, pour cet exemple précis, les Pods semblent bien répartis (puisque qu’on sélectionne un seul Deployment, on a bien un Pod par Node).

Et la solution ?

Comment on fait pour voir tous les déploiements d’un coup ? Là, ça commence à devenir un peu plus touchy.

En vrai, la solution n’a plus vraiment d’intérêt en terme de découverte dans l’utilisation de Prometheus et de Grafana, dont j’ai montré les fonctionnalités lors des précédents paragraphes. Cependant, je ne vais pas vous laisser sur un cliffhanger ;-)

Je ne vais tout détailler, mais dans l’idée, la solution que j’ai trouvée (il y en a peut être de plus élégantes) est :

de lister tous les couples nom du déploiement + nom de l’hôte qui l’héberge
de regrouper par déploiement les items de la liste précédente et d’en faire une somme pour chaque déploiement
de diviser chacun des items de cette dernière liste par le nombre total de container par déploiement
d’afficher la liste des valeurs inférieures à 1

1. count(container_last_seen{namespace=~"$k8snamespace",container_name!~"^$|POD"}) by (container_name,instance))
2. count(count(container_last_seen{namespace=~"$k8snamespace",container_name!~"^$|POD"}) by (container_name,instance)) by (container_name)
3. count(count(container_last_seen{namespace=~"$k8snamespace",container_name!~"^$|POD"}) by (container_name,instance)) by (container_name) / count(container_last_seen{namespace=~"$k8snamespace",container_name!~"^$|POD"}) by (container_name)
4. count(count(container_last_seen{namespace=~"$k8snamespace",container_name!~"^$|POD"}) by (container_name,instance)) by (container_name) / count(container_last_seen{namespace=~"$k8snamespace",container_name!~"^$|POD"}) by (container_name) < 1

Ainsi, avec cette dernière formule, on peut lister l’ensemble des Deployments Kubernetes dont il existe un nombre de replica supérieur au nombre de Nodes qui les hébergent (et donc, de dénicher des soucis sur l’anti-affinités et par extension, de potentiels SPOF).

CQFD :-D

ElasticStack : Visualisez vos données dans Kibana

Tue, 17 Oct 2017 11:30:19 +0000

Collecter, c’est bien ; visualiser, c’est mieux

Cet article fait partie d’une suite d’articles sur ElasticStack, un produit elastic.co, composé des produits ElasticSearch, Logstash, Kibana et depuis plus récemment des agents Beats.

Pour ceux qui auraient raté les articles précédents, j’explique plus en détail de quoi il s’agit dans 2 articles. Et bon DevOps que je suis, tout est bien entendu entièrement automatisé par des playbooks Ansible (et oui, vous n’avez rien à faire) :

On en est où ?

Dans les deux articles précédents nous avons donc travaillé en amont d’ElasticSearch. Les données des serveurs ont été collectées, centralisées, traitées puis intégrées dans ElasticSearch. On sait faire des requêtes simples dessus via des curl.

C’est bien beau tout ça, mais on en fait quoi maintenant ? Et bien maintenant on va aller en aval et travailler avec Kibana !

Premiers pas avec Kibana

Normalement si tout s’est bien passé, on peut maintenant se connecter à Kibana, et Kibana peut communiquer avec ElasticSearch.

L’URL par défaut est http://@IP_MON_SERVEUR_ELK:5601

Joli logo qui change de couleur pendant le chargement

S’il y a un souci de connexion entre les deux logiciels qu’on vient de citer, vous aurez rapidement un message d’erreur plutôt explicite qui vous indiquera que ElasticSearch n’est pas joignable. Parfois c’est temporaire, par exemple lorsque vous démarrez ElasticSearch il arrive qu’il mette du temps à récupérer les index mais ça sera indiqué dans le message d’erreur.

Création des Index Patterns

La première page sur laquelle vous devriez tomber est une page de Management pour la création des Index Pattern. Il s’agit ni plus ni moins d’indiquer à Kibana quels sont les données (index) dans ElasticSearch nous intéressent (on peut en avoir plusieurs) et ensuite de lister les différentes colonnes pour chaque information contenue dans l’index en question.

Attention il s’agit là d’une notion importante : Plus les données présentes dans un même index seront différentes (différentes sources, différents champs), plus le nombre de champs dans votre « index pattern » sera important (logique).

Ça compliquera d’autant plus la création de nouveau graphique et l’exploitation de l’outil en général. Si vous voulez ajouter un nouveau graphique, il faudra filtrer potentiellement beaucoup de données pour n’extraire que celle qui vous intéresse et EN PLUS, de nombreux champs ne vous serviront à rien du tout et compliqueront la conception des visualisation.

Dans la mesure du possible, on s’astreindra donc à séparer en amont (lors de la configuration Logstash ou Beats) les données trop différentes dans des index distincts.

Si vous avez suivi les 2 premiers tutos, ça devrait fonctionner tout seul puisque les playbooks utilisent l’index par défaut, logstash-*. Sélectionnez @timestamp comme Time Filter puis cliquez simplement sur Create.

Discover

L’interface d’ELK est relativement simple une fois qu’on sait à quoi sert chaque menu. Maintenant que les index sont configurés, la conception des graphiques peut commencer, dans l’onglet Discover.

Cette vue est la plus importante pour la conception des graphiques puisque c’est là que vous pourrez explorer puis filtrer vos données, pour en tirer des indicateurs pertinents à surveiller.

Cette vue se découpe en plusieurs parties que je vais décrire ici :

En jaune, l’index courant et l’ensemble des champs qu’il possède. Dans mon cas, j’en ai pratiquement 200 sur cet index, d’où la nécessité de ne pas trop en rajouter !
En vert, un rapide graphique permettant de visualiser le nombre d’occurrences correspondant aux filtres et à la plage horaire sélectionnée. Très pratique pour avoir une idée du volume de données récoltées avec le filtre en cours.
En bleu, un extract des données en elles même. On peut ainsi analyser ce qui tombe dans notre filtre, et ainsi concevoir les graphiques en fonction.
En violet, la plage horaire sélectionnée (ici 7 jours en relatif, on peut aussi définir un intervalle fixe avec des dates/heures).
En rouge, la grande force de l’outil => vous pouvez écrire à la main des requêtes pour filtrer en live vos données.
En orange, les filtres en cours d’utilisation. Ici, j’ai cliqué sur la remote IP 80.74.x.x ce qui a eu pour effet d’immédiatement filtrer et restreindre à cette seule IP.

La barre de recherche s’utilise de la façon suivante : on entre les infos qu’on souhaite voir (ou ne pas voir avec « -« ) et hop, ça filtre !

Une fois qu’on est content de son filtre, on peut le sauvegarder grâce au menu Save en haut à droite. Il suffit de lui donner un nom explicite, puis de confirmer en cliquant sur le bouton Save Bleu.

Visualize

Le but du jeu avant de passer à cet étape est donc de créer un ensemble de requêtes plus ou moins complexes permettant de récupérer les données qui nous sont pertinentes.

L’onglet Visualize sert donc à créer des graphiques à partir de ses sources de données pertinentes (aka filtrées). Dans mon cas, je vais donc directement m’appuyer sur la recherche que je viens de sauvegarder pour ne récuperer que les données dont le type est égale à « nginx_access ».

A partir de là, le 2ème gros travail commencer. Ce n’est pas si simple de trouver les champs pertinents pour visualiser nos données de manières efficaces.

Comme j’ai un peu bossé pour vous dans l’article précédent, j’ai déjà ajouté dans la configuration logstash un champ qui n’est pas présent par défaut : à savoir geoip.ip.

Avec ce champ, je vais pouvoir me baser sur l’adresse IP pour déterminer plusieurs informations pour chacune des requêtes arrivant sur mon frontal nginx.

Je tire donc partie de ce champ pour réaliser un comptage de toutes les adresses IP distinctes pour l’axe des ordonnées.

Pour l’axe des abscisse, dans la majorité des cas, on se contentera du temps via le timestamp.

Cliquez sur le petit logo « Play » en haut pour visualiser le résultat :

Même principe que dans « Discover », on sauvegarde la visualisation en cliquant sur le menu Save en haut à droite, puis en validant avec le bouton Save bleu.

D’autre exemples de visualisations

En sélectionnant un graphique de type « Pie Chart », avec comme Aggregation « Count » et en séparant les tranches via le terme response.keyword, on peut faire un camembert des codes retours HTML.

En utilisant le module geoip, dont j’ai parlé plus haut, on peut créer une carte des visiteurs d’un site web :

Vous n’êtes donc maintenant (presque) limités que par votre imagination. Je dis « presque » parce qu’il n’est, à ma connaissance, pas facile voire impossible de réaliser des opérations mathématiques sur un graphique donné.

Un exemple : si je souhaite afficher la RAM consommée par un container Docker en Mo et non pas en octets (ce qui est illisible), a priori je ne peux pas le faire (à moins d’utiliser une obscure fonction permettant de dupliquer un index en lui appliquant une formule mathématique, bref, c’est compliqué).

Pour remédier à ça, elastic.co a sorti un outil appelé Timelion, intégré dans Kibana, mais ce n’est pas le sujet d’aujourd’hui ;-).

Dashboard

Le plus simple maintenant ! On peut créer des Dashboard dans l’onglet Dashboard, simplement en sélectionnant les graphiques précédemment créés puis en les réagençant avec des drags and drops. E-Z !

Voilà quelques uns des dashboards que j’ai créés pour les besoins de cet article pour vous donner une idée, mais on peut bien entendu faire bien plus complexe !

Have fun !