Avec la Suite Elastic 7.2, l'observabilité devient encore plus simple. Découvrez des nouveautés et des améliorations comme les indicateurs spécifiques aux

<p>Chez Elastic, nous sommes toujours enthousiastes quand il s'agit d'améliorer les outils qu'utilisent les opérateurs pour assurer la disponibilité, l'intégrité et la rapidité de leurs applications et services. C'est ce que nous appelons l'observabilité. Et vous&nbsp;? Cet article vous en dira plus.
</p>
<p>Vous l'attendiez impatiemment, il est là&nbsp;! L'agent&nbsp;.NET est désormais pris en charge par Elastic&nbsp;APM et disponible en version bêta. Sur le front du monitoring de l'infrastructure, voici Metrics&nbsp;Explorer, une nouvelle façon d'explorer les données dans l'application Infrastructure de Kibana, avec, à la clé, une nette amélioration des interactions ad&nbsp;hoc avec les indicateurs d'infrastructure. Du nouveau aussi du côté du monitoring Kubernetes&nbsp;: la version&nbsp;7.2 propose un plus grand éventail d'outils, mais aussi de nouvelles intégrations de données pour les technologies cloud-native, comme CoreDNS et CRI-O.
</p>
<p>Impatient d'essayer&nbsp;? La version&nbsp;7.2 est disponible via <a href="/fr/cloud/elasticsearch-service">Elasticsearch&nbsp;Service</a>&nbsp;– la seule offre Elasticsearch hébergée à proposer ces nouvelles fonctionnalités. Et si vous préférez <a href="/fr/downloads">télécharger la dernière version de la Suite&nbsp;Elastic, c'est par ici</a>.
</p>
<h2>L'observabilité vue par Elastic</h2>
<p>Qu'est-ce que l'observabilité&nbsp;? C'est une approche qui donne la priorité à une visibilité unifiée sur l'intégrité des systèmes, des services et des applications. Bien que ce terme ait récemment fait son apparition dans le secteur, il nous éclaire sur les raisons qui amènent bon nombre d'équipes et d'utilisateurs à miser sur la Suite&nbsp;Elastic pour répondre à leurs besoins opérationnels. Comme son nom l'indique, Elasticsearch est flexible par nature. <em>Chaque élément y est un index</em>. Résultat, les utilisateurs sont en mesure de regrouper dans un seul et même datastore opérationnel les logs, les indicateurs, les traces et les indicateurs de disponibilité qui étaient jusque-là des sources de données hétérogènes.
</p>
<p>
	<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt6082737bba8cc593/5d0416aa0b20e952523c959c/elastic-observability-devops.png" data-sys-asset-uid="blt6082737bba8cc593" alt="Avec la Suite&nbsp;Elastic, unifiez tous vos logs d'infrastructure, vos indicateurs, vos données de disponibilité et vos traces&nbsp;APM" data-image="wvo4blfyqzu1" style="display: block; margin: auto;">
