Le moins qu’on puisse dire, c’est qu’avec 1,2 pétaoctet quotidien de logs et 5 millions de points de données d’indicateurs entrant par seconde, eBay a de quoi s’occuper ! Chaque jour, l’équipe de logging et de monitoring de la société d’e-commerce est confrontée à une tâche monumentale : collecter et visualiser l’ensemble de ces logs et de ces indicateurs. Et comme la plupart des entreprises, elle se sert d’un éventail d’applications (comme Hadoop ou MySQL pour ne citer qu’elles) pour alimenter différents cas d’utilisation dans les équipes.

C’est alors que les conteneurs ont fait leur apparition, proposant une nouvelle façon de déployer les applications. L’équipe a commencé à conteneuriser avec Docker et à effectuer le déploiement avec Kubernetes, qu’elle utilise aussi pour gérer le cycle de vie. Seulement, il restait une problématique de taille : l’évolution continuelle des applications et de l’environnement. Difficile de suivre le rythme ! C’est là qu’intervient Beats. Pour collecter et envoyer des logs de transfert et des indicateurs depuis Docker et Kubernetes, Filebeat et Metricbeat sont deux solutions idéales.

L’équipe souhaitait également voir les charges de travail au fur et à mesure de leur apparition. Avant que la fonctionnalité d’autodécouverte ne soit proposée dans Beats (nouveauté de la version 6.2), eBay a donc créé sa propre fonction : Collectbeat. Construite sur libbeat, cette fonction a découvert de nouveaux pods dans les clusters Kubernetes. Collectbeat s’est appuyé sur l’API Kubernetes pour mettre au jour les charges de travail, collecter des données et les enrichir, puis les envoyer sur le système de monitoring interne. Connu sous le nom de Sherlock.io, ce système a été conçu pour être flexible et s’adapter à l’adoption de nouvelles technologies.

L’aspect « collecte » ? C’est fait. Tournons-nous maintenant vers l’analyse et la visualisation. La collecte des données est utile uniquement si les utilisateurs d’eBay sont capables de les analyser avec des étiquettes communes. L’étape suivante consistait donc à trouver le moyen de baliser les données avec des métadonnées avant qu’elles ne soient transférées. Logique ! Vijay Samuel et son équipe eBay ont donc conçu un processeur appelé « add_kubernetes_metadata », qui reprend les messages des logs et les charges des indicateurs et y ajoute des métadonnées, comme le nom et l’espace de pod. Ce processeur est désormais disponible sur GitHub. Un exemple parfait qui montre la puissance des projets open source menés à bien par la communauté.

Bien sûr, eBay continue à évoluer. Et qui dit adoption de nouvelles technologies, dit plus d’applications, plus de logs et plus d’indicateurs. Concrètement, si l’on se penche sur la croissance de logging organique d’eBay, celle-ci est de 50 % d’une année sur l’autre. Question : comment la société fait-elle pour gérer des volumes croissants de données alors que les ressources sont limitées ? Une tactique consiste à mesurer les applications au niveau de l’hôte/du pool en créant des quotas basés sur le niveau et en appliquant des limites de rétention. Une autre méthode consiste à donner la priorité à des types spécifiques de données : d’abord les événements, puis les indicateurs donnant une visibilité opérationnelle, et enfin les logs. Pour vérifier la pertinence de l’ordre de priorité, rien de plus simple : basez-vous sur les calendriers d’événements et la fonction d’autodécouverte qui permet d’ajouter une pondération aux configurations.

Envie d’en savoir plus sur les outils et les stratégies de l’équipe eBay ? Regardez la présentation de Vijay lors d’Elastic{ON} 2018 pour avoir plus d’infos sur Sherlock.io et sur la façon dont eBay utilise Beats pour monitorer l’ensemble des données de ses clusters Kubernetes. Vous voulez en savoir plus sur l’utilisation de la Suite Elastic pour monitorer Kubernetes et Docker ? Découvrez notre webinaire Elastic Stack: Monitoring Kubernetes Applications with Beats.

La Suite Elastic est utilisée dans de nombreux cas d'utilisation. L'un des plus courants consiste à stocker et à analyser différents types de données basées sur des événements ou des séries temporelles, tels que les événements de sécurité, les logs et les indicateurs. Ces événements se composent généralement de données liées à un horodatage qui indique quand l'événement a eu lieu ou a été enregistré. Le plus souvent, aucune clé naturelle ne permet d'identifier l'événement de façon unique.

Selon les cas d'utilisation et les types de données, il est important que les données ne soient pas dupliquées dans Elasticsearch : les documents en double sont susceptibles de fausser les analyses et de provoquer des erreurs de recherche. L'année dernière, nous avions publié sur notre blog une introduction au traitement des doublons avec Logstash. Nous allons désormais approfondir le sujet et répondre à quelques questions fréquemment posées.

L'indexation dans Elasticsearch

Lorsque vous indexez des données dans Elasticsearch, seul le renvoi d'une réponse garantit l'indexation correcte des données. Si une anomalie, telle qu'une erreur de connexion ou un incident de nœud, empêche le renvoi d'une réponse, vous n'avez aucun moyen de savoir si les données ont été indexées. Lorsque les clients se trouvent dans cette situation, ils retentent le plus souvent l'opération pour s'assurer que l'indexation a bien eu lieu. Il se peut ainsi qu'un même document ait été indexé plusieurs fois.

Comme le décrit l'article sur le traitement des doublons, nous pouvons contourner ce problème en assignant un identifiant unique à chaque document dans le client plutôt que de demander à Elasticsearch d'en assigner un automatiquement lors de l'indexation. Pour éviter les doublons, l'indexation des documents en double est traitée comme une mise à jour, et les documents ne sont pas inscrits une deuxième fois.

UUID ou identifiants de document basés sur le hachage

Vous pouvez choisir parmi deux types d'identifiants.

Les identifiants universels uniques (UUID) reposent sur des numéros 128 bits qui peuvent être générés sur des systèmes distribués tout en étant uniques dans les faits. Ce type d'identifiant ne dépend généralement pas du contenu de l'événement auquel il est associé.

Si vous souhaitez utiliser les UUID pour éviter la présence de doublons, il est indispensable de les générer et de les assigner aux événements au bon moment pour garantir leur unicité. Dans la pratique, l'UUID doit le plus souvent être assigné au point d'origine. Si le système dont est issu l'événement ne peut pas générer d'UUID, un autre type d'identifiant pourrait être requis.

L'autre principal type d'identifiant utilise une fonction de hachage numérique qui repose sur le contenu de l'événement. La fonction de hachage générera systématiquement la même valeur pour un même fragment de contenu, mais l'unicité de la valeur générée n'est pas garantie. La probabilité qu'une collision de hachage survienne, c'est-à-dire que deux événements différents sont à l'origine d'une même valeur de hachage, dépend du nombre d'événements contenus dans l'index, du type de fonction de hachage utilisé ainsi que de la longueur des valeurs générées. Un hachage d'au moins 128 bits, tel que celui produit par les fonctions MD5 et SHA1, offre généralement un compromis intéressant entre longueur et faible risque de collision pour un grand nombre de scénarios. Vous pouvez utiliser des fonctions de hachage SHA256 pour limiter davantage le risque de collision.

Étant donné que les identifiants basés sur le hachage dépendent du contenu de l'événement, vous pouvez les assigner plus tard, car leur valeur sera la même à tout moment. Vous pouvez assigner ce type d'identifiant n'importe quand avant d'indexer les données dans Elasticsearch et ainsi bénéficier de plus de flexibilité pour concevoir votre pipeline d'ingestion.

Grâce au plug-in de filtre d'empreinte (fingerprint filter plugin), Logstash peut calculer des UUID ainsi qu'un ensemble de fonctions de hachage parmi les plus communes et populaires.

Choix d'un identifiant de document efficace

Quand Elasticsearch est autorisé à assigner l'identifiant de document lors de l'indexation, il peut procéder à des optimisations, car il sait que l'identifiant généré n'existe pas encore dans l'index. Cela a pour effet d'améliorer les performances d'indexation. Quant aux identifiants générés ailleurs et transmis avec le document, Elasticsearch doit vérifier s'il s'agit d'une mise à jour et si l'identifiant des documents existe dans les segments existants de l'index. Cette tâche supplémentaire ralentit l'opération.

Tous les identifiants de document externes ne sont pas créés de la même façon. Les identifiants qui augmentent progressivement en fonction de l'ordre de tri donnent généralement lieu à une indexation plus performante que les identifiants entièrement aléatoires. En effet, Elasticsearch est capable de déterminer rapidement l'existence d'un identifiant dans les segments antérieurs de l'index en prenant en compte uniquement le premier et le dernier identifiant du segment au lieu d'explorer ce dernier. Ce phénomène est décrit dans cet article de blog qui reste pertinent, même s'il ne date pas d'hier.

Les identifiants basés sur le hachage ainsi qu'un grand nombre d'UUID sont généralement de nature aléatoire. Lors du traitement d'événements horodatés, nous pouvons accoler l'horodatage comme préfixe à l'identifiant pour que ce dernier puisse être trié et ainsi améliorer les performances d'indexation.

La création d'un identifiant dont le préfixe est l'horodatage permet aussi de réduire le risque de collision de hachage, la valeur de hachage n'ayant qu'à être unique par horodatage. Ainsi, il devient possible d'utiliser des valeurs de hachage plus courtes, même avec des volumes importants d'ingestion.

Nous pouvons créer ces types d'identifiants dans Logstash en utilisant le plug-in de filtre d'empreinte pour générer un UUID ou un hachage, ainsi qu'un filtre Ruby pour créer une représentation de chaîne hexadécimale de l'horodatage. Supposons que nous disposons d'un champ message que nous pouvons hacher et que l'horodatage de l'événement a déjà été analysé dans le champ @timestamp, nous pouvons créer les composants de l'identifiant et les stocker dans les métadonnées comme suit :

fingerprint {
  source => "message"
  target => "[@metadata][fingerprint]"
  method => "MD5"
  key => "test"
}
ruby {
  code => "event.set('@metadata[tsprefix]', event.get('@timestamp').to_i.to_s(16))"
}

Ces deux champs peuvent alors être utilisés pour générer un identifiant de document dans le plug-in de sortie d'Elasticsearch :

elasticsearch {
  document_id => "%{[@metadata][tsprefix]}%{[@metadata][fingerprint]}"
}

En résultera un identifiant de document hexadécimal comportant 40 caractères, par exemple 4dad050215ca59aa1e3a26a222a9bbcaced23039. Un exemple complet de configuration est proposé dans ce gist.

Conséquences en matière de performances d'indexation

Les effets liés à l'utilisation de différents types d'identifiants dépendront énormément de vos données, du matériel utilisé et de votre cas d'utilisation. Bien que nous puissions émettre quelques recommandations d'ordre général, nous vous conseillons d'effectuer des comparaisons pour évaluer avec exactitude les impacts sur votre cas d'utilisation.

Pour ce qui est du taux d'indexation, l'utilisation d'identifiants générés automatiquement par Elasticsearch reste l'option la plus efficace. Les vérifications de mise à jour n'étant pas requises, le taux d'indexation varie très peu à mesure que la taille des index et des partitions augmente. Cette option est donc recommandée chaque fois qu'elle est applicable.

Les vérifications de mise à jour qui résultent de l'utilisation d'identifiants externes requièrent plus d'accès au disque. L'ampleur des effets occasionnés dépendra de l'efficacité dont bénéficie le système d'exploitation pour mettre en cache les données requises, de la rapidité du stockage et de la capacité de ce dernier à traiter des lectures aléatoires. La vitesse d'indexation diminue souvent à mesure que les index et les partitions grandissent, et que la quantité de segments à vérifier augmente.

Utilisation de l'API de substitution (rollover API)

Les index temporels traditionnels reposent sur des index qui couvrent chacun d'eux une période précise. Cela signifie que la taille des index et des partitions est susceptible de varier considérablement si le volume des données fluctue au fil du temps. La présence de partitions de tailles inégales n'est pas souhaitable, car de telles disparités peuvent causer des problèmes de performance.

L'API de substitution d'index (rollover index API) offre une manière flexible de gérer les index temporels en fonction de plusieurs critères en plus du critère temporel. Elle permet d'utiliser un index de substitution lorsque l'index d'origine atteint une certaine taille, un certain nombre de documents ou un certain âge. La taille des partitions et des index qui en découle est bien plus prévisible.

Toutefois, cela rompt le lien entre l'horodatage des événements et l'index auquel il appartient. Lorsque les index reposaient uniquement sur une base temporelle, un même événement était systématiquement assigné au même index, quel que soit le moment de son insertion. C'est ce principe qui permet d'éviter les doublons en utilisant des identifiants externes. Lorsque vous utilisez l'API de substitution, il n'est par conséquent plus possible d'empêcher complètement les doublons, bien que le risque soit réduit. Il se peut que deux événements en double soient insérés dans des segments différents de l'index de substitution, finissent par se trouver dans des index différents bien qu'ils aient le même horodatage et ne fassent pas l'objet d'une mise à jour.

Ainsi, l'utilisation de l'API de substitution n'est pas recommandée si la duplication de documents doit être rigoureusement évitée.

Adaptation face à l'imprévisibilité du trafic

Si l'API de substitution ne peut pas être utilisée, il est possible d'ajuster la taille des partitions lorsque des fluctuations du trafic produisent des index temporels trop petits ou trop volumineux.

Si les partitions sont trop volumineuses en raison, par exemple, d'un pic de trafic, vous pouvez utiliser l'API de partition d'index (split index API) pour diviser l'index en un plus grand nombre de partitions. Pour que l'API fonctionne, un paramètre doit être appliqué dès la création de l'index. Celui-ci doit donc être ajouté au moyen d'un modèle d'index.

En revanche, si une chute du trafic est à l'origine de partitions inhabituellement petites, l'API de réduction d'index (shrink index API) permet de réduire le nombre de partitions dans l'index.

Conclusions

Cet article de blog montre qu'il est possible d'éviter les doublons dans Elasticsearch en assignant à chaque document un identifiant externe avant d'indexer les données dans Elasticsearch. Le type et la structure de l'identifiant peuvent avoir un impact significatif sur les performances d'indexation. Étant donné que l'impact occasionné varie selon les cas d'utilisation, nous vous recommandons d'effectuer des évaluations comparatives pour optimiser votre choix selon votre scénario.

Exploration d'éléments Canvas dans Kibana

Canvas propose actuellement une sélection d'environ 20 éléments intégrés qui peuvent être ajoutés aux présentations (consultez la liste complète dans l'article de blog Prise en main). Dans cet article, nous allons nous pencher sur deux d'entre eux : Metrics (Indicateurs) et Markdown

	Metric : Zone de texte simplifiée affichant uniquement une valeur de donnée et une étiquette
	Markdown : Zone de texte complète affichant des données dynamiques avec des {{variables}} handlebars.js et la syntaxe Markdown

Remarque : Si vous avez déjà installé Canvas et l'échantillon de données, vous pouvez ignorer la section suivante et passer directement au tutoriel principal : Utilisation de Metrics (Indicateurs)

Révision rapide

Si vous n'avez pas encore lu attentivement l'article de blog Prise en main, nous vous recommandons de le faire, car il présente des concepts que nous allons utiliser dans le présent article. Aussi nous partons du principe que vous avez installé :

1. Elasticsearch et Kibana (version 6.4 ou ultérieure)
2. Canvas

Création d'une présentation Canvas

1. Cliquez sur l'onglet Canvas dans la barre latérale.
2. Cliquez sur Create workpad (Créer une présentation).
3. Donnez un nom unique à la nouvelle présentation.

Installation d'un échantillon de données

Pour les besoins de ce tutoriel, nous allons utiliser l'échantillon de données suivant fourni par Elastic : Sample flight data (échantillon de données de vols).

Remarque : Cet ensemble de données est uniquement disponible avec Kibana 6.4 ou toute version ultérieure.

Accédez à votre instance Kibana :

1. Cliquez sur Kibana dans la barre latérale.
2. En bas de la section Add Data to Kibana (Ajouter des données à Kibana), cliquez sur le lien Load a data set and a Kibana dashboard (Charger un ensemble de données et un tableau de bord Kibana).
3. Dans la vignette Sample flight data, cliquez sur Add (Ajouter).

Référence rapide

Le tableau ci-dessous contient des informations sur l'échantillon de données que vous venez d'installer. Dans cette activité, nous allons utiliser les champs soulignés en gras, mais n'hésitez pas à manipuler les autres.

Utilisation de Metrics

Fonctionnement de base

Recherchons la durée totale des retards de vol en minutes et affichons-la dans un élément Metric. Pour ce faire, nous allons formuler une requête SQL afin d'extraire le total du champ FlightDelayMin de notre échantillon de données.

1. Cliquez sur Add element (Ajouter un élément).
2. Choisissez Metric
1. CONSEIL : Lorsque vous créez un élément pour la première fois, celui-ci intègre des données de démonstration pour que vous puissiez le découvrir sans attendre.
3. Dans le panneau d'édition situé à droite, sélectionnez l'onglet Data (Données).
4. Cliquez sur Change your data source (Changer de source de données).
5. Sélectionnez Elasticsearch SQL.
6. Dans l'éditeur de requête SQL, saisissez :

SELECT
    SUM(FlightDelayMin) AS delay
FROM
    kibana_sample_data_flights

Explication supplémentaire : Cette requête SQL sélectionne toutes les valeurs JSON qui contiennent la clé FlightDelayMin dans l'index kibana_sample_data_flights. Ces données sont renvoyées dans une colonne intitulée delay (retard).

7. Cliquez sur Save (Enregistrer).

Notez que l'élément Metric affiche désormais un symbole d'avertissement. Cela est dû au fait que l'élément désigne des données incorrectes.

8. En haut du panneau d'édition situé à droite, sélectionnez l'onglet Display (Affichage).
9. Dans la section Number (Nombre), définissez les valeurs suivantes :

• Mesure : Value (Valeur)
• Champ : delay (retard)

Personnalisations

Ajoutons un filtre de temps pour afficher la durée totale des retards de vol en minutes pour une période donnée.

