Nous sommes ravis d'annoncer le lancement de la version 7.3 de la Suite Elastic. D'autant que c'est encore un bon cru.

Dans ce blog, nous allons survoler quelques-unes des grandes nouveautés. Pour tout savoir sur un produit donné et ses nouveautés, n'hésitez pas à consulter l'article de blog qui lui est consacré. Trop impatient d'essayer ? Sachez que la version 7.3 est d'ores et déjà disponible via Elasticsearch Service – la seule offre Elasticsearch hébergée à proposer ces nouvelles fonctionnalités. Si vous préférez télécharger la Suite Elastic, c'est par ici.

Et ces nouveautés, me direz-vous ? Les voici.

Vue matérialisée, index centrés sur les entités... Bienvenue dans les trames de données

Les trames de données ont fait leur entrée. Il s'agit d'une nouvelle fonctionnalité, qui vous permet de réorganiser vos données Elasticsearch à la volée, pour créer des index dynamiques centrés sur les entités. C'est une fonctionnalité passionnante, qui ouvre de nouveaux horizons à l'analyse, y compris aux nouvelles fonctionnalités d'analyse de Machine Learning, comme le clustering, la classification, ou encore la détection de données aberrantes (que nous venons d'ajouter comme fonctionnalité expérimentale dans la version 7.3).

Mais prenons un exemple. Cela vous permettra de mieux cerner toute la puissance de cette fonctionnalité. Imaginons que vous deviez rechercher des adresses IP suspectes dans les logs de votre serveur web. Par exemple, vous pouvez rechercher le nombre de requêtes envoyées, les codes de réponse obtenus et le volume total des données transmises pour chaque adresse IP. C'est là que les trames de données entrent en jeu : elles vous permettent de créer un nouvel index centré sur l'entité, avec un document par adresse IP unique, qui effectue le suivi de chacun des indicateurs qui vous intéresse – à savoir, dans notre exemple : le nombre total de requêtes, le nombre de réponses classées par état de la réponse, et le nombre total d'octets transmis. Cerise sur le gâteau : les trames de données sont compatibles avec le traitement continu. Autrement dit, cet index transformé axé sur l'entité est automatiquement mis à jour, à mesure que de nouveaux documents sont ajoutés à l'index d'entrée.

Avec les trames de données, nous avons développé un moteur ultrapuissant, qui vous permet transformer vos données pour de nouveaux types d'analyse. Ces réorganisations dynamiques ne sont que les premières transformations que les trames de données rendent possibles. Nous sommes impatients de vous annoncer d'autres transformations, qui viendront étendre le concept de trames de données à d'autres cas d'utilisation.

En savoir plus sur les trames de données.

Parce que les règles ne suffisent pas, Elastic SIEM intègre la détection des anomalies

Nous avions lancé notre solution SIEM avec la version 7.2, et depuis, nous y avons travaillé sans relâche.

Les règles à elles seules permettent rarement d'arrêter les intrus. Dans la version 7.3, nous avons donc amélioré les workflows de détection et de recherche de menaces d'Elastic SIEM. Comment ? En intégrant directement nos fonctionnalités de machine learning au cœur de l'application SIEM. Les utilisateurs peuvent désormais activer et exécuter un ensemble de tâches de machine learning dédiées à la détection des anomalies et conçues pour déceler des comportements de cyberattaque spécifiques. Le tout, directement depuis l'application SIEM. Les anomalies détectées s'affichent dans les vues "Hosts" (Hôtes) et "Network" (Réseau) de l'application SIEM.

Et pour aller plus loin que les tâches prédéfinies, vous pouvez aussi créer des tâches personnalisées de détection des anomalies via l'application Machine Learning.

Avec cette intégration, exploiter le machine learning pour la détection des comportements malveillants devient plus simple que jamais. L'article de blog consacré au lancement d'Elastic SIEM vous dit tout.

Elastic Maps passe en disponibilité générale