</p>
<p>En matière d'observabilité, nous avons adopté une double stratégie&nbsp;: continuer d'assurer une expérience irréprochable pour chaque "pilier" de l'observabilité, tout en veillant à ce que l'utilisateur puisse regrouper ces flux de données de manière plus naturelle et plus fluide. C'est pourquoi toutes les données d'observabilité sont conformes à Elastic Common&nbsp;Schema (ECS) et toutes les applications Kibana sont intégrées pour assurer une navigation et des workflows de mise en corrélation des données en un clic.
</p>
<p><img data-image="vav8bcqlcf3y" src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt368c68953bf815de/5d0a9a65877575d0584775e5/elastic-observability-containers.gif" data-sys-asset-uid="blt368c68953bf815de" alt="La Suite&nbsp;Elastic&nbsp;: l'observabilité en action" "="">
</p>
<p>"Red Wing Shoes, fabricant emblématique de chaussures de sécurité, s’appuie sur le déploiement hébergé <a href="/fr/products/elasticsearch/service">d’Elasticsearch Service</a> sur Elastic Cloud pour obtenir une visibilité unifiée sur le processus de fabrication en atelier, sur la santé de son site web d’e-commerce et sur ses opérations dans plus de 600 points de vente autour du monde. L’équipe en charge des opérations pilote également le déploiement de nouvelles applications et de nouveaux services visant à développer les activités. "Nous parvenons à tout mener de front avec une équipe réduite car nous faisons en sorte de rendre nos opérations informatiques efficaces", déclare Marc Kermisch, vice-président et directeur de l’information. "Le fait de voir toutes les données opérationnelles pertinentes dans un seul datastore et dans une interface utilisateur unique nous a aidés à gagner en efficacité au niveau du tri et de la résolution des problèmes avec des données exploitables. Et le fait que la suite soit entièrement gérée pour nous dans Elastic Cloud fait que nous ne nous encombrons pas de procédures administratives : l’ensemble du déploiement, de la montée en charge et des mises à niveau de la Suite Elastic se font en un clic."
</p>
<p>Découvrez comment nous voyons cette importante tendance dans cet article de blog&nbsp;: <a href="/fr/blog/observability-with-the-elastic-stack">La Suite&nbsp;Elastic et l'observabilité</a>.
</p>
<p>Dans la version&nbsp;7.2, nous continuons d'étendre et d'enrichir nos initiatives dédiées à l'observabilité. Voyons les améliorations produit que nous avons apportées.
</p>
<h2>Elastic&nbsp;APM&nbsp;: compatibilité .NET, applications web monopage et indicateurs spécifiques aux agents</h2>
<p>Nous adorons vous annoncer de bonnes nouvelles. En voici une de taille&nbsp;: l'agent Elastic&nbsp;APM pour .NET, jusqu'ici disponible en <a href="/fr/blog/elastic-apm-dot-net-agent-preview-released">préversion</a>, passe en bêta. L'agent&nbsp;.NET intègre l'<a href="/guide/en/apm/agent/dotnet/current/index.html">instrumentation</a> automatique pour ASP.NET Core&nbsp;2.x+ et Entity&nbsp;Framework Core&nbsp;2.x+, mais il propose aussi une&nbsp;<a href="/guide/en/apm/agent/dotnet/current/public-api.html">API&nbsp;publique</a>&nbsp;qui vous permet d'instrumenter manuellement n'importe quelle application&nbsp;.NET utilisant nos frameworks.
</p>
<p>Vous avez été très nombreux à demander la compatibilité .NET dans Elastic&nbsp;APM. Inutile de vous dire comme nous sommes heureux d'avoir enrichi notre tour de Babel de langages. Nous tenons d'ailleurs à remercier les membre de notre communauté qui ont pris le temps de répondre à notre <a href="https://docs.google.com/forms/d/e/1FAIpQLSfBjUbv9qjcwNFSXpjJT_PmGJn0kpuF1IdZDtnBl0MLNRbYbQ/viewform">enquête</a> pour nous donner leur avis sur la préversion et nous aider à prioriser les langages demandés.
</p>
<p>Autre nouveauté, l'agent RUM (Real User&nbsp;Monitoring) d'Elastic&nbsp;APM accepte désormais les applications web monopage (SPA), ce qui permet aux utilisateurs de capturer les transactions relatives à des changements d'itinéraire, outre celles relatives aux chargements de page. Comparées aux applications multipages (MPA), les SPA, ou applications web monopage, présentent de nombreux avantages, notamment, une rationalisation de l'expérience utilisateur et une accélération des temps de chargement, grâce au rendu dynamique des éléments de données à mesure que l'internaute navigue sur la page. Ce fonctionnement dynamique nécessite une évaluation plus nuancée de l'expérience utilisateur, comme l'examen des changements d'itinéraire internes de l'application.
</p>
<p>De plus, les agents APM collectent maintenant les indicateurs spécifiques au langage, outre les indicateurs clés de performance (utilisation globale des ressources, par exemple) liés aux données de trace APM. Par exemple, l'agent Java collecte désormais les indicateurs JVM tels que la mémoire Java et le nombre de threads, qui s'affichent automatiquement dans l'application APM. Ces indicateurs spécifiques aux agents enrichissent le monitoring. En effet, ils fournissent davantage de contexte sur le comportement de l'application sans nécessiter l'ajout d'agents supplémentaires.
</p>
<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt5151674c453e2ec8/5d01990fc06daee314d200a4/elastic-observability-metrics.jpg" data-sys-asset-uid="blt5151674c453e2ec8" alt="Indicateurs spécifiques au langage" "="">
</p>
<p>APM vous réserve de belles surprises. Cet <a href="/fr/blog/elastic-apm-7-2-0-released">article de blog consacré au lancement d'Elastic&nbsp;APM</a> vous dit tout.
</p>
<h2>Avec Metrics&nbsp;Explorer, l'exploration des indicateurs d'infrastructure passe à la vitesse supérieure</h2>
<p>Ces dernières années, l'équipe d'ingénierie de la Suite&nbsp;Elastic n'a eu de cesse d'étendre la prise en charge des indicateurs. Meilleure efficacité du stockage grâce à de nouveaux formats de données comme les arborescences Bkd, qui sont optimisées pour les données numériques&nbsp;; plus grand choix d'intégrations de données pour les indicateurs avec les modules Metricbeat&nbsp;; ou encore amélioration des fonctionnalités de visualisation des séries temporelles via les applications dédiées de Kibana, comme Time&nbsp;Series Visual&nbsp;Builder... Voilà quelques exemples de notre engagement continu dans ce domaine.
</p>
<p>Il avait fait un tabac. Dans la version&nbsp;7.2, nous rejouons la carte de l'exploration ad&nbsp;hoc des indicateurs et allons encore plus loin, avec l'intégration de Metrics&nbsp;Explorer dans l'application Elastic&nbsp;Infrastructure. Vous disposez ainsi d'une interface utilisateur qui vous permet de parcourir les indicateurs d'infrastructure les plus importants et d'interagir avec eux grâce à des balises courantes et des groupements de graphiques. Vous pouvez ouvrir les graphiques Metrics&nbsp;Explorer dans Time&nbsp;Series Visual&nbsp;Builder pour les examiner de plus près. Parcourir les indicateurs en un clic tout en capitalisant sur la puissance des agrégations Elasticsearch, avouons que c'est un duo gagnant. Et bien sûr, quels que soient le nombre et la cardinalité de vos balises et de vos dimensions, la rapidité de toute cette exploration est absolument époustouflante.&nbsp;
</p>
<p><img data-image="ah8ondecltp5" src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltaa9753682c89f6e9/5d0a9a485fe8e2af5a55ae2e/elastic-observability-metrics-explorer.gif" data-sys-asset-uid="bltaa9753682c89f6e9" alt="Metrics&nbsp;Explorer dans Kibana&nbsp;7.2" "="">
</p>
<p>Metrics&nbsp;Explorer est actuellement disponible en version bêta. N'hésitez pas à nous dire ce que vous en pensez sur le <a href="https://discuss.elastic.co/c/infrastructure">forum de discussion</a>.&nbsp;Envie d'en savoir plus sur les autres améliorations&nbsp;? Consultez cet <a href="/fr/blog/elastic-infrastructure-7-2-0-released">article de blog consacré au lancement d'Elastic&nbsp;Infrastructure</a>.
</p>
<h2>Elastic renforce l'observabilité Kubernetes</h2>
<p>Propulsé par l'innovation open&nbsp;source qui fleurit un peu partout, l'écosystème Kubernetes évolue à pas de géant. Chaque mois, de nouveaux projets viennent s'ajouter à l'écosystème de la Cloud&nbsp;Native Computing Foundation (CNCF) et passent au niveau Graduated avec une rapidité déconcertante.
</p>
<p>Elastic s'engage à soutenir les équipes qui migrent vers Kubernetes, y compris lorsqu'il s'agit du monitoring de cette pile technologique dynamique. Par exemple, des fonctionnalités comme Autodiscovery dans Filebeat et Metricbeat, ou encore les modules destinés à des technologies cloud-native comme <a href="/fr/blog/elasticsearch-observability-embracing-prometheus-and-openmetrics-standards-for-metrics">Prometheus</a>, vous simplifient considérablement le monitoring de l'infrastructure Kubernetes et des services qui y sont exécutés.
</p>
<p>La version&nbsp;7.2 capitalise sur tout cela et propose un certain nombre de nouvelles intégrations conçues pour les technologies cloud-native. Filebeat et Metricbeat, quant à eux, acceptent désormais CoreDNS, le DNS de cluster par défaut de Kubernetes, qui est récemment passé au niveau Graduated à la CNCF. En étroite collaboration avec notre communauté, nous étendons aussi la <a href="/fr/blog/monitoring-nats-messaging-system-with-elastic-beats">prise en charge du système de messagerie NATS</a>, un système cloud-native en open&nbsp;source.
</p>
<p>Sans oublier CRI-O (projet open&nbsp;source de conteneur runtime pour Kubernetes), maintenant pris en charge par Filebeat&nbsp;7.2. Développée par Red&nbsp;Hat, cette alternative à Docker, plus légère, est déjà devenue le conteneur runtime par défaut dans la célèbre distribution Openshift. Avec le module CRI-O, les utilisateurs de Kubernetes peuvent choisir CRI-O comme conteneur runtime et basculer vers celui-ci sans compromis en matière de monitoring.
</p>
<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltb62e24736c6384d5/5d019984ea19705f1784b04f/elastic-observability-kubernetes.jpg" data-sys-asset-uid="bltb62e24736c6384d5" alt="L'observabilité Kubernetes avec la Suite&nbsp;Elastic" "="">
</p>
<p>Pour en savoir plus sur les intégrations de données Kubernetes et sur leurs avantages, consultez ces articles de blog dédiés au lancement d'<a href="/fr/blog/elastic-infrastructure-7-2-0-released">Elastic&nbsp;Infrastructure</a> et d'<a href="/fr/blog/elastic-logs-7-2-0-released">Elastic&nbsp;Logs</a>.
</p>
<h2>Et ce n'est pas tout&nbsp;!</h2>
<p>Elastic&nbsp;Uptime, introduit il y a peu pour assurer une expérience simplissime du monitoring actif de la disponibilité, propose désormais des intégrations en un clic avec les applications Elastic&nbsp;Logs, Infrastructure et APM. L'intégration du monitoring actif dans vos workflows d'observabilité et d'analyse des logs devient ainsi bien plus simple. Notre <a href="/fr/blog/elastic-uptime-monitoring-7-2-0-released">article de blog consacré au lancement d'Elastic&nbsp;Uptime</a> vous dit tout sur ces améliorations et bien d'autres.
</p>
<p>Lancée dans la version&nbsp;6.5 pour rationaliser le traitement des données de logs, l'application Elastic&nbsp;Logs, quant à elle, prend cette fois en charge les événements et les logs structurés grâce à la configuration explicite des colonnes. Elle signe aussi l'arrivée d'une fonctionnalité de filtrage par champ qui permet à son tour l'affichage des logs voisins, ce qui s'avère souvent utile pour l'analyse dans les cas d'utilisation de logging. Pour tout savoir sur ces fonctionnalités, n'hésitez pas à consulter notre <a href="/fr/blog/elastic-logs-7-2-0-released">article de blog consacré au lancement d'Elastic&nbsp;Logs</a>.
</p>
<h2>À vous de jouer</h2>
<p>Le moyen le plus simple d'essayer ces nouvelles fonctionnalités est de déployer un cluster <a href="/fr/cloud/elasticsearch-service">Elasticsearch&nbsp;Service</a> sur Elastic&nbsp;Cloud. Les dernières versions de la Suite&nbsp;Elastic y sont disponibles le jour du lancement. Et si vous ne vous voyez plus vivre sans votre cluster, gardez-le&nbsp;! Nous nous chargeons de l'exécuter, de le faire évoluer et de le mettre à niveau pour vous. Vous préférez l'exécuter vous-même&nbsp;? Nos <a href="/fr/downloads">options autogérées</a> sont peut-être faites pour vous&nbsp;: découvrez comment télécharger des binaires, exécuter des conteneurs Docker et déployer la Suite&nbsp;Elastic sur Kubernetes.
</p>