1. Cliquez sur Add element (Ajouter un élément).
2. Choisissez Time Filter (Filtre de temps).

Notez que l'élément Metric affiche désormais un symbole d'avertissement. Cela s'explique par le fait que tous les éléments de la présentation sont directement affectés par le filtre de temps alors que ce dernier n'est pas encore configuré.

3. Déplacez le filtre de temps vers un emplacement vide de la présentation.
4. Le champ de temps par défaut de l'élément Time filter (filtre de temps) indique @timestamp, ce qui est incorrect dans ce cas. Dans le panneau d'édition du filtre de temps, modifiez la valeur de la colonne comme suit : timestamp (autrement dit, supprimez le symbole @).
5. Cliquez sur Set (Configurer).
6. Cliquez sur le filtre de temps, puis sélectionnez les périodes suivantes :

• Last 24 hours (24 dernières heures)
• Last 7 days (7 derniers jours)
• Last 2 weeks (2 dernières semaines)

Remarque : L'échantillon contient quatre semaines de données : deux semaines de données "passées" et deux semaines de données "futures". Le point médian correspond à la date d'installation de l'échantillon de données.

Utilisation plus avancée

Essayons maintenant d'obtenir le retard de vol moyen. Nous allons devoir apporter une petite modification au code qui s'exécute en arrière-plan pour améliorer la présentation.

1. Vérifiez que le premier indicateur que nous avons créé est sélectionné.
2. Tout en haut à droite de l'écran, cliquez sur le bouton Duplicate (Dupliquer).
3. Déplacez le nouvel élément Metric vers un emplacement vide de la présentation.
4. Modifiez l'étiquette de l'indicateur comme suit : Average Delay in Minutes (Retard moyen en minutes)
5. Sélectionnez l'onglet Data (Données).
6. Dans l'éditeur de requête SQL, saisissez :

SELECT
    AVG(FlightDelayMin) AS delay
FROM
    kibana_sample_data_flights

7. Cliquez sur Save (Enregistrer).
8. Développez l'élément Metric pour afficher le nombre dans sa totalité.

• Un nombre du type suivant devrait s'afficher : 47.33517114633586
• À l'évidence, il serait préférable de l'arrondir.

11. Dans la documentation de Canvas, Elastic fournit une liste de fonctions mathématiques que nous pouvons utiliser.
12. Nous souhaitons utiliser la fonction round(a,b).

• a indique la valeur à arrondir.
• b indique le nombre de décimales.

1. Ligne 3 : | math "round(delay,0)"

Utilisation de Markdown

Fonctionnement de base

Recherchons le nombre total de vols et affichons le résultat dans un élément Markdown. Pour ce faire, nous allons exécuter une commande SQL pour interroger le champ FlightNum de notre échantillon de données.

1. Cliquez sur Add element (Ajouter un élément).
2. Choisissez Markdown.
1. CONSEIL : Lorsque vous créez un élément pour la première fois, celui-ci intègre des données de démonstration pour que vous puissiez le découvrir sans attendre.
3. Dans le panneau d'édition situé à droite, sélectionnez l'onglet Data (Données).
4. Cliquez sur Change your data source (Changer de source de données).
5. Sélectionnez Elasticsearch SQL.
6. Dans l'éditeur de requête SQL, saisissez :

SELECT
    FlightNum
FROM
    kibana_sample_data_flights

7. Cliquez sur Save (Enregistrer).
8. Cliquez sur l'onglet Display (Affichage).
9. Supprimez tout le contenu de l'éditeur Markdown content (Contenu Markdown) sauf :

**{{rows.length}} rows**

Remarque : Comme son nom l'indique, l'élément Markdown prend entièrement en charge la syntaxe Markdown : p. ex. **, ##, ```, etc. Pour ceux qui ne connaissent pas la syntaxe Markdown, dans l'exemple ci-dessus, nous entourons le texte avec ** pour mettre le texte en gras.

10. Cliquez sur Apply (Appliquer).
11. L'élément Markdown affiche désormais le nombre total de lignes de l'ensemble de données. Ce nombre correspond au nombre total de vols. Modifiez le texte comme suit :

Total number of flights: **{{rows.length}}**

12. Cliquez sur Apply (Appliquer).
13. Cliquez sur le symbole + dans l'éditeur Markdown situé en haut à droite de l'écran.
14. Dans le menu déroulant, sélectionnez Text Settings (Paramètres de texte).
15. Dans les paramètres de texte, effectuez les réglages suivants :
1. Taille de la police : 36
2. Alignement : Centré
16. Redimensionnez l'élément Markdown pour l'adapter au texte.

Personnalisations

Recherchons maintenant le nombre de vols en retard pour chaque type de retard. Pour ce faire, nous allons utiliser le champ FlightDelayType.

1. Cliquez sur Add element (Ajouter un élément).
2. Choisissez Markdown.
3. Dans le panneau d'édition situé à droite, sélectionnez l'onglet Data (Données).
4. Cliquez sur Change your data source (Changer de source de données).
5. Sélectionnez Elasticsearch SQL.
6. Dans l'éditeur de requête SQL, saisissez :

SELECT
    FlightDelayType,
    COUNT(FlightDelayType) AS count
FROM
    kibana_sample_data_flights
GROUP BY
    FlightDelayType

7. Cliquez sur Save (Enregistrer).
8. Cliquez sur l'onglet Display (Affichage).
9. Supprimez tout le contenu de l'éditeur Markdown content (Contenu Markdown) sauf :