Les données géographiques ont toujours fait partie des composants essentiels de la recherche : qu'il s'agisse de rechercher la source des attaques que subit un réseau, de diagnostiquer la lenteur des temps de réponse dans une région donnée, d'effectuer le suivi de camions de livraison en temps réel, ou simplement de trouver la meilleure pizzeria à proximité. C'est pourquoi, depuis le début (c'est-à-dire depuis la version 0.9.1 !), nous ne cessons de doper la rapidité, la puissance et l'efficacité des fonctionnalités géospatiales de la Suite Elastic.

Nous avons ainsi lancé Elastic Maps en bêta dans la version 6.7. Objectif : rendre l'exploration et la compréhension des données géospatiales de Kibana plus intuitives et plus interactives. Ce faisant, nous jetions des bases robustes pour la suite. Avec cette version 7.3, nous sommes heureux d'annoncer que Maps est maintenant prêt pour la production.

Mais ce n'est pas tout : Elastic Maps fait aussi le plein de nouvelles fonctionnalités. Parmi elles, la possibilité d'importer des fonctionnalités, des formes et des couches dans vos cartes depuis des fichiers GeoJSON. Autre nouveauté qui booste l'expérience utilisateur : la possibilité de créer des icônes personnalisées et de visualiser le dernier emplacement connu.

Pour tout savoir sur Maps, consultez l'article de blog qui lui est consacré. J'avoue que nous sommes très fiers d'avoir franchi ce nouveau cap avec Elastic Maps. Nous attendons avec impatience que vous découvriez les nouvelles fonctionnalités de la version 7.3, mais aussi celles que nous sommes en train de vous concocter pour des versions ultérieures.

Et ce n'est pas tout

Loin de là. N'hésitez donc pas à consulter les articles de blog que nous consacrons à chaque produit pour découvrir toutes les nouveautés de la version 7.3. Par exemple :

• Elasticsearch introduit les nœuds maîtres "voting-only" (c'est-à-dire des nœuds maîtres qui ne peuvent que voter sans pouvoir être élus) ; s'enrichit de l'agrégation tant attendue des termes rares ; propose une nouvelle interface utilisateur de gestion des instantanés et de la restauration ; prend en charge la mise à jour dynamique des synonymes, et bien plus encore. Pour tout savoir sur la nouvelle version d'Elasticsearch, consultez l'article de blog dédié.
• Kibana prend désormais en charge Kerberos, la saisie semi-automatique, et KQL pour le filtrage des agrégations, mais aussi les modèles de présentation Canvas pour faciliter la création de superbes affichages. Et on est loin de vous avoir tout dit.
• Beats est compatible avec une pléthore de nouvelles sources de données. Citons les bases de données relationnelles comme Oracle et Amazon RDS, les indicateurs Kubernetes kube-proxy, kube-scheduler et kube-controller-manager, la prise en charge de flux réseau pour les logs de flux VPC de GCP, ou encore l'amélioration de la prise en charge d'Amazon Cloudwatch et des flux de données Amazon Kinesis avec Functionbeat. Pour en savoir plus, découvrez l'article de blog consacré à la nouvelle version de Beats.
• Logstash est désormais compatible JMS par défaut.
• L'agent .NET d'Elastic APM passe en disponibilité générale. De plus, Elastic APM propose une nouvelle façon d'afficher les services, avec des tableaux de répartition des services, ou encore la configuration du taux d'échantillonnage de l'agent directement depuis Kibana, pour ne citer qu'une infime partie des nouveautés.
• Elastic Uptime améliore l'apparence des moniteurs multisites et affiche des informations récapitulatives et détaillées sur les moniteurs.
• Elastic Logs permet la mise en surbrillance de mots-clés et donne la possibilité de passer directement à certaines traces APM en fonction de leur identifiant trace.id.
• Dans l'application Elastic Infrastructure, Metrics Explorer, qui vous permet de créer des visualisations d'agrégation à partir d'indicateurs de séries temporelles, est maintenant prêt pour les systèmes de production. L'application Elastic Infrastructure, quant à elle, propose un monitoring optimisé, et prend en charge de nouveaux services Kubernetes stratégiques, ainsi qu'un nouvel ensemble d'indicateurs RDS dans le module AWS. Envie d'en savoir plus ? Découvrez l'article de blog consacré à la nouvelle version d'Elastic Infrastructure.

En espérant que vous prendrez autant de plaisir à découvrir ces nouveautés que nous en avons eu à les créer.

Nous avons le plaisir d'annoncer qu'Elasticsearch Service sur Elastic Cloud est désormais compatible avec les déploiements sur Microsoft Azure. Le lancement d'Elasticsearch Service sur Azure sera une excellente nouvelle pour un grand nombre de nos utilisateurs de services gérés qui recherchent plus d'options de fournisseur cloud et apprécient la grande portée mondiale d'Azure. Les entreprises ayant effectué leur standardisation sur Azure pourront maintenant profiter de la commodité d'un Elasticsearch Service entièrement géré, fourni par les créateurs d'Elasticsearch, sur la plateforme cloud de leur choix, ce qui n'était pas possible jusqu'ici.

Les utilisateurs d'Elasticsearch Service sur Azure peuvent désormais déployer des services Elasticsearch et Kibana fournis par les créateurs du logiciel et entièrement hébergées en un seul clic. Les clients existants d'Elasticsearch Service peuvent lancer des déploiements sur Azure avec leur compte existant, tandis que les nouveaux utilisateurs peuvent se lancer avec un essai d’Elasticsearch Service gratuit de 14 jours.

L'ajout d'Elasticsearch Service à Azure est l'un de nos moyens pour améliorer encore l'expérience des utilisateurs de la Suite Elastic et des produits de Microsoft. De nombreux utilisateurs déploient déjà Elasticsearch sur Azure, en utilisant souvent le modèle ARM pour la Suite Elastic, qui a été lancé en collaboration il y a plusieurs années. Nous prenons en charge les technologies de Microsoft dans d'autres domaines, par exemple avec nos clients .NET, Winlogbeat pour les ensembles d'événements WindowsOS, l'intégration d'Azure Active Directory pour protéger les clusters Elasticsearch et la prise en charge de .NET dans notre produit Elastic APM. La collaboration avec Microsoft est importante, car elle nous aide à servir notre communauté d'utilisateurs communs.

Elasticsearch Service sur Elastic Cloud est le service Elasticsearch et Kibana hébergé officiel créé et pris en charge par Elastic. Il propose des fonctionnalités telles qu'Elastic APM, SIEM, Maps, Canvas, le machine learning et bien plus encore, et une expertise d'assistance technique que vous ne trouverez nulle part ailleurs. Les utilisateurs peuvent se servir d'Elasticsearch et de Kibana en toute confiance, certains de toujours disposer de la dernière version et des derniers correctifs de sécurité et de pouvoir mettre à jour leurs déploiements en un seul clic, sans aucune indisponibilité.

Et maintenant, les clients d'Azure peuvent profiter de tous ces avantages.

"L'importance accordée par les deux entreprises aux développeurs et à l'aspect open source ont rendu cette intégration très naturelle. L'engagement de Microsoft envers les choix est évident dans leur expérience de développement sur Microsoft Azure, et il reflète bien le nôtre", déclare Shay Banon, fondateur et PDG d'Elastic.

Scott Guthrie, VPE de Cloud + AI, Microsoft Corp., explique : "Lorsque les clients adoptent les services cloud, pouvoir proposer une solution répondant à leurs besoins les plus importants, comme la recherche, le logging, l'observabilité et la sécurité de leurs applications critiques, est un avantage essentiel. L'importance que Microsoft et Elastic accordent aux choix des développeurs et aux services gérés profitera à nos clients mutuels."

La version bêta publique est disponible pour tous les clients d'Elasticsearch Service et les clients d'essai dans deux régions Azure : East US 2 en Virginie et West Europe aux Pays-Bas. Elle comprend la totalité des fonctionnalités d'Elasticsearch Service. Le support technique d'Elastic, y compris le niveau de service critique, est disponible pendant la période de la version bêta. Plus tard en 2019, nous quitterons la version bêta pour passer en version définitive.

Dans le cadre du lancement de notre version bêta, nous proposons également une période promotionnelle pendant laquelle le transfert de données (entrée/sortie/entre les nœuds) et le stockage des snapshots (taille totale du stockage et demandes) sont gratuits. Nous sommes impatients de découvrir vos commentaires pendant la version bêta publique, et nous annoncerons plus d'informations sur la période promotionnelle peu après.

Les équipes d'ingénieurs d'Elastic et de Microsoft on collaboré pour évaluer et sélectionner soigneusement les VM optimales afin de supporter divers cas d'utilisation Elastic avec différents profils de performance lors de l'exécution d'Elasticsearch Service sur Azure. Cet effort a permis d'aboutir à quatre modèles de déploiement pour optimiser Elasticsearch Service sur Azure :

• E/S hautes performances : idéal pour les cas d'utilisation de recherche ou généraux, ce modèle s'exécute sur les VM de la série L ayant des SSD NVMe locaux optimisés pour les lectures/écritures hautes performances.
• Hot/Warm : une architecture puissante idéale pour les cas d'utilisation de logging et de séries temporelles, qui associent les SSD NVMe pour un accès rapide et un ratio RAM:disque de 1:100 avec un stockage HDD pour une conservation rentable prolongée.
• Processeur hautes performances : souvent utilisé pour les scripts, les calculs, le traitement d'ingestion ou les autres cas d'utilisation nécessitant d'importantes ressources de calcul, ce modèle permet de doubler les performances du processeur.
• Grandes capacités de mémoire : offre une option rentable aux cas d'utilisation de recherche pour les volumes de données plus faibles.

Il suffit aux utilisateurs existants d'Elasticsearch Service de se connecter et de sélectionner les régions Azure lors de la création d'un déploiement. Si vous cherchez à effectuer une migration depuis les systèmes que vous gérés manuellement, consultez notre documentation. Vous trouverez également d'autres détails dans ce webinar. Nous nous efforçons de simplifier la migration le plus possible et de l'améliorer à chaque version.

Cet article fait partie d'une série de témoignages d'utilisateurs provenant de notre campagne #ElasticStories. Si vous êtes intéressé(e) et souhaitez partager à votre tour votre expérience, taguez-nous sur Twitter en utilisant #ElasticStories.

Le contexte

Fondé en 2012, Synapticiel se spécialise dans l’exploration et l’analyse big data en télécommunication. Nous proposons la solution S-One, permettant à nos clients de pouvoir mieux exploiter leurs données et les aider dans leur prise de décision. S-One offre une architecture distribuée basée sur la Suite Elastic pour stocker et visualiser et analyser en temps réel les données générées par l’ensemble des switches réseaux de l’opérateur.

Cette solution a été présentée chez un opérateur mobile en Afrique de l’ouest qui compte près de 3 millions d’abonnés et offre des services Internet 3G/4G pour une clientèle variée dans un marché de plus en plus exigeant.

Situation technique

Environ 50 millions de CDR (Call Detail Record) sont générés chaque jour par différents noeuds de réseau (AIR, SDP, CCN, OCC, MSC, CGSN, SMSC). Le système décisionnel existant de notre client comporte 4 fonctions techniques principales :

• un outil de médiation pour collecter et transformer les données,
• un ensemble de scripts ETL (Extraction Transformation Lead),
• un Datawarehouse (DWH) principalement composé d'une base de données Oracle 11g,
• un serveur Business Intelligence ,exploité par la plateforme SAP Business Object pour la conception des univers et pour la couche présentation.

Le système décisionnel de notre client présentait plusieurs faiblesses dans les domaines suivants :

• Scalabilité : originellement conçu pour supporter la charge de 500 000 abonnés, le système n’était plus en mesure de suivre la croissance lorsque le nombre d’abonnés fut multiplié par 6.
• Flexibilité : L’ETL ne pouvait plus s’adapter aux changements de structure des fichiers, incapable de gérer l’exhaustivité des données et d’assurer un système d’alerte dynamique.
• Standard : La nomenclature des types de fichiers évoluant avec le temps rendait les contrôles de saut inefficace et forçait des rejeux manuels des fichiers dans le système
• Performance : l’exécution des requêtes et le chargement des données étaient inefficaces causant une multitude de problèmes de performance et dysfonctionnements.
• Configuration : les comptes dédiés et les règles de gestion pour le calcul des indicateurs n’étant pas sauvegardées sur le système, rendait la gestion difficile à chaque mise à jour de l’outil de reporting BO.
• Agilité : les utilisateurs étaient aussi contraints de demander auprès des administrateurs les fichiers dont ils avaient besoin.

Déployer la solution S-One “Events Mediation & Streaming Analytics”

Pour remédier intégralement à l’ensemble des problèmes du système décisionnel de notre client, nous avons proposé une solution unique basée sur S-One “Streaming Analytics”.

S-One est bâtie autour d’une bibliothèque de plus de 170 connecteurs qui récupèrent en temps réel les logs générés par les différents nœuds du réseau. Ces logs sont collectés, décodés, formatés, enrichis puis transformés en un format unifié pour faciliter les analyses métiers. La Suite Elastic a été choisie comme socle principal de la solution S-One en raison du caractère complet, distribué et scalable de la suite. Ce sont 3 critères essentiels pour garantir l’élasticité d’une solution Big Data pour le secteur de la télécommunication.

Parallèlement plus de 50 KPIs sont calculés par abonné et par jour en continu :

La nouvelle solution traite en moyenne plus de 50 millions CDR par jour, la répartition par source de données est la suivante :

Notre configuration de la Suite Elastic repose sur la version 6.5.2 avec pour socle Elasticsearch, Logstash et Kibana. Voici un aperçu de l’architecture :

S-One Features

L’un des besoins majeurs de notre client est la visibilité en quasi temps réel de l’activité business, en l’occurrence :

• L’évolution du chiffre d’affaire de recharges
• L’évolution du chiffre d’affaires de consommation par type (voice, sms, data, VAS, expiration des crédits)

Pour répondre à ces besoins nous avons mis en place une chaîne de collecte combinant 2 approches de traitement des données :

• Stream Processing : Pour accélérer la mise à disposition des dashboards dynamiques en temps réel, et calculer des KPIs par abonné
• Batch processing : Pour faire des contrôles supplémentaires pour s’assurer de l’exhaustivité des fichiers collectés et traités.

Ces approches sont possibles grâce à la flexibilité, la scalabilité et les performances offertes par la Suite Elastic :

• Logstash : une fois les fichiers collectés et décodés (transformation d’un format binaire ASN1 vers un format Json), Logstash applique des transformations, corrélations et enrichissements pour faire correspondre chaque événement àun format métier plus riche en informations.
• Elasticsearch : stocke les données envoyées depuis une instance Logstash, les indexe et répond en quasi temps réel aux requêtes de recherche et aux agrégations, indépendamment du nombre de documents présents
• Kibana : permet la visualisation en quasi temps réel des KPIs business.

Conclusion

Grâce à la Suite Elastic, nous avons rapidement consolidé l’ensemble des flux Ericsson en temps réel (60 millions d’événements par jour) et construit les tableaux de bord permettant de suivre les KPI métiers des activités dont :

• Chiffre d’affaires de la recharge, par canal (Recharges Physique, Électronique, Mobile Money)
• Chiffre d’affaires VAS (Services à valeur ajoutés) par Produit/Service et par jour
• Consommation prépayés Voix/SMS/Data, par type (Local/Roaming) et par destination, par jour
• Consommation par compte, par service et par jour
• Crédit principal disponible et crédit expiré par jour
• Statistique du parc (Activation, Déconnexion, Gross Add, Parc Actif, Parc par Opérateur)

A l’aide de la Suite Elastic nous avons posé l'infrastructure logicielle d’une solution évolutive, scalable, standard et performante qui assurera la réponse aux besoins futurs de notre client. La richesse de la Suite Elastic nous a permis d’adresser des nouveaux cas d’utilisation dans le secteur des télécoms et il continue à nous accompagner avec succès dans le déploiement de la roadmap de notre solution S-One.

Yassine LASRI est le CEO et co-fondateur de Synapticiel, une société fondée en 2012 qui se spécialise en Big Data Analytics dans le secteur des télécoms. Il est responsable du développement commercial et des relations d'affaires stratégiques au niveau mondial. Aspirant à l'innovation en entreprise et avec plus de 12 ans d'expérience en conception de solutions OSS/BSS, RA & FMS, Yassine utilise ces nouvelles technologies pour résoudre avec succès des problématiques de Big Data Analytics dans le secteur des télécoms.

En février 2019, nous avons présenté Elastic Common Schema (ECS) dans un article de blog et un webinar. Pour résumer en quelques mots : en définissant un ensemble commun de champs et de types de données, ECS permet une recherche uniforme, la visualisation et l’analyse de sources de données disparates. Il s’agit d’un avantage énorme pour les environnements hétérogènes constitués de différentes normes fournisseur, dans lesquels il est fréquent d’utiliser de façon concomitante des sources de données similaires mais différentes.

Autre point que nous avons souligné : l'implémentation d'ECS n'a rien d'une tâche anodine. Pour pouvoir générer des événements compatibles avec ECS, de nombreux champs émis par les sources des événements doivent être copiés ou renommés lors du processus d’ingestion des données.

Nous avons conclu la présentation d’ECS en indiquant que, si vous avez déjà configuré un modèle d'index Elasticsearch et écrit quelques fonctions de transformation avec Logstash ou les pipelines d'ingestion Elasticsearch, vous aurez une idée assez juste de ce que cela implique. Selon la façon dont vous avez conçu vos pipelines d’ingestion de données de la Suite Elastic, le volume de travail requis pour migrer votre environnement vers ECS sera variable. À l’une des extrémités du spectre, Beats et les modules Beats permettront une migration optimisée vers ECS. Les événements Beats 7 sont déjà au format ECS. La seule tâche qu’il reste à faire, c’est de faire le lien entre le contenu d’analyse existant et les nouvelles données ECS. À l’autre extrémité du spectre, on retrouve les pipelines personnalisés ayant été conçus par les utilisateurs.

En juin, nous avons également présenté un webinar expliquant comment effectuer une migration vers ECS. Dans cet article de blog, nous nous baserons sur les éléments que nous avons abordés dans le webinar et exploreront plus en détail la migration vers ECS au sein des environnements Beats. En ce qui concerne la migration des pipelines personnalisés d’ingestion des données vers ECS, ce sujet sera abordé dans un futur article de blog.

Voici les différents thèmes que nous étudierons aujourd’hui :

• Migration vers ECS avec la Suite Elastic 7
• Présentation conceptuelle d’une migration vers ECS
• Présentation de la migration d’un environnement Beats vers ECS
• Mise en place de votre propre stratégie en matière de migration
• Exemple de migration
• Conclusion
• Références

Migration vers ECS avec la Suite Elastic 7

Ayant réalisé que renommer les champs d’événements utilisés par Beats occasionnerait un certain bouleversement, nous avons lancé les noms de champs ECS dans notre dernière version majeure, c.-à-d. la version 7 de la Suite Elastic.

Dans cet article, nous commencerons par donner un aperçu détaillé de la migration vers ECS avec Beats, dans le cadre d’une mise à niveau de la Suite Elastic de la version 6.8 vers la version 7.2. Nous poursuivrons avec un exemple de migration pas à pas d’une source d’événement Beats.

Attention : cet article de blog n’abordera qu’une partie de la migration vers la version 7. Comme suggéré par nos directives de mise à niveau des stacks, Beats doit être mis à niveau après Elasticsearch et Kibana. Dans l’exemple de migration que nous étudierons ci-dessous, nous présenterons uniquement la mise à niveau de Beats, et partirons donc du principe qu’Elasticsearch et Kibana ont déjà été mis à niveau vers la version 7. Nous pourrons ainsi nous attacher aux spécificités de la mise à niveau de Beats à partir du schéma "avant ECS" vers ECS.

Lorsque vous passerez à la version 7 de la Suite Elastic, n’oubliez pas de lire auparavant les directives susmentionnées, de consulter l’assistant de mise à niveau Kibana, et bien sûr, de prendre connaissance des notes de mise à niveau et des changements majeurs apportés concernant la partie du stack que vous utilisez.

Remarque : si vous envisagez d’adopter Beats, mais que vous n’avez aucune donnée venant de Beats 6, ne vous faites pas de souci concernant la migration. Dans ce cas, commencez tout simplement à utiliser Beats version 7 ou supérieure, qui génère des événements mis en forme pour ECS directement prêts à l’emploi.

Présentation conceptuelle d’une migration vers ECS

Quelle que soit la migration effectuée vers ECS, celle-ci impliquera les étapes suivantes :

1. Convertir vos sources de données pour ECS
2. Résoudre les différences et les conflits entre les formats d’événement "avant ECS" et les événements ECS
3. Régler le contenu d’analyse, les pipelines et les applications pour utiliser les événements ECS
4. Rendre les événements "avant ECS" compatibles avec ECS pour fluidifier la transition
5. Supprimer les alias de champ une fois que toutes les sources ont été migrées vers ECS

Dans cet article de blog, nous allons nous pencher sur chacune de ces étapes, dans le cadre spécifique d’une migration d’un environnement Beats vers ECS.

Suite à cette présentation des étapes, nous illustrerons la théorie par la pratique avec un exemple de migration d’un module Filebeat de la version 6.8 vers la version 7.2. Cet exemple de migration est extrêmement simple, le but étant que vous puissiez facilement le reproduire sur votre poste de travail, réaliser chaque étape de la migration et faire des tests tout au long du processus.

Présentation de la migration d’un environnement Beats vers ECS

Il existe bien des façons d’appréhender les étapes de migration indiquées ci-dessus. Nous allons les passer en revue une à une dans le cadre de la migration de vos événements Beats vers ECS.

Convertir les sources de données pour ECS

Beats dispose de nombreuses sources d’événement optimisées. À partir de la version 7, ces sources sont déjà converties au format ECS. Les processeurs Beats qui ajoutent des métadonnées à vos événements (comme add_host_metadata) sont aussi convertis vers ECS.

Toutefois, il est important de comprendre que Beats fait parfois office de simple moyen de transport pour vos événements. Par exemple, pour les événements collectés par Winlogbeat et Journalbeat, ainsi que pour les entrées Filebeat via lesquelles vous utilisez des logs et des événements personnalisés (autres que les modules Filebeat eux-mêmes). Vous devrez mapper à ECS chaque source d’événement personnalisée que vous collectez et analysez par vous-même.

Résoudre les différences et les conflits liés aux schémas

Cette migration vers ECS consiste à normaliser les noms de champ sur de nombreuses sources de données. De ce fait, un grand nombre de champs vont être renommés.

Renommages et alias de champ

Il existe plusieurs façons de travailler avec les événements "avant ECS" et les événements ECS au cours de la transition entre les deux formats. Voici les principales :

• Utiliser les alias de champ Elasticsearch afin que les nouveaux index reconnaissent les anciens noms de champ
• Dupliquer les données dans le même événement (pour renseigner aussi bien les anciens champs que les champs ECS)
• Ne rien faire : l’ancien contenu fonctionne uniquement avec les anciennes données, tandis que le nouveau contenu fonctionne uniquement avec les nouvelles données

L’approche la plus simple et la plus économique est d’utiliser les alias de champ Elasticsearch. C’est cette approche que nous avons choisie pour la procédure de mise à niveau de Beats.

Sachez néanmoins que les alias de champ sont soumis à certaines limitations et qu’ils ne constituent pas une solution parfaite. Voyons en quoi ils peuvent nous aider et quelles sont leurs limitations.

Les alias de champ sont de simples champs supplémentaires dans le mappage Elasticsearch de nouveaux index. Ils permettent aux nouveaux index de répondre aux recherches à l’aide des anciens noms de champ. Prenons un exemple. Dans cet exemple, nous utiliserons seulement un champ unique dans un souci de simplicité :

Plus précisément, les alias de champ seront utiles dans les cas suivants :

• Agrégations et visualisations sur le champ d’alias
• Filtrage et recherche sur le champ d’alias
• Saisie semi-automatique dans le champ d’alias

Voici les limitations des alias de champ :

• Les alias sont, par essence, une simple fonctionnalité des mappages Elasticsearch (index de recherche). De ce fait, ils ne modifient pas la source du document, ni les noms des champs. Le document contient soit les anciens noms des champs, soit les nouveaux. Pour illustrer ce propos, voici quelques emplacements où les alias n’ont aucune utilité, étant donné que les champs sont accessibles directement depuis le document.
  • Colonnes affichées dans les recherches enregistrées
  • Traitement supplémentaire dans votre pipeline d’ingestion de données
  • Toute application utilisant vos événements Beats (p. ex. via l’API Elasticsearch)
• Comme les alias de champ sont des entrées de champ en tant que telles, nous ne pouvons pas créer d’alias lorsqu’il y a un nouveau champ ECS portant le même nom.
• Les alias de champ fonctionnement uniquement avec des champs de feuille. Ils ne fonctionnent pas pour les champs complexes comme les champs object, qui contiennent d’autres champs imbriqués.

Ces alias de champ ne sont pas créés par défaut dans vos index Beats 7. Ils doivent être activés en définissant migration.6_to_7.enabled: true dans chaque fichier de configuration de YAML de Beats avant de procéder à la configuration de Beats. Cette option et les alias correspondants seront disponibles pendant toute la durée de vie de la Suite Elastic 7.x et seront supprimés à partir de la version 8.0.

Conflits

Lors de la migration vers ECS, vous pouvez également être confronté à des conflits de champ, selon les sources que vous utilisez.

Sachez que certains types de conflits sont détectés uniquement pour les champs que vous utilisez réellement. Ce qui signifie que les changements ou les conflits se produisant dans des sources que vous n’utilisez pas ne vous affecteront pas. Mais cela signifie également que, lorsque vous planifiez votre migration, vous devez ingérer des échantillons d’événements de chacune de vos sources de données dans les deux formats (Beats 6 et 7) au sein de votre environnement de test afin de mettre au jour les conflits à résoudre.

Les conflits se divisent en deux catégories :

• Le type des données d’un champ change pour être plus approprié.
• Un nom de champ utilisé avant ECS est également dans ECS mais a un sens différent. C’est ce que nous appelons des champs incompatibles.

Les conséquences exactes impliquées varient selon le type de conflit. Mais en général, lorsqu’un champ change de type de données, ou lorsqu’un champ incompatible change d’imbrication (p. ex. un champ "keyword" devient un champ "object"), vous ne pourrez pas effectuer de recherche simultanée sur les sources "avant ECS" et les sources ECS.

Avec les données qui intègrent vos index Beats 6 et 7, il convient d’actualiser les modèles d'indexation Kibana pour révéler ces conflits. Si, après avoir actualisé votre modèle d'indexation, vous ne voyez aucun avertissement de conflit, c’est qu’il ne vous reste aucun conflit à résoudre. Si, par contre, vous recevez un avertissement, vous pouvez définir le sélecteur de types de données pour afficher uniquement les conflits :

Pour gérer ces conflits, une méthode consiste à réindexer les anciennes données pour les rendre compatibles avec le nouveau schéma. Les conflits provoqués par un changement de type sont plutôt simples à résoudre. Vous pouvez tout simplement écraser vos modèles d'indexation Beats 6 pour utiliser le type de données le plus approprié, faire une réindexation sur un nouvel index (pour que le mappage mis à jour s’applique), puis supprimer l’ancien index.

Si vous vous trouvez en présence de champs incompatibles, vous devrez décider s’il faut les supprimer ou les renommer. Si vous renommez le champ, définissez-le tout d’abord dans votre modèle d'indexation.

Régler l’environnement pour utiliser des événements ECS

Le moins qu’on puisse dire, c’est qu’il y a beaucoup de noms de champs qui changent. Par conséquent, le contenu d’analyse échantillon (p. ex. tableaux de bord) accompagnant Beats a été intégralement modifié afin d’utiliser les nouveaux noms de champs ECS. Le nouveau contenu fonctionnera uniquement sur les données ECS générées par Beats 7.0 et versions supérieures. De ce fait, la configuration de Beats n’écrasera votre contenu Beats 6 existant, mais créera à la place une copie de chaque visualisation Kibana. Chaque nouvelle visualisation Kibana a le même nom que la précédente, auquel est ajouté “ECS” à la fin.

Le contenu échantillon Beats 6 et votre contenu personnalisé basé sur cet ancien schéma continueront en général à fonctionner sur les données Beats 6 et 7 grâce aux alias de champ. Comme nous l’avons cependant souligné, les alias de champ constituent une solution partielle et temporaire pour faciliter la migration vers ECS. Aussi, vous devriez inclure la mise à jour ou la duplication de vos tableaux de bord personnalisés au cours de la migration pour commencer à utiliser les nouveaux noms de champs.

Illustrons notre propose avec un tableau :

En plus de la révision et de la modification du contenu d’analyse dans Kibana, vous devrez également réviser les éventuelles sections personnalisées de votre pipeline d’événements, ainsi que les applications accédant aux événements Beats via l’API Elasticsearch.

Rendre les événements "avant ECS" compatibles avec ECS

Nous avons déjà vu comment la réindexation permet de résoudre les conflits liés aux types des données et aux champs incompatibles. Il s’agit d’une approche facultative, mais elle est plutôt simple à mettre en œuvre et elle en vaut généralement la peine. Autre solution : ignorer les conflits. C’est une solution viable pour les cas d'utilisation simples. Attention toutefois : vous pouvez être confronté à des conflits de champ potentiels à partir du moment où vous commencerez à ingérer des données Beats 7 en raison de l’expiration de Beats 6 dans votre cluster.

Réindexation

Si le support fourni par les alias de champ n’est pas suffisant dans votre cas, vous pouvez aussi réindexer les anciennes données pour re-remplir les noms de champs ECS dans vos données Beats 6. Ainsi, le nouveau contenu d’analyse dépendant des champs ECS (nouveau contenu Beats 7 et votre contenu personnalisé mis à jour) pourra interroger vos anciennes données en plus des données Beats 7.

Modification des événements pendant l’ingestion de données

Si vous pensez que le déploiement des agents Beats 7 prendra un certain temps, vous pouvez avancer tout simplement en réindexant les anciens index. Vous pouvez également modifier les événements Beats 6 entrants au cours de l’ingestion de données.

Quelques méthodes permettent d’effectuer la réindexation et de manipuler les documents, telles que la copie, la suppression ou le renommage des champs. La plus simple consiste à utiliser les pipelines d’ingestion d’Elasticsearch. En voici certains avantages :

• Les pipelines sont simples à tester avec _simulate API
• Vous pouvez utiliser le pipeline pour réindexer les anciens index.
• Vous pouvez utiliser le pipeline pour modifier les événements Beats 6 qui continuent à arriver.

Pour modifier les événements au moment où ils arrivent, dans la plupart des cas, il suffit simplement de configurer le paramètre de “pipeline“ de votre sortie Elasticsearch pour qu’ils soient envoyés dans votre pipeline. C’est vrai pour Logstash et Beats.

Remarque : les modules Filebeat se servent déjà de pipelines d’ingestion pour réaliser leurs analyses. Il est également possible de les modifier. Pour cela, vous devez écraser les pipelines Filebeat 6 et ajouter un rappel dans votre pipeline de réglage.

Supprimer les alias de champ

Dès que vous n’avez plus besoin des alias de champ, vous pouvez les supprimer. Pour rappel, ceux-ci prennent moins de place qu’une duplication intégrale des données. Néanmoins, ils consomment tout de même de la mémoire dans l’état de votre cluster, qui est une ressource critique. Ils sont également présents dans la saisie semi-automatique Kibana, ce qui alourdit les choses inutilement.

Pour supprimer vos anciens alias de champ, supprimez tout simplement le paramètre migration.6_to_7.enabled (ou mettez-le sur false) de votre configuration Beats (p. ex. filebeat.yml), réitérez l’opération de "configuration" et écrasez le modèle.

Remarque : une fois que les modèles ont été écrasés pour ne plus inclure les alias, il faut toutefois attendre que les index se déploient pour que la suppression des alias soit effective dans les mappages d’index. Ensuite, une fois les index déployés, vous devez attendre que les données Beats 7 qui contenaient les alias arrivent à expiration dans votre cluster pour que ces alias soient totalement supprimés.

Mise en place de votre propre stratégie en matière de migration

Nous avons vu comment Beats facilitait la migration de vos données Beats vers ECS. Nous avons également abordé les étapes supplémentaires que vous pouvez réaliser pour que votre migration soit encore plus fluide.

Vous devez maintenant évaluer la somme de travail nécessaire pour chacune de vos sources de données de façon indépendante. Vous aurez probablement moins de tâches à accomplir pour les sources moins critiques.

Voici quelques critères à prendre en compte lorsque vous étudiez une source de données :

• Quelle votre période de conservation ? Est-elle définie par un facteur externe ? Avez-vous la possibilité d’écarter des données plus tôt au cours de cette migration ?
• Avez-vous besoin de continuité dans vos données ? Ou peut-il y avoir des transferts ? Cela peut vous aider à déterminer si un re-remplissage, comme décrit ci-dessus, est approprié.
• Combien de temps votre déploiement de Beats 7 prendra-t-il ? Avez-vous besoin de modifier les événements Beats 6 au fur et à mesure qu’ils arrivent ?

Si vous prévoyez de re-remplir de nombreux champs, vous devriez jeter un œil à dev-tools/ecs-migration.yml dans le référentiel Beats. Ce fichier répertorie tous les changements de champs pour la migration de Beats 6 vers Beats 7.

Exemple de migration

Nous allons maintenant étudier pas à pas comment effectuer une migration vers ECS en mettant Beats à niveau de la version 6.8 vers la version 7.2. Nous verrons également en quoi les alias peuvent aider et quelles sont leurs limitations, comment résoudre les conflits, comment réindexer les données précédentes pour faciliter la transition et comment modifier les événements Beats 6 qui continuent d’arriver. Dans cet exemple, nous utiliserons le module Syslog de Filebeat.

Comme nous l’avons déjà indiqué, nous ne verrons qu’une partie de la mise à niveau de la Suite Elastic. Nous partirons du principe qu’Elasticsearch et Kibana ont déjà été mis à niveau vers la version 7, pour nous concentrer sur la réalisation de la mise à niveau du schéma de données vers ECS.

Pour pouvoir reproduire cette procédure, veuillez utiliser les versions les plus récentes d’Elasticsearch 7 et de Kibana 7. Vous pouvez soit passer par un compte d’essai gratuit Elastic Cloud, soit exécuter Elasticsearch et Kibana localement en suivant les instructions d’installation correspondantes.

Exécution de Beats 6.8

Dans cette démo, nous exécuterons Filebeat 6.8 et 7.2 simultanément sur la même machine. Il est donc important d’installer ces versions avec une installation d’archivage (avec zip ou .tar.gz). Les installations d’archivage sont auto-contenues dans leur répertoire et faciliteront la procédure.

Lancez Elasticsearch et Kibana 7, puis installez Filebeat 6.8. Si vous êtes sous Windows, vous pouvez tester en installant Winlogbeat à la place.

Sur la plupart des systèmes, Syslog utilise l’heure locale pour son horodatage sans préciser le fuseau horaire. Nous allons configurer Filebeat pour ajouter le fuseau horaire à chaque événement via le processeur add_locale, puis paramétrer le pipeline du module système pour qu’il interprète l’horodatage en conséquence. Ainsi, nous pourrons valider notre migration ECS à coup sûr lorsque nous rechercherons des événements reçus récemment.

Dans filebeat.yml, repérez la section relative aux processeurs et ajoutez le processeur add_locale. Sous cette section, ajoutez le module de configuration suivant :

processors:
  - add_host_metadata: ~
  - add_cloud_metadata: ~
  - add_locale: ~
filebeat.modules:
  - module: system
    syslog:
      var.convert_timezone: true

Si vous exécutez Elasticsearch et Kibana localement, cela devrait être suffisant. Si vous utilisez Elastic Cloud, vous devrez ajouter vos informations d’identification de cloud dans filebeat.yml (accessibles dans Elastic Cloud lors de la création d’un cluster) :

cloud.id: 'my-cluster-name:a-very-long-string....'
cloud.auth: 'username:password'

Maintenant, préparons Filebeat 6.8 pour qu’il capture les logs système :

./filebeat setup -e
./filebeat -e

Confirmons que les données entrent bien en regardant le tableau de bord [Système Filebeat] Tableau de bord Syslog. Nous devrions voir les événements Syslog les plus récents générés sur le système sur lequel Filebeat a été installé.

Ce tableau de bord est intéressant car il comprend des visualisations et une recherche enregistrée. Cela nous sera utile pour déterminer ce que peuvent faire les alias de champ et ce qu’ils ne peuvent pas.

Exécution de Beats 7 (ECS)

Soyons clairs : certains environnements ne peuvent pas faire de transfert instantané d’une version de Beats à une autre. Il y aura probablement des événements qui viendront à la fois de Filebeat 6 et de Filebeat 7 pendant une certaine période. C’est ce que nous allons faire aussi dans cet exemple.

Pour cela, nous pouvons tout simplement exécuter Filebeat 7.2 avec Filebeat 6.8 sur le même système. Nous allons extraire Filebeat 7.2 dans un répertoire différent, et appliquer les mêmes changements de configuration que ceux apportés à la version 6.8.

Mais attention : ne faites pas la configuration maintenant ! Pour Beats 7, nous devons également activer le paramètre de migration, qui crée les alias de champ. Supprimez cette ligne à la toute fin du fichier filebeat.yml :

migration.6_to_7.enabled: true

Notre fichier de configuration 7.2 dispose désormais des éléments suivants : l’attribut de migration supplémentaire, le processeur add_locale, la configuration du module système et, si besoin, nos informations d’identification de cloud.

Utilisons Filebeat 7.2 depuis un terminal différent :

./filebeat setup -e
./filebeat -e

Conflits

Avant de nous pencher sur les tableaux de bord, accédons directement à la gestion des index Kibana pour confirmer que le nouvel index a été créé et que des données y entrent. Vous devriez avoir une présentation similaire à celle-ci :

Accédons aussi aux modèles d'indexation et actualisons celui intitulé filebeat-*. Suite à cette actualisation, il peut y avoir quelques conflits. Nous pouvons cibler les conflits en changeant le sélecteur de types de données à droite et en le faisant passer de All field types (Tous les types de champs) à conflict :

Examinons deux des conflits ci-dessus et déterminons comment les traiter.

Tout d’abord, étudions un conflit propre à syslog : system.syslog.pid. Si nous nous rendons sur la page de gestion des index et que nous regardons le mappage pour 6.8, nous pouvons constater que le champ est indexé en tant que keyword. Si nous regardons le mappage d’index 7.2, nous voyons que system.syslog.pid est un alias de process.pid. De ce côté, tout est normal. Ce n’est pas ça qui est à l’origine du conflit. Par contre, si nous suivons l’alias et que nous nous penchons sur le type de données pour process.pid, nous constatons qu’il s’agit désormais du type long. C’est le transfert du type keyword à long qui a provoqué le conflit.

Maintenant, étudions un conflit provoqué par un champ incompatible. Un cas classique pour toutes les migrations Filebeat : le champ source. Dans Filebeat 6, source est un champ keyword qui contient habituellement un chemin vers un fichier (ou parfois une adresse source syslog). Dans ECS, et donc dans les mappages de champ Filebeat 7, source devient un objet avec des champs imbriqués servant à décrire la source d’un événement réseau (source.ip, source.port, etc.). Étant donné qu’un champ intitulé source existe déjà dans Beats 7, nous ne pouvons pas créer un champ d’alias ici.

Nous avons identifié deux champs sur lesquels nous pouvons intervenir dans le cadre de notre procédure de migration. Nous y reviendrons dans un moment.

Alias

Gardons notre tableau de bord Syslog [Système Filebeat] Beats 6 ouvert. Étant donné que le modèle d'indexation filebeat-* a changé depuis le premier chargement du tableau de bord, procédons à un rechargement intégral de la page avec Commande + R ou F5.

À partir d’un nouvel onglet, ouvrons le nouveau tableau de bord Tableau de bord Syslog ECS [Système Filebeat].

Lorsque nous nous penchons sur la recherche enregistrée en bas du tableau de bord 6.8, nous voyons qu’il y a des divergences dans les données. Certains événements ont des valeurs pour system.syslog.program et system.syslog.message, d’autres non. Lorsque nous ouvrons ceux qui ont des valeurs vides, nous constatons qu’il s’agit des mêmes événements Syslog prélevés par 7.2, mais avec des noms de champ différents. Pour la même période dans l’onglet avec le tableau de bord ECS, nous observons le même comportement inversé. Les champs ECS process.name et message sont remplis pour les événements 7.2, mais pas pour les événements 6.8.

Il s’agit d’un cas concret dans lequel les alias de champ ne peuvent pas nous aider. Les recherches enregistrées s’appuient sur le contenu du document, pas sur le mappage d’index. Comme nous l’avons déjà mentionné dans l’aperçu, si la continuité est essentielle pour vous, procédez à une réindexation pour re-remplir les champs (et modifier les événements entrants). Nous aborderons ce sujet sous peu.

Voyons à présent en quoi les alias de champ peuvent nous aider. Étudiez la visualisation en forme de donut dans le tableau de bord 6.8 et survolez l’anneau extérieur, qui affiche les valeurs de system.syslog.program :

Cliquez sur une section de l’anneau pour appliquer un filtre sur les messages générés par un programme. Sélectionnons uniquement le filtre sur le nom du programme :

Nous venons d’ajouter un filtre sur un champ qui n’est plus présent dans 7.2 : system.syslog.program. Ceci dit, nous pouvons toujours voir les deux ensembles de messages dans la recherche enregistrée :

Si nous nous penchons sur les éléments 7.2, nous constatons que le filtre a aussi été correctement appliqué sur ces éléments. Cela confirme que notre filtre sur system.syslog.program fonctionne avec nos données 7.2, grâce à l’alias system.syslog.program.

Notez que la visualisation (soutenue par une agrégation Elasticsearch) affiche aussi les résultats de façon correcte pour 6.8 et 7.2 sur le champ system.syslog.program migré.

Si nous revenons au tableau de bord 7.2, sans filtres actifs, nous pouvons consulter les données 6.8 et 7.2. Si nous appliquons le même filtre comme nous l’avons fait sur 6.8, en revanche, nous remarquons que le comportement est différent. Le filtrage pour process.name:iTunes renvoie désormais des événements 7.2 uniquement. Pourquoi ? Car les index 6.8 n’ont pas de champ nommé process.name, ni d’alias pour ce nom.

Réindexation pour une transition fluide

Comme nous l’avons vu, la réindexation permet de résoudre trois différents aspects de la migration : la résolution des conflits de types de données, la résolution de champs incompatibles et le re-remplissage des champs ECS pour préserver la continuité. Passons en revue un exemple de chacun de ces aspects.

Voici comment nous allons modifier nos données Beats 6 :

• Conflit de type de données : changez les types de données pour system.syslog.pid de keyword à long.
• Champ incompatible : Supprimez le fichier source de Filebeat après avoir copié son contenu dans log.file.path. Vous éliminerez ainsi le conflit avec l’ensemble du champ source d’ECS. Remarque : dans Beats 6.6 et versions supérieures, log.file.path est déjà rempli avec la même valeur … mais ce n’est pas le cas dans les versions précédentes de Beats 6. C’est pourquoi nous allons le copier si besoin.
• Re-remplissez le champ ECS process.name avec la valeur de system.syslog.process.

Voici comment procéder à ces changements :

• Nous modifierons le modèle d’index Filebeat 6.8 pour utiliser les nouveaux types de données, ainsi qu’ajouter et supprimer des définitions de champ.
• Nous créerons un nouveau pipeline d’ingestion qui modifie les événements 6.8 en supprimant ou en copiant des champs.
• Nous testerons le pipeline avec l’API _simulate.
• Nous utiliserons le pipeline pour réindexer les anciennes données.
• Nous attacherons également un renvoi à ce nouveau pipeline à la fin du pipeline d’ingestion Filebeat 6.8 pour modifier les événements entrants.

Modification du modèle d’index

Les améliorations apportées aux types de données doivent être intégrées au modèle d’index. Elles prendront effet lors du déploiement de l’index. Par défaut, le déploiement a lieu le lendemain. Si vous vous servez de la gestion du cycle de vie des index dans 6.8, vous pouvez forcer le déploiement avec l’API de substitution.

Affichez le modèle d’index actuel à partir des outils de développement Kibana :

GET _template/filebeat-6.8.1

Les modèles d’index ne peuvent pas être modifiées. Ils doivent être entièrement écrasés (voir documentation). Préparez un appel API PUT avec l’intégralité du modèle d’index tout y ajustant quelques éléments :

• Supprimez la définition de source (toutes les lignes commençant par - ci-dessous).
• Ajoutez une définition de champ pour program.name.
• Changez le type du champ system.syslog.pid sur long.

PUT _template/filebeat-6.8.1
{
  "order" : 1,
  "index_patterns" : [
    "filebeat-6.8.1-*"
  ]
  ...
  "mappings": {
    "properties" : {
-     "source" : {
-       "ignore_above" : 1024,
-       "type" : "keyword"
-     },
      "program" : {
        "properties" : {
          "name": {
            "type": "keyword",
            "ignore_above": 1024
          }
        }
      },
      "system" : {
        "properties" : {
          "syslog": {
            "properties" : {
              "pid" : {
                "type" : "long"
              }
      ...      
}

Dès que le corps de l’appel API est prêt, exécutez-le pour écraser le modèle d’index. Si vous prévoyez de re-remplir un certain nombre de champs ECS, jetez un œil aux exemples de modèles ECS Elasticsearch dans le référentiel git ECS.

Réindexation

La prochaine étape consiste à écrire un nouveau pipeline d’ingestion pour modifier nos événements Beats 6.8. Pour notre exemple, nous allons copier system.syslog.program dans process.name, source dans log.file.path (sauf s’il est déjà rempli) et supprimer le champ source :

PUT _ingest/pipeline/filebeat-system-6-to-7
{ "description": "Pipeline to modify Filebeat 6 system module documents to better match ECS",
  "processors": [
    { "set": {
        "field": "process.name",
        "value": "{{system.syslog.program}}",
        "if": "ctx.system?.syslog?.program != null"
    }},
    { "set": {
        "field": "log.file.path",
        "value": "{{source}}",
        "if": "ctx.containsKey('source') && ctx.log?.file?.path == null"
    }},
    { "remove": {
        "field": "source"
    }}
  ],
  "on_failure": [
    { "set": {
        "field": "error.message",
        "value": "{{ _ingest.on_failure_message }}"
    }}
  ]
}

Apprenez-en davantage sur les pipelines d’ingestion et le langage Painless (utilisé dans les clauses if).

Nous pouvons tester ce pipeline avec l’API _simulate en ayant des événements entièrement remplis. Néanmoins, nous utiliserons ici une procédure bien plus minimaliste, convenant mieux dans le contexte d’un article de blog. Comme vous pouvez le constater, log.file.path est rempli pour un événement (Beats 6.6 et versions supérieures), mais pas pour l’autre (6.5 et versions antérieures) :

POST _ingest/pipeline/filebeat-system-6-to-7/_simulate
{ "docs":
  [ { "_source": {
      "log": { "file": { "path": "/var/log/system.log" } },
      "source": "/var/log/system.log",
      "system": {
        "syslog": {
          "program": "syslogd"
    }}}},
    { "_source": {
      "source": "/var/log/system.log",
      "system": {
        "syslog": {
          "program": "syslogd"
    }}}}
  ]
}

La réponse à l’appel API contient deux événements modifiés. Nous pouvons confirmer que notre pipeline fonctionne car le champ source n’apparaît plus et que les deux événements ont une valeur stockée pour log.file.path.

Nous pouvons désormais procéder à une réindexation sur les index qui ne reçoivent plus d’écritures (p. ex. index d’hier et d’avant) à l’aide de ce pipeline d’ingestion pour chaque index Filebeat que nous migrons. Lisez attentivement les documents _reindex pour comprendre comment faire une réindexation en arrière-plan, contraindre votre opération de réindexation, etc. Voici une réindexation simple applicable aux quelques événements dont nous disposons :

POST _reindex
{ "source": { "index": "filebeat-6.8.1-2019.07.04" },
  "dest": {
    "index": "filebeat-6.8.1-2019.07.04-migrated",
    "pipeline": "filebeat-system-6-to-7"
}}

Si vous reproduisez cette procédure en parallèle et que vous ne disposez que des index d’aujourd’hui, n’hésitez pas à tester tout de même l’appel API et regardez le mappage des index migrés. Mais ne supprimez pas les index d’aujourd’hui par la suite. Ils seront juste recréés car Filebeat 6.8 continue à envoyer des données.

Autrement, une fois que les index inactifs ont été réindexés, nous pouvons confirmer que les nouveaux index disposent des correctifs souhaités, et de là, supprimer les anciens index.

Modification des événements entrants

La plupart des Beats peuvent être configurés pour effectuer des envois directement dans un pipeline d’ingestion de leur sortie Elasticsearch (idem pour la sortie Elasticsearch de Logstash). Étant donné que nous nous servons d’un module Filebeat dans cette démo (qui utilise déjà des pipelines d’ingestion), nous devrons modifier le pipeline du module à la place.

Le pipeline d’ingestion installé par la configuration Filebeat 6.8 à prendre en charge se nomme filebeat-6.8.1-system-syslog-pipeline. Tout ce que nous avons à faire, c’est d’ajouter un renvoi vers notre propre pipeline à la fin du pipeline Syslog Filebeat.

Nous allons afficher le pipeline que nous sommes sur le point de modifier :

GET _ingest/pipeline/filebeat-6.8.1-system-syslog-pipeline

Ensuite, nous allons préparer l’appel API pour écraser le pipeline en collant l’intégralité du pipeline dessous l’appel API PUT. Ensuite, nous ajouterons un processeur de “pipeline” à la fin, pour appeler notre nouveau pipeline.

PUT _ingest/pipeline/filebeat-6.8.1-system-syslog-pipeline
{ "description" : "Pipeline for parsing Syslog messages.",
  "processors" :
  [
    { "grok" : { ... }
    ...
    { "pipeline": { "name": "filebeat-system-6-to-7" } }
  ],
  "on_failure" : [
    { ... }
  ]
}

Après avoir exécuté l’appel API, tous les événements entrants seront modifiés pour mieux correspondre à ECS, avant d’être indexés.

Pour finir, nous pouvons utiliser _update_by_query pour modifier les documents copiés précédemment avant de modifier le pipeline. Nous pouvons déterminer les documents qui doivent être mis à jour en repérant ceux disposant encore du champ source :

GET filebeat-6.8.1-*/_search
{ "query": { "exists": { "field": "source" }}}

Et nous réindexerons uniquement ces documents :

POST filebeat-6.8.1-*/_update_by_query?pipeline=filebeat-system-6-to-7
{ "query": { "exists": { "field": "source" }}}

Vérification des conflits

Après que tous les index ayant des conflits ont été supprimés, seuls les champs réindexés sont conservés. Nous pouvons actualiser le modèle d'indexation pour confirmer la suppression effective des conflits. Si nous revenons à notre tableau de bord Filebeat 7, nous constaterons que les données 6.8 qu’il contient sont désormais plus utiles grâce à notre re-remplissage du champ process.name :

Dans notre exemple, nous avons uniquement re-rempli un champ. Bien entendu, vous pouvez re-remplir le nombre de champs que vous souhaitez.

Nettoyage après la migration

Au cours de votre migration, vous pouvez être amenés à modifier vos tableaux de bord et applications personnalisés utilisant des événements Beats via l’API pour utiliser de nouveaux noms de champs ECS.

Une fois que votre migration vers Beats 7 est achevée et que plus aucun alias de champ n’est utilisé, nous pouvons les supprimer pour tirer parti des avantages abordés précédemment en matière d’économies de mémoire. Pour supprimer les alias, retirons l’attribut migration.6_to_7.enabled de filebeat.yml, puis écrasons le modèle Filebeat 7.2 avec :

./filebeat setup --template -e -E 'setup.template.overwrite=true'

Tout comme précédemment, le nouveau modèle sans alias sera effectif lors du prochain déploiement d’index Filebeat 7.2.

Conclusion

Dans cet article, nous avons abordé les différentes étapes pour migrer vos données vers ECS dans un environnement Beats. Nous avons étudié les avantages d’une procédure de mise à niveau, ainsi que ces limitations. Ces limitations peuvent être palliées en réindexant les anciennes données et même en modifiant les données Beats 6 entrantes lors du processus d’ingestion.

Après avoir détaillé les étapes de la migration, nous avons illustré la théorie par la pratique à l’aide d’un exemple de mise à niveau du module de système Filebeat de la version 6.8 vers la version 7.2. Nous avons étudié les différences entre les événements de Filebeat 6.8 et 7.2, puis nous avons décrit les étapes possibles pour réindexer des données anciennes, et les modifier lors de leur entrée.

La mise en place d’un schéma a inévitablement un impact conséquent sur les installations existantes. Nous sommes néanmoins convaincus que cette migration est avantageuse. Pour en savoir davantage, vous pouvez lire Lancement d'Elastic Common Schema et Why Observability loves the Elastic Common Schema (Quand observabilité rime avec Elastic Common Schema).

Si votre environnement utilise des pipelines d’ingestion de données autres que Beats, restez connecté. Nous prévoyons de publier prochainement un autre article de blog sur la procédure pour migrer un pipeline d’ingestion personnalisé vers ECS.

Si vous avez des questions sur ECS ou si vous avez besoin d’aide avec votre mise à niveau Beats, consultez les forums de discussion et intégrez la balise elastic-common-schema à votre question. Pour en savoir plus sur ECS, lisez notre documentation et apportez votre contribution à ECS sur GitHub.

Références

Documentation

• Assistant de mise à niveau
• Mise à niveau de la Suite Elastic
• Changements majeurs dans la version 7.0
• Réindexation
• Pipeline d’ingestion
• API de simulation du pipeline d’ingestion
• Langage Painless
• Mappages et modèles d’index
• Fichier documentant tous les changements de champs : ecs-migration.yml
• Exemples de modèles d’index Elasticsearch ECS

Blogs et vidéos

• Lancement d'Elastic Common Schema (blog)
• Lancement d'Elastic Common Schema (webinar)
• ECS: How to migrate your data (ECS : Comment effectuer la migration de vos données) (webinar)
• Why observability loves the Elastic Common Schema (Quand observabilité rime avec Elastic Common Schema) (blog)
• Upgrading the Elastic Stack with the 7.x Upgrade Assistant (Mise à niveau de la Suite Elastic avec l’assistant de mise à niveau 7.x) (blog)

• Posez des questions sur ECS dans les forums de discussion et intégrez la balise “elastic-common-schema” à votre question.
• Documentation officielle sur ECS
• Référentiel Github ECS

Dans cet article, nous allons voir comment nous pouvons monitorer NGINX à l’aide des différents composants de la Suite Elastic. Pour collecter des données, nous nous servirons de Metricbeat et de Filebeat. Ces données seront transférées vers Elasticsearch et y seront stockées. Nous les consulterons ensuite avec Kibana.

Metricbeat collectera des données en rapport avec les connexions (actives, prises en charge, acceptées etc.) et le nombre total de requêtes client. Filebeat recueillera des données concernant les logs d’accès et les logs d’erreur. Leur utilisation variera selon les configurations. Néanmoins, ces informations serviront généralement pour effectuer des déductions, par exemple :

• Si l’on constate un pic dans les logs d’erreur par rapport à une certaine ressource, c’est que nous avons peut-être supprimé une ressource qui est toujours nécessaire.
• Les logs d’accès, quant à eux, peuvent indiquer les heures auxquelles les services sont les plus utilisés (et de là, donner des indications sur les heures auxquelles il serait préférable d’effectuer certaines tâches, comme la maintenance).
• Un pic brusque dans les requêtes client peut être synonyme d’une attaque malveillante (par déni de service par exemple).

Dans cet article, nous nous concentrerons sur la fonctionnalité de monitoring. Nous passerons donc très rapidement sur les autres points (comme la configuration d’Elasticsearch par exemple). Pour ma part, j’utilise un Mac. Je me servirai donc des versions d’Elasticsearch, de Metricbeat, de Filebeat et de Kibana pour Mac. Les versions pour les autres plateformes sont disponibles sur la page des téléchargements.

Installation d’Elasticsearch

Metricbeat et Filebeat (pour ne pas dire tous les Beats) ont besoin d’un cluster Elasticsearch pour stocker les données. Nous allons configurer un cluster Elasticsearch simple en local. Étant donné qu’Elasticsearch ne sera pas mis en contact avec l’extérieur, inutile de configurer la sécurité.

1^ère étape : Télécharger Elasticsearch

curl -L -O https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.1.0-darwin-x86_64.tar.gz

2^e étape : Extraire le dossier d’archive

tar -xvf elasticsearch-7.1.0-darwin-x86_64.tar.gz

3^e étape : Passer au répertoire bin

cd elasticsearch-7.1.0/bin

4^e étape : Démarrer notre cluster à nœud unique

./elasticsearch

Par défaut, votre cluster s’exécutera sur localhost:9200.

Exécution de NGINX

Plusieurs options s’offrent à nous pour exécuter NGINX : de manière autonome sur l’hôte, via un conteneur Docker, au sein d’une configuration Kubernetes, etc. Beats dispose d’une fonctionnalité Autodiscover qui peut écouter les événements d’API de conteneur pour suivre nos conteneurs de serveur au fur et à mesure qu’ils sont déployés ou supprimés.

Les possibilités qui s’offrent à nous pour configurer NGINX sont donc légion, mais nous ne les étudierons pas toutes. Ici, nous donnerons des exemples de configuration sur l’hôte et de la fonctionnalité Autodiscover (Docker, dans le cas présent).

Configuration de Metricbeat et de Filebeat

Nous allons maintenant configurer Beats pour commencer à collecter et transférer nos données.

Metricbeat

Nous nous servirons de Metricbeat pour collecter des indicateurs.

1^ère étape : Télécharger Metricbeat :

curl -L -O https://artifacts.elastic.co/downloads/beats/metricbeat/metricbeat-7.1.0-darwin-x86_64.tar.gz

2^e étape : Extraire le dossier d’archive

tar -xvf metricbeat-7.1.0-darwin-x86_64.tar.gz

3^e étape : Changer de répertoire

cd metricbeat-7.1.0-darwin-x86_64

Et c’est parti pour la configuration !

Par défaut, notre fichier de configuration (metricbeat.yml) recherchera un cluster Elasticsearch s’exécutant sur localhost:9200, que nous avons configuré précédemment.

4^e étape : Activer les modules Metricbeat nécessaires

Par défaut, seuls les indicateurs au niveau du système sont collectés :

./metricbeat modules enable nginx

5^e étape : Changer les propriétés du fichier

Nous devons changer quelques propriétés du fichier, car nous allons exécuter Metricbeat en tant que root (vous pouvez aussi choisir d’utiliser l’option --strict.perms=false de la ligne de commande pour désactiver les contrôles stricts d’autorisation) :

sudo chown root metricbeat.yml 
sudo chown root modules.d/system.yml 
sudo chown root modules.d/nginx.yml

6^e étape : Activer les ensembles d’indicateurs

Si nous ouvrons notre fichier modules.d/nginx.yml, nous pouvons activer l’ensemble d’indicateurs stubstatus, qui permet de supprimer les éléments suivants :

#metricsets:
#  - stubstatus

Cet ensemble d’indicateurs collecte des données depuis le module NGINX ngx_http_stub_status. Il est donc important que ce module NGINX soit configuré de sorte à ce que l’ensemble d’indicateurs fonctionne.

Vous pouvez également modifier les hôtes monitorés ici. Par défaut, <a href="http://127.0.0.1">http://127.0.0.1</a> est monitoré. Pour les configurations basées sur l’hôte, c’est tout ce dont nous avons besoin.

7^e étape : Configurations Autodiscover (autre option)

Pour les configurations Autodiscover, la configuration équivalente variera selon le fournisseur utilisé : Docker, Kubernetes ou Jolokia. Prenons Docker. Voici à quoi cela ressemblerait si nous utilisions Docker : nous ajouterions metricbeat.autodiscover à la fin du fichier de configuration metricbeat.yml.

metricbeat.autodiscover:
  providers:
    - type: docker
      templates:
        - condition:
            contains:
              docker.container.image: nginx
          config:
            - module: nginx
              metricsets: ["stubstatus"]
              hosts: "${data.host}:${data.port}"

Avec cette configuration, une correspondance sera établie avec tous les conteneurs Docker utilisant une image dont le nom contient NGINX (correspondance par rapport à une sous-chaîne, et non pas correspondance exacte), et ces conteneurs utiliseront une configuration faisant fonctionner le module NGINX avec l’ensemble d’indicateurs "stubstatus".

8^e étape : Exécuter Metricbeat

Bien ! Maintenant que notre configuration est terminée, nous pouvons exécuter Metricbeat avec un indicateur qui envoie les logs vers stderr et qui désactive la sortie syslog/fichier :

sudo ./metricbeat -e

Si tout fonctionne bien, vous devriez voir apparaître les sorties initiales, puis des sorties à chaque fois que Metricbeat publie des données dans votre cluster.

Filebeat

Nous nous servirons de Filebeat pour collecter des logs.

1^ère étape : Télécharger Filebeat

curl -L -O https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-7.1.0-darwin-x86_64.tar.gz

2^e étape : Extraire le dossier d’archive

tar -xvf filebeat-7.1.0-darwin-x86_64.tar.gz

3^e étape : Changer de répertoire

cd filebeat-7.1.0-darwin-x86_64

4^e étape : Activer le module NGINX

./filebeat modules enable nginx

Par défaut, les logs collectés seront les logs d’accès et les logs d’erreurs. Filebeat essayera de déterminer les chemins de ces logs en fonction de votre système d’exploitation. Si vous avez explicitement besoin de chemins différents, vous pouvez les paramétrer dans le fichier de configuration modules.d/nginx.yml.

5^e étape : Changer les propriétés du fichier

sudo chown root filebeat.yml
sudo chown root modules.d/nginx.yml
sudo chown root module/nginx/access/manifest.yml
sudo chown root module/nginx/error/manifest.yml

Pour les configurations basées sur l’hôte, c’est tout ce dont nous avons besoin.

6^e étape : Configurations Autodiscover (autre option)

Comme précédemment, une configuration supplémentaire est nécessaire pour utiliser Autodiscover. Reprenons l’exemple de Docker. En ajoutant cette section Autodiscover à la configuration, le fichier filebeat.yml se présenterait comme suit :

filebeat.autodiscover:
 providers:
   - type: docker
     templates:
       - condition:
         contains:
           docker.container.image: nginx
         config:
           - module: nginx
             access:
               input:
                 type: docker
                 containers.ids:
                   - "${data.docker.container.id}"
             error:
               input:
                 type: docker
                 containers.ids:
                   - "${data.docker.container.id}"

Ici, nous configurons les options d’accès et d’erreur pour utiliser une entrée Docker. Une entrée Docker recherchera les logs de conteneur se trouvant dans son répertoire (le chemin de base où se situent les logs Docker ; par défaut /var/lib/docker/containers). Pour containers.ids, nous utilisons les identifiants des conteneurs correspondant aux critères de notre modèle. Les logs rassemblés (par défaut) proviennent de /var/lib/docker/containers/ac29b98ad83ca43bb4c15ae8f0d03aff8c7d57bf5dee9024124374b92b14b0f2/ (identifiants différents).

7^e étape : Exécuter Filebeat

sudo ./filebeat -e

Installation de Kibana

Maintenant que Metricbeat et Filebeat transfèrent des données concernant nos serveurs NGINX, nous devons trouver un moyen de consulter ces données. C’est là que Kibana entre en jeu.

1^ère étape : Télécharger Kibana

curl -O https://artifacts.elastic.co/downloads/kibana/kibana-7.1.0-darwin-x86_64.tar.gz

2^e étape : Extraire le dossier d’archive et changer de répertoire

tar -xzf kibana-7.1.0-darwin-x86_64.tar.gz

cd kibana-7.1.0-darwin-x86_64

3^e étape : Exécuter Kibana

./bin/kibana

Par défaut, Kibana utilisera un hôte Elasticsearch de http://localhost:9200, et sera accessible sur http://localhost:5601.

Si vous accédez à http://localhost:5601, vous devriez voir s’afficher l’écran suivant :

Si vous le souhaitez, vous pouvez vous amuser à manipuler les données échantillon. Pour ma part, je vais simplement cliquer sur Explore on my own (Découvrir par moi-même).

Visualisation des données NGINX dans Kibana

Nous allons voir à présent comment utiliser Kibana pour consulter et analyser nos données.

Infrastructure

Si nous accédons à l’application Infrastructure sur la barre latérale de Kibana, nous aurons la possibilité de voir une vue instantanée (dernière minute) de notre infrastructure. Pour les configurations ne se basant pas sur Autodiscover, les données seront accessibles sous Hosts (Hôtes). Pour les configurations basées sur Autodiscover, utilisez le bouton Docker ou Kubernetes (selon le fournisseur utilisé) pour accéder à l’ensemble de données approprié :

Étant donné que j’ai utilisé une configuration basée sur un hôte, je peux cliquer sur le bouton Hosts (Hôtes) et voir les données suivantes être transférées depuis Metricbeat :

Si nous sélectionnons l’un des nœuds et que nous choisissons View Metrics (Voir les indicateurs), une page contenant le détail des indicateurs de ce serveur NGINX s’affiche.

Logs

Si, à la place, nous accédons à l’application Logs, nous verrons les logs d’accès et d’erreur ayant été transférés à partir de Filebeat.

Tableaux de bord NGINX pré-configurés

Maintenant que nous disposons d’une instance fonctionnelle et accessible de Kibana, nous pouvons charger certains tableaux de bord pré-configurés.

Pour charger les tableaux de bord pré-configurés, exécutez la commande suivante dans votre répertoire Metricbeat :

sudo ./metricbeat setup --dashboards

Répétez l’opération pour Filebeat :

sudo ./filebeat setup --dashboards

Maintenant, si nous naviguons vers l’onglet Dashboards (Tableaux de bord) dans Kibana, voici ce que nous devrions obtenir :

Si nous affinons notre recherche en indiquant "nginx", voici les tableaux de bord disponibles :

À titre d’exemple, voici à quoi ressemble le tableau de bord [Filebeat NGINX] Access and error logs ECS (Logs d’accès et d’erreur ECS [Filebeat NGINX]) :

Voilà ! Nous venons d’apprendre à utiliser la Suite Elastic pour monitorer les serveurs NGINX. À partir des éléments que nous avons vus, différentes options s’offrent à nous (en termes de regroupement et de filtrage par exemple) pour explorer les informations réellement importantes.

Jugez-en par vous-même

Chez Elastic, nous avons mis au point une bibliothèque open source de tests et de validation de schémas en Go que je souhaiterais vous présenter. Son nom ? Lookslike. Lookslike vous permet d’établir des correspondances avec la forme de vos structures de données Golang comme JSON Schema, mais avec davantage de puissance et plus dans le style Go. Cette bibliothèque offre de nombreuses possibilités qui n’étaient pas proposées jusque-là.

Pour vous donner un exemple de sa puissance :

// Cette bibliothèque nous permet de vérifier si une structure de données est similaire, ou identique, à un schéma donné.
// Par exemple, nous pourrions faire un test pour déterminer si un animal est un chien ou un chat, à l’aide du code ci-dessous.

// Un chien nommé rover
rover := map[string]interface{}{"name": "rover", "barks": "often", "fur_length": "long"}
// Un chat nommé pounce
pounce := map[string]interface{}{"name": "pounce", "meows": "often", "fur_length": "short"}

// Ici, nous définissons un validateur.
// Ici, nous déterminons le chien comme étant un élément ayant :
// 1. une clé "name" (nom) qui correspond à une chaîne non vide quelconque, utilisant la définition `IsNonEmptyString` intégrée
// 2. une clé "fur_length" (longueur_fourrure) qui a pour valeur "long" (longue) ou "short" (courte)
// 3. une clé "barks" (aboie) qui a pour valeur "often" (souvent) ou "rarely" (rarement)
// 4. nous déterminons aussi qu’il s’agit de critères de correspondance stricts, c’est-à-dire que les éventuelles clés qui seraient présentes
//    autres que celles répertoriées seront considérées comme des erreurs
dogValidator := lookslike.Strict(lookslike.MustCompile(map[string]interface{}{
    "name":       isdef.IsNonEmptyString,
    "fur_length": isdef.IsAny(isdef.IsEqual("long"), isdef.IsEqual("short")),
    "barks": isdef.IsAny(isdef.IsEqual("often"), isdef.IsEqual("rarely")),
}))

result := dogValidator(rover)
fmt.Printf("Checked rover, validation status %t, errors: %v\n", result.Valid, result.Errors())
result = dogValidator(pounce)
fmt.Printf("Checked pounce, validation status %t, errors: %v\n", result.Valid, result.Errors())

L’exécution du code ci-dessus donnera le résultat suivant :

Checked rover, validation status true, errors: []
Checked pounce, validation status false, errors: [@Path 'barks': expected this key to be present @Path 'meows': unexpected field encountered during strict validation]

Nous constatons ici que "rover", le chien, a généré une correspondance parfaite, contrairement à "pounce", le chat, qui est associé à deux erreurs. Quelles sont ces erreurs ? La première est qu’il n’y a pas de clé barks (aboie) définie. La deuxième est qu’il y a une autre clé, meows (miaule), qui n’était pas prévue.

Étant donné que Lookslike est en général utilisé pour réaliser des tests, nous disposons d’un module d’aide testslike.Test qui génère des sorties de tests bien agencées. Pour cela, changez juste les dernières lignes de l’exemple ci-dessus par ce qui suit :

testslike.Test(t, dogValidator, rover)
testslike.Test(t, dogValidator, pounce)

Composition

L’un des concepts clés de Lookslike est la possibilité de combiner des validateurs. Supposons que nous souhaitions des validateurs distincts pour le chien et le chat, mais que nous ne voulons pas redéfinir des champs communs comme name (nom) et fur_length (longueur_fourrure) pour chacun d’eux. Voilà ce que ça donne.

pets := []map[string]interface{}{
    {"name": "rover", "barks": "often", "fur_length": "long"},
    {"name": "lucky", "barks": "rarely", "fur_length": "short"},
    {"name": "pounce", "meows": "often", "fur_length": "short"},
    {"name": "peanut", "meows": "rarely", "fur_length": "long"},
}

// Nous constatons que les deux animaux ont la propriété "fur_length" (longueur_fourrure), mais que seul le chat miaule (clé "meows") et que seul le chien aboie (clé "barks").
// Nous pouvons encoder tous ces critères avec concision dans Lookslike avec lookslike.Compose.
// Comme nous pouvons le voir également, les clés "meows" (miaule) et "barks" (aboie) contiennent toutes deux les mêmes choix de valeur.
// Nous commencerons par créer un type IsDef composé avec la composition IsAny. Cette composition crée un type IsDef qui est
// un opérateur 'or' logique de ses arguments IsDef.

isFrequency := isdef.IsAny(isdef.IsEqual("often"), isdef.IsEqual("rarely"))

petValidator := MustCompile(map[string]interface{}{
    "name":       isdef.IsNonEmptyString,
    "fur_length": isdef.IsAny(isdef.IsEqual("long"), isdef.IsEqual("short")),
})
dogValidator := Compose(
    petValidator,
    MustCompile(map[string]interface{}{"barks": isFrequency}),
)
catValidator := Compose(
    petValidator,
    MustCompile(map[string]interface{}{"meows": isFrequency}),
)

for _, pet := range pets {
    var petType string
    if dogValidator(pet).Valid {
        petType = "dog"
    } else if catValidator(pet).Valid {
        petType = "cat"
    }
    fmt.Printf("%s is a %s\n", pet["name"], petType)
}

// Sortie :
// rover est un chien
// lucky est un chien
// pounce est un chat
// peanut est un chat

Pourquoi nous avons créé Lookslike

L’idée de Lookslike est née du projet Heartbeat chez Elastic. Heartbeat est l’agent sur lequel s’appuie notre solution Uptime. Il émet des requêtes ping sur les points de terminaison, puis indique s’ils sont actifs ou inactifs. Heartbeat génère des documents Elasticsearch, représentés en tant que types map[string]interface{} dans notre base de codes Golang. C’est le fait de tester lesdits documents de sortie qui a créé la nécessité d’établir cette bibliothèque, même si elle est désormais utilisée ailleurs dans la base de codes Beats.

Nous avons été confrontés à certaines problématiques, parmi lesquelles :

• Certains champs contenaient des données avec lesquelles il fallait établir une correspondance imprécise, p. ex. monitor.duration qui mesurait la durée d’une exécution. Et d’une exécution à l’autre, la durée n’était pas la même. Nous souhaitions un moyen d’avoir une correspondance de données flexible.
• Quel que soit le test, de nombreux champs étaient partagés avec d’autres tests, et les variations étaient limitées. Nous souhaitions pouvoir réduire la duplication de code en composant différentes définitions de champ.
• Nous voulions obtenir des sorties de test appropriées, présentant les échecs de champ individuels comme des erreurs individuelles, d’où le module d’aide testslike.

Au vu de ces problématiques, nous avons pris les décisions suivantes au niveau de la conception :

• Nous souhaitions que le schéma soit flexible, et nous voulions que les développeurs puissent créer de nouveaux critères de correspondance avec facilité.
• Nous voulions qu’il soit possible de composer et d’imbriquer les schémas, de sorte que, si vous imbriquiez un document dans un autre, il soit possible de combiner simplement les schémas sans avoir à dupliquer une partie du code.
• Nous avions besoin d’un bon module d’aide de test, pour que les échecs de test soient faciles à lire.

Types de clés

L’architecture de Lookslike tourne autour de deux principaux types : Validator et IsDef. Validator est le résultat de la compilation d’un schéma particulier. C’est une fonction qui prend une structure de données arbitraire et renvoie un résultat. IsDef est le type qui permet d’établir une correspondance avec un champ individuel. Vous vous demandez peut-être pourquoi nous faisons la distinction entre ces deux types. Et cette question est pertinente, car nous serons probablement amenés à fusionner ces types dans le futur. Concrètement, si nous faisons la distinction, c’est principalement parce que IsDef dispose d’arguments supplémentaires par rapport à la localisation dans la structure de documents, qui lui permettent d’effectuer des validations plus pointues d’après le contexte. Les fonctions Validator n’ont pas d’informations supplémentaires, mais elles sont plus conviviales à exécuter (elles prennent juste en compte interface{} et font la validation).

Pour obtenir des exemples de types IsDefs personnalisés, consultez tout simplement les fichiers source. Vous pouvez ajouter un nouveau type IsDef à votre propre source pour l’étendre.

Exemples dans le champ

Nous nous servons très régulièrement de Lookslike dans Beats. Besoin d’un exemple ? Ne cherchez plus, consultez cette recherche github.

Nous avons besoin de votre aide !

Si vous souhaitez utiliser Lookslike, envoyez une requête d’extraction sur le référentiel ! Nous pouvons utiliser un ensemble particulier de types IsDef plus complet.

En savoir plus

Nous n’avons pas ménagé notre peine pour vous aider avec Lookslike. Vous pouvez lire les documents concernant Lookslike sur godoc.org.

Nous sommes ravis d'annoncer la disponibilité générale de la Suite Elastic 7.4. Cette version 7.4 siffle le coup d'envoi d'un grand nombre de nouvelles fonctionnalités qui simplifient le lancement et l'administration des clusters, intègrent de nouvelles capacités d'agrégation et de machine learning et renforcent la sécurité de la Suite. Côté solutions, Elastic SIEM apporte des améliorations aux workflows des opérations de sécurité : l'analyse géospatiale s'appuie désormais sur des cartes en temps réel, et 13 nouvelles tâches de machine learning prédéfinies permettent la détection d'un grand nombre de menaces de sécurité que les seules règles n'étaient pas en mesure de repérer.

La version 7.4 est d'ores et déjà disponible via Elasticsearch Service sur Elastic Cloud – la seule offre Elasticsearch hébergée à proposer ces nouvelles fonctionnalités. Et si vous préférez une expérience autogérée, vous pouvez aussi choisir de télécharger la Suite Elastic.

La présentation complète des fonctionnalités est disponible dans les articles de blog dédiés. Mais sans plus tarder, voici les grandes fonctionnalités de cette nouvelle version.

Gestion du cycle de vie des snapshots : et la sauvegarde des données devient plus simple que jamais

Les snapshots et la restauration sont le meilleur moyen de sauvegarder (et de restaurer) vos données Elasticsearch. Il s'agit d'une étape essentielle pour quasiment tous les déploiements. Dans cette version 7.4, nous lançons la gestion du cycle de vie des snapshots. Celle-ci permet aux administrateurs de définir des règles qui se chargeront de gérer le moment et la fréquence des snapshots. Si vous devez restaurer les données suite à un sinistre ou pour toute autre raison, vous êtes ainsi assuré de disposer des sauvegardes récentes et adaptées.

Associée à la fonctionnalité de gestion du cycle de vie des index lancée dans la version 6.7, la gestion du cycle de vie des snapshots simplifie considérablement l'exploitation des clusters de production. Avec ces fonctionnalités natives directement intégrées à la Suite Elastic, les administrateurs sont moins dépendants des outils externes et des tâches cron, gagnent en fiabilité et en visibilité, et peuvent se consacrer à la définition des règles de protection des données essentielles à leur entreprise. Bien que nous soyons toujours des inconditionnels de l'API-First, nous sommes ravis de proposer une interface utilisateur pour la gestion du cycle de vie des snapshots (accessible via l'interface de sauvegarde et de restauration de Kibana).

Pour tout savoir sur le sujet, consultez l'article de blog dédié à Elasticsearch.

Elastic Maps et Elastic SIEM : à vos sabres laser ! Une carte des cybermenaces conçue pour les analystes

Quiconque a déjà visité un data center sait que les cartes des cybermenaces, avec leurs faisceaux multicolores dignes des sabres laser de Star Wars, sont un plaisir pour les yeux. (En anglais, on les surnomme d'ailleurs parfois "pew pew maps", en référence au son qu'émettent les sabres laser dans le film culte.) Avec la version 7.4, l'application SIEM intègre une carte basée sur les données actives, que les analystes peuvent filtrer, explorer, et dans laquelle ils peuvent lancer des recherches en temps réel. Mais si elle arrache des cris d'admiration aux visiteurs des data centers, elle n'en demeure pas moins un outil de sécurité conçu pour les analystes. Dans Elastic SIEM, l'emplacement géographique devient un attribut qui permet aux analystes de gagner en visibilité et de porter un regard averti sur l'état des cybermenaces.

"Depuis que nous l'avons adoptée, le nombre de sources de données de log que nous ingérons dans la Suite Elastic ne cesse d'augmenter. Notre équipe de sécurité peut rapidement rechercher et visualiser l'ensemble de nos données de sécurité, pour y mener des investigations interactives et efficaces. Tout cela, directement depuis Kibana", déclare Wieger van der Meulen, IT Security Manager chez Leaseweb Global B.V. "De plus, les fonctionnalités Machine Learning de la Suite Elastic assurent la détection automatique des comportements inhabituels dans notre infrastructure. Avec toutes les nouvelles tâches de machine learning intégrées à la version 7.4 de l'application SIEM, nous comptons bien mettre en place un ensemble encore plus complet détections des anomalies. L'adoption d'Elastic SIEM nous a permis de réagir bien plus rapidement aux incidents et de prendre les mesures appropriées pour limiter les risques."

La carte des cybermenaces s'appuie directement sur Elastic Maps : elle bénéficie donc des nombreuses années que nous avons consacrées à l'analyse géospatiale et aux fonctionnalités de recherche. Autre nouveauté Elastic Maps dans la version 7.4 : la fonctionnalité de liaison point à point, qui permet de visualiser d'un coup d'œil les relations qui existent entre les données. Avec l'intégration d'Elastic Maps dans l'application SIEM, les utilisateurs bénéficient de cette nouvelle fonctionnalité point à point, mais aussi des améliorations que nous ne cessons d'apporter à Elastic Maps.

Pour en savoir plus, n'hésitez pas à consulter l'article de blog dédié à Elastic SIEM.

Machine Learning : toujours un tour de plus que la veille dans son sac

Dans la version 7.3, nous avions introduit les transformations de données, afin que les utilisateurs puissent réorganiser à chaud leurs données Elasticsearch dans de nouveaux index centrés sur les entités. Cette fonctionnalité "transformatrice" (c'est le cas de le dire) sert de socle à un ensemble de méthodes d'analyse et de machine learning innovantes, comme la détection des aberrations, la régression, la classification, et plus encore. Nous sommes donc ravis de concrétiser cette vision dans la version 7.4, et d'enrichir Machine Learning d'API dédiées à l'analyse de régression et d'une interface utilisateur de détection des aberrations.

Et pour vous permettre de créer, de gérer et d'afficher vos tâches de détection des aberrations, l'application Machine Learning de Kibana intègre maintenant un nouvel onglet "Analytics" (Analytique).

"Pour mon équipe, l'application Machine Learning d'Elastic est un outil essentiel : c'est un véritable accélérateur, qui nous permet de traiter un volume exponentiel de données, que nous n'aurions jamais pu gérer autrefois", affirme Jonathon Robinson, Fraud Intelligence Manager chez PSCU. "Nous avons tout de suite utilisé Machine Learning pour détecter des activités frauduleuses. Au bout de 15 jours, nous avions déjà réalisé des économies considérables. Et au cours du seul mois dernier, nous avons économisé des millions de dollars pour nos coopératives de crédit."

Et ce n'est pas tout. Outre ces deux nouvelles méthodes, nous lançons aussi plusieurs tâches de machine learning prêtes à utiliser (13, très exactement). Intégrées à Elastic SIEM, elles vous permettent de détecter des menaces de sécurité qui affectent couramment les réseaux, ainsi que les données relatives à l'activité de l'hôte collectées par Auditbeat. Citons par exemple la détection des processus anormaux, ou encore celle des activités de port réseau inhabituelles.

Pour tout savoir sur le sujet, consultez l'article de blog dédié à Elasticsearch.

Une observabilité plus détaillée

Dans la version 7.4, nous avons considérablement renforcé l'instrumentation automatique d'Elastic APM : les agents APM vont désormais plus loin et soutiennent une expérience de type "plug-and-play" pour les frameworks de programmation les plus courants. Parmi ces nouveautés, citons notamment la compatibilité de l'agent RUM avec Angular, ou celle de l'agent .NET avec .NET Framework, qu'on rencontre tous deux couramment dans les applications d'entreprise existantes. Par ailleurs, nous avons aussi capitalisé sur les données de géolocalisation RUM lancées dans la précédente version, et avons ajouté à l'interface utilisateur d'APM un affichage détaillé des performances par zone géographique, ce qui vous permet d'isoler les problèmes spécifiques à certaines régions pour les résoudre plus rapidement. Enfin, les filtres structurés de l'interface utilisateur d'Elastic APM permettent aux analystes de rechercher les données de trace encore plus rapidement, ce qui se traduit par une accélération des cycles de résolution. Pour en savoir plus, jetez un œil à l'article de blog consacré à la nouvelle version d'Elastic APM.

À chaque nouvelle version, la Suite Elastic vous propose de nouvelles façons de monitorer automatiquement l'intégrité de votre infrastructure et de vos services stratégiques. Avec la version 7.4, vous pouvez désormais ingérer des indicateurs depuis un plus grand nombre de services AWS, y compris Elastic Load Balancer (ELB), Elastic Block Storage (EBS) ou encore les statistiques CloudWatch. Autre nouveauté : la possibilité de lire des logs de serveur directement depuis Amazon S3. Nous avons aussi boosté les capacités de monitoring Kubernetes grâce à de nouveaux indicateurs pour les tâches planifiées, et intégré un nouveau module StatsD pour la collecte des indicateurs personnalisés qui utilisent ce format courant. Le monitoring de base de données n'est pas non plus en reste. Il passe à la vitesse supérieure, et intègre un grand nombre de nouveaux ensembles d'indicateurs, ainsi que des tableaux de bord par défaut optimisés pour des datastores comme Oracle, Prometheus et Postgres. Et pour finir, l'analyse de logs est maintenant compatible IBM MQ, puisqu'il s'agit d'une plateforme de messagerie essentielle à bon nombre d'applications d'entreprise. Pour en savoir plus, n'hésitez pas à consulter les articles de blog consacrés aux nouvelles versions d'Elastic Infrastructure et d'Elastic Log.

Authentification PKI dans Kibana

Le modèle de sécurité de Kibana ne cesse d'évoluer pour vous offrir de nouveaux moyens d'accès sécurisés. Après de formidables lancements comme celui des commandes de fonctionnalité dans la version 7.2, ou encore la compatibilité Kerberos dans la version 7.3, nous continuons sur notre lancée, et sommes ravis d'annoncer la prise en charge d'une autre méthode d'authentification que vous étiez très nombreux à réclamer. J'ai nommé l'authentification PKI (Public Key Infrastructure, ou infrastructure à clés publiques), qui est maintenant officiellement prise en charge dans la version 7.4. Notre communauté utilise très largement ce type de chiffrement, par exemple dans les secteurs financier, médical, gouvernemental ou militaire, pour n'en citer que quelques-uns.

Jusqu'ici, il était possible d'utiliser l'authentification PKI avec Kibana derrière un proxy. Mais la version 7.4 vient simplifier ces architectures. Avec la prise en charge native de l'authentification PKI, les utilisateurs peuvent maintenant se connecter à Kibana via des certificats clients X.509 et un système de chiffrement bidirectionnel. Voilà qui ouvre de nouveaux horizons en matière d'accès sécurisé à Kibana. Depuis les autorisations générales par certificat client jusqu'aux cartes d'accès physiques de type carte à puce ou carte d'identité, avec Kibana, tout est possible. Envie d'en savoir plus ? Notre documentation vous explique comment vous lancer.

En savoir plus

• Lancement d'Elasticsearch 7.4.0
• Lancement de Kibana 7.4.0
• Lancement de Beats 7.4.0
• Lancement de Logstash 7.4.0
• Du nouveau du côté de l'observabilité dans la Suite Elastic 7.4
• Lancement d'Elastic SIEM 7.4.0
• Lancement d'Elastic Maps 7.4.0

Elastic APM (monitoring des performances applicatives) apporte une myriade d'informations à propos des performances de l'application et de la visibilité des charges de travail distribuées, avec un support technique officiel dans un grand nombre de langages, y compris Go, Java, Ruby, Python, JavaScript (Node.js et Real User Monitoring [RUM] pour le navigateur).

Pour obtenir ces informations sur la performance, vous devez instrumenter votre application. L'instrumentation est le fait de modifier le code de l'application afin d'analyser son comportement. Pour certains des langages pris en charge, il suffit d'installer un agent. Par exemple, les applications Java peuvent être instrumentées automatiquement à l'aide d'un simple indicateur -javaagent qui utilise une instrumentation du bytecode, c'est-à-dire le processus de manipulation du code byte de Java compilé, généralement lorsqu'une classe Java est chargée au démarrage du programme. En outre, il est fréquent pour un thread unique de prendre contrôle d'une opération du début à la fin afin que le stockage local de thread puisse être utilisé pour mettre les opérations en corrélation.

Les programmes Go sont en général compilés en code machine natif, qui est moins disposé à l'instrumentation automatisée. De plus, le modèle de threading des programmes Go est différent de la plupart des langages. Dans un programme Go, une "goroutine" qui exécute le code peut se déplacer entre les threads du système d'exploitation et les opérations logiques génèrent souvent plusieurs goroutines. Alors, comment instrumenter une application Go ?

Dans cet article, nous examinerons le moyen d'instrumenter une application Go avec Elastic APM afin de capturer des données détaillées de performance du temps de réponse (tracing), capturer des indicateurs d'infrastructure et d'application et les intégrer au logging : le trio gagnant de l'observabilité. Nous créerons une application et son instrumentation au fil de l'article en abordant les sujets suivants dans l'ordre :

• Requêtes Web
• Requêtes SQL
• Intervalles personnalisés
• Requêtes HTTP sortantes
• Suivi d'alerte
• Intégration au logging
• Infrastructure et indicateurs d'application

Suivi des requêtes Web

L'agent Elastic APM Go fournit une API pour les opérations de "suivi" comme les requêtes entrantes vers un serveur. Suivre une opération implique d'enregistrer des événements qui décrivent l'opération, par exemple le nom de l'opération, son type/sa catégorie et quelques attributs comme l'ip source, l'utilisateur authentifié, etc. L'événement enregistre également quand l'opération a commencé, combien de temps elle a duré et les identifiants décrivant le retraçage de l'opération.

L'agent Go pour Elastic APM fournit plusieurs modules pour l'instrumentation de différents frameworks Web, frameworks RPC et pilotes de base de données, et pour l'intégration à plusieurs frameworks de logging. Jetez un œil à la liste complète des technologies prises en charge.

Ajoutons l'instrumentation Elastic APM à un simple service Web à l'aide du routeur gorilla/mux et démontrons comment nous nous y prendrions pour capturer sa performance via Elastic APM.

Voici le code original et non instrumenté :

package main                                                 
import (                                                     
        "fmt"                                                
        "log"                                                
        "net/http"                                           
        "github.com/gorilla/mux"                             
)                                                            
func helloHandler(w http.ResponseWriter, req *http.Request) {
        fmt.Fprintf(w, "Hello, %s!\n", mux.Vars(req)["name"])
}                                                            
func main() {                                                
        r := mux.NewRouter()                                 
        r.HandleFunc("/hello/{name}", helloHandler)          
        log.Fatal(http.ListenAndServe(":8000", r))           
}

Pour instrumenter les requêtes servies par le routeur gorilla/mux, vous avez besoin d'une version récente de gorilla/mux (v1.6.1 ou plus) avec une prise en charge pour les intergiciels. Ensuite, tout ce qu'il vous reste à faire, c'est d'importer go.elastic.co/apm/module/apmgorilla et d'ajouter la ligne de code suivante :

r.Use(apmgorilla.Middleware())

L'intergiciel apmgorilla rapporte chaque requête comme une transaction au serveur APM. Faisons une pause avec l'instrumentation et regardons de quoi cela a l'air dans l'interface utilisateur APM.

Visualisation de la performance

Nous avons instrumenté notre service Web, mais il n'a nulle part où envoyer les données. Par défaut, les agents APM essaient d'envoyer des données à un serveur APM à l'adresse http://localhost:8200. Configurons une nouvelle suite à l'aide de la version 7.0.0 récemment sortie de la Suite Elastic. Vous pouvez télécharger gratuitement le déploiement de la suite par défaut ou commencer un essai gratuit de 14 jours du Elasticsearch Service sur Elastic Cloud. Si vous préférez exécuter le vôtre, vous pouvez trouver l'exemple de configuration Docker Compose sur https://github.com/elastic/stack-docker.

Une fois que vous avez configuré la suite, vous pouvez configurer votre application pour envoyer des données au serveur APM. Vous aurez besoin de connaître l'URL du serveur APM et le token secret. Lorsque vous utilisez Elastic Cloud, ces derniers peuvent être trouvés sur la page "Activity" durant le déploiement et sur l'une des pages "APM" une fois le déploiement complété. Au cours du déploiement, il vous faudra également noter le mot de passe pour Elasticsearch et Kibana, étant donné que vous ne pourrez pas le revoir ensuite (bien qu'il soit possible de le réinitialiser si nécessaire).

L'agent APM Go est configuré avec des variables environnementales. Pour configurer l'URL et le token secret du serveur APM, exportez les variables environnementales suivantes afin qu'elles soient prises en charge par votre application :

export ELASTIC_APM_SERVER_URL=https://bdf8658ddda74d47af1875242c3ef203.apm.europe-west1.gcp.cloud.es.io:443
export ELASTIC_APM_SECRET_TOKEN=H9U312SRGzbG7M0Yp6

Maintenant, si nous exécutons le programme instrumenté, nous devrions voir rapidement des données dans l'interface utilisateur APM. L'agent envoie périodiquement des indicateurs : Le CPU, l'utilisation de la mémoire et les statistiques d'exécution de Go. Dès qu'une requête est servie, l'agent enregistre également une transaction. Cette dernière est mise en mémoire tampon et envoyée en lot toutes les 10 secondes par défaut. Alors, exécutons le service pour envoyer quelques requêtes et voir ce qui se passe.

Afin de vérifier que les événements sont envoyés au serveur API avec succès, nous pouvons définir quelques variables environnementales supplémentaires :

export ELASTIC_APM_LOG_FILE=stderr
export ELASTIC_APM_LOG_LEVEL=debug

Maintenant, démarrez l'application (hello.go contient le programme instrumenté de tout à l'heure) :

go run hello.go

Ensuite, nous allons utiliser github.com/rakyll/hey pour envoyer des requêtes au serveur :

go get -u github.com/rakyll/hey
hey http://localhost:8000/hello/world

Dans la sortie de l'application, vous devriez voir quelque chose qui ressemble à ce qui suit :

{"level":"debug","time":"2019-03-28T20:33:56+08:00","message":"sent request with 200 transactions, 0 spans, 0 errors, 0 metricsets"}

Et dans la sortie de hey, vous devriez voir différentes statistiques, y compris un histogramme du temps de réponse des latences. Si nous ouvrons Kibana et que nous naviguons vers l'interface utilisateur APM, nous devrions trouver un service appelé "hello" avec un groupe de transactions appelé "/hello/{name}". Voyons voir :

Vous avez peut-être quelques questions : comment l'agent sait-il quel nom donner au service ? Et pourquoi le modèle d'itinéraire est-il utilisé à la place de l'URI de requête ? La première est facile : si vous ne précisez pas de nom de service (avec une variable d'environnement), c'est le nom binaire du programme qui est utilisé. Dans ce cas, le programme est compilé en un binaire appelé "hello".

Si le modèle d'itinéraire est utilisé, c'est pour activer des agrégations. Si nous cliquons maintenant sur la transaction, nous pouvons voir un histogramme des latences du temps de réponse.

Remarque : même si nous agrégeons sur le modèle d'itinéraire, l'URL demandée complète est disponible dans les propriétés de transaction.

Tracer des requêtes SQL

Dans une application typique, vous aurez plus de logique complexe impliquant des services externes comme des bases de données, des caches, etc. Lorsque vous essayez de diagnostiquer les problèmes de performance dans votre application, il est essentiel de pouvoir voir les interactions avec ces services.

Examinons la façon dont nous pouvons observer les requêtes SQL de votre application Go.

Dans le but de cette démonstration, nous utiliserons une base de données SQLite, mais du moment que vous utilisez database/sql, le pilote que vous utilisez n'est pas important.

Pour tracer les opérations database/sql, nous fournissons le modèle d'instrumentation go.elastic.co/apm/module/apmsql. Le module apmsql instrumente les pilotes database/sql afin de rapporter les opérations de la base de données en tant qu'intervalles au sein d'une transaction. Pour utiliser ce module, vous devrez effectuer des changements sur votre façon de vous inscrire et ouvrir le pilote de la base de données.

Dans une application, vous importez généralement un pack de pilotes database/sql pour inscrire le pilote, par exemple :

import _ “github.com/mattn/go-sqlite3” // registers the “sqlite3” driver

Nous fournissons plusieurs packs de commodité pour faire de même, mais qui inscrivent des versions instrumentées des mêmes pilotes. Par exemple pour SQLite3, vous effectueriez l'importation comme suit :

import _ "go.elastic.co/apm/module/apmsql/sqlite3"

Sous le capot, cela utilise la méthode apmsql.Register, qui est l'équivalent de faire appel à sql.Register, mais instrumente le pilote inscrit. Chaque fois que vous utilisez apmsql.Register, vous devez utiliser pmsql.Open pour ouvrir une connexion au lieu d'utiliser sql.Open :

import (
        “go.elastic.co/apm/module/apmsql”
        _ "go.elastic.co/apm/module/apmsql/sqlite3"
)
var db *sql.DB
func main() {
        var err error
        db, err = apmsql.Open("sqlite3", ":memory:")
        if err != nil {
                log.Fatal(err)
        }
        if _, err := db.Exec("CREATE TABLE stats (name TEXT PRIMARY KEY, count INTEGER);"); err != nil {
                log.Fatal(err)
        }
        ...
}

Nous avons mentionné précédemment que, contrairement à de nombreux autres langages, il n'y a pas d'infrastructure de stockage local de thread pour rassembler les opérations associées. Au lieu de quoi, vous devez propager le contexte explicitement. Lorsque nous commençons à enregistrer une transaction pour une requête Web, nous stockons une référence à la transaction en cours dans le contexte de requête disponible via la méthode net/http.Request.Context. Voyons voir ce que cela donne lorsque nous enregistrer le nombre de fois où chaque nom a été vu en rapportant les requêtes de base de données à Elastic APM.

var db *sql.DB
func helloHandler(w http.ResponseWriter, req *http.Request) {       
        vars := mux.Vars(req)
        name := vars[“name”]
        requestCount, err := updateRequestCount(req.Context(), name)
        if err != nil {                                             
                panic(err)                                          
        }                                                           
        fmt.Fprintf(w, "Hello, %s! (#%d)\n", name, requestCount)    
}                                                                   
// updateRequestCount augmente un compte de noms dans la base de données et obtient un nouveau compte.
func updateRequestCount(ctx context.Context, name string) (int, error) {                                                    
        tx, err := db.BeginTx(ctx, nil)                                                                                     
        if err != nil {                                                                                                     
                return -1, err                                                                                              
        }                                                                                                                   
        row := tx.QueryRowContext(ctx, "SELECT count FROM stats WHERE name=?", name)                                        
        var count int                                                                                                       
        switch err := row.Scan(&count); err {                                                                               
        case nil:                                                                                                           
                count++                                                                                                     
                if _, err := tx.ExecContext(ctx, "UPDATE stats SET count=? WHERE name=?", count, name); err != nil {        
                        return -1, err                                                                                      
                }                                                                                                           
        case sql.ErrNoRows:
                count = 1                                                                                                 
                if _, err := tx.ExecContext(ctx, "INSERT INTO stats (name, count) VALUES (?, ?)", name, count); err != nil {
                        return -1, err                                                                                      
                }                                                                                                           
        default:                                                                                                            
                return -1, err                                                                                              
        }                                                                                                                   
        return count, tx.Commit()                                                                                           
}

Il faut souligner deux éléments essentiels à propos de ce code :

• Nous utilisons la base de données database/sql *Méthodes de contexte (ExecContext, QueryRowContext)
• Nous transférons le contexte d'une requête englobante à ces appels méthodiques.

Le pilote de la base de données instrumentée avec apmsql s'attend à trouver une référence à la transaction en cours dans le contexte fourni, c'est de cette façon que l'opération de base de données rapportée est associée avec le gestionnaire de requête qui l'appelle. Envoyons quelques requêtes à cette nouvelle version du service et observons ce qui se passe :

Les noms d'intervalle de la base de données ne contiennent pas l'énoncé SQL entier, mais juste une partie de ce dernier. Cela permet par exemple d'agréger plus simplement les intervalles représentant les opérations d'un certain nom de tableau. En cliquant sur l'intervalle, vous pouvez voir l'énoncé SQL entier dans les détails de l'intervalle :

Traçage d'intervalles personnalisés

Dans la section précédente, nous avons présenté les intervalles de recherches de la base de données à nos traces. Si vous connaissez bien le service, vous pouvez savoir immédiatement que ces deux recherches font partie de la même opération (recherche puis mise à jour d'un compteur), mais ce n'est pas nécessairement le cas de tout le monde. En outre, s'il y a un processus important entre ou autour de ces recherches, il peut alors être utile de l'attribuer à la méthode "updateRequestCount". Pour ce faire, nous pouvons rapporter un intervalle personnalisé pour cette fonction.

Vous pouvez rapporter un intervalle personnalisé de plusieurs façons, la plus simple étant d'utiliser apm.StartSpan. Vous devez transférer cette fonction à un contexte qui contient une transaction et un nom et type d'intervalle. Créons un intervalle appelé "updateRequestCount" :

func updateRequestCount(ctx context.Context, name string) (int, error) {             
    span, ctx := apm.StartSpan(ctx, “updateRequestCount”, “custom”)
    defer span.End()
    ...
}

Comme nous pouvons le voir d'après le code ci-dessus, apm.StartSpan renvoie un intervalle et un nouveau contexte. Ce nouveau contexte devrait être utilisé à la place du contexte transféré puisqu'il contient le nouvel intervalle. Voilà à quoi cela ressemble maintenant dans l'interface utilisateur :

Traçage de requêtes HTTP sortantes

Ce que nous avons décrit jusqu'à maintenant est un traçage à processus unique. Bien que de multiples services soient impliqués, nous ne traçons qu'au sein d'un seul processus : les requêtes entrantes et les recherches de base de données du côté du client.

Les microservices sont devenus de plus en plus répandus au cours des dernières années. Avant l'arrivée des microservices, l'architecture orientée services (AOS) était une autre approche populaire pour désagréger des applications monolithiques en composants modulaires. Dans tous les cas, l'effet est une augmentation de la complexité, qui complexifie l'observabilité. Maintenant, il faut associer des opérations non seulement au sein d'un processus, mais également entre les processus et potentiellement (probablement) sur différentes machines, voire même différents centres de données ou services tiers.

Il y a peu de différences entre la façon dont nous gérons le traçage au sein de et entre les processus dans l'agent Go pour Elastic APM. Par exemple, pour tracer une requête HTTP sortante, vous devez instrumenter le client HTTP et vous assurer que le contexte de requête englobante est propagé à la requête sortante. Le client instrumenté utilisera ceci pour créer un intervalle et injecter des en-têtes dans la requête HTTP sortante. Voyons voir ce que cela donne en pratique :

// apmhttp.WrapClient instrumente le http.Client donné
client := apmhttp.WrapClient(http.DefaultClient)
// Si "ctx" contient une référence à une transaction en cours, alors l'appel ci-dessous commencera un nouvel intervalle.
resp, err := client.Do(req.WithContext(ctx))
…
resp.Body.Close() // the span is ended when the response body is consumed or closed

Si la requête sortante est gérée par une autre application instrumentée avec Elastic APM, vous obtenez une "trace distribuée", c'est-à-dire une trace (collection de transactions et intervalles associées) qui croise les services. Le client instrumenté injectera un en-tête qui identifie l'intervalle pour la requête HTTP sortante, puis le service récepteur extrait cet en-tête et l'utilise pour mettre en corrélation l'intervalle du client avec la transaction que ce dernier enregistre. Tout est géré par plusieurs modules d'instrumentation de frameworks Web fournis dans go.elastic.co/apm/module.

Pour présenter un exemple, étendons notre service pour ajouter des éléments superficiels à la réponse : le nombre de bébés nés avec le nom donné en 2018 en Australie-Méridionale. Le service "hello" obtiendra cette information auprès d'un deuxième service via une API HTTP. Le code de ce deuxième service est omis pour des raisons de concision, mais vous pouvez l'imaginer intégré et instrumenté de la même façon que le service "hello".

func helloHandler(w http.ResponseWriter, req *http.Request) {                             
        ...                                                                               
        stats, err := getNameStats(req.Context(), name)                                   
        if err != nil {
                panic(err)
        }                                                                                 
        fmt.Fprintf(w, "Hello, %s! (#%d)\n", name, requestCount)                          
        fmt.Fprintf(w, "In %s, %d: ", stats.Region, stats.Year)                           
        switch n := stats.Male.N + stats.Female.N; n {                                    
        case 1:                                                                           
                fmt.Fprintf(w, "there was 1 baby born with the name %s!\n", name)         
        default:                                                                          
                fmt.Fprintf(w, "there were %d babies born with the name %s!\n", n, name)  
        }                                                                                 
}                                                                                         
type nameStatsResults struct {                                                                    
        Region string                                                                             
        Year   int                                                                                
        Male   nameStats                                                                          
        Female nameStats                                                                          
}                                                                                                 
type nameStats struct {                                                                           
        N    int                                                                                  
        Rank int                                                                                  
}                                                                                                 
func getNameStats(ctx context.Context, name string) (nameStatsResults, error) {                   
        span, ctx := apm.StartSpan(ctx, "getNameStats", "custom")                                 
        defer span.End()                                                                          
        req, _ := http.NewRequest("GET", "http://localhost:8001/stats/"+url.PathEscape(name),
 nil)
        // Instrumentez le client HTTP et ajoutez le contexte environnant à la requête.
        // Cela entraînera la génération d'un intervalle pour la requête HTTP sortante, y compris
        // un en-tête de traçage distribué pour continuer la trace dans le service cible.
        client := apmhttp.WrapClient(http.DefaultClient)                                          
        resp, err := client.Do(req.WithContext(ctx))                                              
        if err != nil {                                                                           
                return nameStatsResults{}, err                                                    
        }                                                                                         
        defer resp.Body.Close()                                                                   
        var res nameStatsResults                                                                  
        if err := json.NewDecoder(resp.Body).Decode(&res); err != nil {                           
                return nameStatsResults{}, err                                                    
        }                                                                                         
        return res, nil                                                                           
}

Une fois les deux services instrumentés, une trace distribuée apparaît désormais pour chaque requête du service "hello" :

Vous pouvez vous renseigner davantage sur le sujet du traçage distribué dans l'article de blog d'Adam Quan Distributed Tracing, OpenTracing and Elastic APM (Traçage distribué, OpenTracing et Elastic APM).

Exception suivi d'alerte

Comme nous l'avons remarqué, les modules d'instrumentation de frameworks Web fournissent des intergiciels qui enregistrent les transactions. En outre, ils capturent également les alertes et les rapportent à Elastic APM pour assister l'enquête des échecs de requêtes. Essayons cette fonction en modifiant updateRequestCount pour qu'il lance une alerte lorsqu'il voit des caractères non ASCII :

func updateRequestCount(ctx context.Context, name string) (int, error) {
    span, ctx := apm.StartSpan(ctx, “updateRequestCount”, “custom”)
    defer span.End()
    if strings.IndexFunc(name, func(r rune) bool {return r >= unicode.MaxASCII}) >= 0 {
        panic(“non-ASCII name!”)
    }
    ...
}

Maintenant, envoyez une requête avec des caractères non-ASCII :

curl -f http://localhost:8000/hello/世界
curl: (22) The requested URL returned error: 500 Internal Server Error

Alors, d'où peut venir le problème ? Jetons un œil dans l'interface utilisateur APM, sur la page Errors (erreurs) du service "hello" :

Ici, nous pouvons voir qu'une erreur s'est produite, y compris le message d'erreur (alerte) "nom non-ASCII !" et le nom de la fonction d'où est venue l'alerte updateRequestCount. En cliquant sur le nom de l'erreur, nous sommes redirigés vers les détails de l'instance la plus récente de cette erreur. Sur la page de détails de l'erreur, nous pouvons voir la trace entière de la suite, un instantané des détails de la transaction où l'erreur s'est produite au moment où elle s'est produite et un lien vers la transaction complète.

En plus de capturer ces alertes, vous pouvez rapporter explicitement les erreurs à Elastic AOPM à l'aide de la fonction apm.CaptureError. Vous devez transférer cette fonction à un contexte qui contient une transaction et une valeur d'erreur. CaptureError renvoie un objet "apm.Error" que vous pouvez personnaliser si vous le souhaitez, puis finaliser à l'aide de sa méthode Send :

if err != nil {
    apm.CaptureError(req.Context(), err).Send()
    return err
}

Enfin, il est possible de l'intégrer aux frameworks de logging pour envoyer des logs d'erreur à Elastic APM. Nous y reviendrons dans la section suivante.

Intégration au logging

Ces dernières années, il a beaucoup été question des "Trois piliers de l'observabilité" : traces, logs et indicateurs. Jusqu'à maintenant, nous avons parlé de traçage, mais la Suite Elastic couvre ces trois piliers et bien plus encore. Nous aborderons les indicateurs un peu plus tard, voyons d'abord comment Elastic APM s'intègre à votre logging d'application.

Si vous avez déjà fait ce genre de logging centralisé, alors vous connaissez probablement déjà bien la Suite Elastic, auparavant connue sous le nom de la suite ELK (Elasticsearch, Logstash et Kibana). Lorsque vous avez vos logs et vos traces dans Elasticsearch, en faire des références croisées devient simple.

L'agent Go dispose de modules d'intégration pour plusieurs frameworks de logging populaires : Logrus (apmlogrus), Zap (apmzap) et Zerolog (apmzerolog). Ajoutons quelques logging à notre service Web à l'aide de Logrus et voyons comment nous pouvons l'intégrer à nos données de traçage.

import "github.com/sirupsen/logrus"
var log = &logrus.Logger{                                                    
        Out:   os.Stderr,                                                
        Hooks: make(logrus.LevelHooks),                                  
        Level: logrus.DebugLevel,                                        
        Formatter: &logrus.JSONFormatter{                                
                FieldMap: logrus.FieldMap{                               
                        logrus.FieldKeyTime:  "@timestamp",              
                        logrus.FieldKeyLevel: "log.level",               
                        logrus.FieldKeyMsg:   "message",                 
                        logrus.FieldKeyFunc:  "function.name", // non-ECS
                },                                                       
        },                                                               
}                                                                        
func init() {
        apm.DefaultTracer.SetLogger(log)
}

Nous avons créé un logrus.Logger qui écrit à stderr et formate des logs en tant que JSON. Pour qu'ils s'adaptent mieux à la Suite Elastic, nous effectuons le mapping de certains champs de logs standards à leurs équivalents dans le Elastic Common Schema (ECS). Nous pourrions aussi les laisser comme ils sont par défaut puis utiliser des processeurs Filebeat pour traduire, mais cette méthode est légèrement plus simple. Nous avons aussi dit à l'agent APM d'utiliser ce logger Logrus pour le logging de messages de débogage au niveau de l'agent.

Maintenant, regardons comment intégrer des logs d'application avec des données de trace APM. Nous allons ajouter quelques logging à notre gestionnaire d'itinéraire helloHandler et voir comment ajouter les ID de trace aux messages de logs. Ensuite, nous allons observer comment envoyer des enregistrements de log d'erreur à Elastic APM pour qu'ils apparaissent dans la page "Errors".

func helloHandler(w http.ResponseWriter, req *http.Request) {                
        vars := mux.Vars(req)
        log := log.WithFields(apmlogrus.TraceContext(req.Context()))                                            
        log.WithField("vars", vars).Info("handling hello request")       
        name := vars["name"]                                             
        requestCount, err := updateRequestCount(req.Context(), name, log)
        if err != nil {                                                  
                log.WithError(err).Error(“failed to update request count”)
                http.Error(w, "failed to update request count", 500)     
                return                                                   
        }                                                                
        stats, err := getNameStats(req.Context(), name)                                   
        if err != nil {
                log.WithError(err).Error(“failed to update request count”)
                http.Error(w, "failed to get name stats", 500)                            
                return                                                                    
        }                                                                                 
        fmt.Fprintf(w, "Hello, %s! (#%d)\n", name, requestCount)                          
        fmt.Fprintf(w, "In %s, %d: ", stats.Region, stats.Year)                           
        switch n := stats.Male.N + stats.Female.N; n {                                    
        case 1:                                                                           
                fmt.Fprintf(w, "there was 1 baby born with the name %s!\n", name)         
        default:                                                                          
                fmt.Fprintf(w, "there were %d babies born with the name %s!\n", n, name)  
        }  
}                                                                        
func updateRequestCount(ctx context.Context, name string, log *logrus.Entry) (int, error) {                          
        span, ctx := apm.StartSpan(ctx, "updateRequestCount", "custom")                                              
        defer span.End()                                                                                             
        if strings.IndexFunc(name, func(r rune) bool { return r >= unicode.MaxASCII }) >= 0 {                        
                panic("non-ASCII name!")                                                                             
        }                                                                                                            
        tx, err := db.BeginTx(ctx, nil)                                                                              
        if err != nil {                                                                                              
                return -1, err                                                                                       
        }                                                                                                            
        row := tx.QueryRowContext(ctx, "SELECT count FROM stats WHERE name=?", name)                                 
        var count int                                                                                                
        switch err := row.Scan(&count); err {                                                                        
        case nil:                                                                                                    
                if count == 4 {                                                                                      
                        return -1, errors.Errorf("no more")                                                          
                }                                                                                                    
                count++                                                                                              
                if _, err := tx.ExecContext(ctx, "UPDATE stats SET count=? WHERE name=?", count, name); err != nil { 
                        return -1, err                                                                               
                }                                                                                                    
                log.WithField("name", name).Infof("updated count to %d", count)                                      
        case sql.ErrNoRows:                                                                                          
                count = 1                                                                                            
                if _, err := tx.ExecContext(ctx, "INSERT INTO stats (name, count) VALUES (?, 1)", name); err != nil {
                        return -1, err                                                                               
                }                                                                                                    
                log.WithField("name", name).Info("initialised count to 1")                                           
        default:                                                                                                     
                return -1, err                                                                                       
        }                                                                                                            
        return count, tx.Commit()                                                                                    
}

Si nous lançons le programme sans sortie redirigée vers un fichier (tmp/hello.log, en partant du principe que vous fassiez fonctionner le programme depuis Linux ou macOS), nous pouvons installer et lancer Filebeat pour envoyer les logs à la même Suite Elastic qui reçoit les données APM. Après avoir installé Filebeat, nous allons modifier sa configuration dans filebeat.yml comme suit :

• Configurez "enabled: true" pour l'entrée du log dans "filebeat.inputs" et modifiez le chemin en "/tmp/hello.log".
• Si vous utilisez Elastic Cloud, configurez "cloud.id" et "cloud.auth", sinon configurez "output.elasticsearch.hosts".
• Ajoutez un processeur "decode_json_fields" afin que les "processors" apparaissent comme suit :

processors:
- add_host_metadata: ~
- decode_json_fields:
    fields: ["message"]
    target: ""
    overwrite_keys: true

Maintenant, lancez Filebeat et les logs abonderont. Si nous envoyons des requêtes au service, nous pourrons désormais passer des traces aux logs au même moment à l'aide de l'action "Show host logs" (afficher les logs de l'hébergeur).

Cette action nous emmènera à l'interface utilisateur des logs filtrée vers l'hébergeur. Si l'application fonctionnait dans un conteneur Docker ou dans Kubernetes, des actions seraient disponibles pour relier les logs au conteneur Docker ou au pod Kubernetes.

En affichant les détails de l'enregistrement d'un log, nous pouvons voir que les ID de traces ont été inclus dans les messages de logs. À l'avenir, une autre action sera ajoutée pour filtrer les logs vers la trace spécifique, vous permettant de ne voir que les messages de logs associés.

Maintenant que nous avons la capacité de passer des traces aux logs, observons l'autre point d'intégration : l'envoi de logs d'erreur à Elastic APM pour qu'ils apparaissent dans la page "Errors". Pour ce faire, nous devons ajouter un apmlogrus.Hook au logger :

func init() {
        // apmlogrus.Hook envoie des messages de log "error" (erreur), "panic" (alerte) et "fatal" à Elastic APM.
        log.AddHook(&apmlogrus.Hook{})
}

Précédemment, nous avons modifié updateRequestCount afin qu'il renvoie une erreur après le quatrième appel, puis nous avons modifié helloHandler afin qu'il l'inscrive dans le log comme une erreur. Envoyons 5 requêtes pour le même nom et voyons ce qui apparaît dans la page "Errors".

Ici, nous pouvons voir deux erreurs. L'une d'elles est une erreur inattendue causée par l'utilisation d'une base de données in-memory, expliquée plus en détail ici : https://github.com/mattn/go-sqlite3/issues/204. Bien joué ! L'erreur "failed to update request count" (échec de la mise à jour du compte requis) est celle que nous sommes venus voir.

Vous pouvez remarquer que les coupables de ces deux erreurs sont updateRequestCount. Comment Elastic APM est-il au courant ? Parce que nous utilisons github.com/pkg/errors, qui ajoute une trace du stack à chaque erreur qu'il crée ou conclue et l'agent Go sait comment utiliser ces traces de stack.

Infrastructure et indicateurs d'application

Enfin, nous arrivons aux indicateurs. De la même manière que lorsque vous pouvez passer vers l'hébergeur et les logs de conteneur à l'aide de Filebeat, vous pouvez passer vers les indicateurs d'infrastructure d'hébergeur et de conteneur à l'aide de Metricbeat. En outre, les agents Elastic APM rapportent périodiquement le CPU du système et de processus ainsi que l'utilisation de la mémoire.

Les agents peuvent aussi envoyer des indicateurs spécifiques au langage et à l'application. Par exemple, l'agent Java envoie des indicateurs spécifiques à JVM tandis que l'agent Go envoie des indicateurs pour l'exécution de Go, par exemple le nombre actuel de goroutines, le nombre cumulé d'allocations de segment de mémoire et le pourcentage de temps passé au nettoyage de la mémoire.

Le travail est en cours pour étendre l'interface utilisateur afin d'accueillir des indicateurs d'application supplémentaires. En attendant, vous pouvez créer des tableaux de bord pour visualiser les indicateurs spécifiques à Go.

Et ce n'est pas tout !

Un élément que nous avons négligé est l'intégration à l'agent Real User Monitoring (RUM) (monitoring des utilisateurs réels), qui permet de voir une trace distribuée depuis le navigateur et jusqu'à vos services back-end. Nous aborderons ce sujet dans un futur article de blog. En attendant, vous pouvez vous mettre en appétit avec une petite gorgée de RUM Elastic.

Nous avons abordé de nombreux sujets dans cet article. S'il vous reste des questions, n'hésitez pas à nous rejoindre dans le forum de discussion et nous ferons de notre mieux pour y répondre.

Elasticsearch est omniprésent quand il s'agit de recherche et d'analyse de données. Développeurs et communautés exploitent Elasticsearch pour répondre à une multitude de cas d'utilisation – depuis la recherche dans l'application et la recherche sur site web jusqu'au logging, en passant par le monitoring de l'infrastructure, APM et l'analyse de la sécurité. Bien qu'il existe maintenant des solutions gratuites pour ces cas d'utilisation, les développeurs doivent commencer par ingérer leurs données dans Elasticsearch avant toute chose.

Cet article vous présente quelques-unes des méthodes les plus utilisées pour ingérer des données dans Elasticsearch Service. Nous prendrons l'exemple d'un cluster hébergé sur Elastic Cloud ou sur Elastic Cloud Enterprise, qui n'est autre que la version sur site d'Elastic Cloud. Qu'on utilise l'un ou l'autre de ces services, l'ingestion des données dans un cluster Elasticsearch autogéré est quasiment identique. L'unique différence tient à la façon dont on s'adresse au cluster.

Mais avant de passer aux détails techniques, si vous avez des questions ou rencontrez des difficultés à la lecture de cet article, n'hésitez surtout pas à vous tourner vers les forums discuss.elastic.co. Notre communauté ultra-réactive sera probablement en mesure de répondre à vos questions.

Prêt à plonger dans l'univers de l'ingestion des données ? Nous aborderons les méthodes suivantes :

• Elastic Beats
• Logstash
• Les clients de langage
• Les outils de développement Kibana

Pour communiquer avec les applications clientes, Elasticsearch intègre une API RESTful très flexible. Les appels REST sont donc utilisés pour l'ingestion des données, la recherche et l'analyse des données. Ils permettent aussi de gérer le cluster et ses index. Sous le capot, toutes les méthodes décrites dans cet article s'appuient sur cette API pour ingérer les données dans Elasticsearch.

Remarque : Dans les paragraphes qui suivent, nous supposons que vous avez déjà créé votre cluster Elasticsearch Service. Si ce n'est pas encore le cas, nous vous suggérons de vous inscrire et d'essayer Elastic Cloud gratuitement. Une fois le cluster créé, vous recevrez un identifiant Cloud ID et un mot de passe associés au compte superutilisateur elastic. L'identifiant Cloud ID est au format suivant : nom_du_cluster_name:ZXVy...Q2Zg==. Il encode l'URL de votre cluster et, comme nous allons le voir, simplifie l'ingestion des données dans ce dernier.

Elastic Beats est un ensemble d'agents légers conçus pour le transfert de données, qui vous permettent d'envoyer facilement des données vers Elasticsearch Service. Les agents Beats étant légers, leur exécution n'entraîne pas vraiment de surcharge : vous pouvez donc les exécuter pour collecter des données sur des appareils aux ressources matérielles limitées, comme les appareils connectés, les dispositifs d'accès ou les périphériques intégrés. Ils sont parfaitement adaptés lorsque vous avez besoin de collecter des données sans pouvoir exécuter de collecteurs de données gourmands en ressources. Avec cette collecte systématique des données sur l'ensemble de vos appareils en réseau, vous êtes en mesure de détecter rapidement des problèmes ou des incidents de sécurité rencontrés à l'échelle du système, par exemple, et d'y réagir immédiatement.

Bien entendu, les agents Beats ne sont pas réservés aux systèmes limités en ressources. Vous pouvez aussi les exécuter sur des systèmes disposant de plus de ressources matérielles.

Il existe autant d'agents Beats que de types de données à collecter :

• Filebeat permet la lecture, le prétraitement et le transfert des données depuis des sources converties en fichiers. Bien que la plupart des utilisateurs l'exploitent pour la lecture de fichiers log, Filebeat accepte n'importe quel type de format de fichier non binaire. Il est également compatible avec d'autres sources de données, telles que TCP/UDP, Redis, Syslog et les conteneurs. De plus, il propose une multitude de modules qui facilitent la collecte et l'analyse des formats de log associés à des applications courantes, comme Apache, MySQL et Kafka.
• Metricbeat assure la collecte et le prétraitement des indicateurs système et des indicateurs de service. Les indicateurs système comprennent des informations relatives aux processus en cours d'exécution, ainsi que des statistiques sur l'utilisation de la CPU, de la mémoire, du disque et du réseau. Metricbeat propose aussi des modules qui permettent de collecter des données depuis un grand nombre de services, dont Kafka, Palo Alto Networks, ou encore Redis, pour n'en citer que quelques-uns.
• Packetbeat vous permet de collecter et de prétraiter les données réseau actives, et donc de monitorer vos applications et d'analyser les performances du réseau. Packetbeat accepte (entre autres) les protocoles suivants : DHCP, DNS, HTTP, MongoDB, NFS et TLS.
• Winlogbeat est conçu pour recueillir les logs d'événements des systèmes d'exploitation Windows : événements d'applications, événements matériels, événements système et de sécurité, par exemple. Les grandes quantités d'informations disponibles grâce aux logs d'événements Windows s'avèrent très utiles pour de nombreux de cas d'utilisation.
• Auditbeat détecte les modifications apportées aux fichiers critiques et collecte les événements depuis le framework d'audit Linux. Différents modules facilitent son déploiement, qui s'avère particulièrement adapté aux cas d'utilisation d'analyse de la sécurité.
• Heartbeat détecte activement la disponibilité des systèmes et services, afin de les monitorer. Heartbeat s'avère donc utile dans un grand nombre de scénarios, tels que le monitoring de l'infrastructure et l'analyse de la sécurité. Parmi les protocoles pris en charge, citons ICMP, TCP et HTTP.
• Functionbeat collecte des logs et des indicateurs depuis un environnement sans serveur, par exemple, AWS Lambda.

Une fois que vous avez choisi l'agent Beats à utiliser en fonction de votre cas d'utilisation, il ne vous reste plus qu'à vous lancer – et comme vous le constaterez dans les explications ci-dessous, c'est vraiment simplissime.

Dans cette section, nous prendrons l'exemple de Metricbeat pour expliquer comment se lancer avec les agents Beats. Les étapes à suivre pour les autres agents Beats sont très similaires. Nous vous conseillons cependant de consulter la documentation de l'agent Beat qui vous intéresse et à suivre les instructions adaptées à cet agent et à votre système d'exploitation.

1. Téléchargez l'agent Beat dont vous avez besoin et installez-le. Il existe plusieurs façons d'installer les agents Beats, mais la plupart des utilisateurs choisissent soit de se servir des référentiels fournis par Elastic pour le gestionnaire de package du système d'exploitation (DEB ou RPM), soit de télécharger et de décompresser les fichiers tgz ou zip.
2. Configurez l'agent Beat et activez les modules qui vous intéressent.

• Par exemple, pour collecter les indicateurs relatifs aux conteneurs Docker exécutés sur votre système, lorsque vous avez utilisé le gestionnaire de package pour l'installation, vous devez activer le module Docker via sudo metricbeat modules enable docker. Si vous avez décompressé les fichiers tgz ou zip, vous devez utiliser /metricbeat modules enable docker.
• Pour spécifier vers quel cluster Elasticsearch Service envoyer les données collectées, l'identifiant Cloud ID s'avère très pratique. Il suffit d'ajouter l'identifiant Cloud ID et les informations d'authentification au fichier de configuration Metricbeat (metricbeat.yml) :

cloud.id: cluster_name:ZXVy...Q2Zg==
cloud.auth: "elastic:YOUR_PASSWORD"
    

• Comme mentionné plus haut, vous avez reçu l'identifiant cloud.idà la création de votre cluster. cloud.auth est une concaténation d'un nom d'utilisateur et d'un mot de passe séparés par deux points, qui disposent de privilèges suffisants au sein du cluster Elasticsearch.
• Pour vous lancer rapidement, utilisez le compte superutilisateur elastic et le mots de passe reçus à la création du cluster. Vous trouverez le fichier de configuration dans le répertoire /etc/metricbeat si vous avez procédé à l'installation via le gestionnaire de package, ou dans le répertoire décompressé si vous avez téléchargé les fichiers tgz ou zip.

3. Chargez les tableaux de bord prépackagés dans Kibana. Pour la plupart, les agents Beats et leurs modules sont fournis avec des tableaux de bord Kibana prédéfinis. Chargez-les dans Kibana via sudo metricbeat setup si vous avez procédé à l'installation via le gestionnaire de package, ou via ./metricbeat setup dans le répertoire décompressé si vous avez téléchargé les fichiers tgz ou zip.

4. Exécutez l'agent Beat. Utilisez sudo systemctl start metricbeatsi vous avez choisi le gestionnaire de package pour l'installation sur un système Linux basé sur systemd ; ou ./metricbeat -e si vous avez décompressé les fichiers tgz ou zip.

Si tout fonctionne comme prévu, les données commencent maintenant à être transmises vers votre cluster Elasticsearch Service.

Dans Elasticsearch Service, accédez à Kibana pour examiner vos données :

• Dans Kibana Discover, sélectionnez le modèle d'indexation metricbeat-*. Cela vous permet d'afficher les différents documents ingérés.
• L'onglet Infrastructure de Kibana vous offre un aperçu graphique de vos indicateurs système et Docker : vous pouvez y afficher des graphes relatifs à l'utilisation des ressources système (CPU, mémoire, réseau).
• Dans Kibana Dashboards, sélectionnez n'importe quel tableau de bord comportant le préfixe [Metricbeat System] pour explorer vos données de manière interactive.

Logstash est un outil aussi puissant que flexible, conçu pour la lecture, le traitement et le transfert de tous types de données. Avec Logstash, vous accédez à des fonctionnalités actuellement indisponibles dans les agents Beats ou trop coûteuses à exécuter avec ces derniers – par exemple, enrichir les documents grâce à des recherches dans des sources de données externes. Toutefois, la flexibilité et les fonctionnalités de Logstash ont un prix. De même, la configuration matérielle requise par Logstash est bien plus élevée que celle des agents Beats. Aussi, Logstash ne doit généralement pas être déployé sur des appareils aux ressources insuffisantes. Logstash peut donc remplacer les agents Beats dans certains cas d'utilisation nécessitant des fonctionnalités plus poussées.

Dans de tels cas, le modèle d'architecture couramment utilisé consiste à associer Beats et Logstash : Beats sert alors à collecter les données, et Logstash à traiter les données dont les agents Beats ne peuvent pas se charger.

Logstash exécute des pipelines de traitement des événements, dans lesquels chaque pipeline comprend au moins une occurrence de chacun des éléments suivants :

• Des entrées lues depuis les sources de données. Un grand nombre de sources de données sont officiellement prises en charge, y compris les fichiers, http, imap, jdbc, kafka, syslog, tcp et udp.
• Des filtres permettant le traitement et l'enrichissement des données de diverses manières. Souvent, les lignes de log non structurées doivent d'abord être analysées dans un format plus structuré. C'est pourquoi Logstash propose, entre autres, des filtres permettant l'analyse de fichiers CSV et JSON, de paires clé-valeur, de données non structurées, et de données complexes non structurées, s'appuyant sur des expressions régulières (filtres grok). Logstash propose en outre des filtres permettant l'enrichissement des données grâce à des recherche DNS, à l'ajout d'informations géographiques relatives aux adresses IP, ou encore grâce à des recherches dans des dictionnaires personnalisés ou des index Elasticsearch. D'autres filtres permettent quant à eux différentes transformations des données, par exemple, la possibilité de renommer, de supprimer ou de copier des champs et des valeurs de données (filtre "mutate").
• Des sorties qui écrivent dans des récepteurs de données les données analysées et enrichies. Ces sorties constituent la dernière étape du pipeline de traitement Logstash. Bien qu'il existe un grand nombre de plug-ins de sortie, dans cet article, nous nous penchons sur l'ingestion des données dans Elasticsearch Service via le plug-in Elasticsearch output (sortie Elasticsearch).

Chaque cas d'utilisation est unique. Il est donc probable que vous ayez à développer des pipelines Logstash qui répondent à des entrées de données et à des besoins bien spécifiques.

Nous présentons ici un exemple de pipeline Logstash qui :

• Lit le flux RSS des blogs Elastic
• Assure un léger prétraitement des données en copiant et renommant les champs, et en supprimant les caractères spéciaux et les balises HTML
• Ingère les documents dans Elasticsearch

Voici les étapes à suivre :

1. Installez Logstash via votre gestionnaire de package ou téléchargez les fichiers tgz ou zip et décompressez-les.
2. Installez le plugin RSS input (entrée RSS) de Logstash, qui permet la lecture des sources de données RSS : ./bin/logstash-plugin install logstash-input-rss
3. Copiez la définition de pipeline Logstash ci-après dans un nouveau fichier, par exemple, ~/elastic-rss.conf :

input { 
  rss { 
    url => "/blog/feed" 
    interval => 120 
  } 
} 
filter { 
  mutate { 
    rename => [ "message", "blog_html" ] 
    copy => { "blog_html" => "blog_text" } 
    copy => { "published" => "@timestamp" } 
  } 
  mutate { 
    gsub => [  
      "blog_text", "<.*?>", "", 
      "blog_text", "[\n\t]", " " 
    ] 
    remove_field => [ "published", "author" ] 
  } 
} 
output { 
  stdout { 
    codec => dots 
  } 
  elasticsearch { 
    hosts => [ "https://<your-elsaticsearch-url>" ] 
    index => "elastic_blog" 
    user => "elastic" 
    password => "<your-elasticsearch-password>" 
  } 
}

4. Dans le fichier ci-dessus, modifiez les paramètres "hosts" (hôtes) et "password" (mot de passe), afin qu'ils correspondent à vos point de terminaison et mot de passe utilisateur Elastic dans Elasticsearch Service. Dans Elastic Cloud, pour obtenir l'URL du point de terminaison Elasticsearch, accédez aux informations détaillées disponibles sur la page de votre déploiement ("Copy Endpoint URL" (Copier l'URL du point de terminaison)).

5. Pour exécuter le pipeline, démarrez Logstash : ./bin/logstash -f ~/elastic-rss.conf

Le démarrage de Logstash prend plusieurs secondes. Des pointillés (.....) s'impriment alors vers la console. Chaque point représente un document ingéré dans Elasticsearch.

6. Ouvrez Kibana. Dans la console "Dev Tools" de Kibana , exécutez la commande suivante pour confirmer que 20 documents ont bien été ingérés : POST elastic_blog/_search

Clients de langage

Kibana Dev Tools (Outils de développement Kibana)

PUT my_first_index/_doc/1 
{ 
    "title" : "How to Ingest Into Elasticsearch Service", 
    "date" : "2019-08-15T14:12:12", 
    "description" : "This is an overview article about the various ways to ingest into Elasticsearch Service" 
}

Pour conclure

• Dois-je utiliser Logstash ou les nœuds d'ingestion Elasticsearch ?
• Get System Logs and Metrics into Elasticsearch with Beats System Modules (Transférez vos log et indicateurs système dans Elasticsearch grâce aux modules système de la famille Beats)

Nous sommes ravis d'annoncer aujourd'hui le lancement d'Elastic Endpoint Security. Celui-ci fait suite à l'acquisition d'Endgame, pionnier et leader reconnu du secteur en matière de prévention, de détection et de réponse aux menaces au niveau des points de terminaison basées sur la matrice MITRE ATT&CK™. Elastic associe SIEM et la sécurité des points de terminaison pour proposer une solution unique, qui permet aux entreprises de répondre aux menaces en temps réel, que ce soit dans le cloud, sur site ou dans des environnements hybrides – le tout, de manière automatique et flexible. Autre nouveauté : Elastic supprime à partir d'aujourd'hui la tarification par point de terminaison.

"En matière de sécurité des points de terminaison, deux grandes tendances – à savoir l'importance d'un back-end analytique fiable et l'essor du framework MITRE ATT&CK, qui s'impose comme langue commune –nous invitent plus que jamais à mettre l'accent sur les cas d'utilisation de lutte contre les menaces et de réponse aux incidents", affirme Fernando  Montenegro, Principal Analyst chez 451 Research. "L'acquisition d'Endgame par Elastic s'inscrit dans ces tendances, et l'association de SIEM et de la sécurité des points de terminaison devrait se traduire pour les entreprises par des gains d'efficience."

Évalué par des organismes de test indépendants tels que NSS Labs, SE  Labs ou la MITRE, Endgame a été désigné comme l'entreprise fournissant les systèmes de prévention et de détection les plus fiables. 

Ajoutons à cela qu'Elastic Endpoint Security propose l'une des sources de données de sécurité les plus fiables pour les points de terminaison, mais aussi pour les données brutes d'événements de points de terminaison et les alertes envoyées à la Suite Elastic, associant la collecte existante des événements Logging, Security, APM et Infrastructure. Avec un temps moyen de détection des menaces habituellement constaté de plus de 100 jours, Elasticsearch, avec son efficacité du transfert, de montée en charge et de stockage des données, rend l'interrogation de toutes ces informations de sécurité disparates plus simple, plus pratique et plus rapide. C'est donc tout naturellement qu'Endpoint Security trouve sa place aux côtés de la Suite Elastic pour fournir une solution de prévention contre les menaces, et les moyens de détection et de réponse les plus rapides pour contrer les attaques le plus précocement possible.

"Les utilisateurs sont en droit de demander plus aux outils qu'ils déploient". C'est pourquoi nous leur proposons aujourd'hui un moyen de générer immédiatement de la valeur, grâce à la simplicité d'une Suite unique, qui leur permet de rechercher, de stocker, d'analyser et de sécuriser leurs données", déclare Shay Banon, fondateur et directeur général d'Elastic. "Nous venons de faire un pas de plus vers la concrétisation de notre vision : appliquer la recherche à une multitude de cas d'utilisation. Nous pouvons désormais proposer la meilleure solution de lutte contre les menaces, doublée de la meilleure protection des points de terminaison, et c'est une étape passionnante."

SIEM et sécurité des points de terminaison : notre parcours

Les entreprises ne peuvent pas assurer leur protection via des outils isolés : les données ainsi collectées ne sont pas exploitables sans une console de gestion centralisée. Les équipes en charge de la sécurité sont alors confrontés à des données cloisonnées, à la lenteur des temps de requête et à des analyses compromises, peu pertinentes et peu contextualisées. Les entreprises savent déjà que le travail en temps réel est devenu incontournable ; elles doivent ingérer et stocker tous types de données de manière illimitée ; elles ont aussi besoin de générer des résultats pertinents et de les opérer automatiquement dans de nouveaux workflows de sécurité et des workflows existants.

Il y a près de deux ans, nous nous sommes donné pour mission d'aider les entreprises à faire progresser leur sécurité. Bien que les utilisateurs aient adopté la Suite Elastic et qu'ils l'exploitent comme solution de sécurité pour des cas d'utilisation comme la lutte contre les menaces, la détection de la fraude et le monitoring de la sécurité, nous voulions leur faciliter encore le déploiement de nos produits de sécurité. Nous avons donc commencé par collaborer avec notre communauté pour développer Elastic Common Schema (ECS) et ainsi proposer une méthode simple de normalisation des données provenant de différentes sources, depuis les données réseau jusqu'au données hôte. Puis nous avons lancé Elastic SIEM, le premier système de gestion de l'information et des événements de sécurité (ou SIEM) gratuit et ouvert...Mais nous n'en sommes pas restés là.

Aujourd'hui, lorsque vous déployez un agent de collecte de données pour Elastic SIEM, vous pouvez protéger simultanément le point de terminaison. Exit, l'inefficacité des innombrables solutions éparses qui s'avèrent incapables de répondre à temps pour éviter les dommages et les pertes.

"Arrêter les attaques aussi précocement que possible. Voilà l'objectif. Cela nécessite d'armer le point de terminaison des systèmes de prévention et de détection les plus performants et les plus précis. L'association de la technologie de protection des points de terminaison Endgame, leader du marché, et d'Elastic SIEM, offre aux SecOps et aux équipes de lutte contre les menaces un espace de travail interactif qui leur permet de bloquer les attaques et de protéger l'entreprise", explique Nate Fick, ancien DG d'Endgame aujourd'hui General Manager d'Elastic Security.

Fin de la tarification par point de terminaison

Outre l'association du premier SIEM ouvert et gratuit au monde avec la meilleure technologie de protection des points de terminaison, Elastic supprime la tarification par point de terminaison.

"Pourquoi obliger les utilisateurs à compter le nombre d'appareils à protéger ? Pourquoi devraient-ils choisir le nombre de jours pendant lesquels ils peuvent conserver les données de Threat Intelligence (TI) ?" ajoute Shay Banon. "Nous voulons que les entreprises puissent disposer de la meilleure protection, qu'elles puissent l'utiliser partout, sans tarification pénalisante par point de terminaison".

Quelle que soit la solution qu'ils utilisent – Elastic Logs, APM, SIEM, App Search, Site Search, Enterprise Search et maintenant Endpoint Security – les clients Elastic règlent une capacité de ressources selon une grille tarifaire cohérente et transparente. Cela leur permet de valoriser leurs données au maximum. Avec Elastic Endpoint Security, les entreprises bénéficient d'une protection totale quel que soit le nombre de points de terminaison dont elles ont besoin. La collecte et le transfert des données ne sont pas non plus en reste et sont totalement pris en charge, sans aucun compromis.

Elastic Endpoint Security vu par les leaders de la sécurité

Université A&M du Texas – Andrew Stokes, directeur adjoint et responsable de la sécurité des systèmes d'information

"Ce que nous apprécions particulièrement, c'est la rapidité de réponse, mais aussi la possibilité d'apprendre de nos données d'historique et de les analyser. Elastic Endpoint Security a considérablement fait chuter nos temps moyens de remédiation, qui sont passés de sept jours à 30 minutes par rapport à notre système antivirus existant. Quant à la Suite Elastic, elle nous a offert un moyen incomparable de stocker et d'analyser nos données, et d'y réagir – elle dépasse de loin tous les concurrents du marché. Associer Elastic Endpoint Security et la Suite Elastic en une seule plateforme axée sur les informations va nous permettre d'aller plus loin dans la simplification et l'automatisation de nos opérations de sécurité."

Optiv, Anthony Diaz, Divisional Vice President, Emerging Services

"Elastic propose l'intégration d'un SIEM nouvelle génération, d'un moteur de visualisation performant et d'un produit de point de terminaison exceptionnel – et tout cela est adossé à la meilleure technologie de recherche du marché. Les entreprises peuvent ainsi s'appuyer sur de solides fondations pour lutter contre des cybermenaces toujours plus complexes. Le fait qu'Elastic regroupe tous ces composants dans un écosystème ouvert est révolutionnaire. Une idée très pratique, qui permet aux entreprises de libérer tout le potentiel de leurs données pour répondre à leurs besoins de sécurité."

Infotrack – Sebastian Mill, CTO, Global Development

"Chez InfoTrack, nous savons que les données des points de terminaison sont très précieuses pour gagner en visibilité sur nos opérations et assurer la sécurité de notre infrastructure. C'est pourquoi notre équipe en charge de l'innovation avait déjà déployé Auditbeat dans nos environnements. Mais avec l'arrivée d'Elastic Endpoint Security, on passe à la vitesse supérieure. Nous sommes impatients d'arrêter les menaces avec Elastic Endpoint Security et d'associer les données des événements de sécurité à une fonctionnalité de détection des anomalies qui s'appuie sur Elastic Machine Learning. Une configuration qui fait rêver."

Ressources

Envie de voir Elastic Endpoint Security en action et d'en savoir plus sur nos nouveautés ? Participez à l'un de nos événements Elastic{ON} Tour au États-Unis et dans les régions EMEA ou Asie-Pacifique.

• Page dédiée à la solution Elastic Endpoint Security
• Documentation Elastic Endpoint
• Page dédiée aux solutions Elastic SIEM
• Documentation Elastic SIEM
• Forum de la communauté Elastic SIEM
• Enregistrement du webinar Elastic SIEM

Nous sommes ravis d'annoncer le lancement du tap Elastic Homebrew officiel.

Sur sa page de documentation, Homebrew est présenté comme "le gestionnaire de paquets pour macOS". Il facilite l'installation de logiciels sur macOS et rencontre un énorme succès dans la communauté des développeurs. Homebrew fournit des formules permettant l'installation de logiciels open source courants. Un tap est un mécanisme qui permet à des tiers comme Elastic de proposer de nouvelles formules, et donc de nouveaux logiciels.

Chez Elastic, cela fait longtemps que nous sommes fans de la communauté Homebrew et que nous admirons l'excellent travail qu'elle fournit pour aider les utilisateurs macOS (comme assurer le support technique de chaque nouvelle version dès le premier jour de lancement). Bref, c'est une communauté incroyable. Bon nombre d'ingénieurs Elastic utilisent d'ailleurs Homebrew et l'un de nos salariés contribue à sa maintenance.

Nous mettons toujours tout en œuvre pour amener nos produits aux utilisateurs là où ils se trouvent, et pour bon nombre d'entre eux, cet endroit s'appelle Homebrew. Il était donc logique de veiller à ce que tous les logiciels de la Suite Elastic puissent facilement être installés via Homebrew. Nous avons donc créé notre propre tap, ce qui nous a aussi permis d'améliorer l'expérience utilisateur à différents niveaux. Pour commencer, vous pouvez maintenant utiliser le tap Elastic Homebrew officiel pour accéder aux logiciels OSS et à la distribution par défaut, qui comprend des fonctionnalités gratuites comme la gestion du cycle de vie des index (ILM), Elasticsearch  SQL et les visualisations Canvas, pour n'en citer que quelques-unes. Mais ce n'est pas tout ! Désormais, la distribution par défaut vous propose aussi Security gratuitement. C'est à nos yeux important, car notre objectif est de proposer une expérience cohérente aux utilisateurs des distributions OSS et par défaut. Autre bonne raison de créer notre propre tap : cela nous permet de nous assurer que les utilisateurs de Homebrew aient toujours accès aux dernières versions de nos logiciels. La mise à jour des formules Homebrew de notre tap fait maintenant automatiquement partie de notre processus de mise en production. Résultat, les mises à jour sont disponibles en même temps que celles de nos autres produits.

Installer la Suite Elastic avec Homebrew

Une fois que vous avez installé Homebrew, se lancer avec le tap Elastic est simplissime :

1. Installez le tap Elastic via brew tap elastic/tap.
2. Installez la distribution OSS ou par défaut d'Elasticsearch.
   • Par défaut : brew install elasticsearch-full
   • OSS : brew install elasticsearch-oss
3. Si votre chemin comprend /usr/local/bin, vous pouvez démarrer Elasticsearch avec la commande elasticsearch. Mais vous pouvez aussi spécifier le chemin complet /usr/local/bin/elasticsearch.

Ce tap vous donne accès à l'ensemble des logiciels de la Suite Elastic, y compris Elastic APM Server, Beats, Logstash, Kibana et Elasticsearch. Pour consulter la liste des formules disponibles, saisissez :

ls $(brew --prefix)/Homebrew/Library/Taps/elastic/homebrew-tap/Formula/*.rb

Happy Hour

En anglais, Homebrew signifie "bière maison", d'où son logo. Et comme toutes les bières, elle est meilleure fraîche. C'est donc le moment de tester le tap Elastic Homebrew. Et comme toujours, vos commentaires nous sont très précieux. N'hésitez pas à nous contacter pour nous dire ce que vous pensez de notre tap via le référentiel ou via notre forum de discussion.

Chez Elastic, nous croyons à la solidarité et au partage. Que ce soit en soutenant les communautés dans lesquelles nous vivons et travaillons, ou en reconnaissant que la participation à ces activités est source d'inspiration et de richesse partagée. Dans le cadre du programme Elastic Cares, nous avons fait un don au projet Homebrew via l'incroyable équipe de l'organisation Software Freedom Conservancy.

Nous sommes convaincus que de telles actions jouent un rôle important en faveur de la durabilité des logiciels, des communautés et des projets open source fondamentaux – comme le fait justement Homebrew pour un grand nombre de développeurs du monde entier.

"Logo de Homebrew" par Vítor Galvão, utilisé sous sous licence Creative Commons CC BY 4.0/Redimensionné et placé dans l'en-tête et la miniature

Depuis le lancement des versions 6.8 et 7.1 de la Suite Elastic, vous avez gratuitement accès à certaines fonctionnalités de sécurité, qui sont désormais intégrées dans la distribution par défaut (licence Basic). Avec cette nouvelle offre, vous pouvez désormais chiffrer le trafic réseau via SSL, ajouter et gérer des utilisateurs, définir des rôles qui protègent l'accès au niveau des index et des clusters, mais aussi assurer la sécurité totale de Kibana. Dans l'article de blog Prise en main de la sécurité Elasticsearch que nous avions publié peu de temps après le lancement, nous vous expliquions comment utiliser les communications TLS entre Elasticsearch et Kibana. Dans l'article ci-dessous, nous allons nous pencher sur d'autres composants de la Suite Elastic, comme Beats ou Logstash. Nous allons voir comment activer TLS entre les composants et comment chiffrer les communications client HTTP.

Remarque : si l'activation de TLS sur la couche HTTP n'est pas obligatoire, elle est néanmoins vivement recommandée pour assurer une sécurité de bout en bout et protéger les données, notamment pour éviter l'interception des noms d'utilisateur et des mots de passe, et donc la compromission du cluster. Pour en savoir plus sur le chiffrement TLS, l'authentification, les scripts limités ou l'isolation, consultez l'article de blog intitulé Chiffrement, sécurisation des données utilisateur et plus encore : nos conseils pour sécuriser gratuitement vos clusters Elasticsearch.

Autre remarque : les fonctionnalités de sécurité que nous allons configurer ci-dessous sont activées par défaut dans Elasticsearch Service sur Elastic Cloud. Si vous utilisez Elasticsearch Service, vous pouvez donc passer directement à l'étape 5.

Étapes à suivre pour sécuriser la Suite Elastic

1. Préparation
2. Créer des certificats SSL et activer TLS pour Elasticsearch sur "node1" (nœud1)
3. Activer TLS pour Kibana sur "node1"
4. Activer TLS pour Elasticsearch sur "node2" (nœud2)
5. Préparer les utilisateurs Logstash sur "node1"
6. Activer TLS pour Logstash sur "node1"
7. Exécuter Filebeat et configurer TLS sur "node1"
8. Utiliser Filebeat pour ingérer les données

Étape 1. Préparation

Téléchargez les composants suivants de la Suite Elastic 7.1 ou d'une version plus récente :

• Elasticsearch
• Kibana
• Logstash
• Filebeat

[1-1] Configurer le fichier /etc/hosts

Dans cet exemple, notre "node1" (nœud1) dispose d'un navigateur, afin que kibana.local autorise l'accès à la page web de Kibana.

#fichier /etc/hosts pour le [node1] (nous avons besoin de kibana.local et de logstash.local)
127.0.0.1 kibana.local logstash.local
192.168.0.2 node1.elastic.test.com node1
192.168.0.3 node2.elastic.test.com node2

#fichier /etc/hosts pour le [node2] (ici, nous n'avons pas besoin de kibana.local et logstash.local)
192.168.0.2 node1.elastic.test.com node1
192.168.0.3 node2.elastic.test.com node2

Étape 2. Créer des certificats SSL et activer TLS pour Elasticsearch sur "node1" (nœud1)

[2-1] Définir les variables d'environnement (adapter le chemin de ces variables en fonction du mode de téléchargement d'Elasticsearch et de son emplacement)

[root@node1 ~]# ES_HOME=/usr/share/elasticsearch
[root@node1 ~]# ES_PATH_CONF=/etc/elasticsearch

[2-2] Créer un dossier tmp

[root@node1 ~]# mkdir tmp
[root@node1 ~]# cd tmp/
[root@node1 tmp]# mkdir cert_blog

[2-3] Créer un fichier d'instance yaml

[root@node1 cert_blog]# vi ~/tmp/cert_blog/instance.yml
# ajoutez les informations relatives à l'instance au fichier yml
instances:
  - name: 'node1'
    dns: [ 'node1.elastic.test.com' ]
  - name: "node2"
    dns: [ 'node2.elastic.test.com' ]
  - name: 'my-kibana'
    dns: [ 'kibana.local' ]
  - name: 'logstash'
    dns: [ 'logstash.local' ]

[2-4] Générer des certificats d'autorité de certification (CA) et de serveur (une fois Elasticsearch installé)

[root@node1 tmp]# cd $ES_HOME
[root@node1 elasticsearch]# bin/elasticsearch-certutil cert ca --pem --in ~/tmp/cert_blog/instance.yml --out ~/tmp/cert_blog/certs.zip

[2-5] Décompresser les certificats

[root@node1 elasticsearch]# cd ~/tmp/cert_blog
[root@node1 cert_blog]# unzip certs.zip -d ./certs

[2-6] Configurer le TLS Elasticsearch

[2-6-1] Copier le fichier "cert" vers le dossier "config"

[root@node1 ~]# cd $ES_PATH_CONF
[root@node1 elasticsearch]# pwd
/etc/elasticsearch
[root@node1 elasticsearch]# mkdir certs
[root@node1 elasticsearch]# cp ~/tmp/cert_blog/certs/ca/ca.crt ~/tmp/cert_blog/certs/node1/* certs
[root@node1 elasticsearch]# ll certs
total 12
-rw-r--r--. 1 root elasticsearch 1834 Apr 12 08:47 ca.crt
-rw-r--r--. 1 root elasticsearch 1509 Apr 12 08:47 node1.crt
-rw-r--r--. 1 root elasticsearch 1679 Apr 12 08:47 node1.key
[root@node1 elasticsearch]#

[2-6-2] Configurer elasticsearch.yml

[root@node1 elasticsearch]# vi elasticsearch.yml 
## ajoutez le contenu suivant
node.name: node1
network.host: node1.elastic.test.com
xpack.security.enabled: true
xpack.security.http.ssl.enabled: true
xpack.security.transport.ssl.enabled: true
xpack.security.http.ssl.key: certs/node1.key
xpack.security.http.ssl.certificate: certs/node1.crt
xpack.security.http.ssl.certificate_authorities: certs/ca.crt
xpack.security.transport.ssl.key: certs/node1.key
xpack.security.transport.ssl.certificate: certs/node1.crt
xpack.security.transport.ssl.certificate_authorities: certs/ca.crt
discovery.seed_hosts: [ "node1.elastic.test.com" ]
cluster.initial_master_nodes: [ "node1" ]

[2-6-3] Démarrer et vérifier le log du cluster

[root@node1 elasticsearch]# grep '\[node1\] started' /var/log/elasticsearch/elasticsearch.log 
[o.e.n.Node               ] [node1] started

[2-6-4] Définir un mot de passe intégré

[root@node1 elasticsearch]# cd $ES_HOME
[root@node1 elasticsearch]# bin/elasticsearch-setup-passwords auto -u "https://node1.elastic.test.com:9200"
Initiating the setup of passwords for reserved users elastic,apm_system,kibana,logstash_system,beats_system,remote_monitoring_user.
The passwords will be randomly generated and printed to the console.
Please confirm that you would like to continue [y/N] y
Changed password for user apm_system
PASSWORD apm_system = <apm_system_password>
Changed password for user kibana
PASSWORD kibana = <kibana_password>
Changed password for user logstash_system
PASSWORD logstash_system = <logstash_system_password>
Changed password for user beats_system
PASSWORD beats_system = <beats_system_password>
Changed password for user remote_monitoring_user
PASSWORD remote_monitoring_user = <remote_monitoring_user_password>
Changed password for user elastic
PASSWORD elastic = <elastic_password>

[2-6-5] Accéder à l'API _cat/nodes via HTTPS

[root@node1 elasticsearch]# curl --cacert ~/tmp/cert_blog/certs/ca/ca.crt -u elastic 'https://node1.elastic.test.com:9200/_cat/nodes?v'
Enter host password for user 'elastic':
ip          heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name
192.168.0.2           16          95  10    0.76    0.59     0.38 mdi       *      node1

Étape 3. Activer TLS pour Kibana sur "node1"

[3-1] Définir les variables d'environnement

Adaptez le chemin de ces variables en fonction du mode de téléchargement de Kibana et de son emplacement :

[root@node1 ~]# KIBANA_HOME=/usr/share/kibana
[root@node1 ~]# KIBANA_PATH_CONFIG=/etc/kibana

[3-2] Créer un dossier "config" et "config/certs" et copier "certs" (une fois Kibana installé)

Copiez les fichiers de certificat créés à l'étape 2-4 et collez-les dans kibana/config/certs.

[root@node1 kibana]# ls config/certs
total 12
ca.crt
my-kibana.crt
my-kibana.key

[3-3] Configurer kibana.yml

Pensez à utiliser le mot de passe que vous avez généré plus haut pour l'utilisateur intégré. Remplacez <kibana_password> par le mot de passe défini à l'étape 2-6-4.

[root@node1 kibana]# vi kibana.yml 
server.name: "my-kibana"
server.host: "kibana.local"
server.ssl.enabled: true
server.ssl.certificate: /etc/kibana/config/certs/my-kibana.crt
server.ssl.key: /etc/kibana/config/certs/my-kibana.key
elasticsearch.hosts: ["https://node1.elastic.test.com:9200"]
elasticsearch.username: "kibana"
elasticsearch.password: "<kibana_password>"
elasticsearch.ssl.certificateAuthorities: [ "/etc/kibana/config/certs/ca.crt" ]

[3-4] Démarrer Kibana et tenter de se connecter

Accédez à https://kibana.local:5601/ depuis un navigateur. Connectez-vous à l'aide du nom d'utilisateur elastic et du mot de passe défini à l'étape 2-6-4. Dans cet exemple, notre "node1" (nœud1) dispose d'un navigateur, afin que kibana.local autorise l'accès à Kibana.

Les autorités de certification approuvées publiquement appliquent des normes et des pratiques d'audit très strictes, afin de garantir que seules les identités correctement confirmées puissent obtenir un certificat. À des fins d'illustration, nous allons créer un certificat auto-signé pour Kibana (ce qui signifie que le certificat généré est signé via sa propre clé privée). Les clients ne faisant pas confiance aux certificats Kibana auto-signés, un message similaire à celui-cis'affiche dans vos logs Kibana jusqu'à ce que l'utilisation de certificats générés par une autorité de certification publique ou d'entreprise permette d'établir la confiance (ce lien vous permet d'accéder au problème dans le référentiel Kibana). Le problème ne vous empêche pas de travailler dans Kibana :

[18:22:31.675] [error][client][connection] Error: 4443837888:error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown:../deps/openssl/openssl/ssl/s3_pkt.c:1498:SSL alert number 46

Étape 4. Activer TLS pour Elasticsearch sur "node2" (nœud2)

[4-1] Définir les variables d'environnement

[root@node2 ~]# ES_HOME=/usr/share/elasticsearch
[root@node2 ~]# ES_PATH_CONF=/etc/elasticsearch

[4-2] Configurer TLS sur "node2"

Vous pouvez utiliser la commande "scp" pour copier des certificats de "node1" vers "node2". Pour sécuriser la connexion, les deux nœuds nécessitent une clé et un certificat. Dans un environnement de production, il est recommandé d'utiliser une clé correctement signée pour chaque nœud. À des fins de démonstration, nous utilisons ici un certificat d'autorité de certification généré automatiquement et un certificat de nom d'hôte multi-DNS signé par l'autorité de certification que nous avons générée.

[root@node2 ~]# cd $ES_PATH_CONF
[root@node2 elasticsearch]# pwd
/etc/elasticsearch
[root@node2 elasticsearch]# mkdir certs
[root@node2 elasticsearch]# cp ~/tmp/cert_blog/certs/ca/ca.crt ~/tmp/cert_blog/certs/node2/* certs  
[root@node2 elasticsearch]# 
[root@node2 elasticsearch]# ll certs
total 12
-rw-r--r--. 1 root elasticsearch 1834 Apr 12 10:55 ca.crt
-rw-r--r--. 1 root elasticsearch 1509 Apr 12 10:55 node2.crt
-rw-r--r--. 1 root elasticsearch 1675 Apr 12 10:55 node2.key

[4-3] Configurer elasticsearch.yml

[root@node2 elasticsearch]# vi elasticsearch.yml 
node.name: node2
network.host: node2.elastic.test.com
xpack.security.enabled: true
xpack.security.http.ssl.enabled: true
xpack.security.transport.ssl.enabled: true
xpack.security.http.ssl.key: certs/node2.key
xpack.security.http.ssl.certificate: certs/node2.crt
xpack.security.http.ssl.certificate_authorities: certs/ca.crt
xpack.security.transport.ssl.key: certs/node2.key
xpack.security.transport.ssl.certificate: certs/node2.crt
xpack.security.transport.ssl.certificate_authorities: certs/ca.crt
discovery.seed_hosts: [ "node1.elastic.test.com" ]

[4-4] Démarrer et vérifier le log du cluster

[root@node2 elasticsearch]# grep '\[node2\] started' /var/log/elasticsearch/elasticsearch.log 
[o.e.n.Node               ] [node2] started

[4-5] Accéder à l'API _cat/nodes via HTTPS

[root@node2 elasticsearch]# curl --cacert ~/tmp/cert_blog/certs/ca/ca.crt -u elastic:<password set previously> 'https://node2.elastic.test.com:9200/_cat/nodes?v'
ip          heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name
192.168.0.2           25          80   5    0.18    0.14     0.30 mdi       *      node1
192.168.0.3           14          96  44    0.57    0.47     0.25 mdi       -      node2

Étape 5. Préparer les utilisateurs Logstash sur "node1"

[5-1] Créer un rôle logstash_write_role

Il existe différentes façons de créer le rôle.

Vous pouvez le créer via l'interface utilisateur "Roles" de Kibana : 

Mais vous pouvez aussi le créer via l'API disponible dans l'onglet "Dev Tools" de Kibana :

POST /_security/role/logstash_write_role
{
    "cluster": [
      "monitor",
      "manage_index_templates"
    ],
    "indices": [
      {
        "names": [
          "logstash*"
        ],
        "privileges": [
          "write",
          "create_index"
        ],
        "field_security": {
          "grant": [
            "*"
          ]
        }
      }
    ],
    "run_as": [],
    "metadata": {},
    "transient_metadata": {
      "enabled": true
    }
}

Vous obtenez alors la réponse suivante :

{"role":{"created":true}}

Les utilisateurs associés à ce rôle ne pourront supprimer aucun document. Ce rôle limite les autorisations des utilisateurs à la création d'index commençant par logstash et à l'indexation de documents dans ces index.

[5-2] Créer un utilisateur logstash_writer (penser à modifier le mot de passe de l'utilisateur logstash_writer)

Il existe différentes façons de créer l'utilisateur.

Vous pouvez le créer via l'interface utilisateur "Users" de Kibana :

Mais vous pouvez aussi le créer via l'API disponible dans l'onglet "Dev Tools" de Kibana :

POST /_security/user/logstash_writer
{
  "username": "logstash_writer",
  "roles": [
    "logstash_write_role"
  ],
  "full_name": null,
  "email": null,
  "password": "<logstash_system_password>",
  "enabled": true
}

Vous obtenez alors la réponse suivante :

{"user":{"created":true}}

Étape 6. Activer TLS pour Logstash sur "node1"

[6-1] Créer un dossier et copier les certificats

[root@node1 logstash]# ls -l
total 24
ca.crt
logstash.crt
logstash.key

[6-2] Convertir logstash.key au format PKCS#8 pour le plug-in d'entrée Beats

[root@node1 logstash]# openssl pkcs8 -in config/certs/logstash.key -topk8 -nocrypt -out config/certs/logstash.pkcs8.key

[6-3] Configurer logstash.yml

Pensez à utiliser le mot de passe généré automatiquement pour l'utilisateur logstash_system. Utilisez le mot de passe défini à l'étape 2-6-4.

[root@node1 logstash]# vi logstash.yml

Puis modifiez :

node.name: logstash.local
path.config: /etc/logstash/conf.d/*.conf
xpack.monitoring.enabled: true
xpack.monitoring.elasticsearch.username: logstash_system
xpack.monitoring.elasticsearch.password: '<logstash_system_password>'
xpack.monitoring.elasticsearch.hosts: [ 'https://node1.elastic.test.com:9200' ]
xpack.monitoring.elasticsearch.ssl.certificate_authority: /etc/logstash/config/certs/ca.crt

[6-4] Créer et configurer conf.d/example.conf

Sur la sortie Elasticsearch, utilisez le mot de passe défini à l'étape 5-2.

[root@node1 logstash]# vi conf.d/example.conf 
input {
  beats {
    port => 5044
    ssl => true
    ssl_key => '/etc/logstash/config/certs/logstash.pkcs8.key'
    ssl_certificate => '/etc/logstash/config/certs/logstash.crt'
  }
}
output {
  elasticsearch {
    hosts => ["https://node1.elastic.test.com:9200","https://node2.elastic.test.com:9200"]
    cacert => '/etc/logstash/config/certs/ca.crt'
    user => 'logstash_writer'
    password => <logstash_writer_password>
  }
}

[6-5] Démarrer Logstash avec l'exemple de configuration et vérifiez le log Logstash

Les messages de log suivants doivent s'afficher :

[INFO ][logstash.pipeline        ] Pipeline started successfully {:pipeline_id=>".monitoring-logstash", :thread=>"#<Thread:0x640c14d2@/usr/share/logstash/logstash-core/lib/logstash/pipeline.rb:246 run

Dans l'onglet "Monitoring" de Kibana, Logstash doit également s'afficher (informations sur le nœud, les paramètres du pipeline, le système d'exploitation, la machine virtuelle Java (JVM), les statistiques de traitement et les statistiques d'exécution du pipeline) :

Étape 7. Exécuter Filebeat et configurer TLS sur "node1"

[7-1] Créer un dossier "config" et copier les certificats

[root@node1 filebeat]# mkdir config
[root@node1 filebeat]# mkdir config/certs
[root@node1 filebeat]# cp ~/tmp/cert_blog/certs/ca/ca.crt config/certs
[root@node1 filebeat]# ll config/certs/
total 4
-rw-r--r--. 1 root root 1834 Apr 20 00:18 ca.crt

[7-2] Créer un nouveau fichier filebeat.yml

[root@node1 filebeat]# pwd
/etc/filebeat
[root@node1 filebeat]# mv filebeat.yml filebeat.yml.old

[7-3] Modifier le nouveau fichier de configuration filebeat.yml

filebeat.inputs:
- type: log
  paths:
    - /etc/filebeat/logstash-tutorial-dataset
output.logstash:
  hosts: ["logstash.local:5044"]
  ssl.certificate_authorities:
    - /etc/filebeat/config/certs/ca.crt

Étape 8. Utiliser Filebeat pour ingérer les données

[8-1] Préparer les données du log d'entrée (logstash-tutorial.log) pour Filebeat

Commencez par télécharger les données du log d'entrée.

[root@node1 filebeat]# pwd
/etc/filebeat
[root@node1 filebeat]# mkdir logstash-tutorial-dataset
[root@node1 filebeat]# cp /root/logstash-tutorial.log logstash-tutorial-dataset/.
[root@node1 filebeat]# ll logstash-tutorial-dataset/
total 24
-rwxr-x---. 1 root root 24464 Apr 20 00:29 logstash-tutorial.log

[8-2] Démarrer Filebeat

[root@node1 filebeat]# systemctl start filebeat
[root@node1 filebeat]# systemctl enable filebeat
Created symlink from /etc/systemd/system/multi-user.target.wants/filebeat.service to /usr/lib/systemd/system/filebeat.service.

[8-3] Vérifier le log

Les messages de log suivants doivent s'afficher :

INFO    log/harvester.go:216    Harvester started for file: /etc/filebeat/logstash-tutorial-dataset/logstash-tutorial.log

[8-4] Créer un modèle d'indexation

Ensuite, créez un modèle d'indexation correspondant aux données en cours d'ingestion. Cela permet la visualisation des données dans Kibana, par exemple via les onglets Graph ou Discover.

Sélectionnez ensuite le nom du champ "Time Filter" (filtre temporel). Dans notre exemple, il s'agit de @timestamp :

Et voilà ! Vous venez de chiffrer la communication entre les différents composants de la Suite Elastic et vous ingérez maintenant des données de log en toute sécurité.

Pour terminer

Si vous rencontrez des problèmes lors de la configuration de la sécurité, commencez par jeter un œil au guide de résolution des problèmes de sécurité. Il peut vous aider à résoudre bon nombre de problèmes courants. Si vous avez toujours des questions après cela, n'hésitez pas à demander de l'aide sur les forums Elastic. Et si vous préférez contacter directement l'équipe de support technique Elastic, souscrivez un abonnement Elastic : il vous donnera directement accès à une équipe d'experts. En attendant un prochain article, faites attention à vous (et à votre cluster) !

En 2016, nous avions publié un article sur le monitoring de Kafka avec Filebeat. Depuis la version 6.5, Beats prend en charge un module Kafka. Ce module automatise une bonne partie des tâches liées au monitoring d'un cluster Kafka.

Dans cet article de blog, nous allons nous pencher sur la collecte des données de logs et d'indicateurs via les modules Kafka de Filebeat et de Metricbeat. Nous allons ingérer ces données dans un cluster hébergé sur Elasticsearch Service, et examiner les tableaux de bord Kibana fournis par les modules Beats.

Nous utiliserons ici la Suite Elastic 7.1. Vous trouverez un exemple d'environnement sur GitHub.

Pourquoi utiliser des modules ?

Quiconque a travaillé avec des filtres Grok complexes dans Logstash vous dira combien il est appréciable de pouvoir configurer la collecte de logs via un module Filebeat aussi facilement. Mais l'utilisation de modules pour configurer le monitoring présente d'autres avantages :

• Configuration simplifiée de la collecte de logs et d'indicateurs
• Documents standardisés via Elastic Common Schema
• Modèles d'index judicieux, fournissant des types optimaux de champ de données
• Taille adaptée des index. Les agents Beats utilisent l'API Rollover pour veiller à ce que la taille des partitions d'index Beats reste gérable.

Pour découvrir la liste complète des modules pris en charge par Filebeat et Metricbeat, consultez la documentation correspondante.

Présentation de l'environnement

Notre exemple de configuration est constitué d'un cluster Kafka composé de trois nœuds (kafka0, kafka1 et kafka2). Chaque nœud exécute Kafka 2.1.1, ainsi que Filebeat et Metricbeat pour assurer le monitoring du nœud. Pour envoyer les données vers notre cluster Elasticsearch Service, les agents Beats sont configurés via l'identifiant Cloud ID. Les modules Kafka intégrés à Filebeat et Metricbeat configureront quant à eux des tableaux de bord dans Kibana pour la visualisation des données. Remarque : pour essayer cette configuration dans votre propre cluster, vous pouvez déployer gratuitement une version d'essai de 14 jours d'Elasticsearch Service, et tester l'ensemble de ses fonctionnalités.

Configurer les agents Beats

Ensuite, vous allez configurer puis lancer les agents Beats.

Installer et activer les services Beats

Pour installer Filebeat et Metricbeat, nous suivrons les instructions de leurs guides de prise en main respectifs. Comme nous sommes sous Ubuntu, nous installerons les agents Beats via le référentiel APT.

wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -
echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" | sudo tee -a /etc/apt/sources.list.d/elastic-7.x.list
sudo apt-get update
sudo apt-get install filebeat metricbeat
systemctl enable filebeat.service
systemctl enable metricbeat.service

Configurer l'identifiant Cloud ID du déploiement Elasticsearch Service

Copiez l'identifiant Cloud ID depuis la console Elastic Cloud, puis utilisez-le pour configurer les sorties Filebeat et Metricbeat.

CLOUD_ID=Kafka_Monitoring:ZXVyb3BlLXdlc...
CLOUD_AUTH=elastic:password
filebeat export config -E cloud.id=${CLOUD_ID} -E cloud.auth=${CLOUD_AUTH} > /etc/filebeat/filebeat.yml
metricbeat export config -E cloud.id=${CLOUD_ID} -E cloud.auth=${CLOUD_AUTH} > /etc/metricbeat/metricbeat.yml

Activer les modules Kafka et système dans Filebeat et Metricbeat

Nous devrons ensuite activer les modules Kafka et système pour les deux agents Beats.

filebeat modules enable kafka system
metricbeat modules enable kafka system

Une fois les modules activés, nous pouvons lancer la commande setup pour configurer chaque agent Beats. Cette commande permet de configurer les modèles d'index et les tableaux de bord Kibana qu'utilisent les modules.

filebeat setup -e --modules kafka,system
metricbeat setup -e --modules kafka,system

Lancer les agents Beats

Bien. Maintenant que tout est configuré, démarrons Filebeat et Metricbeat.

systemctl start metricbeat.service
systemctl start filebeat.service

Explorer les données de monitoring

Voici que qu'affiche le tableau de bord de logging par défaut :

• Les exceptions récemment rencontrées par le cluster Kafka. Les exceptions sont groupées par classe d'exceptions et les informations détaillées de l'exception sont affichées.
• Un aperçu du débit des logs par niveau, ainsi que les informations détaillées sur le log.

Filebeat ingère les données suivant Elastic Common Schema, ce qui nous permet d'appliquer des filtres pour descendre jusqu'au niveau de l'hôte.

Le tableau de bord fourni par Metricbeat affiche l'état actuel de n'importe quel sujet du cluster Kafka. Un menu déroulant nous permet aussi de filtrer le tableau de bord sur un seul sujet.

Les visualisations "consumer lag" et "offset" nous montrent si les consommateurs décrochent sur certains sujets. Les offsets par partition montrent également si une partition donnée est à la traîne.

La configuration Metricbeat par défaut collecte deux ensembles de données : kafka.partition et kafka.consumergroup. Ces ensembles de données nous informent sur l'état d'un cluster Kafka et des consommateurs qu'il contient.

L'ensemble de données kafka.partition comprend toutes les informations relatives à l'état des partitions contenues dans un cluster. Ces données peuvent servir à :

• Créer des tableaux de bord montrant le mapping des partitions vers les nœuds du cluster
• Signaler les partitions sans replicas synchronisés
• Effectuer le suivi de l'affectation des partitions au fil du temps
• Visualiser les limites d'offset des partitions au fil du temps.

Voici un document kafka.partition complet.

L'ensemble de données kafka.consumergroup indique l'état d'un seul consommateur. On peut utiliser ces données pour connaître les partitions que lit un seul consommateur et les offsets actuels de ce consommateur.

Pour conclure

Pour capitaliser sur les puissantes fonctionnalités de recherche d'Elasticsearch, bon nombre d'entreprises le déploient en parallèle de leurs bases de données relationnelles existantes. Dans ces cas-là, il faudra probablement veiller à ce qu'Elasticsearch reste synchronisé avec les données stockées dans la base de données relationnelle qui lui est associée. Dans cet article de blog, nous allons donc voir comment utiliser Logstash pour copier efficacement des enregistrements et synchroniser les mises à jour provenant d'une base de données relationnelle dans Elasticsearch . Pour tester le code et les méthodes présentées ici, nous utiliserons MySQL, mais cela doit a priori fonctionner avec n'importe quel SGBDR.

Configuration système

Pour les besoins de cet article, j'ai effectué les tests avec les composants suivants :

• MySQL : 8.0.16.
• Elasticsearch : 7.1.1
• Logstash : 7.1.1
• Java : 1.8.0_162-b12
• Plug-in d'entrée JDBC : v4.3.13
• Connecteur JDBC : Connector/J 8.0.16

Présentation détaillée des étapes de synchronisation

Dans cet article, nous allons utiliser Logstash et le plug-in d'entrée JDBC pour synchroniser Elasticsearch avec MySQL. L'idée est que le plug-in d'entrée JDBC de Logstash exécute une boucle qui interroge régulièrement les enregistrements MySQL insérés ou modifiés depuis la dernière itération de la boucle. Pour que cela fonctionne correctement, les conditions suivantes doivent être remplies :

1. Les documents MySQL étant écrits dans Elasticsearch, le champ "_id" d'Elasticsearch doit être défini sur le champ "id" provenant de MySQL. Cela permet de mapper directement l'enregistrement MySQL et le document Elasticsearch. Lorsqu'un enregistrement est mis à jour dans MySQL, le document associé est intégralement remplacé dans Elasticsearch. Remarque : le remplacement d'un document dans Elasticsearch est aussi efficace qu'une opération de mise à jour. Une mise à jour consisterait à supprimer l'ancien document, puis à indexer un document totalement nouveau.
2. Lorsqu'un enregistrement est inséré ou mis à jour dans MySQL, il doit comporter un champ contenant la date et l'heure de mise à jour ou d'insertion. Ce champ permet à Logstash de ne demander que les documents modifiés ou insérés depuis la dernière itération de sa boucle d'interrogation. Chaque fois que Logstash interroge MySQL, il stocke la date de mise à jour et d'insertion du dernier enregistrement qu'il a lu dans MySQL. Lors de l'itération suivante, Logstash sait qu'il ne doit interroger que les enregistrements dont la date de mise à jour ou d'insertion est plus récente que celle reçue lors de l'itération précédente de la boucle d'interrogation.

Si les conditions ci-dessus sont remplies, nous pouvons configurer Logstash pour qu'il demande régulièrement à MySQL tous les enregistrements modifiés ou nouvellement créés, et qu'il les écrive ensuite dans Elasticsearch. Nous présenterons plus bas le code Logstash utilisé pour assurer cette synchronisation.

Configuration de MySQL

Pour configurer la base de données et la table MySQL, vous pouvez procéder comme suit :

CREATE DATABASE es_db;
USE es_db;
DROP TABLE IF EXISTS es_table;
CREATE TABLE es_table (
  id BIGINT(20) UNSIGNED NOT NULL,
  PRIMARY KEY (id),
  UNIQUE KEY unique_id (id),
  client_name VARCHAR(32) NOT NULL,
  modification_time TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  insertion_time TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);

La configuration MySQL ci-dessus comporte quelques paramètres intéressants :

• es_table : c'est le nom de la table MySQL depuis laquelle les enregistrements seront lus puis synchronisés dans Elasticsearch.
• id : il s'agit de l'identifiant unique de cet enregistrement. Remarquons que "id" est défini comme "PRIMARY KEY" (clé principale) et "UNIQUE KEY" (clé unique). Cela permet d'assurer que chaque "id" n'apparaît qu'une seule fois dans la table actuelle. Pour mettre à jour ou insérer le document dans Elasticsearch, "id" sera converti en "_id".
• client_name : ce champ représente les données qui seront stockées dans chaque enregistrement, telles que définies par l'utilisateur. Pour simplifier, nous n'utiliserons dans cet article qu'un seul champ contenant des données définies par l'utilisateur, mais vous pouvez facilement en ajouter d'autres. C'est ce champ que nous modifierons pour montrer que les enregistrements MySQL nouvellement insérés et les enregistrements mis à jour sont copiés vers Elasticsearch.
• modification_time : toute insertion ou mise à jour d'un enregistrement dans MySQL modifie la valeur de ce champ, afin qu'elle corresponde à la date et à l'heure de la modification. La date et l'heure de modification nous permettent d'extraire les enregistrements modifiés depuis la dernière demande de documents envoyée par Logstash vers MySQL.
• insertion_time : nous utilisons ce champ à des fins de démonstration. Il n'est pas strictement nécessaire au bon fonctionnement de la synchronisation. Il va nous permettre de vérifier la date et l'heure auxquelles un enregistrement a été inséré dans MySQL pour la première fois.

Opérations MySQL

Étant donné la configuration ci-dessus, l'écriture des enregistrements dans MySQL peut se faire comme suit :

INSERT INTO es_table (id, client_name) VALUES (<id>, <client name>);

Pour mettre à jour les enregistrements MySQL, vous pouvez utiliser la commande suivante :

UPDATE es_table SET client_name = <new client name> WHERE id=<id>;

Les upserts MySQL peuvent quant à eux être effectués comme suit :

INSERT INTO es_table (id, client_name) VALUES (<id>, <client name when created> ON DUPLICATE KEY UPDATE client_name=<client name when updated>;

Code de synchronisation

Le pipeline Logstash ci-dessous permet d'implémenter le code de synchronisation décrit dans la section précédente :

input {
  jdbc {
    jdbc_driver_library => "<path>/mysql-connector-java-8.0.16.jar"
    jdbc_driver_class => "com.mysql.jdbc.Driver"
    jdbc_connection_string => "jdbc:mysql://<MySQL host>:3306/es_db"
    jdbc_user => <my username>
    jdbc_password => <my password>
    jdbc_paging_enabled => true
    tracking_column => "unix_ts_in_secs"
    use_column_value => true
    tracking_column_type => "numeric"
    schedule => "*/5 * * * * *"
    statement => "SELECT *, UNIX_TIMESTAMP(modification_time) AS unix_ts_in_secs FROM es_table WHERE (UNIX_TIMESTAMP(modification_time) > :sql_last_value AND modification_time < NOW()) ORDER BY modification_time ASC"
  }
}
filter {
  mutate {
    copy => { "id" => "[@metadata][_id]"}
    remove_field => ["id", "@version", "unix_ts_in_secs"]
  }
}
output {
  # stdout { codec =>  "rubydebug"}
  elasticsearch {
      index => "rdbms_sync_idx"
      document_id => "%{[@metadata][_id]}"
  }
}

Revenons sur certains éléments du pipeline ci-dessus :

• tracking_column : ce champ spécifie le champ "unix_ts_in_secs" (décrit ci-dessous), qui sert à effectuer le suivi du dernier document lu par Logstash depuis MySQL, celui-ci étant stocké sur le disque dans .logstash_jdbc_last_run. Cette valeur sert à définir la valeur de départ des documents que Logstash demandera lors de l'itération suivante de sa boucle d'interrogation. La valeur stockée dans .logstash_jdbc_last_run est accessible dans le statement (c'est-à-dire l'instruction) "SELECT", où elle apparaît en tant que ":sql_last_value".
• unix_ts_in_secs : ce champ est généré par l'instruction "SELECT" ci-dessus. Il contient le paramètre "modification_time" comme timestamp Unix (ou heure Unix) standard, exprimé en secondes écoulées depuis l'époque Unix. Comme nous venons de le voir, ce champ est référencé par "tracking_column". On utilise un timestamp Unix pour effectuer le suivi du temps écoulé plutôt qu'un système d'horodatage normal, car ce dernier risquerait d'entraîner des erreurs en raison de la complexité des conversions entre temps métrique universel (UMT, "Universal Metric Time") et fuseau horaire local.
• sql_last_value : ce paramètre intégré contient le point départ de l'itération de la boucle d'interrogation Logstash en cours d'exécution. Il est référencé dans la ligne d'instruction "SELECT" de la configuration de l'entrée JDBC ci-dessus. Il est défini sur la valeur "unix_ts_in_secs" la plus récente, qui est lue depuis .logstash_jdbc_last_run. Il sert de point de départ pour les documents devant être renvoyés par la requête MySQL exécutée dans la boucle d'interrogation Logstash. L'ajout de cette variable à la requête garantit que les insertions ou mises à jour déjà répercutées dans Elasticsearch ne soient pas envoyées de nouveau.
• schedule : ce champ utilise la syntaxe cron pour spécifier la fréquence à laquelle Logstash doit interroger MySQL. Ici, la valeur "*/5 * * * * *" indique à Logstash qu'il doit contacter MySQL toutes les 5 secondes.
• modification_time < NOW() : cette partie de l'instruction "SELECT" fait partie des concepts les plus difficiles à expliquer. Nous l'aborderons donc à la section suivante, qui lui est consacrée.
• filter : ici, nous copions simplement la valeur "id" de l'enregistrement MySQL dans un champ de métadonnées nommé "_id", que nous référencerons plus bas dans la sortie, afin que chaque document écrit dans Elasticsearch comporte la bonne valeur "_id". Le champ de métadonnées permet d'éviter que cette valeur temporaire n'entraîne la création d'un nouveau champ. Nous supprimons aussi les champs "id", "@version" et "unix_ts_in_secs" du document, étant donné que nous ne voulons pas les écrire dans Elasticsearch.
• output : dans cette section du code, nous indiquons que chaque document doit être écrit dans Elasticsearch et doit être associé à un "_id" extrait du champ de métadonnées que nous avons créé dans la section "filter". Nous avons ajouté une sortie rubydebug commentée, qui peut être activée pour aider au débogage.

Analyse de l'instruction "SELECT" et de son exactitude

Dans cette section, nous allons voir pourquoi il est important d'ajouter modification_time < NOW() à l'instruction "SELECT". Nous commencerons par quelques contre-exemples, qui démontrent pourquoi les approches les plus intuitives ne fonctionnent pas. Nous expliquerons ensuite comment l'ajout de modification_time < NOW() permet de surmonter les problèmes rencontrés dans les approches intuitives.

1^er scénario intuitif

Que se passe-t-il si la clause "WHERE" ne comporte pasmodification_time < NOW() et qu'elle spécifie uniquement UNIX_TIMESTAMP(modification_time) > :sql_last_value ? C'est ce que nous allons voir ici. Dans ce scénario, l'instruction "SELECT" serait la suivante :

statement => "SELECT *, UNIX_TIMESTAMP(modification_time) AS unix_ts_in_secs FROM es_table WHERE (UNIX_TIMESTAMP(modification_time) > :sql_last_value) ORDER BY modification_time ASC"

À première vue, l'approche ci-dessus devrait fonctionner correctement. Mais dans certains cas limites, elle risque de manquer des documents. Imaginons un exemple où MySQL insérerait 2 documents par seconde, et où Logstash exécuterait son instruction "SELECT" toutes les 5 secondes. Ce scénario est illustré dans le diagramme ci-dessous, où les valeurs T0 à T10 représentent les secondes, et les valeurs R1 à R22 représentent les enregistrements MySQL. Supposons que la première itération de la boucle d'interrogation de Logstash ait lieu à T5, et qu'elle lise les documents R1 à R11 (en turquoise ci-dessous). La valeur stockée dans sql_last_value est maintenant T5, puisqu'il s'agit du timestamp présent sur le dernier enregistrement lu (R11). Supposons aussi que juste après que Logstash ait lu les documents depuis MySQL, un autre document (R12) soit inséré dans MySQL, et qu'il comporte un timestamp de T5.

À la prochaine itération de l'instruction "SELECT" ci-dessus, nous n'extrairons que les documents dont l'heure est supérieure à T5 (tel que demandé par WHERE (UNIX_TIMESTAMP(modification_time) > :sql_last_value)), ce qui signifie que l'enregistrement R12 sera ignoré. C'est ce que montre le diagramme ci-dessous, dans lequel les cases turquoise représentent les enregistrements lus par Logstash dans l'itération en cours d'exécution, et les cases grises, les enregistrements déjà lus par Logstash au cours de l'itération précédente.

Remarquez que dans l'instruction "SELECT" de ce scénario, l'enregistrement R12 n'est jamais écrit dans Elasticsearch.

2^e scénario intuitif

Pour remédier au problème ci-dessus, on peut décider de modifier la clause "WHERE" pour la définir sur supérieur ou égal, comme suit :

statement => "SELECT *, UNIX_TIMESTAMP(modification_time) AS unix_ts_in_secs FROM es_table WHERE (UNIX_TIMESTAMP(modification_time) >= :sql_last_value) ORDER BY modification_time ASC"

Cependant, cette implémentation n'est pas non plus idéale. Dans ce cas, le problème qui se pose est le suivant : le ou les documents les plus récents lus depuis MySQL au cours de l'intervalle de temps le plus récent seront de nouveaux envoyés vers Elasticsearch. Bien que cela n'ait aucun impact négatif sur l'exactitude des résultats, cela implique des tâches non nécessaires. Comme après l'itération d'interrogation initiale au paragraphe précédent, le diagramme ci-dessous montre quels documents ont été lus depuis MySQL.

Lorsque nous exécutons l'itération d'interrogation de ce scénario, nous extrayons tous les documents dont le timestamp est supérieur ou égal à T5. C'est ce que montre le diagramme suivant. Remarquez que l'enregistrement R11 (en violet) est de nouveau envoyé vers Elasticsearch.

Aucun de ces deux scénarios n'est parfait. Dans le premier, nous risquons de perdre des données, et dans le second, les données sont lues depuis MySQL et envoyées à Elasticsearch plusieurs fois.

Comment résoudre les problèmes que posent ces approches intuitives

Aucun des deux scénarios précédents n'étant parfait, nous devons trouver une autre approche. Si nous spécifions (UNIX_TIMESTAMP(modification_time) > :sql_last_value AND modification_time < NOW()), nous n'envoyons chaque document vers Elasticsearch qu'une seule et unique fois.

C'est ce qu'illustre le diagramme ci-dessous, dans lequel Logstash interroge MySQL à T5. Remarque : la condition modification_time < NOW() devant être remplie, seuls les documents allant jusqu'à la période T5, mais non compris dans cette période, seront lus depuis MySQL. Puisque nous avons récupéré tous les documents de T4 et aucun document de T5, nous savons que sql_last_value sera ensuite défini sur T4 à la prochaine itération d'interrogation de Logstash.

Le diagramme ci-dessous illustre la prochaine itération de l'interrogation Logstash. Puisque UNIX_TIMESTAMP(modification_time) > :sql_last_value, et parce que sql_last_value est défini sur T4, nous savons que nous ne récupérons que les documents à partir de T5. De plus, puisque nous ne récupérons que les documents remplissant la condition modification_time < NOW(), seuls les documents allant jusqu'à T9 et compris dans cette période seront récupérés. Ici encore, cela signifie que nous récupérons tous les documents compris dans T9 et que sql_last_value sera défini sur T9 pour la prochaine itération. Nous voyons donc que cette approche nous évite de ne récupérer qu'une partie des documents MySQL dans un intervalle de temps donné.

Tester le système

Pour vérifier que notre implémentation fonctionne comme prévu, nous pouvons effectuer des tests simples. Nous pouvons écrire des enregistrements dans MySQL, comme suit :

INSERT INTO es_table (id, client_name) VALUES (1, 'Jim Carrey');
INSERT INTO es_table (id, client_name) VALUES (2, 'Mike Myers');
INSERT INTO es_table (id, client_name) VALUES (3, 'Bryan Adams');

Une fois que la planification de l'entrée JDBC a déclenché la lecture d'enregistrements depuis MySQL et leur écriture dans Elasticsearch, nous pouvons exécuter la requête Elasticsearch suivante pour afficher les documents dans Elasticsearch :

GET rdbms_sync_idx/_search

ce qui renvoie une réponse semblable à celle-ci :

"hits" : {
    "total" : {
      "value" : 3,
      "relation" : "eq"
    },
    "max_score" : 1.0,
    "hits" : [
      {
        "_index" : "rdbms_sync_idx",
        "_type" : "_doc",
        "_id" : "1",
        "_score" : 1.0,
        "_source" : {
          "insertion_time" : "2019-06-18T12:58:56.000Z",
          "@timestamp" : "2019-06-18T13:04:27.436Z",
          "modification_time" : "2019-06-18T12:58:56.000Z",
          "client_name" : "Jim Carrey"
        }
      },
Etc …

Nous pouvons alors mettre à jour le document correspondant à _id=1 dans MySQL, comme suit :

UPDATE es_table SET client_name = 'Jimbo Kerry' WHERE id=1;

ce qui met à jour le document identifié par un _id de 1. Pour afficher le document directement dans Elasticsearch, nous exécutons la commande suivante :

GET rdbms_sync_idx/_doc/1

ce qui renvoie ce document :

{
  "_index" : "rdbms_sync_idx",
  "_type" : "_doc",
  "_id" : "1",
  "_version" : 2,
  "_seq_no" : 3,
  "_primary_term" : 1,
  "found" : true,
  "_source" : {
    "insertion_time" : "2019-06-18T12:58:56.000Z",
    "@timestamp" : "2019-06-18T13:09:30.300Z",
    "modification_time" : "2019-06-18T13:09:28.000Z",
    "client_name" : "Jimbo Kerry"
  }
}

Remarque : la _version est maintenant définie sur 2, modification_time ne correspond plus à insertion_time, et le champ client_name a été correctement mis à jour avec la nouvelle valeur. Le champ @timestamp ne présente pas d'intérêt particulier dans notre exemple : Logstash l'ajoute par défaut.

Pour effectuer un upsert dans MySQL, procédez comme suit – vous pouvez ensuite vérifier que vous retrouvez les bonnes informations dans Elasticsearch :

INSERT INTO es_table (id, client_name) VALUES (4, 'Bob is new') ON DUPLICATE KEY UPDATE client_name='Bob exists already';

Et les documents supprimés ?

Comme rien ne vous échappe, vous avez probablement remarqué que lorsqu'on supprime un document de MySQL, sa suppression n'est pas répercutée dans Elasticsearch. Pour résoudre ce problème, vous pouvez adopter les approches suivantes :

1. Les enregistrements MySQL peuvent comprendre un champ "is_deleted", indiquant qu'ils ne sont plus valides. C'est ce qu'on appelle une "suppression réversible". Comme pour toutes les autres mises à jour d'enregistrements MySQL, ce champ "is_deleted" est répercuté dans Elasticsearch via Logstash. Si vous adoptez cette approche, les requêtes Elasticsearch et MySQL doivent être écrites de manière à exclure les enregistrements ou les documents dans lesquels "is_deleted" = "true". Enfin, des tâches en arrière-plan peuvent supprimer ces documents de MySQL et d'Elastic.
2. Autre possibilité : s'assurer que lorsqu'un système supprime des enregistrements dans MySQL, il doit aussi exécuter une commande pour supprimer directement les documents correspondants dans Elasticsearch.

Pour conclure

Dans cet article de blog nous avons vu comment utiliser Logstash pour synchroniser Elasticsearch avec une base de données relationnelle. Pour tester le code et les méthodes présentées ici, nous avons utilisé MySQL, mais cela doit a priori fonctionner avec n'importe quel SGBDR.

Des questions au sujet de Logstash ? Des questions sur Elasticsearch ? Jetez un œil à nos forums de discussion : vous y trouverez des idées et de précieuses informations. N'oubliez pas non plus d'essayer Elasticsearch Service, la seule offre Elasticsearch et Kibana hébergée, mise à votre disposition par les créateurs d'Elasticsearch.

L’Internet industriel des objets (IIoT) offre aux entreprises de fabrication la possibilité de recueillir des données par le biais de milliers de capteurs et d’appareils.

Ces données doivent être mises en corrélation par la suite pour monitorer les processus de production et déterminer les mesures appropriées pour une analyse plus approfondie. L’une des problématiques majeures consiste donc à collecter et à normaliser les données pour les utiliser dans le contexte de l’analyse prédictive ou de la sécurité de l’atelier.

Or, les entreprises de fabrication, même de petite taille, gèrent souvent plusieurs usines comptant des centaines de machines et des milliers de capteurs. De nouvelles données sont générées en l’espace de quelques millisecondes. Et très vite, vous disposez de plusieurs téraoctets de données. Néanmoins, celles-ci ne sont ni stockées, ni analysées. De ce fait, vous n’en retirez aucune valeur.

Avec Elastic, vous pouvez collecter, améliorer et analyser les données de l’IIoT, et de là, aider les gestionnaires de production à obtenir des informations plus approfondies sur les processus de production.
— Marco De Luca, Principal Solution Architect @ Elastic

La capacité à collecter ces données à l’échelle sera un facteur de différenciation important. Elle permet en effet d’optimiser les processus de production, et ainsi, conduire à une plus grande efficacité et à des produits de plus haute qualité.

En général, les fabricants font face à au moins l’une des problématiques suivantes, en plus de celles mentionnées ci-dessus :

• Les entreprises de fabrication sont innovantes, mais bon nombre de leurs machines sont anciennes et resteront probablement en place pendant encore plusieurs années. En effet, la durée d’un cycle de vie type est de 10 à 20 ans, voire plus ! Comment intégrer ces machines existantes dans des plateformes d’analyse modernes ?
• De nombreux types d’appareils doivent être monitorés, notamment les capteurs ou les véhicules autonomes. Et c’est seulement en ayant une vue complète que vous pourrez procéder à une maintenance prédictive appropriée, des opérations pertinentes, etc. Seulement voilà, les différents types d’appareils utilisent des technologies variées pour communiquer et une connectivité à Internet qui leur est propre.
• De plus, il existe un certain nombre de solutions propriétaires qui ne communiquent pas les unes avec les autres. Comment obtenir des données de ces systèmes et permettre une corrélation avec d’autres données machine ?
• Certaines entreprises de fabrication sont déjà en train de réfléchir à une solution pour établir une plateforme pour les données machine afin de monitorer l’ensemble des systèmes, nouveaux et existants. Comment exploiter les données pour assurer un fonctionnement optimal ou une maintenance appropriée, ou pour concevoir des cas métier et/ou des services supplémentaires ou nouveaux ?

Les entreprises qui s’attachent à collecter les données de leurs machines et à les analyser retireront de nombreux avantages, notamment, l’optimisation des processus de production et l’amélioration de la qualité des produits. Mais ce n’est pas tout !

Une solution de monitoring bien conçue, accompagnée d’une maintenance prédictive appropriée, peut également permettre de réduire considérablement les coûts. Les données de capteur peuvent en dire long sur l’état d’un appareil ou sur la qualité du produit fabriqué. De plus, elles aident à diminuer l’utilisation de ressources. MM Karton a démontré que c’était effectivement possible en réduisant sa consommation de matières premières de 20 %.

Pour pouvoir exploiter cet ensemble de données hétérogène, vous devez le stocker dans un environnement distinct capable d’évoluer avec vos besoins. Elasticsearch est la solution idéale pour ce cas d'utilisation. Non seulement elle vous permet de stocker de nombreux types de données à l’échelle, mais elle vous permet aussi d’analyser ces données avec le Machine Learning et de les visualiser comme vous le souhaitez.

Le fait de collecter l’ensemble des données pertinentes de chaque usine est une première étape. Maintenant, imaginez comment un monitoring global pourrait améliorer l’efficacité de vos usines de production. Pour stocker tous les types de données nécessaires dans Elasticsearch et combiner les données de plusieurs usines sur une seule vue avec Canvas, rien de plus simple. Il suffit de créer une diapositive de présentation connectée à des données réelles.

Voici quelques exemples :

Il est essentiel d’avoir cette vue générale sur différentes usines. Mais ce n’est pas tout. Vous voulez aussi connaître les performances des machines dans chaque usine. De plus, vous devez pouvoir combiner et mettre en corrélation les différents modèles de données de chaque fournisseur.

Cas d'utilisation IIoT typiques avec la Suite Elastic

Les cas d'utilisation suivants sont quelques exemples parmi d’autres de l’utilisation de la Suite Elastic pour analyser et monitorer les données IIoT. La mise en place de réponses automatisées à des problèmes grâce à l’interaction à distance avec les machines en fait également partie.

Des analyses prédictives pour une maintenance prédictive

L’utilisation de données de capteurs est très efficace pour analyser l’état des appareils IoT. Les données de capteurs, telles que la pression de l’air ou de l’huile, la température, la tension, la vitesse, le son, la fréquence ou le changement de couleur/d’éclairage sont des symptômes précoces d’une défaillance à venir. Si vous savez qu’une défaillance va se produire, vous pouvez donc réagir tout de suite et ainsi limiter les coûts.

De plus, en ayant connaissance des seuils des données de capteurs ou des plages de données, la direction de la production peut définir des plans de maintenance individuels basés sur des données réelles, plutôt que des cycles de maintenance rigides qui impliquent de changer des composants, qu’ils soient encore en bon état ou non. L’utilisation de ces données permet donc de mettre en place un plan de maintenance dédié et pertinent, qui réduit les coûts et les interruptions de production.

Mais pour cela, il faut déjà avoir une connaissance précise des circonstances susceptibles de mener à une défaillance. Ce qui signifie qu’il faut observer des centaines de capteurs simultanément en temps réel et comparer les données aux événements qui se sont produits par le passé. Autant dire que ce n’est pas chose aisée, pour les simples humains que nous sommes. Pour le Machine Learning, en revanche, c’est une tâche idéale. La détection d’anomalies sur un capteur ou la mise en corrélation des données de tous les capteurs pour obtenir une vue unique relative à l’état sont des capacités réellement puissantes.

Un autre KPI important est le taux de rejets et de déchets. Pour pouvoir réduire le taux de rejets, il faut d’abord savoir quels aspects de la production entraînent des rejets. La détection des valeurs anormales basée sur le Machine Learning de la Suite Elastic permet de déterminer les produits dont les résultats diffèrent de ceux attendus. En utilisant cette fonction de détection avec les données des capteurs, vous pouvez identifier les problèmes avec rapidité et facilité.

Au niveau de l’atelier, une tâche de Machine Learning bien conçue peut permettre aux machines de s’optimiser par elles-mêmes sans qu’aucune intervention humaine ne soit nécessaire.

Sécurité de l’atelier

De nos jours, la sécurité des systèmes IT est une problématique bien connue. Dans le cas d’un atelier, cependant, la sécurité est souvent bien plus difficile à mettre en place. Actuellement, le principe appliqué pour garantir la sécurité est d’empêcher les intrusions en ne connectant pas les installations de production à Internet.

Mais cette contrainte s’avère de plus en plus difficile à respecter. L’impact croissant de “l’IT classique” (p. ex. ERP comme SAP PP ou PLM) sur des systèmes SPS (comme Siemens SIMATIC) aboutit sur la mise en place d’une communication directe, avec tous les avantages et les inconvénients que cela représente. La demande est émise par l’entreprise. D’ailleurs, la fabrication à la demande existe déjà avec les imprimantes 3D ou la découpe laser. Réfléchissons un instant. Imaginons que des processus de production entièrement automatisés soient déclenchés par les commandes personnalisées émises par un atelier Web quelconque. Le risque de production d’étincelles par l’IT interconnectée à l’atelier prend alors une nouvelle dimension. La sécurité de l’atelier deviendra donc une problématique vraiment importante lors de la transition vers l’industrie 4.0. Grâce à la combinaison d’Elastic SIEM (gestion des informations et des événements de sécurité) à la possibilité de collecter toutes les données appropriées, vous pourrez monitorer les événements de sécurité dans votre usine intelligente également.

Les capacités d’analyse dont une entreprise a besoin ont été intégrées à la Suite Elastic il y a déjà un certain temps. La difficulté reposait sur le fait d’obtenir les données de différentes sources pour les mettre dans la suite.

Dans le cas d’une usine de production, les données venant de différentes sources ne peuvent pas être collectées que d’une seule manière. Vous devez réunir toutes les sources. Étant donné qu’Elastic est une plateforme de données libre et en temps réel, vous pouvez facilement vous appuyer sur son écosystème pour intégrer tous les types de sources de données.

Une usine de fabrication dispose de nombreux systèmes différents qu’il faut monitorer, depuis les systèmes très anciens (exécutant peut-être des logiciels de commande basés sur Windows 95 voire une version antérieure) jusqu’aux dernières technologies exécutant Linux et OPC-UA. Nous parlons principalement des types de systèmes suivants :

• Les logiciels de commande de fabrication, tels que IBM MQ, servant à contrôler le processus de fabrication d’une usine, et aussi entre les usines.

• Un contrôleur logique programmable (PLC) est un type distinct d’appareil informatique conçu pour être utilisé dans des systèmes de commande industriels. Il s’agit d’un "PC industriel" spécial qui contrôle les capteurs et les actionneurs. Par exemple, il commande les machines qui fabriquent des produits papier dans l’industrie papetière ou il commande les ascenseurs et les escaliers roulants. Il existe de nombreux cas d'utilisation sur les éléments que peut contrôler un PLC.

• Les robots industriels, comme ceux fabriqués par KUKA (fabricant allemand/chinois). Les robots KUKA sont équipés d’un serveur OPC-UA qui permet de les contrôler, mais qui interagit en même temps avec d’autres robots et systèmes de l’atelier. Le protocole OPC-UA permet également d’interconnecter des systèmes via Internet, et de ce fait, les expose à des menaces de sécurité. C’est pourquoi la sécurité joue un rôle important dans la spécification OPC-UA. Néanmoins, elle doit être monitorée par des plateformes de monitoring comme Elastic.

• Les capteurs et autres véhicules autonomes ou appareils servent principalement à mesurer la température, l’humidité, la vitesse, l’accélération, le positionnement, les vibrations ou d’autres indicateurs qu’il faut mettre en corrélation avec les données des processus de production. Par exemple, les changements de température et d’humidité peuvent affecter le fonctionnement d’un robot et provoquer des vibrations plus intenses, qui peuvent entraîner la défaillance du robot ou la fabrication de produits de mauvaise qualité. De ce fait, les données des capteurs et des robots sont importantes pour les opérations des clients.

Pour collecter l’ensemble de ces données en temps quasi-réel, nous pouvons utiliser Machinebeat, une communauté Beat qui peut collecter des données auprès de brokers MQTT et d’appareils OPC-UA. Le module MQTT peut également collecter des données auprès de différents fournisseurs de services cloud IoT, tels que AWS IoT Core ou Azure IoT Hub.

Pour collecter des données auprès d’appareils PLC, il existe une intégration au projet Apache PLC4X sous forme de plugin Logstash, qui permet aux clients de collecter des indicateurs venant de tous les PLC pris en charge par PLC4X. Pour en savoir plus sur la combinaison PLC4X/Elasticsearch, lisez cet article de blog de notre partenaire Codecentric.

Visualisez vos données avec Kibana

Vous disposez donc maintenant d’un grand volume de données. La problématique qui se pose désormais est de réussir à en retirer de la valeur. Il sera inutile de disposer d’un tel volume de données si vous ne parvenez pas à l’exploiter. Pour en tirer parti, vous devez par exemple obtenir des perspectives approfondies sur le déroulement des opérations. C’est là que les visualisations peuvent aider. L’exemple ci-dessous présente une visualisation des communications entre plusieurs files d’attente d’un environnement de fabrication contrôlé par IBM MQ. Dans les anciens systèmes de monitoring, vous devez avoir des connaissances précises sur les éléments que vous monitorez. En utilisant Canvas, ces connaissances sont inutiles, et vous pouvez afficher une représentation à code couleur de la situation actuelle.

Jugez-en par vous-même

1. Lancez-vous avec une version d’évaluation gratuite de 14 jours d’Elasticsearch Service, qui vous fournira la base de votre solution de monitoring IoT.
2. Rendez-vous sur Github et téléchargez la version Linux ou Windows de Machinebeat. 
3. Suivez la procédure indiquée dans la section Configurations du fichier Lisez-moi pour configurer une connexion à un serveur OPC-UA gratuit ou saisissez les informations d’identification de votre propre serveur OPC-UA. Si vous préférez, vous pouvez suivre la procédure pour configurer un broker MQTT et collecter des données auprès de différents capteurs via ce broker.
4. Une fois que les données commencent à affluer, concevez vos propres tableaux de bord pour visualiser/analyser vos données. Canvas propose une autre option idéale pour visualiser vos données en vous permettant de créer des diapositives de présentation avec des données en temps réel. Pour en savoir plus, consultez l’article de blog Prise en main de Canvas dans Kibana.

Faites-nous part de vos réflexions ! Rendez-vous sur nos forums de discussion ou entrez une requête d’extraction dans GitHub.

Depuis le lancement des versions 6.8 et 7.1 de la Suite Elastic, vous avez gratuitement accès à certaines fonctionnalités de sécurité, qui sont désormais intégrées dans la distribution par défaut (licence Basic). Avec cette nouvelle offre, vous pouvez désormais chiffrer le trafic réseau via SSL, ajouter et gérer des utilisateurs, définir des rôles qui protègent l'accès au niveau des index et des clusters, mais aussi assurer la sécurité totale de Kibana. Dans l'article de blog Prise en main de la sécurité Elasticsearch que nous avions publié peu de temps après le lancement, nous vous expliquions comment utiliser les communications TLS entre Elasticsearch et Kibana. Dans l'article ci-dessous, nous allons nous pencher sur d'autres composants de la Suite Elastic, comme Beats ou Logstash. Nous allons voir comment activer TLS entre les composants et comment chiffrer les communications client HTTP.

Remarque : si l'activation de TLS sur la couche HTTP n'est pas obligatoire, elle est néanmoins vivement recommandée pour assurer une sécurité de bout en bout et protéger les données, notamment pour éviter l'interception des noms d'utilisateur et des mots de passe, et donc la compromission du cluster. Pour en savoir plus sur le chiffrement TLS, l'authentification, les scripts limités ou l'isolation, consultez l'article de blog intitulé Chiffrement, sécurisation des données utilisateur et plus encore : nos conseils pour sécuriser gratuitement vos clusters Elasticsearch.

Autre remarque : les fonctionnalités de sécurité que nous allons configurer ci-dessous sont activées par défaut dans Elasticsearch Service sur Elastic Cloud. Si vous utilisez Elasticsearch Service, vous pouvez donc passer directement à l'étape 5.

Étapes à suivre pour sécuriser la Suite Elastic

1. Préparation
2. Créer des certificats SSL et activer TLS pour Elasticsearch sur "node1" (nœud1)
3. Activer TLS pour Kibana sur "node1"
4. Activer TLS pour Elasticsearch sur "node2" (nœud2)
5. Préparer les utilisateurs Logstash sur "node1"
6. Activer TLS pour Logstash sur "node1"
7. Exécuter Filebeat et configurer TLS sur "node1"
8. Utiliser Filebeat pour ingérer les données

Étape 1. Préparation

Téléchargez les composants suivants de la Suite Elastic 7.1 ou d'une version plus récente :

• Elasticsearch
• Kibana
• Logstash
• Filebeat

[1-1] Configurer le fichier /etc/hosts

Dans cet exemple, notre "node1" (nœud1) dispose d'un navigateur, afin que kibana.local autorise l'accès à la page web de Kibana.

#fichier /etc/hosts pour le [node1] (nous avons besoin de kibana.local et de logstash.local)
127.0.0.1 kibana.local logstash.local
192.168.0.2 node1.elastic.test.com node1
192.168.0.3 node2.elastic.test.com node2

#fichier /etc/hosts pour le [node2] (ici, nous n'avons pas besoin de kibana.local et logstash.local)
192.168.0.2 node1.elastic.test.com node1
192.168.0.3 node2.elastic.test.com node2

Étape 2. Créer des certificats SSL et activer TLS pour Elasticsearch sur "node1" (nœud1)

[2-1] Définir les variables d'environnement (adapter le chemin de ces variables en fonction du mode de téléchargement d'Elasticsearch et de son emplacement)

[root@node1 ~]# ES_HOME=/usr/share/elasticsearch
[root@node1 ~]# ES_PATH_CONF=/etc/elasticsearch

[2-2] Créer un dossier tmp

[root@node1 ~]# mkdir tmp
[root@node1 ~]# cd tmp/
[root@node1 tmp]# mkdir cert_blog

[2-3] Créer un fichier d'instance yaml

[root@node1 cert_blog]# vi ~/tmp/cert_blog/instance.yml
# ajoutez les informations relatives à l'instance au fichier yml
instances:
  - name: 'node1'
    dns: [ 'node1.elastic.test.com' ]
  - name: "node2"
    dns: [ 'node2.elastic.test.com' ]
  - name: 'my-kibana'
    dns: [ 'kibana.local' ]
  - name: 'logstash'
    dns: [ 'logstash.local' ]

[2-4] Générer des certificats d'autorité de certification (CA) et de serveur (une fois Elasticsearch installé)

[root@node1 tmp]# cd $ES_HOME
[root@node1 elasticsearch]# bin/elasticsearch-certutil cert ca --pem --in ~/tmp/cert_blog/instance.yml --out ~/tmp/cert_blog/certs.zip

[2-5] Décompresser les certificats

[root@node1 elasticsearch]# cd ~/tmp/cert_blog
[root@node1 cert_blog]# unzip certs.zip -d ./certs

[2-6] Configurer le TLS Elasticsearch

[2-6-1] Copier le fichier "cert" vers le dossier "config"

[root@node1 ~]# cd $ES_PATH_CONF
[root@node1 elasticsearch]# pwd
/etc/elasticsearch
[root@node1 elasticsearch]# mkdir certs
[root@node1 elasticsearch]# cp ~/tmp/cert_blog/certs/ca/ca.crt ~/tmp/cert_blog/certs/node1/* certs
[root@node1 elasticsearch]# ll certs
total 12
-rw-r--r--. 1 root elasticsearch 1834 Apr 12 08:47 ca.crt
-rw-r--r--. 1 root elasticsearch 1509 Apr 12 08:47 node1.crt
-rw-r--r--. 1 root elasticsearch 1679 Apr 12 08:47 node1.key
[root@node1 elasticsearch]#

[2-6-2] Configurer elasticsearch.yml

[root@node1 elasticsearch]# vi elasticsearch.yml 
## ajoutez le contenu suivant
node.name: node1
network.host: node1.elastic.test.com
xpack.security.enabled: true
xpack.security.http.ssl.enabled: true
xpack.security.transport.ssl.enabled: true
xpack.security.http.ssl.key: certs/node1.key
xpack.security.http.ssl.certificate: certs/node1.crt
xpack.security.http.ssl.certificate_authorities: certs/ca.crt
xpack.security.transport.ssl.key: certs/node1.key
xpack.security.transport.ssl.certificate: certs/node1.crt
xpack.security.transport.ssl.certificate_authorities: certs/ca.crt
discovery.seed_hosts: [ "node1.elastic.test.com" ]
cluster.initial_master_nodes: [ "node1" ]

[2-6-3] Démarrer et vérifier le log du cluster

[root@node1 elasticsearch]# grep '\[node1\] started' /var/log/elasticsearch/elasticsearch.log 
[o.e.n.Node               ] [node1] started

[2-6-4] Définir un mot de passe intégré

[root@node1 elasticsearch]# cd $ES_HOME
[root@node1 elasticsearch]# bin/elasticsearch-setup-passwords auto -u "https://node1.elastic.test.com:9200"
Initiating the setup of passwords for reserved users elastic,apm_system,kibana,logstash_system,beats_system,remote_monitoring_user.
The passwords will be randomly generated and printed to the console.
Please confirm that you would like to continue [y/N] y
Changed password for user apm_system
PASSWORD apm_system = <apm_system_password>
Changed password for user kibana
PASSWORD kibana = <kibana_password>
Changed password for user logstash_system
PASSWORD logstash_system = <logstash_system_password>
Changed password for user beats_system
PASSWORD beats_system = <beats_system_password>
Changed password for user remote_monitoring_user
PASSWORD remote_monitoring_user = <remote_monitoring_user_password>
Changed password for user elastic
PASSWORD elastic = <elastic_password>

[2-6-5] Accéder à l'API _cat/nodes via HTTPS

[root@node1 elasticsearch]# curl --cacert ~/tmp/cert_blog/certs/ca/ca.crt -u elastic 'https://node1.elastic.test.com:9200/_cat/nodes?v'
Enter host password for user 'elastic':
ip          heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name
192.168.0.2           16          95  10    0.76    0.59     0.38 mdi       *      node1

Étape 3. Activer TLS pour Kibana sur "node1"

[3-1] Définir les variables d'environnement

Adaptez le chemin de ces variables en fonction du mode de téléchargement de Kibana et de son emplacement :

[root@node1 ~]# KIBANA_HOME=/usr/share/kibana
[root@node1 ~]# KIBANA_PATH_CONFIG=/etc/kibana

[3-2] Créer un dossier "config" et "config/certs" et copier "certs" (une fois Kibana installé)

Copiez les fichiers de certificat créés à l'étape 2-4 et collez-les dans kibana/config/certs.

[root@node1 kibana]# ls config/certs
total 12
ca.crt
my-kibana.crt
my-kibana.key

[3-3] Configurer kibana.yml

Pensez à utiliser le mot de passe que vous avez généré plus haut pour l'utilisateur intégré. Remplacez <kibana_password> par le mot de passe défini à l'étape 2-6-4.

[root@node1 kibana]# vi kibana.yml 
server.name: "my-kibana"
server.host: "kibana.local"
server.ssl.enabled: true
server.ssl.certificate: /etc/kibana/config/certs/my-kibana.crt
server.ssl.key: /etc/kibana/config/certs/my-kibana.key
elasticsearch.hosts: ["https://node1.elastic.test.com:9200"]
elasticsearch.username: "kibana"
elasticsearch.password: "<kibana_password>"
elasticsearch.ssl.certificateAuthorities: [ "/etc/kibana/config/certs/ca.crt" ]

[3-4] Démarrer Kibana et tenter de se connecter

Accédez à https://kibana.local:5601/ depuis un navigateur. Connectez-vous à l'aide du nom d'utilisateur elastic et du mot de passe défini à l'étape 2-6-4. Dans cet exemple, notre "node1" (nœud1) dispose d'un navigateur, afin que kibana.local autorise l'accès à Kibana.

Les autorités de certification approuvées publiquement appliquent des normes et des pratiques d'audit très strictes, afin de garantir que seules les identités correctement confirmées puissent obtenir un certificat. À des fins d'illustration, nous allons créer un certificat auto-signé pour Kibana (ce qui signifie que le certificat généré est signé via sa propre clé privée). Les clients ne faisant pas confiance aux certificats Kibana auto-signés, un message similaire à celui-cis'affiche dans vos logs Kibana jusqu'à ce que l'utilisation de certificats générés par une autorité de certification publique ou d'entreprise permette d'établir la confiance (ce lien vous permet d'accéder au problème dans le référentiel Kibana). Le problème ne vous empêche pas de travailler dans Kibana :

[18:22:31.675] [error][client][connection] Error: 4443837888:error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown:../deps/openssl/openssl/ssl/s3_pkt.c:1498:SSL alert number 46

Étape 4. Activer TLS pour Elasticsearch sur "node2" (nœud2)

[4-1] Définir les variables d'environnement

[root@node2 ~]# ES_HOME=/usr/share/elasticsearch
[root@node2 ~]# ES_PATH_CONF=/etc/elasticsearch

[4-2] Configurer TLS sur "node2"

Vous pouvez utiliser la commande "scp" pour copier des certificats de "node1" vers "node2". Pour sécuriser la connexion, les deux nœuds nécessitent une clé et un certificat. Dans un environnement de production, il est recommandé d'utiliser une clé correctement signée pour chaque nœud. À des fins de démonstration, nous utilisons ici un certificat d'autorité de certification généré automatiquement et un certificat de nom d'hôte multi-DNS signé par l'autorité de certification que nous avons générée.

[root@node2 ~]# cd $ES_PATH_CONF
[root@node2 elasticsearch]# pwd
/etc/elasticsearch
[root@node2 elasticsearch]# mkdir certs
[root@node2 elasticsearch]# cp ~/tmp/cert_blog/certs/ca/ca.crt ~/tmp/cert_blog/certs/node2/* certs  
[root@node2 elasticsearch]# 
[root@node2 elasticsearch]# ll certs
total 12
-rw-r--r--. 1 root elasticsearch 1834 Apr 12 10:55 ca.crt
-rw-r--r--. 1 root elasticsearch 1509 Apr 12 10:55 node2.crt
-rw-r--r--. 1 root elasticsearch 1675 Apr 12 10:55 node2.key

[4-3] Configurer elasticsearch.yml

[root@node2 elasticsearch]# vi elasticsearch.yml 
node.name: node2
network.host: node2.elastic.test.com
xpack.security.enabled: true
xpack.security.http.ssl.enabled: true
xpack.security.transport.ssl.enabled: true
xpack.security.http.ssl.key: certs/node2.key
xpack.security.http.ssl.certificate: certs/node2.crt
xpack.security.http.ssl.certificate_authorities: certs/ca.crt
xpack.security.transport.ssl.key: certs/node2.key
xpack.security.transport.ssl.certificate: certs/node2.crt
xpack.security.transport.ssl.certificate_authorities: certs/ca.crt
discovery.seed_hosts: [ "node1.elastic.test.com" ]

[4-4] Démarrer et vérifier le log du cluster

[root@node2 elasticsearch]# grep '\[node2\] started' /var/log/elasticsearch/elasticsearch.log 
[o.e.n.Node               ] [node2] started

[4-5] Accéder à l'API _cat/nodes via HTTPS

[root@node2 elasticsearch]# curl --cacert ~/tmp/cert_blog/certs/ca/ca.crt -u elastic:<password set previously> 'https://node2.elastic.test.com:9200/_cat/nodes?v'
ip          heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name
192.168.0.2           25          80   5    0.18    0.14     0.30 mdi       *      node1
192.168.0.3           14          96  44    0.57    0.47     0.25 mdi       -      node2

Étape 5. Préparer les utilisateurs Logstash sur "node1"

[5-1] Créer un rôle logstash_write_role

Il existe différentes façons de créer le rôle.

Vous pouvez le créer via l'interface utilisateur "Roles" de Kibana : 

Mais vous pouvez aussi le créer via l'API disponible dans l'onglet "Dev Tools" de Kibana :

POST /_security/role/logstash_write_role
{
    "cluster": [
      "monitor",
      "manage_index_templates"
    ],
    "indices": [
      {
        "names": [
          "logstash*"
        ],
        "privileges": [
          "write",
          "create_index"
        ],
        "field_security": {
          "grant": [
            "*"
          ]
        }
      }
    ],
    "run_as": [],
    "metadata": {},
    "transient_metadata": {
      "enabled": true
    }
}

Vous obtenez alors la réponse suivante :

{"role":{"created":true}}

Les utilisateurs associés à ce rôle ne pourront supprimer aucun document. Ce rôle limite les autorisations des utilisateurs à la création d'index commençant par logstash et à l'indexation de documents dans ces index.

[5-2] Créer un utilisateur logstash_writer (penser à modifier le mot de passe de l'utilisateur logstash_writer)

Il existe différentes façons de créer l'utilisateur.

Vous pouvez le créer via l'interface utilisateur "Users" de Kibana :

Mais vous pouvez aussi le créer via l'API disponible dans l'onglet "Dev Tools" de Kibana :

POST /_security/user/logstash_writer
{
  "username": "logstash_writer",
  "roles": [
    "logstash_write_role"
  ],
  "full_name": null,
  "email": null,
  "password": "<logstash_system_password>",
  "enabled": true
}

Vous obtenez alors la réponse suivante :

{"user":{"created":true}}

Étape 6. Activer TLS pour Logstash sur "node1"

[6-1] Créer un dossier et copier les certificats

[root@node1 logstash]# ls -l
total 24
ca.crt
logstash.crt
logstash.key

[6-2] Convertir logstash.key au format PKCS#8 pour le plug-in d'entrée Beats

[root@node1 logstash]# openssl pkcs8 -in config/certs/logstash.key -topk8 -nocrypt -out config/certs/logstash.pkcs8.key

[6-3] Configurer logstash.yml

Pensez à utiliser le mot de passe généré automatiquement pour l'utilisateur logstash_system. Utilisez le mot de passe défini à l'étape 2-6-4.

[root@node1 logstash]# vi logstash.yml

Puis modifiez :

node.name: logstash.local
path.config: /etc/logstash/conf.d/*.conf
xpack.monitoring.enabled: true
xpack.monitoring.elasticsearch.username: logstash_system
xpack.monitoring.elasticsearch.password: '<logstash_system_password>'
xpack.monitoring.elasticsearch.hosts: [ 'https://node1.elastic.test.com:9200' ]
xpack.monitoring.elasticsearch.ssl.certificate_authority: /etc/logstash/config/certs/ca.crt

[6-4] Créer et configurer conf.d/example.conf

Sur la sortie Elasticsearch, utilisez le mot de passe défini à l'étape 5-2.

[root@node1 logstash]# vi conf.d/example.conf 
input {
  beats {
    port => 5044
    ssl => true
    ssl_key => '/etc/logstash/config/certs/logstash.pkcs8.key'
    ssl_certificate => '/etc/logstash/config/certs/logstash.crt'
  }
}
output {
  elasticsearch {
    hosts => ["https://node1.elastic.test.com:9200","https://node2.elastic.test.com:9200"]
    cacert => '/etc/logstash/config/certs/ca.crt'
    user => 'logstash_writer'
    password => <logstash_writer_password>
  }
}

[6-5] Démarrer Logstash avec l'exemple de configuration et vérifiez le log Logstash

Les messages de log suivants doivent s'afficher :

[INFO ][logstash.pipeline        ] Pipeline started successfully {:pipeline_id=>".monitoring-logstash", :thread=>"#<Thread:0x640c14d2@/usr/share/logstash/logstash-core/lib/logstash/pipeline.rb:246 run

Dans l'onglet "Monitoring" de Kibana, Logstash doit également s'afficher (informations sur le nœud, les paramètres du pipeline, le système d'exploitation, la machine virtuelle Java (JVM), les statistiques de traitement et les statistiques d'exécution du pipeline) :

Étape 7. Exécuter Filebeat et configurer TLS sur "node1"

[7-1] Créer un dossier "config" et copier les certificats

[root@node1 filebeat]# mkdir config
[root@node1 filebeat]# mkdir config/certs
[root@node1 filebeat]# cp ~/tmp/cert_blog/certs/ca/ca.crt config/certs
[root@node1 filebeat]# ll config/certs/
total 4
-rw-r--r--. 1 root root 1834 Apr 20 00:18 ca.crt

[7-2] Créer un nouveau fichier filebeat.yml

[root@node1 filebeat]# pwd
/etc/filebeat
[root@node1 filebeat]# mv filebeat.yml filebeat.yml.old

[7-3] Modifier le nouveau fichier de configuration filebeat.yml

filebeat.inputs:
- type: log
  paths:
    - /etc/filebeat/logstash-tutorial-dataset
output.logstash:
  hosts: ["logstash.local:5044"]
  ssl.certificate_authorities:
    - /etc/filebeat/config/certs/ca.crt

Étape 8. Utiliser Filebeat pour ingérer les données

[8-1] Préparer les données du log d'entrée (logstash-tutorial.log) pour Filebeat

Commencez par télécharger les données du log d'entrée.

[root@node1 filebeat]# pwd
/etc/filebeat
[root@node1 filebeat]# mkdir logstash-tutorial-dataset
[root@node1 filebeat]# cp /root/logstash-tutorial.log logstash-tutorial-dataset/.
[root@node1 filebeat]# ll logstash-tutorial-dataset/
total 24
-rwxr-x---. 1 root root 24464 Apr 20 00:29 logstash-tutorial.log

[8-2] Démarrer Filebeat

[root@node1 filebeat]# systemctl start filebeat
[root@node1 filebeat]# systemctl enable filebeat
Created symlink from /etc/systemd/system/multi-user.target.wants/filebeat.service to /usr/lib/systemd/system/filebeat.service.

[8-3] Vérifier le log

Les messages de log suivants doivent s'afficher :

INFO    log/harvester.go:216    Harvester started for file: /etc/filebeat/logstash-tutorial-dataset/logstash-tutorial.log

[8-4] Créer un modèle d'indexation

Ensuite, créez un modèle d'indexation correspondant aux données en cours d'ingestion. Cela permet la visualisation des données dans Kibana, par exemple via les onglets Graph ou Discover.

Sélectionnez ensuite le nom du champ "Time Filter" (filtre temporel). Dans notre exemple, il s'agit de @timestamp :

Et voilà ! Vous venez de chiffrer la communication entre les différents composants de la Suite Elastic et vous ingérez maintenant des données de log en toute sécurité.

Pour terminer

Si vous rencontrez des problèmes lors de la configuration de la sécurité, commencez par jeter un œil au guide de résolution des problèmes de sécurité. Il peut vous aider à résoudre bon nombre de problèmes courants. Si vous avez toujours des questions après cela, n'hésitez pas à demander de l'aide sur les forums Elastic. Et si vous préférez contacter directement l'équipe de support technique Elastic, souscrivez un abonnement Elastic : il vous donnera directement accès à une équipe d'experts. En attendant un prochain article, faites attention à vous (et à votre cluster) !

Récemment, nous avons fait deux annonces importantes :

1. Endgame a rejoint les troupes d’Elastic.
2. Nous supprimons la tarification par point de terminaison non seulement pour les cas d’utilisation "traditionnels" de protection des points de terminaison, mais également pour la détection et la réponse des points de terminaison.

On nous a parfois demandé où se trouvait le piège. Il est vrai que, historiquement parlant, les fournisseurs de sécurité ont toujours proposé une tarification par point de terminaison. Désormais, vous n’avez plus à vous préoccuper de cette variable, et cela semble trop beau pour être vrai.

Mais rassurez-vous... Il n’y a aucun piège. Chez Elastic, nous proposons juste une tarification simple.

Pour nous, le plus important, c’est que vous trouviez encore et toujours de nouvelles façons de tirer parti de nos produits. Et nous voulons que vous puissiez prédire avec facilité et précision l’impact en termes de coûts des nouveaux cas d'utilisation. Aussi, ne perdez pas de temps à compter vos appareils et à négocier des licences. Ce qui importe, c’est de protéger votre entreprise.

Que facturons-nous ?

À compter du 1er novembre, la solution Elastic Endpoint Security sera intégrée dans une nouvelle forme d’abonnement Enterprise. Vous payez simplement des frais d’abonnement basés sur les ressources informatiques que vous utilisez pour gérer, stocker, rechercher et analyser les données d’événements de vos points de terminaison. Ainsi, vous pouvez allouer les ressources qu’il vous faut en toute flexibilité selon vos besoins et selon la croissance des capacités d’Elastic.

Avec l’abonnement Enterprise de la Suite Elastic, intégrez l’ensemble de vos données d’événements de sécurité au point de terminaison dans la Suite Elastic pour détecter et chasser les menaces, et pour permettre une réponse et une orchestration automatisées. Vous pouvez vous appuyer sur une architecture flexible de stockage hot/warm/cold pour accéder à l’ensemble de données dont vous avez besoin quand vous en avez besoin. Aucun taux d’ingestion, tarif par appareil ou tarif par utilisateur ne vous est facturé. De plus, vous bénéficiez d’une technologie de pointe en matière de prévention contre les malware et les menaces pour vos ordinateurs portables, ordinateurs de bureau et serveurs, dans une expérience unique.

Et comme nos solutions tirent parti de la meilleure technologie de recherche du marché, vous pouvez réellement utiliser vos données pour mettre au jour les anomalies, chasser les menaces et éviter les dommages et les pertes.

En payant uniquement pour les ressources que vous utilisez, vous ne vous retrouvez pas bloqué dans un cas d'utilisation ou une approche spécifique.

Supposons que vous souhaitiez tester une nouvelle capacité d’Elastic, par exemple l’observabilité. Vous pourriez faire des tests avec les indicateurs d’application, et vous n’auriez à étendre vos ressources que si vous décidez de stocker et d’analyser plus de données. C’est aussi simple que ça.

Lorsque des données historiques perdent de leur intérêt, vous pouvez les déplacer, sans avoir à les supprimer complètement. Placez-les sur du matériel moins coûteux à l’aide du gel des index. Si certaines données deviennent inutiles, vous pouvez les supprimer ou les archiver, puis réorienter vos ressources Elastic vers d’autres projets.

Notre approche simple et flexible en termes de tarification facilite la détermination de votre utilisation actuelle, avec la possibilité d’adopter de nouvelles capacités et de prendre en charge d’autres cas d'utilisation dans le futur.

Faites le tri dans vos événements, pas dans vos budgets

L’ancien modèle de tarification par point de terminaison et par fonctionnalité convient bien aux fournisseurs, mais il se fait souvent en défaveur de la sécurité. Pour les fournisseurs de sécurité, les clients passent au second plan. Plutôt que d’avoir les intérêts des clients en tête, les fournisseurs proposent des "niveaux" de protection accompagnés d’une multitude de modules complémentaires. Si vous avez déjà dû faire le choix entre les points de terminaison et les serveurs ayant une protection "complète" et ceux qui n’auraient qu’une protection partielle (voire nulle), vous savez de quoi nous parlons. Et là, c’est le drame. Une infraction se produit parce que vous n’avez pas fait la mise à niveau vers le dernier SKU en vogue...

Lorsque l’on sait que le temps moyen avant qu’une infraction soit découverte est de plus de 90 jours, il ne rime à rien pour les fournisseurs de limiter le stockage de vos données à sept jours. Et il est encore plus illogique que vous deviez choisir quels événements de point de terminaison seront ingérés dans le SIEM et quels seront ceux que vous devrez mettre de côté, faute de finances. Quand il faut "chercher une aiguille dans une botte de foin", il est nécessaire d’avoir toute la botte.

Engagement envers une approche juste et prévisible

Elastic a mis en place un modèle de tarification à l’utilisation cohérent sur l’ensemble de ses produits, depuis Elastic SIEM jusqu’à Logs, en passant par Metrics et APM. Une tarification à l’utilisation signifie tout simplement que les frais d’abonnement se basent sur le nombre de ressources informatiques que vous utilisez pour exécuter votre Suite Elastic.

Par exemple, nous avons choisi de ne pas tarifier Elastic SIEM en fonction du nombre d’utilisateurs ou d’un taux d’ingestion. En ce qui concerne la fonction d’observabilité, nous avons supprimé la tarification par agent et par hôte. Et pour la fonction de recherche, nous avons mis fin à une tarification par document, par recherche et par utilisateur.

Chez Elastic, nous facturons uniquement les ressources utilisées pour stocker, rechercher et analyser vos données.

Aujourd’hui, c’est cette même approche que nous appliquons à Elastic Endpoint Security.

Jugez-en par vous-même

Envie de vous lancer ? Déployez un cluster sur Elasticsearch Service ou installez la dernière version de la Suite Elastic.

Vous avez déjà des données ECS dans Elasticsearch ? Il vous suffit de mettre vos clusters à niveau vers la version 7.4, et Elastic SIEM est à vous.

L’arrivée d’Elastic Endpoint Security est imminente. Soyez informé des développements concernant Elastic Endpoint Security ou soumettez votre candidature pour faire partie du Programme d’accès en avant-première.

Nous sommes ravis d'annoncer l'arrivée de Kibana Lens – un grand pas en avant en matière de visualisation et d'exploration des données avec la Suite Elastic, qui deviennent encore plus simples et plus intuitives.

Des millions de personnes exploitent déjà Kibana pour visualiser leurs données et interagir avec elles en temps réel. Avec ce premier lancement de Kibana Lens en version bêta, l'accès aux précieuses informations que renferment vos données Elasticsearch gagne en simplicité, en intuitivité et en rapidité. Lens met l'accent sur la flexibilité, la simplicité d'utilisation et les bonnes pratiques en matière de visualisation. Créer une visualisation devient un jeu d'enfants : il vous suffit de placer un champ de données dans une fenêtre par simple glisser-déposer. De plus, Lens intègre des suggestion intelligentes, qui vous offrent des façons inédites de visualiser vos données. Vous décidez finalement de changer de type de graphique ou de modèle d'indexation ? Aucun problème : quelques clics, et le tour est joué. Avec Lens, l'analyse des données dans Kibana n'a jamais été aussi simple et aussi passionnante. 

Cerise sur le gâteau : Kibana Lens est disponible gratuitement et fait partie de notre distribution par défaut. Lancé en version bêta dans la Suite Elastic 7.5, Lens est d'ores et déjà disponible dans Elasticsearch Service sur Elastic Cloud. Si vous préférez le télécharger, c'est par ici.

Un parcours visuel haut en couleur

À l'origine, Kibana avait été créé par des ingénieurs pour des ingénieurs. Tout est parti d'une interface utilisateur pour les développeurs Elasticsearch. Très vite, nos développeurs se sont mis à utiliser Kibana au lieu de la ligne de commande : bien plus pratique pour afficher et interroger les données Elasticsearch. Peu de temps après, nous avons ajouté des visualisations et des graphiques, ce qui permettait l'agrégation et l'affichage visuels des données. Kibana n'a pas tardé à être adopté par des clients comme Netflix, Uber et Walmart, et à s'imposer dans le domaine de la visualisation et de l'exploration des données. Au fil des ans, inspirés par notre communauté, nous n'avons cessé de proposer toujours plus de fonctionnalités de visualisation. Toute notre attention s'est alors tournée vers un défi qu'il nous fallait absolument relever : la visualisation de grands volumes de données à grande échelle.  

À mesure que se multipliaient les cas d'utilisation d'Elasticsearch et de Kibana, nous avons proposé notre produit à de nouveaux groupes d'utilisateurs : ingénieurs, développeurs, analystes, dirigeants et data scientists. Pour bon nombre d'entre eux, Kibana est devenu un outil du quotidien. Ce qui nous a amené à nous pencher sur un nouveau défi : simplifier l'utilisation de Kibana pour une audience plus large. 

Il y a deux ans environ, nous avons donc commencé à réfléchir à une solution qui mettrait l'exploration des données à la portée d'un plus grand nombre d'utilisateurs. Il nous fallait appliquer la connaissance que nous avions acquise pendant des années sur le terrain de la visualisation des données, mais aussi échanger avec les utilisateurs pour développer un produit innovant qui réponde réellement à leurs besoins. L'objectif de ce projet était de nous permettre d'aller plus loin, de diversifier les types de diagrammes pris en charge et d'associer en une seule visualisation les données provenant de différents modèles d'indexation, tout en assurant une expérience utilisateur irréprochable. 

Pendant un an, tandis que nous développions cette infrastructure complètement inédite, nous nous sommes penchés sur les défis auxquels étaient confrontés les utilisateurs en matière de visualisation des données et avons étudié les solutions existantes. Nous avons aussi interrogé des dizaines d'entreprises qui s'appuyaient sur Kibana et d'autres outils pour répondre à de nombreux cas d'utilisation. L'objectif ? Identifier comment elles exploitaient leurs données et connaître les défis qu'elles rencontraient. 

Tout cela a débouché sur Kibana Lens : une expérience utilisateur complètement inédite, qui allie simplicité et intuitivité, tout en permettant l'analyse ultraperformante d'énormes volumes de données en temps réel.

La famille s'agrandit avec Kibana Lens

Avec Lens, tout devient plus simple pour les utilisateurs de Kibana : ils peuvent explorer leurs données, basculer d'un diagramme et d'une fonction à l'autre, et ainsi lancer des analyses sur plusieurs dimensions. Grâce à une interface utilisateur simplifiée qui devient accessible à tous, il n'est plus nécessaire de maîtriser la terminologie complexe d'Elasticsearch. Pour découvrir de précieuses informations dans leurs données, les utilisateurs de Kibana n'ont plus qu'à déplacer des champs par glisser-déposer, à afficher un aperçu de leur visualisation, puis à exploiter les suggestions intelligentes fournies par Lens pour découvrir d'autres visualisations possibles et choisir celle qui leur convient.

Cela fait des années que les utilisateurs exploitent la Suite Elastic pour explorer les données. Forts de cette expérience, nous avons construit Lens autour de quatre concepts, qui pour être simples, n'en sont pas moins puissants.

Axé sur les données

Créer une visualisation implique de choisir les champs de données qu'on veut utiliser. Durant la phase de test, nous avons remarqué que les utilisateurs ne cessaient de basculer entre différents écrans, afin de sélectionner le champ qui répond à leurs questions. Ce n'est souvent pas chose aisée, car les utilisateurs qui analysent les données ne sont pas nécessairement ceux qui ont nommé les champs, créé les index ou encore les mappings. Dans Lens, grâce à la rapidité d'Elasticsearch, il suffit de sélectionner un champ pour afficher un aperçu de son contenu et découvrir rapidement son contexte. Ainsi, pour savoir si un champ donné répond à votre question, il suffit de jeter un œil à sa valeur. 

Aperçu immédiat

Rien de tel que des visualisations pour comprendre ses données. C'est d'ailleurs à cela qu'elles servent. Dites ainsi, les choses ont l'air simples. Mais en réalité, la visualisation est souvent plus complexe qu'il n'y paraît, notamment lorsqu'il s'agit de créer des visualisations pertinentes à partir d'énormes ensembles de données, afin de les synthétiser. 

Avec Lens, l'objectif est de faciliter aux utilisateurs la création de visualisations et de leur fournir des conseils généraux sur les meilleures approches. Ainsi, il suffit de placer un champ de données dans une fenêtre centrale par glisser-déposer pour générer un aperçu immédiat d'un diagramme. Exit la configuration, exit la sélection d'agrégations ou de fonctions : juste un champ à faire glisser. Et Lens se charge de visualiser vos données. 

Suggestions intelligentes

Nous avons aussi remarqué que des modèles communs se dessinaient dans la façon qu'ont les utilisateurs de visualiser leurs données, ainsi que certaines difficultés à le faire de manière efficace. Il s'agissait d'un point important, car ce sont les diagrammes utilisés pour présenter les données qui servent de base aux insights. Avec Lens, nous voulions associer les modèles d'utilisation couramment observés avec les bonnes pratiques en matière de visualisation. C'est pourquoi, dès le premier aperçu, Lens fournit des suggestions intelligentes, qui aident l'utilisateur à visualiser les données autrement, en fonction du champ qu'il a sélectionné. Ces suggestions s'appuient sur différents facteurs (type de champ, type de de diagramme et autres éléments communément utilisés), ainsi que sur un algorithme de classement, qui les trie selon leur probabilité de pertinence. Grâce à ces suggestions intelligentes, les utilisateurs parviennent souvent à répondre à des questions qui leur viennent à l'esprit après avoir affiché un diagramme, ou changent légèrement d'angle par rapport à la visualisation affichée. Chaque suggestion est accompagnée d'une description, ce qui permet aux utilisateurs de saisir rapidement ce qui la différencie de la visualisation en cours d'affichage. Les suggestions intelligentes sont un premier pas vers les recommandations personnalisées en fonction des données de l'utilisateur.

Ad-hoc et réutilisable

S'il peut arriver de savoir exactement le type de visualisation dont on a besoin, le plus souvent, on a une question en tête et la réponse se trouve dans les données, qu'il faut alors explorer. Pour répondre à des requêtes ad hoc, il faut avoir la possibilité de changer de point de vue – c'est-à-dire la possibilité de basculer d'un type de diagramme à un autre, de changer la source des données sous-jacentes d'un diagramme voire d'associer différents modèles d'indexation dans une seule visualisation. Avec Lens, vous avez la possibilité d'explorer plus librement vos données. Mieux encore : vous pouvez enregistrer les visualisations performantes et les réutiliser ultérieurement dans un tableau de bord.

Une foule de projets en stock

Dans Kibana, tout va très vite. Lorsqu'on regarde le chemin parcouru, notamment ces dernières années, tous ces progrès et toutes ces innovations sont frappantes. Nous continuons de lancer de nouvelles fonctionnalités et de répondre à de nouveaux cas d'utilisation à un rythme plus soutenu que jamais. Nous sommes convaincus qu'avec Kibana Lens, nous venons de faire un autre grand pas vers cette vision qui est la nôtre : permettre aux utilisateurs de découvrir dans leurs données des informations pertinentes grâce à des fonctionnalités ultraperformantes, tout en leur proposant une expérience simplissime. Nous sommes profondément reconnaissants envers les membres de notre communauté qui ne cessent de nous communiquer leurs demandes et qui nous poussent à améliorer nos produits, tout comme les nombreux utilisateurs qui nous font part de leurs commentaires au sujet de Lens. 

La société Harel Insurance Investments and Financial Services Ltd., qui exploite Kibana pour visualiser et explorer ses données opérationnelles, métier, marketing, et de sécurité, s'est montrée enthousiaste face aux nouvelles possibilités offertes par Kibana Lens. "Chez Harel, nous donnons la priorité à nos clients. Et cela implique de leur garantir une expérience positive lorsqu'ils interagissent avec nos services digitaux. Les solutions d'Elastic nous aident à atteindre cet objectif. Non seulement, elles nous offrent un emplacement centralisé pour le stockage et l'analyse des données relatives à nos processus stratégiques, mais avec des produits comme Kibana, nos business analysts peuvent interroger et visualiser les données pour y détecter des insights essentielles", déclare Niv Raz, directeur technique d'Harel . "Avec le lancement de Lens, nous sommes ravis de mettre entre les mains de nos collaborateurs toute la puissance de l'analyse par simple glisser-déposer, des aperçus immédiats des données, et des bonnes pratiques de visualisation qui sont automatiquement générées. Tout cela permettra d'accélérer l'exploitation des données pour mieux répondre aux besoins des clients". 

Lens marque une étape importante du parcours d'Elastic, et nous sommes impatients de continuer à développer ce produit et à le faire progresser. Parmi les grandes priorités de notre roadmap, nous prévoyons la prise en charge d'un plus grand nombre de diagrammes, l'ajout de nouvelles fonctions et de suggestions encore plus intelligentes, ou encore une personnalisation plus poussée. Nous prévoyons aussi d'itérer rapidement, tout en continuant de repousser les limites de la visualisation des données, pour proposer une solution aussi simple que performante.

Lancez-vous avec Lens

Envie de vous lancer ? Déployez un cluster sur Elasticsearch Service ou installez la dernière version de la Suite Elastic. Vous exécutez déjà Kibana ? Il vous suffit de mettre vos clusters à niveau vers la version 7.5, et Kibana Lens est à vous.

Lens est disponible via l'application Visualize de Kibana. Une fois que vous avez créé et enregistré une visualisation avec Lens, vous pouvez l'ajouter à un tableau de bord comme n'importe quelle autre visualisation.

Se lancer n'est pas sorcier, mais c'est encore plus simple avec les bonnes ressources :

• Présentation vidéo
• Documentation
• Nous proposons aussi des webinars Kibana Lens : n'hésitez pas à vous inscrire

Nous sommes ravis d'annoncer la disponibilité générale de la Suite Elastic 7.5. Outre le lancement de Kibana Lens, qui accélère la création de visualisations et la rend plus intuitive, cette version 7.5 propose des améliorations majeures du côté de nos solutions Observability et Security, et intègre Elastic Enterprise Search.

Nous vous proposons de découvrir ici les grandes nouveautés et vous invitons à consulter les blogs de lancement consacrés à chaque produit pour en savoir plus. 

Lancement de Kibana Lens : la visualisation des données complètement revisitée

Kibana est (et a toujours été) le meilleur moyen de visualiser les données stockées dans Elasticsearch et de naviguer dans la Suite Elastic. Avec la version 7.5, nous lançons Kibana Lens : la création de visualisations est complètement repensée. Lens est conçu pour vous permettre de travailler aussi vite et aussi naturellement que vous pensez : il vous permet de transformer rapidement vos données brutes en visualisations pertinentes, sans nécessiter d'expérience technique, ni de connaissance d'Elasticsearch. Pour commencer, Lens métamorphose l'expérience du glisser-déposer, et vous permet de basculer facilement entre les types de graphiques et les différents modèles d'index. À mesure que vous ajoutez des champs à votre graphique, Lens vous propose des suggestions intelligentes, qui vous permettent d'afficher d'autres vues de vos données. Associé à la rapidité d'Elasticsearch, Lens accélère et facilite comme jamais la visualisation, l'exploration et la compréhension des données.

Envie d'en savoir plus ? L'article de blog consacré au lancement de Lens vous dit tout. Vous pouvez aussi consulter l'article que nous consacrons à Kibana pour découvrir toutes les autres fonctionnalités de Kibana 7.5.

L'enrichissement au moment de l'indexation dans Elasticsearch fait le plein de fonctionnalités

Il y a longtemps, dans Elasticsearch 5.0, nous avions lancé le pipeline d'ingestion, qui permettait de traiter et d'enrichir les documents au moment de l'indexation. Directement intégré à Elasticsearch, il facilitait la montée en charge et la configuration via une API, tout en accélérant les performances. Au fil des ans, cette fonctionnalité a rencontré un franc succès, et nous l'utilisons pour le traitement et l'enrichissement dans quasiment tous nos modules (c'est-à-dire les nombreuses sources de données que nous prenons en charge nativement). Qu'il s'agisse d'analyser une ligne de log avec Grok ou dissect, ou d'ajouter des données géographiques à une adresse IP, dans la Suite Elastic, les pipelines d'ingestion assurent de plus en plus le gros du traitement au moment de l'ingestion. Avec cette version 7.5, nous sommes ravis de lancer l'une des fonctionnalités les plus demandées. J'ai nommé : l'enrichissement basé sur la recherche. Avec le nouveau processeur Enrich, vous disposez d'un moyen efficace d'interroger un index Elasticsearch et d'ajouter les résultats à votre document au moment de l'indexer. Cela vous permet d'identifier des services web ou des fournisseurs en fonction d'adresses IP connues, d'ajouter des codes postaux en fonction des coordonnées de l'utilisateur, ou encore de rechercher des informations sur l'hôte, ingérées depuis une base de données de gestion de la configuration, puis d'ajouter les métadonnées pertinentes à votre document juste au moment de l'indexer. Et ce ne sont là que quelques exemples de ce vous pouvez faire. 

Pour en savoir plus sur le processeur Enrich et découvrir toutes les nouvelles fonctionnalités Elasticsearch de la version 7.5, n'hésitez pas à consulter l'article de blog consacré à Elasticsearch.

La Suite Elastic héberge aussi nos propres solutions : des applications tout spécialement conçues pour répondre à nos cas d'utilisation les plus courants. Voyons maintenant les principales nouveautés d'Observability, Security, et Enterprise Search. 

Elastic Enterprise Search

Elastic Enterprise Search est conçu pour connecter les collaborateurs et les équipes au contenu dont ils ont le plus besoin pour mener à bien leurs activités. Pour les entreprises qui ont investi dans des produits Microsoft, Elastic Enterprise Search propose maintenant des intégrations en un clic avec SharePoint Online, Office 365 et OneDrive. L'unification et l'interrogation des plateformes devient plus simple que jamais. Et ce n'est pas tout : Enterprise Search intègre aussi un tout nouveau connecteur ServiceNow, qui vous permet de centraliser en un seul et même emplacement toutes les informations relatives aux opérations métier. Avec ces nouvelles sources, qui viennent s'ajouter à celles que nous proposions déjà – à savoir, Salesforce, Google Drive, Atlassian JIRA, Confluence ou encore Dropbox, par exemple – votre équipe peut maintenant entièrement se consacrer aux tâches qui lui sont confiées.

Autre grande nouveauté : Elastic Enterprise Search fait désormais partie de la Suite Elastic. Nous en sommes aujourd'hui à la version 7.5.0, que nous vous proposons toujours en bêta pour le moment. Pour en savoir plus sur les nouveautés d'Enterprise Search, consultez l'article de blog qui lui est consacré.

Elastic Observability

Chez Elastic, nous sommes convaincus d'une chose : pour bien comprendre vos applications et votre infrastructure, vous devez être en mesure de "voir", autrement dit, d'observer, chaque couche du système. La famille s'agrandit donc avec Elastic Observability, qui regroupe désormais nos produits Elastic Logs, Metrics, APM et Uptime, afin de vous offrir une vision plus complète et plus globale d'un bout à l'autre de l'entreprise. Par ailleurs, la version 7.5 de la Suite Elastic Stack donne un grand coup d'accélérateur à Elastic Metrics et propose aux entreprises qui adoptent des initiatives d'observabilité plusieurs intégrations stratégiques entre les données APM, de logging et de sécurité. 

Côté indicateurs, rappelons que nous avions déjà mis les bouchées doubles dans les dernières versions, avec le lancement de Metrics Explorer, une interface utilisateur spécialement conçue pour l'analyse en temps réel. Nous vous avions aussi facilité la prise en main de Metrics, grâce à l'intégration des données pour les indicateurs de services et d'infrastructures incontournables, comme Kubernetes, Prometheus, ou encore Amazon Web Services (AWS). Le tout, prêt à utiliser. Et avec la version 7.5, nous ne nous arrêtons pas là : dans le cadre de notre partenariat avec Microsoft, nous lançons aujourd'hui le monitoring clés en main des logs et indicateurs Microsoft Azure. Enfin, pour la première fois, il devient possible d'afficher directement les données Endpoint Security dans les applications Elastic Metrics et Elastic Logs. Résultat de toutes ces avancées ? Elles accélèrent la configuration du monitoring des services critiques pour les utilisateurs de la Suite Elastic, qui peuvent en outre associer plus efficacement leurs indicateurs avec des événements importants, comme les logs d'audit provenant des périphériques des points de terminaison. 

Pour en savoir plus, n'hésitez pas à consulter l'article de blog consacré à Observability.

Elastic Security

Pour les équipes en charge de la sécurité de l'entreprise, utiliser la Suite Elastic n'a jamais été aussi passionnant. Depuis la dernière version, nous avons uni nos forces avec Endgame, un leader de la sécurité des points de terminaison. C'était aussi l'occasion d'annoncer la fin de la tarification par point de terminaison pour les EPP (plateformes de protection des points de terminaison) et l'EDR (détection et réponse sur les points de terminaison). Sans oublier que les abonnements Enterprise comprennent maintenant la protection d'un nombre illimité de points de terminaison : vous n'avez plus à choisir quelles machines méritent d'être protégées. Sur le front des serveurs, si vous collectez déjà des données de sécurité et des données opérationnelles, pourquoi ne pas les protéger du même coup ? D'ailleurs, pourquoi s'arrêter aux serveurs ? Les analystes de la sécurité doivent pouvoir accéder aux événements de sécurité de toute votre infrastructure – ordinateurs de bureau et ordinateurs portables compris. C'est pourquoi la version 7.5 d'Elastic SIEM intègre désormais les données et les alertes d'Endpoint Security directement dans l'application SIEM. 

Côté détection des menaces via Machine Learning, la version 7.5 d'Elastic SIEM continue sur sa lancée. Elle vous permet maintenant d'identifier des modèles inhabituels dans l'activité DNS, qui sont potentiellement synonymes de tunnels DNS ou de comportements de commande et de contrôle ; des connexions inhabituelles via RDP ; ou encore l'utilisation de la commande runas. Et ce ne sont là que quelques exemples de tout ce que vous pouvez maintenant détecter. Nous avons aussi étendu les fonctionnalités de l'application SIEM elle-même, qui propose désormais de nouvelles visualisations et de nouveaux widgets qui vous facilitent la recherche des menaces : visualisations interactives de l'activité de l'hôte, nouvel affichage TLS permettant de détecter les certificats inhabituels, mais aussi de simplifier la recherche des menaces grâce aux empreintes digitales TLS, telles que le hachage JA3. 

Curieux de savoir comment nous envisageons Elastic SIEM et Elastic Endpoint Security ? Cette vidéo de lancement vous dit tout. Et pour tout savoir sur les nouveautés de la version 7.5, consultez l'article de blog consacré à Security. 

Et ce n'est pas tout...

Loin de là. N'hésitez donc pas à consulter les articles de blog que nous consacrons à chaque produit pour découvrir toutes les nouveautés de la version 7.5 :

La Suite Elastic

• Lancement d'Elasticsearch 7.5.0
• Lancement de Kibana 7.5.0
• Lancement de Beats 7.5.0
• Lancement de Logstash 7.5.0

Solutions

• Lancement d'Elastic Enterprise Search 7.5.0
• Lancement d'Elastic Observability 7.5.0
• Lancement d'Elastic Security 7.5.0

Il y a quelques mois, nous avions rendue publique la version bêta d'Elasticsearch Service sur Microsoft Azure, avec toutes ses fonctionnalités. Nous avons aujourd'hui le plaisir d'annoncer que l'offre Elasticsearch Service sur Microsoft Azure passe en disponibilité générale. Si vous utilisez déjà Elasticsearch Service, il vous suffit de vous connecter pour lancer des déploiements sur Azure via votre compte existant. Si vous n'avez pas encore de compte, vous pouvez commencer par essayer Elasticsearch Service gratuitement pendant 14 jours.

La collaboration entre Elastic et Microsoft passe à la vitesse supérieure

Pendant la période de lancement en version bêta publique, nos clients communs avaient rapidement adopté Elasticsearch Service sur Azure. Exposé à un très grand nombre de charges de travail, que ce soit en production ou non, ce service s'est avéré aussi performant que fiable – ce qui a encouragé Elastic et Microsoft à annoncer sa disponibilité générale.

Elasticsearch Service sur Azure n'est qu'un exemple de tout ce que nous entreprenons pour doper l'expérience des utilisateurs d'Elastic et de Microsoft. Ceux qui préfèrent les déploiements autogérés de la Suite Elastic passent ainsi par la Marketplace Azure pour accéder à notre modèle ARM de la Suite Elastic (lancé conjointement il y a plusieurs années déjà). Mais la prise en charge des technologies Microsoft ne s'arrête pas au cloud. Citons par exemple nos clients .NET, Winlogbeat pour la collecte d'événements du système d'exploitation Windows, l'intégration d'Azure Active Directory pour sécuriser les clusters Elasticsearch, ou encore la compatibilité de notre produit Elastic APM avec .NET. Pour les utilisateurs d'Elastic et de Microsoft, il est essentiel que nos portefeuilles technologiques fonctionnent de manière homogène et offrent de nouvelles occasions d'innover.

"Notre collaboration avec Microsoft a créé une dynamique qui continue sur sa lancée", affirme Craig Griffin, vice-président du développement commercial d'Elastic. "Proposer les solutions Elastic sur Azure est devenu une priorité, car nous avons constaté que cela suscitait un très grand intérêt chez les utilisateurs."

Elasticsearch + Azure = toutes les fonctionnalités que vous aimez

Elasticsearch Service sur Elastic Cloud ? C'est l'offre hébergée officielle Elasticsearch et Kibana. Créée par Elastic, elle bénéficie aussi de son support technique. Elle n'intègre pas seulement des solutions comme Elastic App Search, Elastic APM, Elastic SIEM et Elastic Maps. Elle vous donne aussi accès au savoir-faire d'Elastic via nos équipes de SRE (ingénierie de la fiabilité des sites), notre support technique et nos services de consulting. Résultat, vous pouvez déployer les yeux fermés sur Azure : vous disposez systématiquement des versions logicielles et des correctifs de sécurité Elastic les plus récents. Les mises à niveau se font en un clic, sans aucune interruption.

Depuis la publication de la version bêta publique, nous avons lancé de nouvelles régions Azure à Washington et Singapour, et nous sommes armés pour en proposer bien d'autres dans le monde entier, grâce à un plan audacieux. Dans la version 7.5 de la Suite Elastic, nos agents Beats ont évolué, pour ingérer des logs et des indicateurs directement depuis Azure Monitor et Azure Event Hub, puis les afficher dans des tableaux de bord Kibana prédéfinis. Nous avons aussi publié de nouveaux modèles de déploiement Elasticsearch Service s'exécutant sur Azure, par exemple, nos modèles de déploiement hot-warm et de recherche inter-clusters.

Et pour ne rien vous cacher, nous nous réjouissons déjà de l'arrivée prochaine d'Elastic App Search sur Elasticsearch Service, qui devrait être disponible dans toutes les régions Azure prises en charge dès son lancement.

Une dynamique qui profite aux clients

"Avec nos milliers de machines, il nous fallait une technologie basée sur Azure pour diffuser leurs flux de données et les transformer en informations pertinentes et exploitables. Celles-ci, à leur tour, devaient nous permettre de contrôler les machines à distance, de développer des modèles prédictifs, de fournir de précieuses informations à nos techniciens et à nos clients, et de préconiser des actions", explique le Dr.  Haroon Abbu, vice-président du pôle Analytics Practice & Data Services chez Bell and Howell.

"Grâce à Elasticsearch, nous avons pu dire adieu à nos laborieux processus manuels de traitement par lots, et avec Elasticsearch Service sur Azure, nous pouvons exécuter et gérer tout cela de manière homogène, tout en continuant d'utiliser le fournisseur cloud sur lequel repose notre système. Nous disposons maintenant d'une plateforme gérée qui nous permet d'observer les données depuis différents systèmes. Nous sommes ainsi bien mieux équipés pour offrir un service client de qualité, nos équipes techniques et DevOps sont plus productives, et la disponibilité des systèmes s'est aussi améliorée grâce à la maintenance prédictive et aux informations normatives en temps réel."

Offre promotionnelle sur le transfert et le stockage de données

Nous vous offrons gratuitement le transfert et le stockage des données pour une période limitée. C'est le moment de déployer sur Azure : cette offre promotionnelle est ponctuelle. Pour y participer, il vous suffit de créer des déploiements Azure via votre compte Elastic Cloud existant. Et si vous êtes un nouvel utilisateur, vous pouvez essayer Elasticsearch Service gratuitement pendant 14 jours.