blog-generic-teal-banner.png

elastic-observability-7-2-0-thumb.jpg

Observability updates: .NET in APM, Kubernetes monitoring, Metrics Explorer

Du nouveau du côté de l'observabilité : .NET dans APM, monitoring Kubernetes, Metrics Explorer

À la manière d'un cuisinier qui prépare avec soin ses plats pour de meilleurs résultats, vous pouvez accélérer vos recherches et vos analyses en prenant

schema-banner.jpg

schema-read-write-thumb.jpg

Schema on write vs. schema on read

Schéma d'écriture vs schéma de lecture

Alors comme ça, vous avez besoin de mettre les logs, les indicateurs et les traces en corrélation ? Aucun problème. Avec la Suite Elastic, la gestion des trois

<p>Je suis responsable de produit pour l’observabilité chez Elastic. En général, quand j’emploie le terme «&nbsp;observabilité&nbsp;», j’obtiens différentes réactions. La plus courante, c’est qu’on me demande ce qu’est l’observabilité. Néanmoins, j’entends de plus en plus de gens me répondre qu’ils viennent de mettre en place une initiative d’observabilité, mais qu’ils ne savent pas exactement comment procéder. Enfin, j’ai eu aussi le plaisir de travailler avec des organisations pour qui l’observabilité fait partie intégrante de leur façon de concevoir et de fabriquer leurs produits et services.
</p>
<p>Étant donné que ce concept prend de plus en plus d’ampleur, je me suis dit qu’il serait utile d’expliquer comment nous concevons l’observabilité chez Elastic, ce que nous avons appris de nos clients avant-gardistes, et comment nous l’envisageons du point de vue du produit lorsque nous faisons évoluer notre suite avec de nouveaux cas d'utilisation opérationnels.
</p>
<h2>L’observabilité, qu’est-ce que c’est&nbsp;?</h2>
<p>Ce n’est pas nous qui avons inventé le terme «&nbsp;observabilité&nbsp;». Nous avons commencé à l’entendre dans la bouche de nos clients, principalement de ceux exerçant dans l’ingénierie de fiabilité des sites (SRE). D’après plusieurs sources, ce terme aurait été utilisé pour la première fois par des géants SRE de la Silicon Valley, comme <a href="https://blog.twitter.com/engineering/en_us/a/2013/observability-at-twitter.html">Twitter</a>. Et même si le <a href="https://landing.google.com/sre/books/">livre précurseur de Google sur la SRE</a> ne mentionne pas ce terme, il établit bon nombre de principes associés à l’observabilité aujourd’hui.
</p>
<p>L’observabilité n’est pas un composant qu’on livre dans un paquet. C’est un attribut d’un système que vous construisez, au même titre que la facilité d’utilisation, la haute disponibilité et la stabilité. Lorsqu’on conçoit et qu’on fabrique un système «&nbsp;observable&nbsp;», l’objectif est de s’assurer que, lorsqu’il est mis en production, les opérateurs soient capables de détecter les comportements indésirables (p.&nbsp;ex. indisponibilité du service, erreurs, réponses lentes) et qu’ils disposent d’informations exploitables pour déterminer la cause du problème avec efficacité (p.&nbsp;ex. logs d’événements détaillés, informations granulaires sur l’utilisation des ressources, traces d’applications). Seulement, les entreprises se retrouvent parfois confrontées à des obstacles courants qui les empêchent d’atteindre cet objectif, parmi lesquels le manque d’informations, l’excédent d’informations non converties en renseignements exploitables, ou encore la fragmentation de l’accès à ces informations.
</p>
<p>Le premier aspect que nous avons cité, à savoir la détection des comportements indésirables, démarre généralement par la configuration <a href="https://landing.google.com/sre/sre-book/chapters/service-level-objectives/">d’indicateurs et d’objectifs de niveau de service.</a> Il s’agit de mesures de réussite mises en place en interne qui permettent de jauger les systèmes de production. Si une obligation contractuelle impose de respecter ces indicateurs et objectifs de niveau de service, un accord de niveau de service est alors mis en place. Parmi les exemples courants d’indicateurs de niveau de service, citons la <em>disponibilité d’un système</em>, pour laquelle vous pouvez définir un objectif de niveau de service de 99,999&nbsp;%. La disponibilité d’un système représente aussi l’accord de niveau de service que l’on présente le plus souvent aux clients externes. Néanmoins, en interne, vos indicateurs et objectifs de niveau de service peuvent s’avérer bien plus granulaires, et ces facteurs critiques du comportement des systèmes de production sont soumis au monitoring et à l’alerting, lesquels constituent la base de toute initiative d’observabilité. Cet aspect de l’observabilité est également connu sous le nom de «&nbsp;monitoring&nbsp;».
</p>
<p>Le second aspect que nous avons évoqué, à savoir le fait de fournir des informations granulaires aux opérateurs pour déboguer les problèmes de production avec rapidité et efficacité, est un domaine qui est en constante évolution et qui donne naissance à de nombreuses innovations. Les «&nbsp;trois piliers de l’observabilité&nbsp;», c.-à-d. les indicateurs, les logs et les traces d’application, sont un vaste sujet sur lequel il y a beaucoup de choses à dire. Il est également avéré que le fait de collecter toutes ces données granulaires à l’aide d’outils divers et variés n’est pas forcément rentable, aussi bien d’un point de vue analytique que financier.&nbsp;
</p>
<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltf85be52d51892228/5c98d45f8e3cc6505f19f678/three-pillars-of-observability-logs-metrics-tracs-apm.png" data-sys-asset-uid="bltf85be52d51892228" alt="three-pillars-of-observability-logs-metrics-tracs-apm.png" "="" width="446" height="194" style="width: 446px; height: 194px; display: block; margin: auto;">
</p>
<h2>Les «&nbsp;piliers&nbsp;» de l’observabilité</h2>
<p>Étudions ces aspects de la collecte de données plus en détail. Voici comment nous avons tendance à procéder aujourd’hui&nbsp;: on collecte des indicateurs dans un premier système (en général une base de données temporelles ou un service SaaS pour le monitoring des ressources), on collecte les logs dans un deuxième système (sans surprise, la Suite ELK habituellement), puis on utilise encore un troisième outil pour instrumenter les applications, et ainsi, effectuer le traçage au niveau des requêtes. Lorsqu’une alerte se déclenche et révèle une violation d’un niveau de service, c’est un véritable branle-bas de combat&nbsp;! Les opérateurs se ruent sur leurs systèmes et font du mieux qu’ils peuvent en jonglant entre les fenêtres&nbsp;: ils étudient les indicateurs dans l’une, les mettent en corrélation avec les logs manuellement dans une autre, et suivent les traces (au besoin) dans une troisième.
</p>
<p>Cette approche comprend plusieurs inconvénients. Tout d’abord, la mise en corrélation manuelle de différentes sources de données racontant toutes la même histoire fait perdre un temps précieux lors de la dégradation ou de la panne du service. Ensuite, les frais engendrés par la gestion de trois datastores opérationnels sont élevés&nbsp;: coûts de licence, effectifs distincts pour les administrateurs d’outils opérationnels disparates, capacités de Machine Learning incohérentes dans chaque datastore, capacité de réflexion «&nbsp;éparpillée&nbsp;» concernant l’alerting... Chaque entreprise avec laquelle nous nous sommes entretenus lutte pour faire face à ces problématiques.
</p>
<p>De plus en plus, les entreprises se rendent compte qu’il est important de disposer de toutes ces informations dans un magasin opérationnel unique, avec la possibilité de mettre automatiquement ces données en corrélation dans une interface utilisateur intuitive. L’idéal serait que les opérateurs puissent accéder à chaque donnée qui concerne leur service de façon unifiée, qu’il s’agisse d’une ligne de log émise par l’application, les données de trace résultant de l’instrumentation, ou l’utilisation d’une ressource représentée au moyen d’indicateurs dans une série temporelle. Le souhait qu’expriment régulièrement les utilisateurs serait de pouvoir disposer d’un accès ad-hoc uniforme à ces données, qu’elles proviennent d’une recherche avec filtrage, d’une agrégation ou encore d’une visualisation. Démarrer avec des indicateurs, explorer les logs et les traces en quelques clics sans que le contexte ne change, voilà ce qui permettrait d’accélérer l’investigation. De la même façon, on peut considérer les valeurs numériques extraites de logs structurés comme des indicateurs. Et le fait de comparer ces valeurs aux indicateurs est particulièrement intéressant d’un point de vue opérationnel.
</p>
<p>Comme évoqué précédemment, si on se contente de collecter des données, on risque de se retrouver avec un volume trop important d’informations sur le disque, et pas assez de données exploitables lorsqu’un incident se produit. À côté de cela, on compte de plus en plus sur le système qui collecte les données opérationnelles pour détecter automatiquement des événements «&nbsp;intéressants&nbsp;», des traces et des anomalies dans le schéma d’une série temporelle. Cela permet aux opérateurs d’enquêter sur un problème en se concentrant sur sa cause plus rapidement. Cette capacité de détection des anomalies est parfois désignée comme le «&nbsp;quatrième pilier de l’observabilité&nbsp;». La détection des anomalies dans les données de disponibilité, dans l’utilisation de ressources, dans les schémas de logging et dans la plupart des traces pertinentes fait partie des exigences émergentes mises en avant par les équipes d’observabilité.
</p>
<h2>Observabilité... et la Suite&nbsp;ELK&nbsp;?</h2>
<p>En quoi l’observabilité concerne-t-elle la Suite&nbsp;Elastic (ou la <a href="/fr/elk-stack">Suite&nbsp;ELK</a>, comme on l’appelle dans les cercles opérationnels)&nbsp;?
</p>
<p>La Suite&nbsp;ELK est réputée pour être la solution incontournable pour centraliser les logs issus des systèmes opérationnels. On part du principe qu’Elasticsearch (un «&nbsp;moteur de recherche&nbsp;») est l’outil idéal dans lequel importer des logs texte afin d’effectuer une recherche de texte libre. Et effectivement, rien que le fait de rechercher le mot «&nbsp;error&nbsp;» dans les logs texte ou de filtrer les logs en fonction d’un ensemble de balises bien connu donne déjà des résultats très pertinents. C’est d’ailleurs par là que commencent généralement les utilisateurs.
</p>
<p>L’utilisation d’Elasticsearch en tant que datastore permet de bénéficier d’un index inversé proposant des capacités efficaces de recherche de texte intégral et de filtrage simple. Mais comme la plupart des utilisateurs de la Suite&nbsp;ELK le savent, ses avantages vont bien au-delà. Il contient également une structure en colonnes optimisée pour le stockage et qui fonctionne dans une série temporelle numérique dense. Cette structure en colonnes sert à stocker les données structurelles venant des logs analysés, qu’il s’agisse de chaînes ou de valeurs numériques. Pour tout vous dire, ce qui nous a incités à la base à optimiser Elasticsearch en vue d’un stockage efficace et de l’extraction des valeurs numériques, c’est le cas d'utilisation qui impliquait de convertir les logs en indicateurs.
</p>
<p>Au fil du temps, les utilisateurs ont commencé à importer des <a href="/fr/solutions/metrics">séries temporelles numériques</a> directement dans Elasticsearch, venant remplacer les bases de données existantes des séries temporelles. Guidé par ce besoin, Elastic a récemment introduit <a href="/guide/en/beats/metricbeat/6.6/metricbeat-modules.html">Metricbeat</a> pour la collecte automatisée d’indicateurs, le concept de cumuls automatiques et d’autres fonctionnalités spécifiques aux indicateurs, aussi bien dans le datastore que dans l’interface utilisateur. Résultat&nbsp;: <a href="/fr/webinars/ns1-leveraging-elasticsearch-as-a-time-series-database">un nombre croissant d’utilisateurs</a> qui avaient adopté la Suite&nbsp;ELK pour les logs ont également commencé à importer des données d’indicateurs, comme l’utilisation de ressource, dans la Suite Elastic. En plus des économies opérationnelles déjà mentionnées ci-dessus, une autre raison poussant les utilisateurs à se tourner vers Elasticsearch est le manque de restrictions que cette solution applique à la cardinalité des champs éligibles aux agrégations numériques (un souci courant lorsque l’on évoque la plupart des bases de données temporelles existantes).
</p>
<p>À l’instar des indicateurs, les <a href="/fr/products/beats/heartbeat">données de disponibilité</a> représentent un type de données extrêmement important avec les logs, fournissant une source conséquente d’alertes relatives aux indicateurs et objectifs de niveau de service depuis un moniteur. Les données de disponibilité peuvent fournir des informations sur la dégradation des services, des API et des sites web, souvent avant que les utilisateurs n’en ressentent l’impact. Autre avantage&nbsp;: les données de disponibilité prennent très peu de place en termes de stockage. Elles présentent donc une grande valeur pour un coût supplémentaire minime.
</p>
<p>L’année dernière, Elastic a aussi introduit <a href="/fr/solutions/apm">Elastic&nbsp;APM</a>, une solution qui ajoute le traçage d’applications et le traçage distribué à la suite. Pour nous, il s’agissait d’une évolution naturelle, étant donné que plusieurs projets open source et fournisseurs APM réputés se servaient déjà d’Elasticsearch pour stocker et rechercher les données de trace. En général, les outils APM traditionnels séparent les données de trace APM des logs et des indicateurs, ce qui crée des silos de données opérationnelles. Elastic&nbsp;APM propose un ensemble d’agents pour collecter des données de trace à partir de langages et de frameworks pris en charge, ainsi que pour prendre en charge OpenTracing. Les données de trace recueillies sont automatiquement mises en corrélation avec les indicateurs et les logs.
</p>
<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt248065423cca3f6c/5c98d436fc9053fa5ecd78e3/Screen_Shot_2019-02-28_at_6.58.21_AM.png" data-sys-asset-uid="blt248065423cca3f6c" alt="Screen Shot 2019-02-28 at 6.58.21 AM.png">
</p>
<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltc5c9236cde8b37b8/5c98d43b146c873d59750036/Screen_Shot_2019-02-28_at_6.47.51_AM.png" data-sys-asset-uid="bltc5c9236cde8b37b8" alt="Screen Shot 2019-02-28 at 6.47.51 AM.png">
</p>
<p>Le fil conducteur qui relie ces entrées de données est que chacune d’elles constitue un index d’Elasticsearch. Il n’y a aucune restriction sur les agrégations que vous exécutez sur ces données, sur la façon dont vous les visualisez dans Kibana et sur la manière dans l’alerting et le Machine Learning s’appliquent à chaque source de données. Pour en voir une démonstration, <a href="https://www.youtube.com/watch?v=d6h5gpACD4o&feature=youtu.be">regardez cette vidéo</a>.
</p>
<div style="height: 478px; margin-bottom: 20px;">
	<iframe width="100%" height="478" src="//www.youtube.com/embed/d6h5gpACD4o?rel=0" class="video-iframe" frameborder="0" allowfullscreen="">
	</iframe>