{{#each columns}}
 **{{name}}**
{{/each}}

1. Explication supplémentaire :
2. Ce code utilise la syntaxe handlebar.js. Pour chaque colonne renvoyée par la requête SQL, nous affichons le nom de la colonne. Cependant, nous devons afficher la valeur de chaque ligne dans la colonne FlightDelayType. Nous allons effectuer quelques corrections à l'étape suivante.

10. Dans l'éditeur Markdown content (Contenu Markdown), remplacez :

• columns (colonnes) par rows (lignes)
• name (nom) par FlightDelayType

{{#each rows}}
- {{FlightDelayType}} -- {{count}}
{{/each}}

1. Explication du code ci-dessus :
2. Ligne 1 : Pour chaque ligne...
3. Ligne 2 : Afficher "-" pour indiquer qu'il s'agit d'un élément de liste, puis afficher les deux variables séparées par "--"
4. Ligne 3 : Afficher une nouvelle ligne
5. Ligne 4 : Fin de la boucle

13. Cliquez sur Apply (Appliquer).

Utilisation plus avancée

Dans l'élément Markdown que nous venons de créer, l'une des lignes indique : No Delays -- 2856 Cette valeur ne nous dit rien au sujet des retards. Bien au contraire, elle nous indique le nombre de vols partis à l'heure. Supprimons cette ligne afin d'afficher uniquement les vols qui ont subi un retard. Pour ce faire, nous allons utiliser la fonction filterrows de Canvas.

1. Vérifiez que l'élément Markdown que nous venons de créer (celui qui affiche tous les types de retard) est sélectionné.
2. En bas à droite de l'écran, cliquez sur Expression editor (Éditeur d'expression). L'éditeur de code qui s'affiche vous permet de modifier le code qui alimente l'élément sélectionné.
3. Dans l'éditeur d'expression, vous devriez voir quelque chose de semblable à ce qui suit :

filters
| essql 
  query="SELECT
    FlightDelayType,
    COUNT(FlightDelayType) AS count
FROM
    kibana_sample_data_flights
GROUP BY
    FlightDelayType"
| markdown "{{#each rows}}
- {{FlightDelayType}} -- {{count}}
{{/each}}"

4. Nous allons acheminer les données au moyen de la fonction filterrows avant de les diriger vers l'élément Markdown. Insérons une nouvelle ligne à la ligne 10, puis ajoutons la fonction filterrows juste au-dessus de la fonction | markdown. N'oubliez pas la barre verticale | au début de la ligne.

...
GROUP BY
    FlightDelayType"
<b style="background-color:#ffae5b"><i>| filterrows {}</i></b>
| markdown "{{#each rows}}
- {{FlightDelayType}} -- {{count}}
...

5. Nous voulons filtrer les lignes en fonction des valeurs contenues dans la colonne FlightDelayType. Pour ce faire, nous devons utiliser une autre fonction dénommée getCell. Celle-ci renvoie la valeur de chaque ligne à partir d'une colonne donnée (documentation de la fonction getCell).

| filterrows { <b style="background-color:#ffae5b"><i>getCell “FlightDelayType”</i></b> }

6. Ensuite, nous allons acheminer la valeur de chaque ligne vers la fonction any. Celle-ci renvoie true (vrai) ou false (faux) en fonction d'une condition de vérification (documentation de la fonction any).

| filterrows {getCell “FlightDelayType” <b style="background-color:#ffae5b"><i>| any {}</i></b> }

7. Enfin, pour ce qui est de la condition de vérification, assurons-nous que la valeur est différente de No delay (Aucun retard) en utilisant la fonction neq (documentation de la fonction neq).

| filterrows {getCell “FlightDelayType” | any { <b style="background-color:#ffae5b"><i>neq “No Delay”</i></b> }}

8. En bas à droite de l'éditeur d'expression, cliquez sur Run (Exécuter). La ligne qui indique No Delay -- 2856 devrait disparaître.

Liens vers d'autres ressources utiles

Et voilà ! Vous venez de parcourir plusieurs exemples d'utilisation d'éléments Metric et Markdown dans Canvas. N'hésitez pas à y ajouter d'autres éléments et à essayer l'ensemble des fonctionnalités de Canvas.

Nous vous suggérons aussi de consulter d'autres tutoriels Canvas :

• Prise en main de Canvas dans Kibana
• Articles à propos de Canvas
• Un café d’abord... (une histoire au sujet de Canvas à l’Elastic{ON})

Organisez votre travail avec Kibana Spaces

Avec la version 6.5, nous introduisons une nouvelle fonctionnalité : Spaces. Spaces vous permet d'organiser vos tableaux de bord, visualisations et autres objets enregistrés en catégories pertinentes. Chaque espace étant indépendant, les objets enregistrés dans un espace ne viennent pas encombrer les autres espaces.

Premiers pas

Kibana crée automatiquement l'espace "Default" (Par défaut). C'est là que se trouvent vos objets enregistrés existants si vous effectuez une mise à niveau à partir d'une version antérieure.

L'espace en cours d'utilisation est toujours visible en bas à gauche, dans la barre de navigation de Kibana. Cette dernière vous permet aussi d'accéder directement à l'IU de gestion de Spaces pour y créer un nouvel espace. Cliquez sur le bouton "Create space" (Créer un espace).

Maintenant, nommez votre espace et personnalisez son avatar :

Au sujet du champ "URL Identifier" (Identificateur d'URL)

Une fois défini, cet identificateur est ajouté à l'URL de Kibana. Vous pouvez personnaliser cette URL au moment où vous créez un espace, mais une fois cela fait, vous ne pouvez plus la modifier.

Comment s'y retrouver ?

L'espace en cours d'utilisation est toujours visible dans la barre de navigation de Kibana. Il vous suffit de cliquer sur l'avatar de l'espace pour afficher un menu qui vous permet de passer à un autre espace.

Supprimer un espace

Pour supprimer un espace, accédez à Management > Spaces (Gestion > Espaces). Sur cet écran, cliquez sur la corbeille en regard de l'espace à supprimer.

Attention ! La suppression d'un espace entraîne la suppression de tous les objets qui y sont enregistrés.Cette opération est irréversible.

Déplacer des objets d'un espace à un autre

Une fonctionnalité d'importation et d'exportation vous permet de déplacer d'un espace à un autre des objets enregistrés. Pour tout savoir sur la question, n'hésitez pas à consulter l'article de blog Migrating to Spaces.

Sécuriser l'accès aux espaces

Les licences Gold et Platinum vous permettent de contrôler les rôles autorisés à accéder aux différents espaces. Pour commencer, accédez à l'écran Management > Roles (Gestion > Rôles).

L'accès aux espaces est régi par le concept du privilège minimum. Trois options sont possibles avec ce privilège :

Une fois que vous avez défini un privilège minimum, vous pouvez personnaliser l'accès à certains espaces.

Exemples de sécurisation des espaces

Exemple : accès total à tous les espaces

Lorsque vous définissez le privilège minimum sur "all" (tous) vous accordez l'accès à tous les espaces. Ce réglage ne vous permet pas de personnaliser l'accès à certains espaces.

Exemple : accès en lecture seule à tous les espaces et accès total à l'espace Marketing

Lorsque vous définissez le privilège minimum sur "read" (lecture), vous accordez l'accès en lecture seule à tous les espaces. Ce réglage vous permet d'accorder un accès total à certains espaces, mais il est impossible de révoquer l'accès accordé pour un espace donné.

Exemple : accès en lecture seule, exclusivement pour l'espace "Executive"

Lorsque vous définissez le privilège minimum sur "none" (aucun) vous interdisez l'accès à tous les espaces. Le privilège accordé pour l'espace "Executive" permet un accès en lecture seule à cet espace.

Afficher tous les privilèges associés aux espaces

Pour connaître l'accès accordé à un rôle pour tous les espaces de Kibana, cliquez sur le lien "View summary of spaces privileges" (Afficher le récapitulatif des privilèges associés aux espaces) :

Pour conclure

Spaces est une nouvelle fonctionnalité tout en puissance. Intégrée à Kibana, elle révolutionne l'organisation de vos tableaux de bord et visualisations. Et ce n'est pas tout : elle vous permet d'en sécuriser l'accès via une interface de gestion des rôles complètement repensée. Pour vous lancer, n'oubliez pas de consulter notre article de blog How to Migrate to Kibana Spaces.

La Suite Elastic propose des fonctions d'analyse de la sécurité qui sont largement utilisées en matière de détection des menaces, de visibilité et de réponse aux incidents. La vitesse et l'échelle en fonction desquelles Elasticsearch est capable d'indexer et de rechercher des informations de sécurité rendent le travail des analystes de sécurité plus efficace, tandis que les tableaux de bord Kibana offrent une visibilité élargie et permettent de débusquer les menaces interactives. En outre, le moteur de machine learning est capable d'automatiser l'analyse d'ensembles complexes de données, et permet ainsi d'identifier des intrus qui seraient autrement passés inaperçus.

Les systèmes populaires de détection d'intrusion (IDS), tels que Wazuh ou Suricata, utilisent une approche basée sur les signatures pour détecter les menaces. Autrement dit, ils comparent les modèles identifiés dans les fichiers, les logs et le trafic réseau à une base de données de modèles connus et associés à des activités malveillantes, puis alertent l'utilisateur lorsqu'une correspondance est établie. Ces systèmes proposent des ensembles de règles utiles pour analyser et mettre en corrélation les données, et génèrent généralement des milliers ou des millions d'alertes par jour dans un environnement de production.

Tendre un vaste filet permet d'intercepter la totalité des événements de sécurité, mais cela implique de devoir trier des milliers (voire des millions) d'alertes par jour. Les fonctionnalités de machine learning d'Elastic permettent de réduire ce bruit de fond en identifiant automatiquement les comportements inhabituels. Ce cas d'utilisation met en évidence la complémentarité des technologies basées sur les anomalies et celles basées sur les signatures, facilitant ainsi la détection des menaces tout en rendant les analyses plus efficaces.

Fréquemment déployé avec la Suite Elastic, Wazuh est un système open source de détection d'intrusion basé sur l'hôte (HIDS). Il permet d'analyser les logs, de monitorer l'intégrité des fichiers, de détecter les rootkits et les vulnérabilités, d'évaluer les configurations et de répondre aux incidents. L'architecture de la solution Wazuh repose sur des agents multiplateformes de transfert léger. Ces agents s'exécutent sur des systèmes monitorés et communiquent avec un serveur centralisé sur lequel les données sont analysées. En outre, ce système propose un plug-in Kibana complet pour gérer la configuration, monitorer les statuts, effectuer des recherches et visualiser les données d'alerte.

D'autre part, Suricata est un moteur open source de détection de menace réseau, capable de détecter les intrusions réseau (NIDS) en temps réel, de prévenir les intrusions en ligne (NIPS), de monitorer la sécurité réseau (NSM) et d'utiliser pcap hors ligne. Suricata examine le trafic réseau en appliquant ses règles et sa langue de signature pour identifier les menaces connues, les violations de politique et les comportements malveillants. La prise en charge des scripts lui permet de détecter des menaces complexes.

Dans cet article de blog, nous nous pencherons sur la détection d'intrusions en intégrant Wazuh et Suricata aux tâches de machine learning d'Elastic pour classer les analyses par ordre de priorité.

Intégration de Wazuh, de Suricata et de la Suite Elastic

Pour les besoins de cet article, nous avons configuré un environnement lab dans lequel les agents Wazuh ont été déployés dans plusieurs serveurs connectés à Internet pour monitorer les logs système et d'applications, l'intégrité des fichiers ainsi que les appels système.

De plus, nous utilisons un capteur Suricata chargé de monitorer le trafic réseau. Ce capteur est généralement configuré de façon à monitorer le trafic au moyen d'un TAP réseau, d'un port de mise en miroir ou d'un port SPAN (Switched Port Analyzer), mais il peut aussi être déployé directement dans vos serveurs.

Pour bénéficier au maximum de ces deux outils, nous avons décidé d'analyser les alertes de Suricata en appliquant les règles de Wazuh pour unifier le format des alertes, effectuer des corrélations (avec des sources de Threat Intelligence, par exemple) et déclencher des réponses automatiques.

Cette intégration a été obtenue en configurant un agent Wazuh pour qu'il puisse lire les fichiers JSON produits par Suricata. Cet agent fait office de collecteur. Il transmet les alertes NIDS de Suricata au serveur Wazuh pour les traiter conformément aux règles d'analyse de logs de Wazuh et ainsi produire de nouveaux événements de sécurité enrichis.

Résultat : les alertes NIDS et HIDS sont envoyées à Elasticsearch par l'intermédiaire de Filebeat (configuré pour lire les alertes Wazuh) et Logstash (également utilisé pour enrichir les données de géolocalisation). C'est là que nous utiliserons les tâches de machine learning pour détecter les anomalies et les comportements inhabituels.

Voici l'exemple d'un déploiement de technologies IDS hôte et réseau combinées à la Suite Elastic :

Détection d'acteurs malveillants grâce aux tâches de machine learning

Après avoir activé la totalité des règles dans notre environnement lab, nous avons constaté que notre agent Wazuh produit entre 4 000 et 10 000 alertes IDS par jour pour un seul serveur Web connecté à Internet. Ces alertes sont pour la plupart liées à des attaques Web, à des échecs d'authentification, à des problèmes de configuration (détectés grâce aux vérifications de sécurité renforcée), à des variations de l'intégrité des fichiers ou à des logiciels vulnérables.

Pour faciliter le travail des analystes de sécurité, des métadonnées, telles que les valeurs de niveau ou les groupes, enrichissent les alertes IDS de Wazuh pour qu'elles puissent être filtrées par priorité ou par type. En outre, le plug-in Kibana de Wazuh propose des tableaux de bord préconfigurés qui contiennent des informations utiles sur le statut de l'agent, la configuration et les alertes. Examinez la capture d'écran ci-dessous :

L'information fournie par Wazuh est certes utile, mais ne met pas le doigt sur les comportements inhabituels. C'est là que les tâches de machine learning d'Elastic entrent en scène.

Le machine learning d'Elastic nous offre la possibilité de créer plusieurs types de "tâches". La tâche est l'élément de base de l'analyse par le machine learning. Dans le cas qui nous intéresse, nous avons décidé de créer une "analyse de population". Nous avons demandé au moteur de machine learning de construire un modèle de référence du comportement type des adresses IP sur une période donnée pour identifier celles qui se comportent de façon anormale par rapport au reste de la population.

Pour être plus précis, nous souhaitons identifier les adresses IP sources qui, lorsqu'elles sont comparées à toutes les autres adresses IP, sont à l'origine d'un nombre inhabituellement élevé de types d'alertes. La création de tableaux d'agrégation ne suffit pas pour obtenir un tel résultat, car les anomalies se produisent à un moment précis que notre analyste de sécurité ne connait pas. Aussi, nous disposons de plus de 60 jours d'alertes (nous avons détecté des attaques qui duraient moins de deux minutes).

Suite à cette analyse de population, nous avons identifié plusieurs comportements anormaux (sous la forme d'une liste d'adresses IP) que nous avons décidé d'analyser. Nous avons utilisé l'"Anomaly Explorer" pour savoir quand chacun de ces acteurs potentiellement malveillants a attaqué notre environnement.

Analyse d'une tentative d'intrusion

Attardons-nous sur l'une des adresses IP identifiées par la tâche de machine learning. Cette adresse IP a été à l'origine de plusieurs alertes NIDS et HIDS en moins d'une minute. Cela a déclenché une action Wazuh automatique qui a bloqué l'adresse IP dans le pare-feu local de notre serveur Web.

Comme l'illustre la capture d'écran ci-dessus, le NIDS Suricata a détecté du trafic malveillant provenant des adresses IP spécifiées. Le trafic entrant a permis de vérifier quatre règles et est à l'origine des alertes suivantes :

• ET DROP Dshield Block Listed Source group 1
• ET CINS Active Threat Intelligence Poor Reputation IP group 77
• SURICATA HTTP URI terminated by non-compliant character
• SURICATA HTTP METHOD terminated by non-compliant character

Les deux premières règles appartiennent à l'ensemble de règles Emerging Threats. Elles indiquent que l'adresse IP source a mauvaise réputation d'après les sources de Threat Intelligence (TI) : Dshield et Active Threat Intelligence.

De plus, deux autres signatures ont détecté une activité HTTP anormale provenant de la même adresse IP source, probablement dans le cadre d'une phase d'analyse durant laquelle l'assaillant recueille des informations pour identifier les vulnérabilités potentielles.

Le composant HIDS de Wazuh a également généré différentes alertes suite à l'analyse des logs d'accès au serveur Web. Cette approche qui se différencie complètement de l'inspection des paquets réseau a permis de générer les alertes suivantes :

• IP address found in AlienVault reputation database
• Host Blocked by firewall-drop.sh Active Response
• Host Unblocked by firewall-drop.sh Active Response

La première alerte indique que l'adresse IP source est également signalée par une autre source de Threat Intelligence (TI) : la base de données de réputation IP AlienVault OTX.

Les deux alertes suivantes ont été déclenchées par le module Wazuh Active Response qui, suite aux alertes déjà mentionnées, a automatiquement ajouté une règle de pare-feu pour bloquer le trafic provenant de cette adresse IP source pendant exactement 60 secondes (ceci est configurable). Cette action a suffi à bloquer les activités d'analyse de l'acteur malveillant qui a immédiatement cessé sa tentative d'intrusion.

Conclusion

Avec des technologies comme Wazuh, Suricata et le machine learning d'Elastic, l'utilisation des techniques de détection d'intrusion basées sur les signatures et les anomalies permettent de simplifier la détection des menaces et de rendre leur analyse plus efficace.

D'autre part, l'intégration d'un IDS hôte (pour monitorer les systèmes au niveau de l'hôte) et d'un IDS réseau (pour inspecter le trafic réseau) permet aussi d'améliorer la détection des menaces et la visibilité en matière de sécurité. Wazuh simplifie tout cela, car il permet d'intégrer les systèmes IDS hôte et réseau à la Suite Elastic, et est en mesure de fournir des mécanismes pour déclencher des réponses automatiques et bloquer des attaques en temps réel.

Canvas propose actuellement une sélection d’environ vingt éléments intégrés qu’il est possible d’ajouter aux présentations (voir le blog sur la prise en main pour obtenir une liste complète). Dans cet article, nous allons nous pencher sur deux d'entre eux : Data Table (Table de données) et Debug (Débogage).

	Data Table (Table de données) Une table extrêmement flexible, dynamique et prête à l’emploi qui prend en charge le défilement, la pagination et la personnalisation du langage CSS.
	Debug (Débogage) Donne accès aux données JSON sous-jacentes, pour une analyse plus précise des problèmes susceptibles de se produire.

Plus spécifiquement, Canvas nous servira à créer une table de données que nous connaissons bien : un tableau des vols dans un aéroport.
Voici le résultat du produit fini :

Exigences et révision

Nous allons partir des hypothèses indiquées dans le blog sur la prise en main et supposer que vous disposez des éléments suivants :

1. Elasticsearch et Kibana (à partir de la version 6.4)
2. Canvas (Canvas est intégré dans Kibana à partir de la version 6.5)

Installation de l’échantillon de données

Dans ce tutoriel, nous allons utiliser un échantillon de données fourni par Elastic, portant sur des données de vol.

Remarque : Cet échantillon de données est disponible dans Kibana à partir de la version 6.4.

Accédez à Kibana :

1. Cliquez sur la page d’accueil principale de "Kibana" dans la barre latérale.
2. En bas de la section "Add Data to Kibana" (Ajouter des données à Kibana), cliquez sur le lien "Load a data set and a Kibana dashboard" (Charger un ensemble de données et un tableau de bord Kibana).
3. Sur la mosaïque "Sample flight data" (Échantillon de données de vol), cliquez sur "Add" (Ajouter).

Référence rapide

La table ci-dessous fournit des informations sur l’échantillon de données de vol venant d’être installé. Nous utiliserons les champs indiqués en gras et soulignés ultérieurement dans cette activité. Mais n’hésitez pas à tester les autres aussi !

Création d’un tableau des vols

Création

Pour commencer, nous devons créer une présentation, puis ajouter une table contenant nos données.

Création d'une présentation Canvas

1. Accédez à Kibana.
2. Cliquez sur l'onglet "Canvas" dans la barre latérale.
3. Cliquez sur "Create workpad" (Créer une présentation).
4. Donnez un nom unique à la nouvelle présentation.

Création d’un élément Data Table (Table de données)

1. Cliquez sur le bouton "Add element" (Ajouter un élément).
2. Choisissez l’élément "Data Table" (Table de données).
1. CONSEIL : Lorsque vous créez un élément pour la première fois, celui-ci intègre des données de démonstration, afin que vous puissiez vous lancer sans attendre.
3. Dans le panneau d'édition situé à droite, sélectionnez l'onglet "Data" (Données).
4. Cliquez sur "Change your data source" (Changer de source de données).
5. Sélectionnez "Elasticsearch SQL".
6. Dans l'éditeur de requête SQL, saisissez :

SELECT
  DestCityName AS Destination,
  timestamp AS Time,
  Carrier AS Airline,
  FlightNum AS Flight,
  FlightDelayType AS Status,
  Cancelled
FROM
  kibana_sample_data_flights

Remarque : Vous avez peut-être remarqué que notre échantillon de données n’indique aucun champ concernant le numéro de porte d’embarquement. C’est parce que nous allons utiliser un générateur de numéros aléatoires un peu plus tard pour créer la colonne correspondante.

7. Cliquez sur "Save" (Enregistrer).
8. Maintenant, vous disposez d’une table de données similaire à celle-ci :

CODE

Nous avons à présent une table contenant nos données. Toutefois, elle n’est pas présentée comme nous le voudrions. Pour y remédier, nous allons devoir plonger dans le code qui se cache derrière.

Ajustement du format de la colonne Time (Heure)

1. Vérifiez que la table de données est sélectionnée.
2. En bas à droite de l'écran, cliquez sur la touche bascule "Expression editor" (Éditeur d'expression).
3. Dans l’éditeur d’expression, le code suivant est affiché :

filters

| essql
  query="SELECT
  DestCityName AS Destination,
  timestamp AS Time,
  Carrier AS Airline,
  FlightNum AS Flight,
  FlightDelayType AS Status,
  Cancelled
FROM
  kibana_sample_data_flights"

| table

| render

Décomposition -- Ce code se répartit en quatre sections principales :

1. Filtres : Si nous ajoutions un élément Time Filter (Filtre d’heure) à cette présentation, les données arrivant dans l’élément Data Table (Table de données) passeraient tout d’abord par l’élément Time Filter (Filtre d’heure), et seules les données restantes seraient affichées. Si nous supprimons cette ligne, notre élément Data Table (Table de données) ne serait plus affecté par les éléments de filtre ajoutés à la présentation. Cela peut s’avérer utile dans certaines situations.
2. Source de données : Dans le cas présent, nous utilisons la source de données Elastic SQL. C’est également ici que nous pouvons également consulter et modifier notre requête SQL.
3. Élément : Cette ligne définit le type d’élément affiché dans la présentation. Si vous vous sentez d’humeur à faire des expériences, petite suggestion : remplacez "table" par "shape", puis cliquez sur "Run" (Exécuter) en bas à droite et observez ce qui se passe. Juste un point : n’oubliez pas de rétablir l’élément d’origine !
4. Rendu : Avec cette ligne, vous pouvez personnaliser l’apparence d’un élément donné. Tout à l’heure, nous ajouterons du langage CSS personnalisé pour donner du style à notre table de données.
1. Nous devons modifier les données avant qu’elles ne s’affichent dans la fonction d’élément "table". Nous allons donc ajouter une nouvelle fonction "mapColumn" entre la fonction de source de données "essql" et la fonction d’élément "table". Cette nouvelle fonction nous permettra tout simplement de modifier les valeurs d’une colonne donnée. La colonne que nous voulons modifier est la colonne "Time" (Heure). Pour cela, nous ajoutons le code ci-dessous à la ligne 12 :

...
FROM kibana_sample_data_flights"
<b style="background-color:#ffae5b"><i>| mapColumn Time fn={}</i></b>
| table
...

5. Canvas dispose de nombreuses fonctions intégrées utiles, notamment la fonction "formatdate". Nous voulons afficher l’heure au format "hh:mm A". Pour cela, nous ajoutons à la ligne 12 :

...
FROM kibana_sample_data_flights"
| mapColumn Time fn={ <b style="background-color:#ffae5b"><i>formatdate “hh:mm A”</i></b> }
| table
...

6. En bas à droite de l'éditeur d'expression, cliquez sur "Run" (Exécuter).
7. Oups... Il y a une erreur ! Il est temps d’attaquer le débogage !

Petit aparté sur le débogage (à lire absolument !)

Nous reviendrons au code d’ici quelques minutes, mais nous devons tout d’abord apprendre le débogage avec Canvas.

Identification de l’erreur

1. Dans l’élément table, cliquez sur le symbole d’avertissement.
2. La cause de l’erreur s’affiche, comme dans l’image ci-dessous :

3. On dirait que la fonction "mapColumn" essaye d’afficher nos données d’horodatage sous forme de nombre. Cela est dû au fait que la fonction "formatdate" que nous utilisons demande à ce que les horodatages s’affichent sous forme numérique (p. ex. millisecondes UTC).
4. Mais au fait... sous quel format les horodatages se trouvent-ils actuellement ? Pour le déterminer, ajoutons un élément "debug" (débogage).

Ajout d’un élément Debug (Débogage)

1. Cliquez sur "Add element" (Ajouter un élément).
2. Sélectionnez l’élément "Debug" (Débogage).
3. Dans le panneau d'édition situé à droite, sélectionnez l'onglet "Data" (Données).
4. Cliquez sur "Change your data source" (Changer de source de données).
5. Sélectionnez "Elasticsearch SQL".
6. Dans l'éditeur de requête SQL, saisissez :

SELECT
  DestCityName AS Destination,
  timestamp AS Time,
  Carrier AS Airline,
  FlightNum AS Flight,
  FlightDelayType AS Status,
  Cancelled
FROM
  kibana_sample_data_flights

7. Cliquez sur "Save" (Enregistrer).
8. Dans l’élément Debug (Débogage), nous pouvons voir que le type du champ "Heure" est "date", et que la première entrée a pour format : 2018-11-05T00:00:00.000Z
   
9. Heureusement, Canvas dispose d’une fonction intégrée qui peut convertir les types "date" en valeurs numériques en millisecondes UTC.
10. Sélectionnez à nouveau la table de données. Dans l’éditeur d’expression, ajoutez la fonction "date" au code, de la façon suivante :

| mapColumn Time fn={<b style="background-color:#ffae5b"><i> date | </i></b>formatdate “hh:mm A” }

11. Cliquez sur “Run” (Exécuter).
12. Désormais, la table de données affiche les horodatages au format approprié.

CONSEIL : Il n’est pas nécessaire d’ajouter un élément Debug (Débogage) à chaque fois. Dans l’éditeur d’expression d’un élément, il suffit d’ajouter | render as="debug" pour accéder aux données json de cet élément. Toutefois, il peut être pratique de garder un élément Debug (Débogage) dédié pour référence lorsque vous travaillez.

Maintenant, revenons à nos moutons !

CODE (suite)

À présent, ajoutons une colonne "Gate" (Porte d’embarquement). Étant donné que notre ensemble de données ne contient aucune donnée sur les portes d’embarquement, nous allons tout simplement en générer de façon aléatoire avec certaines fonctions puissantes intégrées dans Canvas.

Ajout de données sur les portes d’embarquement

1. Pour ajouter une nouvelle colonne, rien de plus simple : il suffit d’ajouter une autre entrée dans notre requête SQL. Nous allons dupliquer les données "FlightNum" et appeler la nouvelle colonne "Gate" (Porte d’embarquement).
2. Dans le panneau d’éditeur à droite, cliquez sur l’onglet "Data" (Données), et dans l’éditeur SQL, ajoutez la ligne suivante :

SELECT
  DestCityName AS Destination,
  timestamp AS Time,
  Carrier AS Airline,
  FlightNum AS Flight,
  <b style="background-color:#ffae5b"><i>FlightNum AS Gate,</i></b>
  FlightDelayType AS Status,
  Cancelled
FROM
  kibana_sample_data_flights

3. Cliquez sur "Save" (Enregistrer).
4. Dans l’éditeur d’expression, nous allons ajouter une autre fonction "mapColumn" sous la première. Cette fois-ci, nous allons modifier la colonne "Gate" (Porte d’embarquement) :

...
| mapColumn Time fn={ date | formatedate “hh:mm A” }
<b style="background-color:#ffae5b"><i>| mapColumn Gate fn={}</i></b>
| table
...

5. Pour obtenir des numéros réels de porte d’embarquement, nous devons générer des numéros aléatoires compris entre 1 et 100. Pour nous aider, Canvas propose des fonctions mathématiques intégrées très pratiques. Nous allons nous servir de la fonction "random". Seul bémol : cette fonction génère des numéros aléatoires avec de longues décimales, et ce n’est pas du tout ce que nous voulons. Nous allons donc y ajouter une deuxième fonction, "round", qui permettra d’arrondir les numéros générés. Voici à quoi notre code ressemble :

| mapColumn Gate fn={ <b style="background-color:#ffae5b"><i>math "round(random(0,100),0)"</i></b> }

6. Cliquez sur “Run” (Exécuter).
7. La nouvelle colonne "Gate" s’affiche avec des numéros de porte d’embarquement générés de façon aléatoire :

Combinaison de colonnes

L’idéal serait que la colonne "Cancelled" (Annulé) soit combinée avec la colonne "Status" (Statut). Ainsi, le statut "Cancelled" (Annulé) serait affiché à chaque fois que la valeur serait "true" (vrai).

1. Vérifiez que l’élément Data Table (Table de données) est sélectionné et que l’éditeur d’expression est ouvert.
2. Nous devons ajouter une autre fonction "mapColum", mais cette fois-ci, pour la colonne "Status" (Statut).

...
| mapColumn Gate fn={math "round(random(1,100),0)"}
<b style="background-color:#ffae5b"><i>| mapColumn Status fn={}</i></b>
| table
...

3. Ensuite, nous devons nous vérifier si le champ (ou la "cellule") de la colonne "Cancelled" (Annulé) a la valeur "true".

| mapColumn Status fn={<b style="background-color:#ffae5b"><i>if {getCell "Cancelled" | eq true}</i></b>}

4. Maintenant, nous voulons que la valeur de la colonne "Status" (Statut) soit affichée sous forme de chaîne, "Cancelled" (Annulé), lorsque la condition est vraie.

| mapColumn Status fn={if {getCell “Cancelled” | eq true}<b style="background-color:#ffae5b"><i> then=”Cancelled” </i></b>}

5. Si nous cliquons sur "Run" (Exécuter), nous constatons que la chaîne "Cancelled" (Annulé) est bien mappée à la colonne "Status" (Statut). Par contre, nous obtenons aussi une valeur "null" dans la colonne "Status" lorsque la condition n’est pas vraie.

6. Ce qui nous amène à la dernière étape : indiquer à Canvas de conserver la valeur d’origine de la colonne "Status" pour tout ce qui n’est pas "Cancelled" (Annulé).

| mapColumn Status fn={if {getCell “Cancelled” | eq true} then=”Cancelled”<b style="background-color:#ffae5b"><i> else={getCell "Status"}</i></b>}

7. Cliquez sur “Run” (Exécuter).
8. À présent, la colonne "Status" (Statut) est correctement combinée avec la colonne "Cancelled" (Annulé).

Suppression d’une colonne

Maintenant que la colonne "Status" (Statut) contient toutes les informations que nous souhaitons, nous n’avons plus besoin d’afficher la colonne "Cancelled" (Annulé) (même si nous la conservons de façon sous-jacente). Aussi, supprimons la colonne "Cancelled" (Annulé).

1. Vérifiez que l’élément Data Table (Table de données) est sélectionné et que l’éditeur d’expression est ouvert.
2. Canvas dispose d’une fonction "columns" qui permet d’inclure ou d’exclure des colonnes. Dans le cas présent, nous souhaitons exclure la colonne "Cancelled" (Annulé). Aussi, ajoutons la ligne de code suivante :

...
| mapColumn Status fn={if {getCell “Cancelled” | eq true} then=”Cancelled” else={getCell “Status”}}
<b style="background-color:#ffae5b"><i>| column exclude=”Cancelled”</i></b>
| table
...

3. Cliquez sur “Run” (Exécuter).
4. Désormais, la colonne "Cancelled" (Annulé) n’est plus affichée dans l’élément Data Table (Table de données), même si nous continuons à utiliser les données de cette colonne de manière sous-jacente.

Personnalisation

Maintenant que nous avons les données comme nous le voulions, personnalisons l’apparence de notre présentation.

Définition de la couleur de l’arrière-plan

1. Vérifiez qu’aucun élément de la présentation n’est sélectionné.
2. Dans le panneau d’édition à droite de la page, cliquez sur le sélecteur de couleur "Page Background" (Arrière-plan de la page) et définissez la valeur sur #0276fd.

Suppression de la pagination

1. Sélectionnez l’élément Data Table (Table de données).
2. À droite de la page, dans le panneau d’édition, sélectionnez l’onglet "Display" (Affichage).
3. Dans le panneau "Table Style" (Style du tableau), cliquez sur le bouton "+".
4. Dans la liste déroulante, sélectionnez "Pagination".
5. Cliquez sur la touche bascule pour désactiver la pagination.

Définition du nombre de lignes du tableau

1. À nouveau, cliquez sur le bouton "+" dans le panneau "Table Style" (Style du tableau).
2. Dans la liste déroulante, sélectionnez "Rows per page" (Lignes par page).
3. Augmentez le nombre jusqu’à 25.
4. En réalité, nous voulons 18 lignes. Ouvrez l’éditeur d’expression de l’élément Data Table (Table de données) et modifiez la valeur "perPage" sur 18.

| table paginate=false perPage=<b style="background-color:#ffae5b"><i>18</i></b>

5. Cliquez sur “Run” (Exécuter).
6. Développez l’élément Data Table (Table de données) pour pouvoir afficher les 18 lignes.

Style du texte du tableau

1. À nouveau, cliquez sur le bouton "+" dans le panneau "Table Style" (Style du tableau).
2. Cette fois-ci, sélectionnez "Text Settings" (Paramètres de texte).
3. Mettez le texte en gras et appliquez la couleur blanche.

Style de l’en-tête du tableau

1. Nous voulons appliquer un style particulier à l’en-tête du tableau afin qu’il ressorte par rapport aux lignes. Toutefois, nous avons atteint les limites du panneau "Table Style" (Style du tableau). C’est là que nous allons faire intervenir le langage CSS personnalisé.
2. Pour cela, cliquez sur le bouton "+" du panneau "Element Style" (Style de l’élément).
3. Dans le menu déroulant, sélectionnez "CSS".
4. Supprimez le contenu de l’éditeur CSS et collez-y le code suivant :

canvasDataTable__th { text-decoration: underline; background-color: #d0e9ff; color: black;}

5. Cliquez sur “Apply stylesheet” (Appliquer la feuille de style).
6. Votre en-tête de tableau s’affiche désormais avec une couleur bleu clair en arrière-plan et un texte noir souligné.

Style des lignes du tableau

1. Nous voulons que les couleurs des lignes soient alternées. Là encore, nous allons utiliser un langage CSS personnalisé.
2. Collez le code ci-dessous dans l’éditeur CSS :

.canvasDataTable__tbody>:nth-child(even) {
background-color: #2a2a50;
}

.canvasDataTable__tbody>:nth-child(odd) {
background-color: #5f67af;
}

3. Cliquez sur “Apply stylesheet” (Appliquer la feuille de style).
4. Ajustez la largeur de l’élément Data Table (Table de données) par rapport à celle de la présentation.
5. Désormais, les couleurs s’affichennt de façon alternée, comme dans l’image ci-dessous :

Ajout d’un titre

1. Cliquez sur "Add element" (Ajouter un élément).
2. Sélectionnez l’élément "Markdown".
3. Supprimez tout le texte de l’éditeur "Markdown content" (Contenu Markdown) situé à droite de l’écran.
4. À la place, entrez "Departures" (Départs).
5. Cliquez sur "Apply" (Appliquer).
6. Redimensionnez l’élément "Markdown" et placez-le au centre de l’écran.
7. Dans le panneau "Markdown" du volet d’édition situé à droite, cliquez sur le bouton "+".
8. Dans le menu déroulant, sélectionnez "Text Settings" (Paramètres de texte).
9. Définissez le texte comme suit :
1. Taille : 48
2. Police : Gras
3. Alignement : Centré
4. Couleur : Blanc
10. Voilà ! Maintenant, vous avez une présentation qui ressemble à un véritable tableau de vols !

Code complet

Voici le code complet du tableau de données que l’on trouve dans l’éditeur d’expression :

filters
| essql
  query="SELECT
  DestCityName AS Destination,
  timestamp AS Time,
  Carrier AS Airline,
  FlightNum AS Flight,
  FlightNum AS Gate,
  FlightDelayType AS Status,
  Cancelled
FROM
  kibana_sample_data_flights
"
| mapColumn "Time" fn={date | formatdate "hh:mm A"}
| mapColumn "Gate" fn={math "round(random(1,100),0)"}
| mapColumn "Status" fn={if {getCell "Cancelled" | eq true} then="Cancelled" else={getCell "Status"}}
| columns exclude="Cancelled"
| table paginate=false perPage=18
 font={font family="'Open Sans', Helvetica, Arial, sans-serif" size=14 align="left" color="#FFFFFF" weight="bold" underline=false italic=false}
| render
 css=".canvasDataTable__th { text-decoration: underline; background-color: #d0e9ff; color: black;}
.canvasDataTable__tbody>:nth-child(even) {
background-color: #2a2a50;
}
.canvasDataTable__tbody>:nth-child(odd) {
background-color: #5f67af;
}"

Liens vers d'autres ressources utiles

C'est aussi simple que ça. Vous venez de parcourir plusieurs exemples d'utilisation d'éléments Data Table (Table de données) et Debug (Débogage) dans Canvas. N'hésitez pas à ajouter d'autres éléments à votre présentation et à essayer les différentes fonctionnalités de Canvas.

Nous vous suggérons aussi de consulter d'autres articles de blog sur Canvas :

• Prise en main de Canvas dans Kibana
• Éléments Metric (Indicateur) et Markdown

Image de la bannière : L’"écran d’aéroport Miami" de MPD01605 est concédé sous licence par CC BY 2.0

Lorsque nous avons lancé Elastic Cloud Enterprise (ECE) pour la première fois il y a plus d'un an, nous étions tous très enthousiastes et prudemment optimistes. Nous avions conçu ECE pour vous permettre de provisionner, gérer, monitorer et scaler l'ensemble de vos déploiements Elasticsearch depuis une seule et même console centralisée qui rime avec simplicité. Nous ne connaissions que trop bien les défis associés au développement d'une solution conçue pour gérer d'énormes déploiements Elasticsearch – et pour cause : nous avions rencontré les mêmes au moment ou nous mettions en place Elasticsearch Service.

Nous avons développé ECE sur exactement la même base de code qu'Elasticsearch Service. La seule différence est que nous l'avons packagée de manière à ce que les utilisateurs puissent déployer ECE où bon leur semble, tout en exploitant les mêmes logiciels éprouvés et les mêmes ensembles de fonctionnalités que ceux qui servent à gérer des milliers de clusters hébergés chez différents fournisseurs de services cloud.

Mais nous n'avons pas tardé à découvrir qu'ECE avait autant de succès auprès de grandes entreprises gérant une multitude de clusters qu'auprès d'entreprises dont la charge de travail est moindre. Tout le monde avait visiblement une bonne raison d'opter pour ECE.

L'année qui s'est écoulée nous a donné l'occasion d'apprendre des utilisateurs d'ECE, d'améliorer notre offre et de comprendre comment elle devait évoluer. Nous sommes donc ravis d'annoncer le lancement d'une version revue, corrigée et plus performante que jamais : ECE 2.0.

Cette version fait le plein d'avantages. Nous ne résistons pas au plaisir de vous dévoiler quelques-unes de nos fonctionnalités préférées. 

N'importe quel cas d'utilisation à n'importe quelle échelle

Avec ECE 2.0, l'une de nos priorités était la prise en charge de cas d'utilisation plus complexes et de plus grande envergure, comme le logging et les données de séries temporelles. Nous voulions aussi accorder un plus grand contrôle aux administrateurs concernant le déploiement et la configuration de ces cas d'utilisation par le propriétaire du cluster. Voici les principales fonctionnalités qui ont rendu tout cela possible.

Posez vos balises et faites comme chez vous

Les balises sont des paires clé-valeur ajoutées à chaque machine hébergeant l'allocator. Il s'agit d'un concept bien connu des professionnels du cloud et de l'orchestration de conteneurs, où le couplage se fait grâce à des étiquettes et des sélecteurs. ECE 2.0 permet désormais l'ajout de balises à l'allocator : autrement dit, vous pouvez maintenant intégrer des balises arbitraires à un allocator afin d'en faciliter la classification. Ces balises peuvent indiquer à quelle équipe appartient l'allocator, les caractéristiques du hardware sous-jacent auquel il est associé et, d'une manière générale, tout autre identificateur permettant de le classifier. Ces balises servent ensuite à associer les nœuds de cluster et les instances Kibana à l'allocator le mieux indiqué pour les héberger. 

Configuration d'instance personnalisée

Dans les premières versions d'ECE, tous les nœuds Elasticsearch étaient identiques. C'est-à-dire qu'ils partageaient la même configuration et les mêmes rôles. Par conséquent, lorsqu'un utilisateur voulait gérer chaque type de nœud séparément (ce qui est nécessaire dans bien des cas d'utilisation), les possibilités étaient limitées. 

Avec ECE 2.0, vous pouvez désormais déployer, gérer et scaler chaque composant de votre cluster indépendamment des autres. Les configurations d'instance disponibles avec ECE 2.0 vous permettent de définir les rôles à activer sur chaque nœud, de configurer des filtres qui associent un nœud à une machine hébergeant l'allocator grâce aux balises précédemment citées, et de définir le ratio RAM-stockage en fonction de l'utilisation prévue pour le nœud.

Autre nouveauté : les modèles de déploiement

Les nouveaux modèles de déploiement personnalisables font sans conteste partie des outils les plus polyvalents de la console. En effet, un modèle de déploiement permet de regrouper un ensemble de configurations d'instance associés à différents types de nœuds, ce qui sert de structure à votre cluster. Avec les modèles de déploiement, vous pouvez définir les valeurs et les configurations par défaut de chaque type de nœud (taille du nœud, nombre de zones de disponibilité, etc.).

Vous pouvez aussi créer vos propres modèles et les configurer en fonction de votre cas d'utilisation, de votre équipe, ou de tout autre élément nécessitant un ensemble unique d'allocators. Lorsque vous créez un nouveau cluster, les modèles de déploiement vous proposent en outre des paramètres prédéfinis, ce qui vous permet de rationaliser votre processus de déploiement à chaque étape.

Gérer les index des séries temporelles avec la Suite Elastic ? Une fonctionnalité dont vous ne pourrez plus vous passer.

L'ingestion des données de séries temporelles (messages de log, par exemple) fait partie des cas d'utilisation fréquents avec la Suite Elastic. Dans ces cas-là, nous recommandons souvent de recourir à une architecture hot-warm, notamment pour les déploiements de grande envergure. 

Avec ECE 2.0, vous disposez d'un modèle d'architecture hot-warm intégré, qui vous permet de configurer deux niveaux de nœuds de données. Les nœuds de données hot servent ainsi à ingérer les données et à stocker les index les plus récents (ceux-ci étant plus susceptibles d'être exploités pour les recherches, ils doivent être déployés sur des hôtes plus puissants, qui affichent de bonnes performances E/S). Les nœuds de données warm, quant à eux, sont prévus pour le stockage et la conservation de grands volumes de données à long terme. Dans la majorité des cas, les anciennes données sont immuables et l'accès à ces dernières est beaucoup moins fréquent. Ce qui signifie que vous pouvez les stocker sur des machines hébergeant des allocators plus économiques. Moins performants, ceux-ci s'avèrent aussi beaucoup moins onéreux pour le stockage des données.

Pour définir le moment où les index doivent passer du niveau hot au niveau warm, ECE 2.0 prévoit une fonctionnalité de curation d'index intégrée qui vous permet de configurer ces périodes. Vous avez l'esprit tranquille. ECE se charge du reste.

Des fonctionnalités qui convergent pour répondre à votre cas d'utilisation

Ce n'est un secret pour personne : la Suite Elastic est polyvalente et peut prendre en charge une multitude de cas d'utilisation – depuis l'analyse des logs et de la sécurité jusqu'à la recherche, en passant par les indicateurs, et plus encore. Lorsqu'ils procèdent à un déploiement, les utilisateurs peuvent se rendre compte que certains cas d'utilisation sont plus performants lorsqu'ils sont associés à un hardware donné. De plus, même au sein d'un même cluster, il peut être judicieux d'exécuter chaque type de nœud sur une machine hébergeant l'allocator qui soit associée au type de hardware approprié. Par exemple, il est possible que vos instances Kibana affichent des performances optimales lorsque vous les exécutez sur un hôte disposant d'une mémoire RAM importante, mais d'un stockage limité ; alors que vos nœuds Machine Learning, sans nécessiter un stockage important, soient plus performants sur un hôte disposant d'un processeur un peu plus puissant. 

Les fonctionnalités de host tagging, de configurations d'instance et de modèle de déploiement intégrées à ECE 2.0 vous permettent de gérer vos clusters de manière bien plus flexible, tout en vous offrant un plus grand contrôle. Sans compter qu'elles rendent possible la prise en charge native de différents types de hardware, optimisant ainsi leur utilisation, tout en améliorant les performances et en réduisant les coûts. 

Il existe mille et une manière de capitaliser sur ces fonctionnalités dans votre cas d'utilisation. Nous y consacrerons d'ailleurs un post prochainement pour les examiner de plus près. De même, nous verrons comment implémenter la configuration adaptée à vos besoins à travers quelques exemples.

Libérez toute la puissance de Machine Learning

Comme nous l'avons vu plus haut au paragraphe traitant des configurations d'instance, les précédentes versions d'ECE ne permettaient pas aux utilisateurs d'activer des rôles différents sur chaque nœud du cluster. Cela empêchait la prise en charge de Machine Learning dans les clusters hébergés, puisque l'exécution de tâches Machine Learning dans un environnement de production nécessitait des nœuds Machine Learning. 

Avec l'arrivée des configurations d'instance, vous pouvez maintenant configurer des nœuds Machine Learning dédiés, que vous pouvez gérer et scaler indépendamment des autres nœuds du cluster.

Vous pouvez aussi exploiter les configurations d'instance pour créer des nœuds maîtres dédiés, nécessaires à la prise en charge des grands clusters ou des nœuds d'ingestion dédiés. Cela s'avère particulièrement pratique si le traitement génère des durées d'ingestion importantes, et que vous voulez scaler votre couche d'ingestion à mesure que vous ajoutez des pipelines pour enrichir vos données.

Compatibilité avec la dernière version de Docker sur Ubuntu

Vous pouvez maintenant installer ECE sur Ubuntu 16.04 avec Docker 18.03. Voilà une importante nouveauté, puisque ECE 1.x n'était compatible qu'avec Docker 1.11, qui a officiellement atteint sa fin de vie il y a un certain temps. Vous pouvez maintenant mettre à niveau le moteur Docker sur tous les nœuds ECE.

À l'avenir, nous annoncerons la prise en charge des nouvelles versions de Docker de façon plus régulière, de manière à nous aligner sur la version LTS de Docker, qui sort tous les deux ans.

Authentification SAML pour les déploiements

ECE proposait déjà des intégrations de sécurité et d'authentification, telles que LDAP/AD, pour tous vous déploiements. Avec ECE 2.0, nous passons à l'étape supérieure avec l'authentification SAML.

Compatibilité de la mise à niveau

Bien qu'ECE 2.0.0 soit une version importante, toutes les fonctionnalités décrites ci-dessus sont rétrocompatibles. Cela signifie que vous pouvez mettre à niveau ECE 1.x vers ECE 2.0.0, tout en bénéficiant de l'ensemble des avantages de la nouvelle version.

Une interface plus conviviale

Côté console utilisateur, nous avons apporté beaucoup d'améliorations pour vous faciliter la vie. En voici quelques-unes :

• Exit, les clusters. Bienvenue aux déploiements : avec la prise en charge d'autres produits de la Suite Elastic, il était plus logique d'employer un terme plus générique pour désigner ce que vous créez avec ECE. Bien que les clusters Elasticsearch soient des éléments essentiels de tout déploiement, le terme "déploiement" reflète mieux la façon dont la Suite Elastic est gérée dans ECE.
• Workflow "Create Deployment" : un nouveau workflow "Create Deployment" était nécessaire à la prise en charge des configurations d'instance et des modèles de déploiement. Ce nouveau workflow vous permet d'affiner vos configurations, d'enregistrer les valeurs et configurations par défaut de vos déploiements et de sélectionner le modèle de votre choix pour en créer de nouveaux.
• Simplification de la navigation : nous avons revu la navigation pour vous permettre de vous y retrouver plus facilement dans l'IU et de modifier vos déploiements plus simplement. De même, la page d'aperçu de tous les déploiements et l'aperçu détaillé d'un déploiement donné ont fait peau neuve : ils affichent maintenant les informations et les actions possibles de manière plus pertinente.
• Nous pensons aussi à ceux qui sont plutôt du soir : si vous aimez travailler lorsque le soleil se couche, ECE vous permet de définir un "thème nuit" plus reposant pour les yeux.

Et ce ne sont là que quelques-unes des nouvelles fonctionnalités que vous réserve ECE 2.0. Pour en savoir plus, reportez-vous aux notes de publication. Envie de juger ECE 2.0 par vous-même ? Lancez-vous grâce à notre essai gratuit de 30 jours et dites-nous ce que vous en pensez.

Les idées que la plupart des gens se font de l'agriculture sont dépassées. "Ils se figurent quelqu'un en salopette sur un tracteur", indique Tim Arp, ingénieur d'exploitation en chef chez John Deere Intelligent Solutions Group (ISG). "Alors qu'aujourd'hui, tout repose sur les données." Qu'il s'agisse de données GPS qui guident les équipements autonomes, d'indicateurs sur la performance des machines, voire de données de mise en culture, ces données représentent une quantité considérable d'informations qui se répandent dans les systèmes de John Deere.

Alors que de nombreuses personnes associent l'entreprise à ses innombrables "engins verts", les applications de données de John Deere sont tout aussi indispensables pour les agriculteurs. Aujourd'hui, avec John Deere, les exploitants agricoles peuvent accéder à des applications télématiques de gestion des machines et de l'agronomie qui leur permettent de maximiser les rendements et de gérer les coûts.

Lors de la conférence Elastic{ON} Tour Chicago, M. Arp est revenu sur JDLink, leur première application mobile. Installée à l'origine sur 25 serveurs, JDLink permettait aux agriculteurs de facilement recueillir les données d'engins agricoles, tels que des moissonneuses-batteuses. Ces données comprenaient les positions géographiques et des indicateurs d'état des machines. À mesure que l'application grandissait et requérait de plus en plus de serveurs, ISG commença à rencontrer des difficultés de montée en charge à l'origine de coupures de service. Pour garantir le bon fonctionnement de l'application auprès des agriculteurs qui dépendent d'elle, ISG s'est vite rendue à l'évidence qu'elle devait trouver un moyen de rassembler les logs et de consolider les données afin de visualiser le système de façon holistique.

En 2013, ISG trouva une solution : la Suite Elastic. M. Arp et un collègue ont commencé à utiliser Elasticsearch pour concevoir une démonstration avec la version 0.98. Ils ont rapidement réussi à créer leur premier cluster de production avec la version 1.4 et 4 nœuds.

"Nous avons commencé à introduire toutes sortes de logs : des logs de serveurs Web, des logs d'application, des logs système, des logs d'équilibreur de charge. Nous nous sommes vite rendu compte du potentiel d'analyse qui s'offrait à nous. Au lieu d'examiner indépendamment chaque serveur, nous nous sommes concentrés sur le système." Tim Arp, ingénieur d'exploitation en chef, Intelligent Solutions Group (ISG), John Deere

M. Arp et son équipe ont aussi utilisé Kibana pour créer des tableaux de bord afin de monitorer les erreurs et les logs Web Apache, et ce, en visualisant les codes de réponses et les résultats par serveur.

Au fil des années, la plateforme applicative de John Deere s'est élargie pour épauler les agriculteurs dans de nombreux domaines essentiels. L'entreprise ne se limite pas à la gestion des données, elle propose des applications de gestion à distance, de guidage, d'application à débit variable, de gestion des champs et de gestion de l'eau. L'utilisation d'Elasticsearch a évolué à mesure que l'offre de John Deere s'est élargie.  

Leur environnement actuel, Logcentral@Deere, a grandi de 4 à 25 nœuds pour mettre une architecture de logging à la disposition de toutes les équipes de développement d'applications d'ISG. Le système utilise la Suite Elastic 6.3 et traite 18 milliards de documents qui occupent 11 téraoctets d'espace de stockage. Environ 14 applications différentes y enregistrent des logs en permanence. Cela représente un flux de 20 000 événements par seconde. John Deere a également étendu Logcentral au cloud, avec 8 clusters Elasticsearch. Le plus large d'entre eux reçoit les logs de plus de 100 applications et comporte 51 nœuds.

Aujourd'hui, John Deere compte sur Elastic Cloud Enterprise (ECE) pour bénéficier de fonctionnalités telles que le support technique, l'authentification et les autorisations intégrées, le monitoring et les alertes avec Watcher (fonctionnalité d'alerte de la Suite Elastic), les recherches interclusters, les mises à niveau intégrées et le machine learning. À l'avenir, John Deere souhaite bénéficier de nouvelles fonctionnalités, telles que les cumuls et les agrégations de données, pour que les agriculteurs puissent bénéficier de résultats optimaux.

Regardez le témoignage complet de Tim Arp lors de l'Elastic{ON} Tour afin d'en savoir plus sur la façon dont John Deere utilise Elasticsearch pour transmettre des données essentielles aux agriculteurs de par le monde.

Aginic est l'une des principales agences australiennes de conseil en analyse de données. En tant que partenaires d'Elastic, nos analystes, ingénieurs, développeurs, concepteurs et coachs d'implémentation aident nos clients communs à produire des informations qui favorisent le changement en prenant part à des projets d'envergure dans les secteurs de la santé, de l'éducation, de l'énergie, du divertissement, de la défense et de la finance, pour ne citer que ceux-là.

Lors d'une récente rencontre Elastic à Brisbane, notre équipe a présenté quelques-unes des nouvelles fonctionnalités Canvas et SQL de la Suite Elastic en développant une suite de tableaux de bord fictifs qui pourraient permettre de réorganiser pour de bon le partage de vélos dans la Nouvelle-Galles-du-Sud.

Notre équipe a d'abord examiné quelques sources de données ouvertes ainsi que d'anciens cas d'utilisation, puis a rapidement débouché sur Canvas, la nouvelle application de Kibana. Cette application nous a permis d'intégrer les données de transport existantes du système NYC CitiBike¹ dans une élégante visualisation. À partir de là, nous avons entrepris d'identifier des améliorations en matière de tarif de location de vélo, de monitoring de l'inventaire, de satisfaction globale des usagers et d'utilisation globale des vélos dans la Nouvelle-Galles-du-Sud. 

Voici comment nous y sommes arrivés...

Notre tableau de bord Canvas a illustré certaines données du système NYTC CitiBike. Pour être plus précis, l'ensemble de données que nous avons choisi nous a permis d'exploiter les données transactionnelles des trajets ainsi que des indicateurs ponctuels d'état des stations. Nous avons pensé que ces deux différents types de données allaient nous permettre de présenter de la meilleure manière possible les nouvelles fonctionnalités de Canvas.

La première source de données, celle qui se rapporte aux trajets, exploite les données historiques hébergées sur S3. Pour les besoins de la présentation, nous avons utilisé un simple pipeline d'importation CSV Logstash groupé. Il est possible de programmer le téléchargement automatique des résultats pour s'assurer que les données d'Elasticsearch sont à jour.

La seconde source de données, celle qui se rapporte aux stations, se présente sous la forme d'une URL JSON fréquemment mise à jour. Elle comporte un ensemble d'indicateurs, y compris le nombre de vélos disponibles dans chaque station. Le résultat d'une demande transmise à cette URL aboutit à un objet JSON de haut niveau au format :

{"last_updated":1549188861,"ttl":10,"data":{"stations":[]}}

Les clés de notre flux en temps réel sont les champs last_updated et ttl (durée de vie). Le champ ttl représente la durée qui nous sépare de la prochaine mise à jour du flux. Ainsi, la somme des champs last_updated et ttl nous permet de savoir à quelle heure le flux sera mis à jour. En programmant une application Python personnalisée et en l'intégrant dans une boucle qui comprend une extraction de données suivie d'une pause, nous pouvons maximiser la mise à jour des données.

Une fois les données chargées dans Elasticsearch, nous avons pu commencer à faire des expériences avec les visualisations de Kibana. Traditionnellement, les tableaux de bord ont plusieurs finalités selon le cas d'utilisation :

• communiquer des informations de façon efficace ;
• permettre la découverte libre d'informations au moyen de fonctionnalités d'exploration et de filtre ; 
• automatiser la génération de rapports spécifiques d'activité.

Les charges de travail interactives, de filtrage et d'exploration libre s'ajustent parfaitement à la fonctionnalité de tableau de bord intégrée à Kibana. Cette dernière permet aux utilisateurs de manipuler rapidement et facilement les données présentées. Nous avons observé qu'en règle générale des applications personnalisées sont développées (en utilisant p. ex. d3) pour répondre aux cas d'utilisation non interactifs. Ces applications personnalisées requièrent du temps de développement et un support technique continu. Ce n'est pas le cas des tableaux de bord intégrés.

Canvas vous épargne ces difficultés en laissant de côté les tableaux de bord sous forme de grille et en adoptant une présentation cohérente, centrée sur l'objet. Cela donne cours à la créativité et permet de créer des styles libres de visualisation. Plus important encore, en raison du contrôle qu'un concepteur peut désormais avoir sur chaque objet ou graphique, les interactions entre les visualisations de données et les données peuvent instantanément donner beaucoup plus de sens que jamais auparavant, et ce, en les associant à des objets graphiques. 

Néanmoins, n'oublions pas que les outils de présentation des données ne sont utiles que lorsque vous comprenez votre audience. Il est essentiel de savoir associer le sens (définitions) aux données (lorsqu'elles existent dans une forme facile à comprendre). La facilité de développement de Canvas compense ceci en permettant aux utilisateurs de parcourir rapidement les versions afin de répondre à leurs besoins et de vérifier que la visualisation dans son ensemble fournit suffisamment de contexte pour présenter rapidement des informations. En tant que plateforme, elle nous permet d'apprécier le véritable potentiel du design thinking et de l'itération agile dans un contexte d'informatique décisionnelle.

La première présentation Canvas a été conçue avec l'intention d'intégrer l'image de marque dans le tableau de bord plutôt que de simplement ajouter un logo au coin de la page. C'est grâce à cette approche que certaines possibilités ont vu le jour, comme celle de créer des infographies animées en temps réel à un faible coût de développement. 

Bien que ce tableau de bord soit principalement une démonstration de la technologie de Canvas, il peut facilement être transformé pour offrir une vue d'ensemble aux personnels de maintenance ou indiquer les disponibilités en un clin d'œil aux usagers d'une station. Dans les deux cas, l'utilisation de tableaux de bord attrayants permet aux utilisateurs d'identifier rapidement les indicateurs clés ou les informations qui les intéressent.

Dans l'ensemble, nous avons constaté l'incroyable potentiel que représentent les tableaux de bord Canvas pour notre activité. Une telle solution pourrait simplifier l'utilisation de tableaux de bord existants et ainsi augmenter le recours aux données ainsi que l'interaction des utilisateurs. Malgré son jeune âge, Canvas a comblé le vide laissé par les logiciels traditionnels de tableau de bord et d'informatique décisionnelle. Nous sommes enthousiastes à l'idée de développer des solutions uniques avec nos clients pour résoudre leurs problèmes de visualisation grâce à Canvas.

¹ Aginic Pty Ltd n'est pas agréée, soutenue ni financée par Bikeshare, et ne lui est pas affiliée.

Ruben Slabbert
Ruben est ingénieur de données cloud et développeur d'applications. Les pipelines de données d'entreprise avec Amazon Web Services (AWS), Microsoft Azure et Google Cloud sont sa spécialité. Chez Aginic, il s'est chargé de concevoir les pipelines et a géré des équipes polyvalentes pour permettre le traitement fiable de lots et de données en temps réel, des systèmes de production aux lacs ainsi qu'aux entrepôts de données dans le cloud.

Andrew Li
Andrew est conseiller en analyse et possède des connaissances étendues en science des données et en recherche plein texte. Sa passion : améliorer les résultats grâce à l'analyse. Il a débuté sa carrière professionnelle avec un diplôme de génie mécanique (biomédicale) et a conseillé des institutions publiques et privées de nombreux secteurs, y compris la santé et l'administration publique, ainsi que des entreprises parmi les plus performantes de l'indice australien ASX.

Il est tout nouveau et il vient de sortir : il s’agit d’Elastic Cloud on Kubernetes (ECK), un nouveau produit d’orchestration basé sur le schéma de Kubernetes Operator, qui vous permet de provisionner, de gérer et d’exécuter des clusters Elasticsearch sur Kubernetes.

Au cours de ces dernières années, Kubernetes s’est avéré être la solution incontournable pour orchestrer les conteneurs et les applications qui s’y exécutent. Et la communauté Elasticsearch n’y a pas coupé. Nous avions promis que nous serions présents là où le vent porterait nos utilisateurs. Notre réponse, la voici, avec le lancement d’Elastic Cloud on Kubernetes. Notre but est de vous fournir les meilleures solutions possibles pour déployer et exécuter les produits Elastic sur la plate-forme de votre choix.

Notre passé commun avec Kubernetes ne date pas d’hier, avec la publication d’images Docker officielles pour Elasticsearch et Kibana, ou encore avec la modification de Beats pour collecter des logs et des indicateurs à partir des pods et des daemonsets éphémères. En décembre dernier, nous avons renforcé notre engagement en rejoignant la CNCF et en lançant Helm Charts. Le lancement d’ECK s’inscrit donc dans la suite logique des choses, pour simplifier encore davantage le déploiement et l’exécution de nos produits et solutions dans les environnements Kubernetes.

Un Elasticsearch Operator, et bien plus encore

Conçu à l’aide du schéma de Kubernetes Operator, ECK s’installe dans votre cluster Kubernetes et simplifie le déploiement d’Elasticsearch et de Kibana sur Kubernetes. Il a pour but de rationaliser les opérations du deuxième jour, à savoir :

• Gérer et monitorer plusieurs clusters
• Mettre à niveau de nouvelles versions des stacks en toute simplicité
• Adapter la capacité des clusters
• Modifier la configuration des clusters
• Faire évoluer le stockage local de façon dynamique (avec Elastic Local Volume, pilote de stockage local)
• Planifier les sauvegardes

Mais ECK est bien plus qu’un Kubernetes Operator. Il ne se contente pas d’automatiser l’ensemble des tâches administratives opérationnelles et de cluster : il vise à simplifier l’expérience de la Suite Elastic sur Kubernetes dans sa globalité. La vision d’ECK est de fournir une expérience de type SaaS pour les produits et les solutions Elastic sur Kubernetes.

Sécurisation par défaut

Tous les clusters Elasticsearch lancés sur ECK sont sécurisés par défaut. Plus concrètement, cela signifie qu’ils disposent du chiffrement et qu’ils sont protégés par un mot de passe par défaut élevé, dès leur création. Cette expérience s’inscrit dans la lignée de celle dont vous bénéficiez avec Elasticsearch Service sur Elastic Cloud.

Et on peut vous le dire, ça n’a pas été simple de la mettre en place ! Obtenez davantage d’informations sur les derniers changements de sécurité que nous avons apportés du côté de la Suite Elastic pour rendre cette expérience possible. TL;DR: À partir des versions 6.8 et 7.1, les principales fonctionnalités de sécurité d’Elasticsearch, comme le chiffrement TLS, le contrôle d'accès basé sur les rôles, ou encore l’authentification native et basée sur fichiers, sont désormais gratuites.

Canvas, Maps, Uptime, oh my

Tous les clusters déployés avec ECK comprennent des capacités de niveau de base (gratuites) puissantes, tels que le gel des index pour le stockage dense, Kibana Spaces, Canvas, Elastic Maps, et bien plus. Vous pouvez même monitorer les logs et l’infrastructure Kubernetes à l’aide des applications Elastic Logs et Elastic Infrastructure. Ainsi, vous bénéficiez d’une expérience intégrale de la Suite Elastic sur Kubernetes, que seul Elastic peut vous proposer.

Déployez des topologies hot-warm-cold et personnalisées

La topologie hot-warm-cold est une topologie de cluster puissante pour le logging, les indicateurs et d’autres cas d'utilisation de séries temporelles. Il s’agit d’un schéma architectural courant qui équilibre les besoins en stockage à long terme et en performances sans se ruiner. Avec ECK, vous pouvez déployer des clusters hot-warm-cold sur Kubernetes, puis configurer facilement les politiques relatives aux cycles de vie des données à l’aide de la gestion du cycle de vie des index (ILM) pour acheminer les données entre les niveaux de nœuds au fur et à mesure qu’elles vieillissent.

Pas d’algorithme de compression pour l’expérience

Lorsqu’il s’agit de déployer un logiciel, le premier jour est simple. Le deuxième jour... c’est une autre paire de manches. Une grande partie consiste à rationaliser l’exécution d’un système à états comme Elasticsearch dans un framework d’orchestration dynamique comme Kubernetes. Comment fournir un stockage local persistant qui puisse évoluer de façon dynamique ? Nous intégrons directement dans ECK le pilote de stockage conçu pour Kubernetes, Elastic Local Volume. Celui-ci comprend de nombreuses bonnes pratiques, comme le drainage d’un nœud avant de restreindre une capacité, ou comme le rééquilibrage des partitions lorsque vous étendez le déploiement.

Elastic Cloud on Kubernetes est le fruit de notre expérience opérationnelle en tant que créateurs d’Elasticsearch et d’Elastic Cloud Enterprise, et opérateurs d’Elasticsearch Service. Toutes ces connaissances que nous avons accumulées, nous les avons exploitées pour définir l’orchestration et le fonctionnement des déploiements Elasticsearch et Kibana au sein de Kubernetes.

Nous nous sommes assurés qu’il n’y avait aucune perte de données lors des changements de configuration, qu’il n’y avait aucune indisponibilité lors de la montée en charge... Bref, nous avons étudié chaque aspect opérationnel en détail lors de la conception d’ECK.

Un niveau qui restera toujours gratuit

Depuis le jour où Elasticsearch est né, notre objectif a toujours été de proposer aux nouveaux utilisateurs une première expérience riche en intégrant des fonctionnalités puissantes dans la version de base gratuite. C’est en gardant cet objectif à l’esprit que nous avons conçu ECK.

La version de base d’ECK restera toujours gratuite. Dans une optique d’ouverture et de transparence, nous avons aussi mis l’ensemble du code source d’ECK à la disposition du public, sous licence Elastic, dans le référentiel GitHub Elastic cloud-on-k8s.

Un abonnement (payant) Enterprise donne accès à des fonctionnalités supplémentaires, parmi lesquelles la capacité à déployer des clusters avec des fonctionnalités avancées comme le contrôle d’accès basé sur les champs ou les documents, le Machine Learning, l’analyse de graphes, et bien d’autres. Dans le futur, l’abonnement Entreprise permettra aussi de bénéficier d’autres fonctionnalités d’orchestration avancées.

Support technique GKE officiel, avec de belles perspectives à venir

Dans cette première version alpha de lancement d’ECK, nous prenons en charge Google Kubernetes Engine (GKE) et Kubernetes « vanille » version 1.11 et supérieure. Les versions à venir continueront à étendre le support technique à d’autres « saveurs » de Kubernetes.

Lancez-vous aujourd’hui

Essayez dès aujourd’hui en exécutant cette version sur votre cluster Kubernetes, et visitez la page de démarrage rapide pour en savoir plus.

Bonne nouvelle ! Les principales fonctionnalités de sécurité de la Suite Elastic sont désormais gratuites. Concrètement, qu’est-ce que cela signifie pour les utilisateurs ? Tout simplement qu’ils pourront chiffrer le trafic réseau, créer et gérer des utilisateurs, définir des rôles qui protègent le niveau d’accès des index et des clusters, et sécuriser intégralement Kibana avec Spaces. Notre communauté s’apprête à franchir un nouveau cap. Et nous nous en réjouissons ! Nous avons ouvert le code de ces fonctionnalités (et bien d’autres) l’année dernière. Aujourd’hui, nous proposons ces fonctionnalités gratuitement, pour que chacun puisse gérer un cluster totalement sécurisé en toute sérénité.

La sécurité est gratuite à partir des versions 6.8.0 et 7.1.0

C’est un vrai changement, et pas des moindres. Nous souhaitions en faire profiter un maximum d’utilisateurs, et c’est pourquoi aujourd’hui, nous publions les versions 6.8.0 et 7.1.0 de la Suite Elastic. Ces versions ne contiennent aucune nouvelle fonctionnalité. En revanche, elles permettent aux utilisateurs de bénéficier des fonctionnalités de sécurité suivantes gratuitement dans la Suite Elastic :

• TLS pour des communications chiffrées
• Authentification native et basée sur fichiers pour la création et la gestion d’utilisateurs
• Contrôle d'accès basé sur les rôles pour contrôler l’accès utilisateur aux API de cluster et aux index, ainsi que pour autoriser une architecture multi-tenant pour Kibana avec une sécurité pour Kibana Spaces

Auparavant, pour pouvoir disposer de ces fonctionnalités de sécurité, il était nécessaire de souscrire un abonnement Gold. Aujourd’hui, ces fonctionnalités sont proposées gratuitement à partir du niveau de base. Notez toutefois que nos fonctionnalités de sécurité avancées, telles que l’authentification unique, l’authentification Active Directory/LDAP et la sécurité aux niveaux des champs et des documents, restent payantes. Consultez la matrice des fonctionnalités pour en savoir plus.

Comme toujours, ces versions sont disponibles dès maintenant sur Elasticsearch Service sur Elastic Cloud, l’offre hébergée officielle d’Elasticsearch.

Mais attendez... Ce n’est pas tout ! Il est temps de parler de Kubernetes !

Nous annonçons ce changement en même temps que le lancement de la version alpha d’Elastic Cloud on Kubernetes (ECK), le Kubernetes Operator officiel pour Elasticsearch et Kibana. ECK est conçu pour automatiser et simplifier le déploiement et le fonctionnement d’Elasticsearch sur Kubernetes.

La sécurité fait partie intégrante des opérations de cluster, en particulier dans les environnements partagés et multi-tenant comme Kubernetes. En intégrant les principales fonctionnalités de sécurité dans la version de base de la Suite Elastic, nous garantissons que tous les clusters lancés et gérés par ECK sont sécurisés par défaut au moment de leur création. Finis, les casse-tête pour les admin ! Par ailleurs, cette expérience s’inscrit dans la lignée de celle dont bénéficient les utilisateurs avec Elasticsearch Service sur Elastic Cloud.

Effectuez une mise à niveau et lancez-vous

Pour démarrer, téléchargez et installez la dernière version de la Suite Elastic, ou mettez vos clusters à niveau sur la version 6.8 ou 7.1.

Pour vous aider à vous lancer facilement, nous avons préparé différents documents à votre intention : 

• Un blog qui explique comment se lancer avec la sécurité Elasticsearch
• Une présentation vidéo sur le même sujet

Vous voulez accélérer votre apprentissage et aller plus loin ? Suivez cette nouvelle formation à la demande concernant les notions de base sur la sécurisation d’Elasticsearch, proposée gratuitement pendant une période limitée (coût normal : 200 $).

L’univers des microservices

C’est un fait : les entreprises se tournent de plus en plus vers des architectures de microservices, qu’elles développent et déploient davantage chaque jour. Souvent, ces services sont développés dans différents langages de programmation, déployés dans des conteneurs d’exécution distincts et gérés par plusieurs équipes et organisations. Les grandes entreprises comme Twitter disposent de dizaines de milliers de microservices, œuvrant tous dans un même but : atteindre les objectifs de l’entreprise. Comme l’explique cet article de blog de Twitter, pour pouvoir déterminer rapidement la cause d’un problème, il est extrêmement important d’avoir de la visibilité sur l’état et les performances des différents services au sein de la topologie. Cela contribuera également à améliorer la fiabilité et l’efficacité globales de Twitter.

C’est là que le traçage distribué peut apporter une aide véritablement précieuse, en prenant en charge deux problématiques fondamentales auxquelles les microservices sont confrontés :

1. Suivi de la latence
   Une demande ou transaction utilisateur peut passer par plusieurs services dans différents environnements d’exécution. Il est nécessaire de comprendre la latence de chacun de ces services pour comprendre les caractéristiques de performances globales du système dans son ensemble. De là, vous pourrez également déterminer où apporter des améliorations.
2. Analyse de la cause d’un problème
   L’analyse de la cause d’un problème est une tâche ardue, en particulier pour les applications soutenues par de grands écosystèmes de microservices. Un service peut à tout moment présenter une défaillance. Le traçage distribué joue un rôle crucial pour déboguer les problèmes dans une telle situation.

Mais revenons un peu en arrière. Le traçage est l’un des éléments des trois piliers de l’observabilité, avec le logging et les indicateurs. Comme nous l’avons déjà évoqué, la Suite Elastic est une plate-forme unifiée regroupant les trois piliers de l’observabilité. Lorsque les logs, les indicateurs et les données APM sont stockés dans le même référentiel, puis analysés et mis en corrélation, vous obtenez des informations contextuelles optimales sur vos applications et systèmes métier. Dans cet article, nous nous intéresserons uniquement au traçage.

Traçage distribué avec Elastic APM

Elastic APM est un système de monitoring des performances applicatives basé sur la Suite Elastic. Il vous permet de monitorer les applications et les services logiciels en temps réel, en recueillant des informations de performances détaillées sur le temps de réponse des demandes entrantes, les requêtes de bases de données, les appels de caches, les requêtes HTTP externes, etc. Les agents Elastic APM proposent une instrumentation automatisée enrichie prête à l’emploi (p. ex. temporisation des requêtes db etc.) pour les frameworks et les technologies pris en charge. Vous pouvez également utiliser une instrumentation personnalisée pour remplir des objectifs bien précis. Ainsi, il sera bien plus facile de détecter les problèmes de performances et de les résoudre rapidement.

Elastic APM prend en charge le traçage distribué et est compatible avec OpenTracing. Cette solution vous permet d’analyser les performances de l’ensemble de votre architecture de microservices, le tout dans une seule vue. Pour cela, Elastic APM trace toutes les requêtes, depuis la requête Web initiale vers votre service front-end, jusqu’aux requêtes envoyées à vos services de back-end. Ainsi, vous repérez les goulots d’étranglement potentiels dans votre application avec plus de facilité et de rapidité. Dans l’interface utilisateur d’APM, les transactions effectuées dans le cadre de services connectés sont affichées sous forme de cascade chronologique dans une trace :

La Suite Elastic est également une plate-forme idéale pour l’agrégation de logs et l’analyse d’indicateurs. Elasticsearch stocke et indexe tous les logs, indicateurs et traces APM. Pour vous, c’est un atout indéniable. Vous pouvez mettre rapidement en corrélation les sources de données, telles que les indicateurs d’infrastructure, les logs et les traces, ce qui vous permet de déboguer la cause d’un problème bien plus rapidement. Dans l’interface utilisateur APM, lorsque vous étudiez une trace, vous pouvez rapidement passer aux indicateurs de l’hôte ou du conteneur, ainsi qu’aux logs, en cliquant sur le menu Actions (si ces indicateurs et ces logs sont aussi recueillis).

L’idéal, ce serait que tous les utilisateurs se servent d’Elastic APM pour instrumenter leurs applications et leurs services. Néanmoins, Elastic APM n’est pas la seule solution de traçage distribué commercialisée sur le marché. Il existe d’autres solutions de traçage open source très prisées, comme Zipkin et Jaeger. Certains concepts, comme la programmation multilangage et la persistance polyglotte, sont bien connus et largement acceptés dans l’univers des microservices. De manière similaire, le « traçage polyglotte » va se démocratiser. En raison du côté indépendant et « découplé » des microservices, les personnes en charge des différents services utiliseront probablement des systèmes de traçage distincts.

Problématiques pour les développeurs

Vu la diversité des systèmes de traçage disponibles, les développeurs sont confrontés à de véritables problématiques. Au final, les systèmes de traçage résident dans le code d’application. Voici quelques-unes des problématiques courantes rencontrées :

1. Quel système de traçage utiliser ?
2. Que faire si je souhaite changer de système de traçage ? Je ne veux pas modifier l’intégralité de mon code source.
3. Comment procéder avec des bibliothèques partagées qui utilisent des systèmes de traçage différents ?
4. Que se passe-t-il si mes services tiers utilisent différents systèmes de traçage ?

Sans surprise, pour répondre à ces problématiques, il est nécessaire de normaliser le traçage. Avant d’aborder la normalisation, étudions tout d’abord le traçage distribué d’un point de vue architectural. Notre but : comprendre les éléments nécessaires pour atteindre le « paradis » du traçage distribué.

Composants architecturaux du traçage distribué

Les systèmes logiciels modernes peuvent être dissociés en composants de haut niveau, généralement conçus et développés par différentes entreprises et exécutés dans des environnements distincts.

• Votre propre code d’application et vos propres services
• Bibliothèques et services partagés
• Services externes

Pour monitorer un tel système de façon holistique et intégrée avec le traçage distribué, quatre composants architecturaux sont nécessaires :

1. API normalisée de traçage distribué. Avec une API de traçage ouverte et normalisée, les développeurs peuvent instrumenter leur code de manière normalisée. Peu importe le système de traçage qu’ils utiliseront par la suite lors de l’exécution. C’est un premier pas ouvrant de nombreuses possibilités.
2. Définition normalisée du contexte de traçage et propagation. Pour qu’une trace soit transmise d’un environnement d’exécution à l’autre, il est nécessaire que son contexte soit compris des deux côtés. Le contexte doit donc être propagé de façon normalisée. Il doit être associé à un ID de trace au minimum.
3. Définition normalisée des données de traçage. Pour que les données d’un système de traçage soient comprises et utilisées par un autre système de traçage, elles doivent être mises sous un format normalisé et extensible.
4. Systèmes de traçage interopérables. Enfin, pour bénéficier d’une compatibilité d’exécution totale, les systèmes de traçage doivent disposer de mécanismes d’exportation et d’importation de données de trace venant d’autres systèmes de façon ouverte. Dans l’idéal, une bibliothèque ou un service partagé instrumenté par un système comme Jaeger devrait pouvoir transmettre ses données de traçage directement à Elastic APM ou à tout autre système de traçage par l’intermédiaire de l’agent Jaeger grâce à une modification de configuration.

Maintenant, ouvrez OpenTracing.

La spécification OpenTracing

La spécification OpenTracing définit une API ouverte pour le traçage distribué. Les utilisateurs n’ont donc pas à se cantonner à un fournisseur spécifique car ils ont la possibilité de changer de système de mise en œuvre OpenTracing quand ils le souhaitent. Cela permet également aux développeurs de frameworks et de bibliothèques partagées de fournir une fonctionnalité de traçage prête à l’emploi et normalisée, pour que les informations en découlant soient plus pertinentes. Les entreprises à l’échelle du Web, comme Uber et Yelp, utilisent OpenTracing pour bénéficier d’une meilleure visibilité sur les applications hautement distribuées et dynamiques.

Le modèle de données OpenTracing

Les concepts de base d’OpenTracing et le modèle de données fondamental sont tirés de l’article sur le système Dapper de Google. Parmi les concepts clés, on trouve la trace et l’intervalle.

1. Une trace représente une transaction au fur et à mesure qu’elle se déplace dans un système distribué. On peut la considérer comme un graphe acyclique dirigé d’intervalles.
2. Un intervalle représente une unité logique de travail, qui possède un nom, une heure de début et une durée. Les intervalles peuvent être imbriqués et mis en ordre pour modeler des relations. Les intervalles acceptent les balises key:value, ainsi que les logs structurés, précis et horodatés associés à une instance d’intervalle donnée.
3. Le contexte d’une trace représente les informations qui accompagnent la transaction distribuée lorsqu’elle passe de service en service sur le réseau ou via un bus de messagerie. Le contexte indique l’identificateur de la trace, l’identificateur de l’intervalle et toute autre donnée que le système de traçage doit propager vers le service en aval.

Comment tout cela s’articule ?

Dans l’idéal, avec la normalisation, les informations de traçage issues du code d’application personnalisé, des bibliothèques partagées et des services partagés mis au point et exécutés par différentes organisations sont échangeables et compatibles au niveau de l’exécution, et ce, quel que soit le système de traçage utilisé par ces composants.

Néanmoins, OpenTracing prend en charge uniquement le premier des quatre composants architecturaux que nous avons abordés ci-dessus. Aussi, où en sommes-nous aujourd’hui avec les autres composants et qu’est-ce que le futur peut nous apporter ?

Où en sommes-nous aujourd’hui ?

Comme nous l’avons vu, OpenTracing définit un ensemble standard d’API de traçage pouvant être mises en œuvre par différents systèmes. C’est un début véritablement prometteur ! Toutefois, nous devons encore normaliser le contexte et les données de traçage pour qu’elles puissent être compatibles et interchangeables.

1. OpenTracing fournit un ensemble standard d’API. C’est pratiquement la seule normalisation dont nous disposons aujourd’hui. Il faut toutefois noter qu’il existe une limitation à la spécification. Par exemple, elle ne prend pas en charge certains langages de programmation. Quoi qu’il en soit, c’est déjà un premier pas. Le premier pas d’une longue série.
2. Aucune définition normalisée de contexte de traçage pour l’instant. Le groupe de travail sur le traçage distribué W3C s’est attaqué à la normalisation de la définition du contexte de traçage : la spécification du contexte d’une trace W3C. La spécification définit une approche unifiée par rapport à la corrélation existant entre un contexte et un événement au sein des systèmes distribués. Elle permettra de tracer une transaction de bout en bout au sein des applications distribuées à l’aide de différents outils de monitoring. Elastic APM aide ce groupe de travail à normaliser le format d’en-tête HTTP pour le traçage distribué. Nos mises en œuvre d’agents respectent rigoureusement la version préliminaire de la spécification du contexte de trace, et nous prévoyons de prendre entièrement en charge la spécification finale.
   
   Ci-dessous, vous trouverez un exemple de l’incompatibilité qui existe au niveau du traçage du contexte actuellement, avec l’en-tête HTTP utilisé par Elastic APM et celui utilisé par Jaeger pour tracer l’ID. Comme vous pouvez le constater, le nom et l’encodage de l’ID sont différents. Lorsque différents en-têtes de traçage sont utilisés, les traces se rompent lorsqu’elles passent les frontières de leurs outils de traçage respectifs.
   
   Jaeger :
   uber-trace-id: 118c6c15301b9b3b3:56e66177e6e55a91:18c6c15301b9b3b3:1
   
   Elastic APM :
   elastic-apm-traceparent : 00-f109f092a7d869fb4615784bacefcfd7-5bf936f4fcde3af0-01
   
   La définition en tant que telle n’est pas la seule problématique. Par exemple, certains en-têtes HTTP ne sont pas automatiquement transférés par l’infrastructure de service, les routeurs etc. Lorsque les en-têtes sont abandonnés, les traces se rompent.
3. Aucune définition normalisée des données de traçage pour l’instant. Comme indiqué par le groupe de travail sur le traçage distribué W3C, le deuxième élément nécessaire à l’interopérabilité d’une trace est « un format normalisé et extensible pour partager les données de trace, en intégralité ou en partie, sur les différents outils pour une meilleure interprétation ». Seul problème : il existe de nombreuses solutions open source et de solutions vendues dans le commerce. La définition d’un format standard est donc une tâche épineuse. Nous espérons y parvenir prochainement.
4. Les systèmes de traçage ne sont pas compatibles au niveau de l’exécution. Pour toutes les raisons citées ci-dessus et à cause de l’incompatibilité des systèmes, les systèmes de traçage ne sont donc pas compatibles les uns avec les autres lors de l’exécution. Nous pouvons avancer avec certitude que ce problème persistera malheureusement à l’avenir.

Fonctionnement d’Elastic APM avec d’autres systèmes de traçage aujourd’hui

Même si nous sommes encore loin d’une compatibilité totale entre les systèmes de traçage aujourd’hui, restons optimistes. La Suite Elastic peut fonctionner avec d’autres systèmes de traçage de différentes façons.

1. Elasticsearch en tant que magasin de données back-end évolutif pour d’autres systèmes de traçage.
   
   Sans surprise, Elasticsearch a servi de magasin de données back-end pour d’autres systèmes de traçage comme Zipkin et Jaeger. Ses atouts : des capacités d’évolutivité et d’analyse puissantes. Pour transférer des données de traçage de Zipkin ou de Jaeger dans Elasticsearch, il suffit simplement de paramétrer la configuration de ces systèmes en ce sens. Dès que les données de traçage ont été transférées dans Elasticsearch, utilisez la capacité d’analyse et de visualisation puissante de Kibana pour analyser vos informations de traçage et créer des visualisations attrayantes qui illustrent bien les performances de vos applications.
2. Pont Elastic OpenTracing
   
   Le pont Elastic APM OpenTracing vous permet de créer des transactions et des intervalles Elastic APM, à l’aide de l’API OpenTracing. En d’autres termes, il convertit les appels de l’API OpenTracing vers Elastic APM, puis permet de réutiliser l’instrumentation existante. Par exemple, une instrumentation existante réalisée par Jaeger peut être tout simplement remplacée par Elastic APM en changeant quelques lignes de code.
   
   Instrumentation d’origine par Jaeger :
   
   

   import io.opentracing.Scope;
   import io.opentracing.Tracer;
   import io.jaegertracing.Configuration;
   import io.jaegertracing.internal.JaegerTracer;
   ...
   private void sayHello(String helloTo) {
       Configuration config = ...
       Tracer tracer = config.getTracer();
       try (Scope scope = tracer.buildSpan("say-hello").startActive(true)) {
           scope.span().setTag("hello-to", helloTo);
       }
       ...
   }
       

   Remplacez Jaeger avec le pont Elastic OpenTracing :
   
   

   import io.opentracing.Scope;
   import io.opentracing.Tracer;
   import co.elastic.apm.opentracing.ElasticApmTracer;
   ...
   private void sayHello(String helloTo) {
       Tracer tracer = new ElasticApmTracer();
       try (Scope scope = tracer.buildSpan("say-hello").startActive(true)) {
           scope.span().setTag("hello-to", helloTo);
       }
       ...
   }
       

   
   
   Avec ce simple changement, les données de traçage circuleront joyeusement dans Elastic APM, sans que vous ayez à intervenir davantage sur le code de traçage. C’est là toute la puissance d’OpenTracing !

Elastic APM Real User Monitoring

Même si nous parlons essentiellement des services back-end lorsque nous abordons le sujet du traçage et de la propagation du contexte, il faut tout de même indiquer qu’il est très intéressant de démarrer la trace côté client dans le navigateur. En procédant ainsi, vous obtenez des données de trace dès le moment où un utilisateur clique sur quelque chose dans le navigateur. Ces données de trace représentent « l’expérience des utilisateurs réels » de vos applications du point de vue des performances. Malheureusement, là encore, il n’existe pas de procédure normalisée pour transférer ces données actuellement. Le groupe W3C a l’intention d’étendre le contexte de trace depuis le navigateur. C’est l’un de ses objectifs pour l’avenir.

Elastic APM Real User Monitoring (RUM) assure cette fonctionnalité aujourd’hui. L’agent RUM JS monitore l’expérience des utilisateurs réels au sein de votre application côté client. Vous pourrez mesurer des indicateurs tels que « Délai jusqu’au premier octet », domInteractive, et domComplete, qui aident à détecter les problèmes de performance dans votre application côté client ainsi que les problèmes de latence de votre application côté serveur. Notre agent RUM JS est compatible avec tous les frameworks. Il peut donc être utilisé avec n’importe quelle application front-end basée sur JavaScript.

<p?</p?

Résumé

Nous espérons que cet article de blog vous a aidé à mieux comprendre l’environnement du traçage distribué et qu’il a clarifié certains points concernant le statut d’OpenTracing aujourd’hui. Voici quelques points à retenir :

1. Le traçage distribué fournit des informations précieuses concernant les performances des microservices.
2. OpenTracing représente une première étape vers la normalisation du traçage distribué dans le secteur. Il reste encore un long chemin à parcourir pour atteindre une compatibilité totale.
3. Elastic APM est compatible avec OpenTracing.
4. Le pont Elastic OpenTracing permet de réutiliser une instrumentation existante.
5. La Suite Elastic représente une solution de stockage à long terme évolutive idéale pour d’autres systèmes de traçage comme ZipKin et Jaeger, même si la compatibilité d’exécution n’est pas encore totale aujourd’hui.
6. Il est possible d’analyser les données de traçage avec Elastic, même si ces données ne proviennent pas d’Elastic. Pour transférer des données de traçage de Zipkin ou de Jaeger dans Elasticsearch, il suffit simplement de paramétrer la configuration.
7. Elastic APM Real User Monitoring (RUM) monitore l’expérience des utilisateurs réels au sein de votre application côté client.
8. Pour résumer, Elastic est une plate-forme d’analyse unifiée et évolutive, équipée de nombreuses fonctionnalités, pour les trois piliers de l’observabilité : le logging, les indicateurs et le traçage.

Comme toujours, rendez-vous sur leforum Elastic APM si vous souhaitez ouvrir un fil de discussion ou si vous avez des questions. Nous vous souhaitons un bon traçage !

Je suis responsable de produit pour l’observabilité chez Elastic. En général, quand j’emploie le terme « observabilité », j’obtiens différentes réactions. La plus courante, c’est qu’on me demande ce qu’est l’observabilité. Néanmoins, j’entends de plus en plus de gens me répondre qu’ils viennent de mettre en place une initiative d’observabilité, mais qu’ils ne savent pas exactement comment procéder. Enfin, j’ai eu aussi le plaisir de travailler avec des organisations pour qui l’observabilité fait partie intégrante de leur façon de concevoir et de fabriquer leurs produits et services.

Étant donné que ce concept prend de plus en plus d’ampleur, je me suis dit qu’il serait utile d’expliquer comment nous concevons l’observabilité chez Elastic, ce que nous avons appris de nos clients avant-gardistes, et comment nous l’envisageons du point de vue du produit lorsque nous faisons évoluer notre suite avec de nouveaux cas d'utilisation opérationnels.

L’observabilité, qu’est-ce que c’est ?

Ce n’est pas nous qui avons inventé le terme « observabilité ». Nous avons commencé à l’entendre dans la bouche de nos clients, principalement de ceux exerçant dans l’ingénierie de fiabilité des sites (SRE). D’après plusieurs sources, ce terme aurait été utilisé pour la première fois par des géants SRE de la Silicon Valley, comme Twitter. Et même si le livre précurseur de Google sur la SRE ne mentionne pas ce terme, il établit bon nombre de principes associés à l’observabilité aujourd’hui.

L’observabilité n’est pas un composant qu’on livre dans un paquet. C’est un attribut d’un système que vous construisez, au même titre que la facilité d’utilisation, la haute disponibilité et la stabilité. Lorsqu’on conçoit et qu’on fabrique un système « observable », l’objectif est de s’assurer que, lorsqu’il est mis en production, les opérateurs soient capables de détecter les comportements indésirables (p. ex. indisponibilité du service, erreurs, réponses lentes) et qu’ils disposent d’informations exploitables pour déterminer la cause du problème avec efficacité (p. ex. logs d’événements détaillés, informations granulaires sur l’utilisation des ressources, traces d’applications). Seulement, les entreprises se retrouvent parfois confrontées à des obstacles courants qui les empêchent d’atteindre cet objectif, parmi lesquels le manque d’informations, l’excédent d’informations non converties en renseignements exploitables, ou encore la fragmentation de l’accès à ces informations.

Le premier aspect que nous avons cité, à savoir la détection des comportements indésirables, démarre généralement par la configuration d’indicateurs et d’objectifs de niveau de service. Il s’agit de mesures de réussite mises en place en interne qui permettent de jauger les systèmes de production. Si une obligation contractuelle impose de respecter ces indicateurs et objectifs de niveau de service, un accord de niveau de service est alors mis en place. Parmi les exemples courants d’indicateurs de niveau de service, citons la disponibilité d’un système, pour laquelle vous pouvez définir un objectif de niveau de service de 99,999 %. La disponibilité d’un système représente aussi l’accord de niveau de service que l’on présente le plus souvent aux clients externes. Néanmoins, en interne, vos indicateurs et objectifs de niveau de service peuvent s’avérer bien plus granulaires, et ces facteurs critiques du comportement des systèmes de production sont soumis au monitoring et à l’alerting, lesquels constituent la base de toute initiative d’observabilité. Cet aspect de l’observabilité est également connu sous le nom de « monitoring ».

Le second aspect que nous avons évoqué, à savoir le fait de fournir des informations granulaires aux opérateurs pour déboguer les problèmes de production avec rapidité et efficacité, est un domaine qui est en constante évolution et qui donne naissance à de nombreuses innovations. Les « trois piliers de l’observabilité », c.-à-d. les indicateurs, les logs et les traces d’application, sont un vaste sujet sur lequel il y a beaucoup de choses à dire. Il est également avéré que le fait de collecter toutes ces données granulaires à l’aide d’outils divers et variés n’est pas forcément rentable, aussi bien d’un point de vue analytique que financier. 

Les « piliers » de l’observabilité

Étudions ces aspects de la collecte de données plus en détail. Voici comment nous avons tendance à procéder aujourd’hui : on collecte des indicateurs dans un premier système (en général une base de données temporelles ou un service SaaS pour le monitoring des ressources), on collecte les logs dans un deuxième système (sans surprise, la Suite ELK habituellement), puis on utilise encore un troisième outil pour instrumenter les applications, et ainsi, effectuer le traçage au niveau des requêtes. Lorsqu’une alerte se déclenche et révèle une violation d’un niveau de service, c’est un véritable branle-bas de combat ! Les opérateurs se ruent sur leurs systèmes et font du mieux qu’ils peuvent en jonglant entre les fenêtres : ils étudient les indicateurs dans l’une, les mettent en corrélation avec les logs manuellement dans une autre, et suivent les traces (au besoin) dans une troisième.

Cette approche comprend plusieurs inconvénients. Tout d’abord, la mise en corrélation manuelle de différentes sources de données racontant toutes la même histoire fait perdre un temps précieux lors de la dégradation ou de la panne du service. Ensuite, les frais engendrés par la gestion de trois datastores opérationnels sont élevés : coûts de licence, effectifs distincts pour les administrateurs d’outils opérationnels disparates, capacités de Machine Learning incohérentes dans chaque datastore, capacité de réflexion « éparpillée » concernant l’alerting... Chaque entreprise avec laquelle nous nous sommes entretenus lutte pour faire face à ces problématiques.

De plus en plus, les entreprises se rendent compte qu’il est important de disposer de toutes ces informations dans un magasin opérationnel unique, avec la possibilité de mettre automatiquement ces données en corrélation dans une interface utilisateur intuitive. L’idéal serait que les opérateurs puissent accéder à chaque donnée qui concerne leur service de façon unifiée, qu’il s’agisse d’une ligne de log émise par l’application, les données de trace résultant de l’instrumentation, ou l’utilisation d’une ressource représentée au moyen d’indicateurs dans une série temporelle. Le souhait qu’expriment régulièrement les utilisateurs serait de pouvoir disposer d’un accès ad-hoc uniforme à ces données, qu’elles proviennent d’une recherche avec filtrage, d’une agrégation ou encore d’une visualisation. Démarrer avec des indicateurs, explorer les logs et les traces en quelques clics sans que le contexte ne change, voilà ce qui permettrait d’accélérer l’investigation. De la même façon, on peut considérer les valeurs numériques extraites de logs structurés comme des indicateurs. Et le fait de comparer ces valeurs aux indicateurs est particulièrement intéressant d’un point de vue opérationnel.

Comme évoqué précédemment, si on se contente de collecter des données, on risque de se retrouver avec un volume trop important d’informations sur le disque, et pas assez de données exploitables lorsqu’un incident se produit. À côté de cela, on compte de plus en plus sur le système qui collecte les données opérationnelles pour détecter automatiquement des événements « intéressants », des traces et des anomalies dans le schéma d’une série temporelle. Cela permet aux opérateurs d’enquêter sur un problème en se concentrant sur sa cause plus rapidement. Cette capacité de détection des anomalies est parfois désignée comme le « quatrième pilier de l’observabilité ». La détection des anomalies dans les données de disponibilité, dans l’utilisation de ressources, dans les schémas de logging et dans la plupart des traces pertinentes fait partie des exigences émergentes mises en avant par les équipes d’observabilité.

Observabilité... et la Suite ELK ?

En quoi l’observabilité concerne-t-elle la Suite Elastic (ou la Suite ELK, comme on l’appelle dans les cercles opérationnels) ?

La Suite ELK est réputée pour être la solution incontournable pour centraliser les logs issus des systèmes opérationnels. On part du principe qu’Elasticsearch (un « moteur de recherche ») est l’outil idéal dans lequel importer des logs texte afin d’effectuer une recherche de texte libre. Et effectivement, rien que le fait de rechercher le mot « error » dans les logs texte ou de filtrer les logs en fonction d’un ensemble de balises bien connu donne déjà des résultats très pertinents. C’est d’ailleurs par là que commencent généralement les utilisateurs.

L’utilisation d’Elasticsearch en tant que datastore permet de bénéficier d’un index inversé proposant des capacités efficaces de recherche de texte intégral et de filtrage simple. Mais comme la plupart des utilisateurs de la Suite ELK le savent, ses avantages vont bien au-delà. Il contient également une structure en colonnes optimisée pour le stockage et qui fonctionne dans une série temporelle numérique dense. Cette structure en colonnes sert à stocker les données structurelles venant des logs analysés, qu’il s’agisse de chaînes ou de valeurs numériques. Pour tout vous dire, ce qui nous a incités à la base à optimiser Elasticsearch en vue d’un stockage efficace et de l’extraction des valeurs numériques, c’est le cas d'utilisation qui impliquait de convertir les logs en indicateurs.

Au fil du temps, les utilisateurs ont commencé à importer des séries temporelles numériques directement dans Elasticsearch, venant remplacer les bases de données existantes des séries temporelles. Guidé par ce besoin, Elastic a récemment introduit Metricbeat pour la collecte automatisée d’indicateurs, le concept de cumuls automatiques et d’autres fonctionnalités spécifiques aux indicateurs, aussi bien dans le datastore que dans l’interface utilisateur. Résultat : un nombre croissant d’utilisateurs qui avaient adopté la Suite ELK pour les logs ont également commencé à importer des données d’indicateurs, comme l’utilisation de ressource, dans la Suite Elastic. En plus des économies opérationnelles déjà mentionnées ci-dessus, une autre raison poussant les utilisateurs à se tourner vers Elasticsearch est le manque de restrictions que cette solution applique à la cardinalité des champs éligibles aux agrégations numériques (un souci courant lorsque l’on évoque la plupart des bases de données temporelles existantes).

À l’instar des indicateurs, les données de disponibilité représentent un type de données extrêmement important avec les logs, fournissant une source conséquente d’alertes relatives aux indicateurs et objectifs de niveau de service depuis un moniteur. Les données de disponibilité peuvent fournir des informations sur la dégradation des services, des API et des sites web, souvent avant que les utilisateurs n’en ressentent l’impact. Autre avantage : les données de disponibilité prennent très peu de place en termes de stockage. Elles présentent donc une grande valeur pour un coût supplémentaire minime.

L’année dernière, Elastic a aussi introduit Elastic APM, une solution qui ajoute le traçage d’applications et le traçage distribué à la suite. Pour nous, il s’agissait d’une évolution naturelle, étant donné que plusieurs projets open source et fournisseurs APM réputés se servaient déjà d’Elasticsearch pour stocker et rechercher les données de trace. En général, les outils APM traditionnels séparent les données de trace APM des logs et des indicateurs, ce qui crée des silos de données opérationnelles. Elastic APM propose un ensemble d’agents pour collecter des données de trace à partir de langages et de frameworks pris en charge, ainsi que pour prendre en charge OpenTracing. Les données de trace recueillies sont automatiquement mises en corrélation avec les indicateurs et les logs.

Le fil conducteur qui relie ces entrées de données est que chacune d’elles constitue un index d’Elasticsearch. Il n’y a aucune restriction sur les agrégations que vous exécutez sur ces données, sur la façon dont vous les visualisez dans Kibana et sur la manière dans l’alerting et le Machine Learning s’appliquent à chaque source de données. Pour en voir une démonstration, regardez cette vidéo.

Kubernetes observable et la Suite Elastic

L’une des communautés dans laquelle le concept d’observabilité est un sujet récurrent de conversation, c’est celle des utilisateurs qui adoptent Kubernetes pour l’orchestration des conteneurs. Ces utilisateurs « cloud native », terme popularisé par la Cloud Native Computing Foundation (ou CNCF), font face à des défis uniques. Ils se retrouvent confrontés à une centralisation massive d’applications et de services s’appuyant sur, ou ayant migrés vers, une plate-forme d’orchestration de conteneurs propulsée par Kubernetes. Ils constatent également qu’il existe une tendance à diviser les applications monolithiques en « microservices ». Les outils et méthodes qui donnaient auparavant la visibilité nécessaire sur les applications exécutées sur cette infrastructure sont désormais obsolètes.

L’observabilité sur Kubernetes mériterait de faire l’objet d’un article à part entière. De ce fait, nous vous invitons à consulter le webinar sur le Kubernetes observable et l’article sur le traçage distribué avec Elastic APM pour en savoir plus.

Et ensuite ?

Pour approfondir un sujet comme celui abordé ici, il nous semble essentiel de vous donner quelques clés pour poursuivre.

Pour en savoir davantage sur les bonnes pratiques de l’observabilité, nous vous recommandons de commencer par lire le livre dont nous avons parlé précédemment, le livre de Google sur la SRE. Ensuite, nous vous invitons à vous pencher sur les articles rédigés par des entreprises pour lesquelles il est essentiel que les applications critiques fonctionnent en continu pour la production. Ces articles donnent généralement matière à réflexion. Par exemple, cet article de l’équipe d’ingénierie Salesforce fait office de guide pragmatique et pratique pour améliorer l’état de l’observabilité de façon itérative.

Pour tester les capacités de la Suite Elastic dans le cadre de vos initiatives d’observabilité, tournez-vous vers la dernière version de notre suite sur Elasticsearch Service sur Elastic Cloud (un sandbox idéal même si vous effectuez un déploiement auto-géré au final) ou téléchargez et installez les composants de la Suite Elastic en local. Pensez à consulter les nouvelles interfaces utilisateur pour les logs, le monitoring d’infrastructure, APM et la disponibilité (prochainement dans la version 6.7) dans Kibana; qui sont conçues spécialement pour les workflows d’observabilité courants. Et n’hésitez pas à nous solliciter sur les forums de discussion si vous avez des questions. Nous sommes là pour vous aider !

La Suite Elastic (également connue comme Suite ELK) est une plateforme populaire de stockage de logs.

De nombreux utilisateurs commencent à stocker des logs sans structure, hormis l'horodatage et quelques étiquettes pour filtrer facilement les données. C'est exactement ce que fait Filebeat par défaut : suivre les logs et les envoyer à Elasticsearch aussi vite que possible, sans extraire de structures supplémentaires. Aussi, l'interface utilisateur de Logs dans Kibana ne tire aucune conclusion de la structure des logs. Un simple schéma "@timestamp" et "message" est suffisant. Schéma minimal, voici comment nous appelons ce type de logging. Il pèse moins sur le disque, mais présente peu d'utilité au-delà de la simple recherche de mots-clés et du filtrage d'étiquettes.

Une fois que vous vous serez familiarisé avec vos logs, vous éprouverez certainement le besoin de les exploiter davantage. Si vous identifiez des numéros dans les logs qui se rapportent à des codes d'état, il se peut que vous souhaitiez les compter pour savoir combien de codes d'état du type 5xx se sont produits dans l'heure. Les champs scriptés vous permettent d'appliquer un schéma aux logs au moment de la recherche pour extraire ces états et effectuer des agrégations, des visualisations et d'autres types d'actions. Cette approche de logging est souvent appelée schéma de lecture.

Bien que cette méthode soit pratique pour les explorations ad hoc, elle présente l'inconvénient de devoir exécuter l'extraction des champs chaque fois que vous effectuez une recherche ou actualisez une visualisation dans le cadre d'opérations continues de reporting et de présentation de tableau de bord. Au lieu de cela, une fois que vous avez choisi les champs structurés qui vous intéressent, un processus de réindexation peut être lancé en arrière-plan pour "perpétuer" ces champs scriptés dans des champs structurés au sein d'un index Elasticsearch permanent. Quant aux données transmises à Elasticsearch, vous pouvez configurer un Logstash ou un pipeline de nœuds d'ingestion pour extraire ces champs de façon proactive avec des processeurs dissect ou grok.

Cela nous mène à une troisième approche qui consiste à analyser les logs lors de leur écriture pour extraire de façon proactive les champs mentionnés ci-dessus. Ces logs structurés sont très appréciés des analystes, car ces derniers n'ont pas à réfléchir à la manière d'extraire les champs, ce qui leur permet d'accélérer leurs recherches et d'augmenter considérablement la valeur des résultats obtenus à partir des données des logs. De nombreux utilisateurs d'ELK ont adopté cette approche de "schéma d'écriture" d'analyse centralisée des logs.

Au fil de cet article, nous allons explorer les compromis que ces approches présupposent et les analyser du point de vue de la planification. Nous reviendrons sur la valeur intrinsèque de la structuration préalable des logs et sur les raisons à mon avis naturelles d'adopter cette méthode à mesure que votre déploiement de logging centralisé évolue, même si votre structure de départ est très simple.

Bénéfices du schéma d'écriture (cassons les mythes)

Analysons d'abord la raison pour laquelle nous devrions structurer des logs alors que nous les enregistrons dans un cluster de logging centralisé.

Une meilleure expérience de recherche. Lorsque nous recherchons des informations importantes dans des logs, nous recherchons naturellement et simplement des mots-clés, tels qu'"erreur". Nous pouvons obtenir des résultats à partir d'une telle recherche en considérant chaque ligne de log comme un document dans un index inversé, puis en effectuant une recherche plein texte. Cependant, que se passera-t-il lorsque nous donnerons des instructions plus complexes comme "renvoie toutes les lignes de log pour lesquelles mon_champ est égal à N" ? Si le champ mon_champ n'est pas défini, nous ne pourrons pas donner directement cette instruction. Aussi, même si votre log contient cette information, vous devrez écrire une règle d'analyse dans le cadre de votre recherche pour extraire le champ afin de le comparer à la valeur attendue. Dans la Suite Elastic, lorsque vous structurez vos logs au préalable, la fonction de saisie semi-automatique de Kibana suggère automatiquement des champs et des valeurs à mesure que vous construisez vos recherches. Ainsi, les analystes peuvent voir leur productivité considérablement augmenter. Vous et vos collègues pouvez désormais poser directement des questions sans avoir à connaître les champs ni à écrire des règles complexes d'analyse qui servent à extraire les champs au moment de la recherche.

Des recherches et des agrégations d'historique plus rapides. Même si elles interrogent des données historiques volumineuses, les recherches lancées sur des champs structurés dans la Suite Elastic renvoient des résultats en quelques millisecondes. Par comparaison, les systèmes habituels de "schéma de lecture" prennent des minutes voire des heures pour afficher leurs résultats. Les opérations de filtrage et d'agrégations statistiques exécutées sur des champs structurés extraits et indexés au préalable sont beaucoup plus rapides que l'exécution d'expressions régulières sur chaque ligne de log qui servent à extraire un champ et lui appliquer des opérations mathématiques. N'oublions pas que l'obtention des résultats ne peut pas être accélérée au préalable dans le cadre de recherches ad hoc, car nous ne savons pas quelles recherches nous exécuterons pendant l'investigation.

Des logs aux indicateurs. Dans le sillage du point précédent, les valeurs numériques extraites à partir de logs structurés ressemblent étonnamment à des séries temporelles numériques ou à des indicateurs. D'un point de vue opérationnel, l'exécution d'agrégations sur ces points de données produit rapidement des informations de grande valeur. Les champs structurés vous permettent de traiter des points de données numériques à partir de logs sous forme d'indicateurs à grande échelle.

La vérité n'attend pas. Lorsque vous rapprochez des champs comme l'adresse IP et le nom d'hôte, faites-le lors de l'indexation et non lors de la recherche, car si vous le faites trop tard, le rapprochement pourrait ne plus correspondre à la transaction qui vous intéresse. Au bout d'une semaine, une adresse IP peut être associée à un autre nom d'hôte. Cela s'applique aux recherches effectuées dans des sources externes. Ces dernières présentent l'instantané le plus récent du mapping, comme le rapprochement entre un nom d'utilisateur et des systèmes de gestion d'identité, une étiquette d'inventaire et une CMDB, etc.

Détection et signalement d'anomalies en temps réel. Tout comme les agrégations, les opérations de détection et de signalement des anomalies fonctionnent de la façon la plus efficace à grande échelle, et ce, avec des champs structurés. Autrement, les exigences de traitement continu de votre cluster seront très coûteuses. De nombreux clients choisissent de ne pas créer d'alertes ou de tâches de détection des anomalies, car l'extraction des champs lors de la recherche représente un effort trop important pour le nombre d'alertes dont ils ont besoin. Cela signifie que les données de log recueillies ne servent qu'aux cas d'utilisation essentiellement réactifs, ce qui limite le retour sur investissement de ces projets.

Les logs dans le cadre d'initiatives d'observabilité. Si vous participez à une initiative d'observabilité, vous savez que vous ne pouvez pas vous contenter de collecter et de rechercher les logs. Les données de log doivent idéalement être liées aux indicateurs (tels que l'utilisation des ressources) et aux traces d'application pour qu'elles puissent raconter une histoire holistique à l'opérateur sur les événements du service, et ce, quelle que soit l'origine des points de données. Ces corrélations fonctionnent de façon optimale avec les champs structurés. Sinon, les recherches sont lentes, et l'analyse est inutilisable dans les situations pratiques à grande échelle.

Qualité des données. Lorsque vos événements sont préalablement traités, vous avez la possibilité d'identifier les données non valides, en double ou manquantes, puis de corriger ces problèmes. Avec le "schéma de lecture", vous ne savez pas si vos résultats sont précis, car la validité et l'exhaustivité de vos données n'ont pas été vérifiées au préalable. Les résultats obtenus pourraient être inexacts, et vous risquez par conséquent de tirer des conclusions incorrectes.

Contrôle d'accès granulaire. Il est difficile d'appliquer des règles de sécurité granulaires, telles que des restrictions au niveau du champ, à des données de log non structurées. Les filtres qui restreignent l'accès aux données lors de la recherche peuvent être utiles, mais ils présentent des limites considérables, telles que l'incapacité de renvoyer des résultats partiels pour constituer un sous-ensemble de champs. Dans la Suite Elastic, la sécurité au niveau du champ permet aux utilisateurs bénéficiant de moins de privilèges de consulter certains champs et pas d'autres dans tout l'ensemble de données. Ainsi, les données personnelles des logs peuvent être facilement protégées, et ce, avec flexibilité, tout en permettant à un ensemble plus vaste d'utilisateurs d'exploiter le reste des informations.

Exigences matérielles

L'un des mythes à propos du "schéma d'écriture" soutient que votre cluster aura besoin de plus ressources pour analyser les logs et stocker à la fois les formats analysés (ou "indexés") et non analysés. La réponse étant "ça dépend", examinons les facteurs à prendre en compte selon votre cas d'utilisation.

Analyse unique ou extraction continue de champs. L'analyse et le stockage des logs dans un format structuré utilisent des capacités de traitement au niveau de l'ingestion. Cependant, l'exécution répétée de recherches dans des logs non structurés qui reposent sur des déclarations complexes d'expressions régulières pour extraire des champs consomme à la longue beaucoup plus de mémoire vive et de ressources du CPU. Si le cas d'utilisation applicable à vos logs consiste à permettre quelques recherches occasionnelles, la structuration préalable des logs pourrait requérir un effort démesuré. En revanche, si vous prévoyez que vos logs fassent l'objet de recherches et d'agrégations fréquentes, le coût unique d'ingestion pourrait être inférieur aux coûts incessants liés à la réexécution des mêmes opérations lors de chaque recherche.

Exigences en matière d'ingestion. Avec des traitements préalables supplémentaires, votre débit d'ingestion risque de baisser un peu. Vous pouvez accroître votre infrastructure d'ingestion pour compenser cette charge en scalant indépendamment vos nœuds d'ingestion Elasticsearch ou vos instances Logstash. D'excellents blogs et références indiquent comment procéder. Si vous utilisez Elasticsearch Service dans Elastic Cloud, il suffit d'ajouter des nœuds capables d'effectuer des ingestions pour monter l'ingestion en charge.

Besoins de stockage. À vrai dire, même si cela semble contre-intuitif, les besoins de stockage pourraient diminuer si vous faites l'effort de comprendre au préalable la structure de vos logs. Les logs peuvent contenir trop d'informations et détourner l'attention de l'utilisateur. En les examinant à l'avance (même si vous n'analysez pas tous les champs), vous pouvez distinguer les lignes de log et les champs extraits à conserver en ligne dans votre cluster de logs centralisé de ceux que vous préférez archiver immédiatement. Cette approche permet d'éviter de stocker des logs qui comportent des données partiellement inutiles, susceptibles de détourner l'attention de l'utilisateur. Il s'agit ni plus ni moins de la mission des processeurs légers dissect et drop de Filebeat.

Même si, pour des raisons réglementaires, vous devez conserver chaque ligne de log, il existe des façons d'optimiser les coûts de stockage liés au "schéma d'écriture". N'oubliez pas que vous êtes aux commandes. Rien ne vous oblige à structurer complètement vos logs. Si votre cas d'utilisation vous le permet, ajoutez seulement les métadonnées structurées dont vous avez vraiment besoin et ignorez le reste de la ligne de log. Autrement, si vous structurez complètement vos logs et que chaque portion de données importantes est transmise à un stockage structuré, il est inutile de conserver le champ d'origine dans le cluster qui contient les logs indexés. Vous pouvez l'archiver dans un stockage à bas prix.

Si le stockage vous inquiète particulièrement, il existe de nombreuses façons d'optimiser Elasticsearch. Par exemple, vous pouvez augmenter les taux de compression avec seulement quelques réglages. Vous pouvez aussi utiliser les architectures hot-warm et le gel des indices pour optimiser le stockage à long terme des données peu utilisées. Néanmoins, si vous souhaitez éviter de longues minutes d'attente lorsque vous avez besoin de résultats rapides, n'oubliez pas que le stockage des données hot est relativement bon marché.

Définition préalable de la structure

Voici un autre mythe : il est difficile de structurer des logs avant de les stocker. Revenons sur cette affirmation.

Logs structurés. De nombreux logs sont déjà produits dans des formats structurés. JSON est pris en charge comme format de logging par les applications les plus courantes. Vous pouvez donc commencer à transmettre vos logs directement à Elasticsearch et à les stocker dans des formats structurés sans avoir à les analyser.

Règles d'analyse préconstruites. Elastic est officiellement compatible avec des dizaines de règles d'analyse préconstruites. Par exemple, les modules Filebeat structurent les logs de certains fournisseurs, alors que Logstash contient une bibliothèque de modèles grok. Bien d'autres règles d'analyse préconstruites sont disponibles auprès de la communauté.

Règles d'analyse autogénérées. Des outils comme Kibana Data Visualizer aident à définir des règles pour extraire les champs de logs personnalisés en vous suggérant automatiquement des façons de les analyser. Collez un échantillon de log, puis obtenez un modèle grok que vous pourrez utiliser dans le nœud d'ingestion ou dans Logstash.

Que se passe-t-il lorsque le format de votre log change ?

Voici un dernier mythe : le "schéma d'écriture" complique la prise en compte des modifications apportées aux formats de log. C'est simplement faux : quelqu'un devra s'occuper des changements de format de log, et ce, quelle que soit l'approche choisie pour extraire les données de vos logs, à moins que vous ne vous contentiez d'effectuer des recherches plein texte. Que vous utilisiez un pipeline de nœuds d'ingestion qui traite les logs au moyen d'un modèle grok lors de leur indexation ou un champ Kibana scripté qui procède de la même façon au moment de la recherche, la logique qui permet d'extraire les champs devra être adaptée chaque fois que le format des logs sera modifié. Quant aux modules Filebeat dont nous assurons la maintenance, nous guettons les nouvelles versions des logs que vous recevez en amont pour effectuer les modifications de compatibilité et les tests nécessaires.

Voici plusieurs façons de traiter les modifications de structure de log au moment de l'écriture.

Modifier la logique d'analyse en amont. Si vous savez que le format du log va changer, vous pouvez créer un pipeline de traitement parallèle et recevoir les deux versions du log pendant une période de transition. Cela s'applique généralement au format des logs dont vous avez le contrôle en interne.

Écrire un schéma minimal en cas d'échec d'analyse. Il est parfois impossible de connaître les modifications à l'avance, et il arrive que les logs dont nous n'avons pas le contrôle changent sans préavis. Vous pouvez prévoir cette possibilité dans le pipeline de logs dès le départ. En cas d'échec de l'analyse grok, utilisez le schéma minimal qui sépare l'horodatage du reste du message, puis envoyez un message à l'opérateur. À partir de là, vous pouvez créer un champ scripté pour le nouveau format du log afin de ne pas interrompre le workflow de l'analyste, modifier le pipeline, puis envisager de réindexer les champs pour la durée de l’interruption dans la logique d'analyse.

Retarder l'événement d'écriture en cas d'échec d'analyse. Si aucun schéma minimal ne répond à vos besoins, vous pouvez empêcher l'écriture de la ligne de log en cas d'échec de la logique d'analyse, puis placer l'événement dans une "file d'attente de lettres mortes" (cette fonctionnalité est prête à l'emploi dans Logstash) avant d'envoyer une alerte à l'opérateur chargé de réparer la logique et de réexécuter les événements de la file d'attente de lettres mortes dans le nouveau pipeline d'analyse. Cette solution interrompt l'analyse, mais vous n'aurez pas à créer de champs scriptés ni à procéder à des réindexations.

Une analogie appropriée

Je ne pensais pas que cet article serait aussi long. Je vous félicite d'être arrivé jusqu'ici ! Les bonnes analogies m'aident à intérioriser les concepts. Neil Desai, spécialiste de la sécurité chez Elastic, m'a récemment présenté l'une des meilleures analogies pour comparer le "schéma de lecture" et le "schéma d'écriture". J'espère qu'elle vous sera utile.

Pour conclure, le choix vous appartient

Comme je l'ai annoncé dès le départ, il n'y a pas forcément une réponse unique pour chaque déploiement de logging centralisé qui nous indique le schéma à adopter. En réalité, la plupart des déploiements que nous observons sont à mi-chemin ; certains logs sont très structurés alors que d'autres suivent le schéma le plus simple (@timestamp et message). Tout dépend de ce que vous voulez faire avec les logs et de vos préférences. Préférez-vous la vitesse et l'efficacité des recherches structurées, ou la possibilité d'écrire les données aussi vite que possible sur le disque sans rien faire en amont ? La Suite Elastic accepte les deux approches.