</div>
<h2>Kubernetes observable et la Suite&nbsp;Elastic</h2>
<p>L’une des communautés dans laquelle le concept d’observabilité est un sujet récurrent de conversation, c’est celle des utilisateurs qui adoptent Kubernetes pour l’orchestration des conteneurs. Ces utilisateurs «&nbsp;cloud native&nbsp;», terme popularisé par la <a href="https://www.cncf.io/">Cloud Native Computing Foundation (ou CNCF)</a>, font face à des défis uniques. Ils se retrouvent confrontés à une centralisation massive d’applications et de services s’appuyant sur, ou ayant migrés vers, une plate-forme d’orchestration de conteneurs propulsée par Kubernetes. Ils constatent également qu’il existe une tendance à diviser les applications monolithiques en «&nbsp;microservices&nbsp;». Les outils et méthodes qui donnaient auparavant la visibilité nécessaire sur les applications exécutées sur cette infrastructure sont désormais obsolètes.
</p>
<p>L’observabilité sur Kubernetes mériterait de faire l’objet d’un article à part entière. De ce fait, nous vous invitons à consulter le <a href="/fr/webinars/observable-kubernetes-with-the-elastic-stack">webinar sur le Kubernetes observable</a> et <a href="/fr/blog/distributed-tracing-opentracing-and-elastic-apm">l’article sur le traçage distribué avec Elastic&nbsp;APM</a> pour en savoir plus.
</p>
<h2>Et ensuite&nbsp;?</h2>
<p>Pour approfondir un sujet comme celui abordé ici, il nous semble essentiel de vous donner quelques clés pour poursuivre.
</p>
<p>Pour en savoir davantage sur les bonnes pratiques de l’observabilité, nous vous recommandons de commencer par lire le livre dont nous avons parlé précédemment, <a href="https://landing.google.com/sre/books/">le livre de Google sur la SRE</a>. Ensuite, nous vous invitons à vous pencher sur les articles rédigés par des entreprises pour lesquelles il est essentiel que les applications critiques fonctionnent en continu pour la production. Ces articles donnent généralement matière à réflexion. Par exemple, cet article de l’équipe d’ingénierie <a href="https://engineering.salesforce.com/what-is-observability-d175eb6cd2e4">Salesforce</a> fait office de guide pragmatique et pratique pour améliorer l’état de l’observabilité de façon itérative.
</p>
<p>Pour tester les capacités de la Suite&nbsp;Elastic dans le cadre de vos initiatives d’observabilité, tournez-vous vers la dernière version de notre suite sur <a href="/fr/cloud/elasticsearch-service">Elasticsearch&nbsp;Service</a> sur <a href="https://cloud.elastic.co/">Elastic&nbsp;Cloud</a> (un sandbox idéal même si vous effectuez un déploiement auto-géré au final) ou <a href="/fr/downloads">téléchargez</a> et <a href="/fr/start">installez</a> les composants de la Suite&nbsp;Elastic en local. Pensez à consulter les nouvelles interfaces utilisateur pour les <strong>logs</strong>, le monitoring d’<strong>infrastructure</strong>, <strong>APM</strong> et la <strong>disponibilité</strong> (prochainement dans la version 6.7) dans Kibana; qui sont conçues spécialement pour les workflows d’observabilité courants. Et n’hésitez pas à nous solliciter sur les <a href="https://discuss.elastic.co/">forums de discussion</a> si vous avez des questions. Nous sommes là pour vous aider&nbsp;!
</p>

observablt-banner.jpg

three-pillars-of-observability-logs-metrics-tracs-apm-banner.jpg

Observability with the Elastic Stack

La Suite Elastic et l'observabilité

Cet article présente des cas d'utilisation courants des scripted fields Kibana, et comment créer des scripted fields dans une nouvelle instance Elastic Cloud.

<p>Kibana offre un moyen puissant de faire des recherches et de visualiser des données stockées dans Elasticsearch. Pour les visualisations, Kibana recherche les champs définis dans les mappings d'Elasticsearch et les propose en tant qu'options à l'utilisateur qui souhaite créer un graphique. Mais que se passe-t-il si vous oubliez de définir une valeur importante dans un champ séparé de votre schéma ? Ou si vous voulez combiner deux champs et les traiter comme un seul ? C'est dans ce type de situations que les scripted fields de Kibana entrent en scène.<br>
</p>
<p>Les scripted fields sont apparus dès le début de Kibana 4. Lors de leur lancement, ils ne pouvaient être définis que via des <a href="https://www.elastic.co/guide/en/elasticsearch/reference/5.0/modules-scripting-expression.html">Lucene Expressions</a>,&nbsp;un langage de script dans Elasticsearch qui utilise exclusivement des valeurs numériques. La puissance des scripted fields&nbsp;se limitait donc&nbsp;à un sous-ensemble de cas d'utilisation. Dans la version 5.0, Elasticsearch a ajouté <a href="https://www.elastic.co/guide/en/elasticsearch/reference/5.0/modules-scripting-painless.html">Painless</a>, un langage de script puissant et sécurisé qui fonctionne avec différents types de données. Les scripted fields de Kibana 5.0 sont donc bien plus puissants.
</p>
<p>Dans la suite de cet article, nous vous montrerons comment créer des scripted fields pour les cas d'utilisation courants. Nous nous appuierons pour cela sur un ensemble de données du <a href="https://www.elastic.co/guide/en/kibana/5.0/tutorial-load-dataset.html">tutoriel Getting Started with Kibana</a>&nbsp;et utiliserons une instance d'Elasticsearch et de Kibana exécutée dans <a href="https://cloud.elastic.co/">Elastic Cloud</a>, que vous pouvez faire tourner gratuitement.
</p>
<p>La vidéo suivante vous indique comment lancer une instance personnelle d'Elasticsearch et de Kibana dans Elastic Cloud et y charger un ensemble de données d'exemple.<br>
</p>
<div class="video embed-container" style="height: 319.725px;">
	<img style="width: 100%; margin: auto; display: block;" class="vidyard-player-embed" src="https://play.vidyard.com/6gWkzXXhT69tUa7uRtvJ96.jpg" data-uuid="6gWkzXXhT69tUa7uRtvJ96" data-v="4" data-type="inline">
</div>
<h2>Fonctionnement des scripted fields</h2>
<p>Elasticsearch vous permet de spécifier des scripted fields à chaque requête. Kibana améliore cela en vous permettant de définir un scripted field une fois pour toutes dans la section Management. Il peut ensuite être utilisé à différents endroits de l'interface utilisateur. Veuillez noter que tant que Kibana enregistre les scripted fields et ses autres configurations dans l'index <code>.kibana</code>, cette configuration est spécifique à Kibana et les scripted fields de Kibana ne seront pas exposés aux utilisateurs de l'API d'Elasticsearch.
</p>
<p>Lorsque vous définirez un scripted field dans Kibana, vous devrez choisir le langage du script dans la liste des langages installés sur les nœuds d'Elasticsearch qui ont l'option de dynamic scripting activé. « expression » et « painless » sont activés par défaut dans la version 5.0, tandis que seule « expression » est activée dans les versions 2.x. Vous pouvez installer d'autres langages de script et activer le dynamic scripting pour ceux-ci, mais cette opération est déconseillée parce que les scripts ne peuvent pas être suffisamment <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-scripting-security.html">isolés</a>&nbsp;et ont donc été dépréciés.
</p>
<p>Les scripted fields traitent un seul document Elasticsearch à la fois, mais peuvent référencer plusieurs champs dans ce document. Il est donc approprié d'utiliser des scripted fields pour combiner ou transformer les champs d'un document, mais pas pour effectuer des calculs à partir de plusieurs documents (par exemple des calculs sur des données temporelles). Lucene Expressions et Painless fonctionnent avec les champs stockés dans <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/doc-values.html">doc_values</a>.&nbsp;Pour les chaînes de caractères, vous devrez donc enregistrer la chaîne dans un type de données <code>keyword</code>. Les scripted fields basés sur Painless ne peuvent pas fonctionner directement sur <code>_source</code>.
</p>
<p>Une fois les scripted fields définis dans « Management », l'utilisateur peut interagir avec eux de la même manière qu'avec d'autres champs de Kibana. Les scripted fields s'affichent automatiquement dans la liste des champs de «&nbsp;Discover&nbsp;» et sont disponibles dans « Visualize »&nbsp;pour pouvoir créer des visualisations. Kibana transmet simplement les définitions des scripted fields à Elasticsearch lors des requêtes pour l'évaluation. L'ensemble de données obtenu est combiné à d'autres résultats provenant d'Elasticsearch et présenté à l'utilisateur sous la forme d'un tableau ou d'un graphique.
</p>
<p>Certaines limitations des scripted fields sont connues à l'heure où nous écrivons ces lignes. Vous pouvez appliquer aux scripted fields la plupart des agrégations Elasticsearch disponibles dans le constructeur visuel de Kibana, à l'exception notable de <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-significantterms-aggregation.html"> l'agrégation « significant terms »</a>. Vous pouvez également filtrer les scripted fields via la barre de filtrage dans Discover, Visualize et Dashboard, même si vous devez prendre garde à écrire des scripts corrects, qui renvoient des valeurs bien définies comme indiqué ci-dessous. Veuillez également vous reporter à la section Bonnes Pratiques&nbsp;ci-dessous pour vous assurer de ne pas déstabiliser l'environnement lorsque vous utilisez des scripted fields.
</p>
<p>La vidéo suivante vous montre comment utiliser Kibana pour créer des scripted fields.
</p>
<div class="video embed-container" style="height: 319.725px;">
	<img style="width: 100%; margin: auto; display: block;" class="vidyard-player-embed" src="https://play.vidyard.com/SKHYsZcKZHq9u7GTNGWPaL.jpg" data-uuid="SKHYsZcKZHq9u7GTNGWPaL" data-v="4" data-type="inline">
</div>
<h2>Exemples de scripted fields</h2>
<p>Cette section présente quelques exemples de scripted fields Lucene Expressions et Painless dans des scénarios Kibana courants. Comme mentionné plus haut, ces exemples ont été développés à partir d'un ensemble de données extrait du <a href="https://www.elastic.co/guide/en/kibana/5.0/tutorial-load-dataset.html">tutoriel Getting started with Kibana</a>&nbsp;et supposent que vous utilisez Elasticsearch et Kibana 5.1.1 puisque les versions précédentes présentent des problèmes connus avec le filtrage et le tri de certains types de scripted fields.
</p>
<p>La plupart des scripted fields devraient fonctionner directement puisque Lucene Expressions et Painless sont activés par défaut dans Elasticsearch 5.0. La seule exception concerne les scripts qui nécessitent l'analyse grammaticale des champs basée sur regex pour lesquels vous devrez définir les paramètres suivants dans <code>elasticsearch.yml</code> afin d'activer la correspondance regex pour Painless : <code>script.painless.regex.enabled: true</code>
</p>
<h3>Effectuer des calculs sur un seul champ</h3>
<ul>
	<li><strong>Exemple</strong> : convertir des octets en kilooctets</li>
	<li><strong>Langage</strong> :&nbsp;expressions</li>
	<li><strong>Type renvoyé</strong> :&nbsp;nombre</li>
</ul>
<pre class="prettyprint"> doc['bytes'].value / 1024
</pre>
<p>Remarque : N'oubliez pas que les scripted fields de Kibana fonctionnent sur un document à un instant donné. Il est donc impossible d'effectuer des calculs avec des données temporelles dans un scripted field.<br>
</p>
<h3>Calcul à partir d'une date qui renvoie un nombre</h3>
<ul>
	<li><strong>Exemple</strong> :&nbsp; convertir une date en heure du jour</li>
	<li><strong>Langage</strong> : expressions</li>
	<li><strong>Type retourné</strong> :&nbsp;nombre</li>
</ul>
<p>Lucene Expressions offre un grand nombre de <a href="https://www.elastic.co/guide/en/elasticsearch/reference/5.0/modules-scripting-expression.html#_date_field_api">fonctions de manipulation de dates</a>&nbsp;prêtes à l'emploi. Cependant, comme Lucene Expressions ne renvoie que des valeurs numériques, nous devrons utiliser Painless pour renvoyer un jour de la semaine au format chaîne de caractère (ci-dessous).
</p>
<pre class="prettyprint"> doc['@timestamp'].date.hourOfDay
</pre>
<p>Remarque : le script ci-dessus renvoie le résultat : 1-24
</p>
<pre class="prettyprint">doc['@timestamp'].date.dayOfWeek
</pre>
<p>Remarque : le script ci-dessus renvoie le résultat : 1-7
</p>
<h3>Associer deux valeurs de chaînes de caractères</h3>
<ul>
	<li><strong>Exemple</strong> :&nbsp;associer la source et la destination ou le nom et le prénom</li>
	<li><strong>Langage</strong> :&nbsp;painless</li>
	<li><strong>Type retourné</strong> :&nbsp;chaînes de caractères</li>
</ul>
<pre class="prettyprint"> doc['geo.dest.keyword'].value + ':' + doc['geo.src.keyword'].value
</pre>
<p> Remarque : Comme les scripted fields doivent fonctionner sur les champs dans <code>doc_values</code>, nous utilisons les versions <code>.keyword</code> des chaînes de caractères ci-dessus.
</p>
<h3>Introduire de la logique</h3>
<ul>
	<li><strong>Exemple</strong> :  renvoyer un message « téléchargement volumineux » pour tout document de plus de 10 000 octets</li>
	<li><strong>Langage</strong> : painless</li>
	<li><strong>Type retourné</strong> : chaînes de caractères</li>
</ul><span id="docs-internal-guid-79afb0c7-f6ba-c23d-a150-111fc040ae24">
<pre class="prettyprint"> if (doc['bytes'].value &gt; 10000) { 
    return "big download";
}
return "";
</pre>
<p dir="ltr">Remarque : Si vous introduisez de la logique, assurez-vous que chaque chemin d'exécution dispose d'une déclaration et d'une valeur de retour (sauf <code>null</code>). Par exemple, le scripted field ci-dessus échouera avec une erreur de compilation s’il est utilisé dans les filtres de Kibana sans la déclaration de retour à la fin ou si la déclaration renvoie <code>null</code>. Souvenez-vous que l'ajout de logique dans des fonctions n'est pas pris en charge par les scripted fields de Kibana.
</p>
<h3 dir="ltr">Renvoi d'une partie d'une chaîne de caractères
</h3>
<ul>
	<li><strong>Exemple</strong> : envoyer la partie de la chaîne de caractères située après le dernier slash d’une URL</li>
	<li><strong>Langage</strong> : painless</li>
	<li><strong>Type retourné</strong> : chaînes de caractères</li>
</ul>
<pre class="prettyprint"> def path = doc['url.keyword'].value;
if (path != null) {
    int lastSlashIndex = path.lastIndexOf('/');
    if (lastSlashIndex &gt; 0) {
    return path.substring(lastSlashIndex+1);
    }
}
return "";
</pre>
<p dir="ltr">Remarque : Évitez dans la mesure du possible d'utiliser des expressions regex pour extraire des parties de chaînes de caractères puisque les opérations <code>indexOf()</code> sollicitent moins les ressources et génèrent moins d'erreurs.
</p>
<h3 dir="ltr">Faire correspondre une chaîne de caractères à l'aide de regex et entreprendre une action suite à une correspondance
</h3>
<ul>
	<li><strong>Exemple</strong> : renvoyer le mot « error » si une partie d'une chaîne de caractères « error » est détectée dans le champ « referer » ou sinon, renvoyer la chaîne de caractères « no error »</li>
	<li><strong>Langage</strong> : painless</li>
	<li><strong>Type retourné</strong> : chaînes de caractères</li>
</ul>
<pre class="prettyprint">if (doc['referer.keyword'].value =~ /error/) { 
return "error"
} else {
return "no error"
}
</pre>
<p dir="ltr">Remarque : La syntaxe regex simplifiée est utile pour les expressions conditionnelles basées sur une correspondance regex.
</p>
<h3 dir="ltr">Faire correspondre une chaîne de caractère et renvoyer cette correspondance
</h3>
<ul>
	<li><strong>Exemple</strong> :  renvoyer le domaine, la chaîne de caractères après le dernier point dans le champ « host »</li>
	<li><strong>Langage</strong> : painless</li>
	<li><strong>Type retourné</strong> : chaînes de caractères</li>
</ul>
<pre class="prettyprint">def m = /^.*\.([a-z]+)$/.matcher(doc['host.keyword'].value);
if ( m.matches() ) {
   return m.group(1)
} else {
   return "no match"
}
</pre>
<p dir="ltr">Remarque : En définissant un objet via les fonctions regex <code>matcher()</code> vous pouvez extraire des groupes de caractères qui correspondent au regex et les renvoyer.
</p>
<h3 dir="ltr">Faire correspondre un nombre et renvoyer cette correspondance
</h3>
<ul>
	<li><strong>Exemple</strong> : renvoyer le premier octet de l'adresse IP (enregistrée en tant que chaîne de caractères) et traiter ce dernier comme un nombre</li>
	<li><strong>Langage</strong> : painless</li>
	<li><strong>Type retourné</strong> : nombre</li>
</ul>
<pre class="prettyprint"> def m = /^([0-9]+)\..*$/.matcher(doc['clientip.keyword'].value);
if ( m.matches() ) {
   return Integer.parseInt(m.group(1))
} else {
   return 0
}
</pre>
<p dir="ltr">Remarque : Il est important de renvoyer le type de données adéquat dans un script. La correspondance regex renvoie une chaîne de caractères, même si elle tombe sur un nombre. Vous devez alors la convertir explicitement en nombre entier lors du résultat.
</p>
<h3 dir="ltr">Calcul à partir d'une date qui renvoie des chaînes de caractères
</h3>
<ul>
	<li><strong>Exemple</strong> : convertir une date en jour de la semaine au format chaîne de caractères</li>
	<li><strong>Langage</strong> : painless</li>
	<li><strong>Type retourné</strong> : chaîne de caractères</li>
</ul>
<pre class="prettyprint">LocalDateTime.ofInstant(Instant.ofEpochMilli(doc['@timestamp'].value), ZoneId.of('Z')).getDayOfWeek().getDisplayName(TextStyle.FULL, Locale.getDefault())
</pre>
<p dir="ltr">Remarque : Comme Painless prend en charge tous les types natifs de Java, il permet d'accéder aux fonctions natives pour ces types, notamment <a href="https://docs.oracle.com/javase/8/docs/api/java/time/LocalDateTime.html#getDayOfWeek--">LocalDateTime()</a>, utile pour effectuer des calculs plus complexes avec des dates.
</p>
<h2 dir="ltr">Bonnes pratiques
</h2>
<p dir="ltr">Comme vous pouvez le constater, le langage&nbsp;Painless permet d'extraire très efficacement des informations utiles de champs arbitraires stockés dans Elasticsearch via les scripted fields de Kibana. Cependant, cette formidable puissance va de pair avec de lourdes responsabilités.&nbsp;
</p>
<p dir="ltr">Vous trouverez ci-dessous quelques-unes des bonnes pratiques pour l'utilisation des scripted fields de Kibana.
</p>
<ul>
	<li>Veiller à toujours utiliser un environnement de développement pour faire des essais avec les scripted fields. Les scripted fields sont immédiatement actifs après leur sauvegarde dans la section Management de Kibana (ils apparaissent par exemple sur l'écran Discover au niveau du modèle d'index pour tous les utilisateurs). Il est donc déconseillé de développer des scripted fields directement dans l'environnement de production. Nous vous recommandons de tester au préalable votre syntaxe dans un environnement de développement, d'évaluer l'impact des scripted fields sur des ensembles de données réalistes et des volumes de données en pré-production avant de les déployer en production.&nbsp;</li>
	<li>Une fois que vous vous êtes assuré que le scripted field sera utile pour les utilisateurs, vous pouvez penser à modifier votre ingestion afin d'extraire le champ au moment de l'indexation de nouvelles données. Le traitement Elasticsearch sera ainsi moins lourd lors de la requête et les utilisateurs de Kibana bénéficieront de résultats plus rapides. Vous pouvez également utiliser l’API <a href="https://www.elastic.co/guide/en/elasticsearch/reference/5.0/docs-reindex.html">_reindex</a> dans Elasticsearch pour indexer à nouveau les données existantes.
	</li>
</ul></span>

Articles by Tanya Bragin

Du nouveau du côté de l'observabilité : .NET dans APM, monitoring Kubernetes, Metrics Explorer

Schéma d'écriture vs schéma de lecture

La Suite Elastic et l'observabilité

Utilisation de Painless avec les « scripted fields » Kibana

Produits

Enterprise

Resources

SaaS

Orchestration

Articles by Tanya Bragin

Du nouveau du côté de l'observabilité : .NET dans APM, monitoring Kubernetes, Metrics Explorer

Schéma d'écriture vs schéma de lecture

La Suite Elastic et l'observabilité

Utilisation de Painless avec les « scripted fields » Kibana