<p>Dans cet article de blog, nous aborderons les points suivants&nbsp;:
</p>
<ul>
	<li>L'importance des standards ouverts</li>
	<li>Le format d'exposition Prometheus</li>
	<li>L'observabilité vue par Elastic</li>
	<li>Trois façons d'exploiter les indicateurs Prometheus via Elasticsearch</li>
	<li>Un exemple de collecte et de visualisation des indicateurs exposés via l'exportateur Redis de Prometheus
	</li>
</ul>
<h2>Les standards ouverts</h2>
<p>Le site 
	<a href="http://opensource.com">opensource.com</a> propose un article instructif, intitulé&nbsp; "<a href="https://opensource.com/resources/what-are-open-standards">What are Open Standards?</a>" (Qu'est-ce que les standards ouverts&nbsp;?).  Vous y trouverez bon nombre d'informations passionnantes. Mais quand on a travaillé pendant des années dans une équipe opérationnelle, certains points s'avèrent particulièrement intéressants&nbsp;:
</p>
<ol start="1">
	<li>La disponibilité&nbsp;: chacun peut lire et implémenter les standards ouverts.
	</li>
	<li>L'utilisateur final dispose d'un choix maximal.</li>
	<li>L'absence de discrimination (neutralité en matière de fournisseurs)&nbsp;: les standards ouverts et les organisations qui les administrent ne favorisent aucun prestataire par rapport à un autre.
	</li>
	<li>L'absence de secrets intentionnels&nbsp;: le standard ne doit dissimuler aucun détail nécessaire à l'interopérabilité de l'implémentation.
	</li>
</ol>
<p>Voilà de bonnes raisons d'opter pour les standards ouverts. Mais voyons maintenant pourquoi <a href="https://openmetrics.io/">OpenMetrics</a> s'appuie sur le <a href="https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md">format d'exposition Prometheus</a>.
	 Lors de ses interventions aux conférences 
	<a href="https://promcon.io/2018-munich/slides/openmetrics-transforming-the-prometheus-exposition-format-into-a-global-standard.pdf">PromCon&nbsp;2018</a> et KubeCon&nbsp;+ <a href="https://www.youtube.com/watch?v=DARVop91kBQ">CloudNativeCon</a> North&nbsp;America&nbsp;2018, Richard&nbsp;Hartmann expliquait pourquoi il était pertinent de créer un standard ouvert s'inspirant du
format d'exposition Prometheus&nbsp;:
</p>
<ul>
	<li>La majorité des formats de données sont propriétaires, difficiles à implémenter, ou les deux.
	</li>
	<li>Prometheus est de fait devenu un standard en matière de monitoring cloud-native.
	</li>
	<li>La simplicité des données au format d'exposition s'est traduite par une explosion des <a href="https://prometheus.io/docs/instrumenting/exporters/">
	points de terminaison d'indicateurs compatibles</a>.</li>
	<li>Le format d'exposition Prometheus s'appuie sur un grand nombre d'expériences opérationnelles, mais seules quelques personnes ont pris part à sa conception.
	</li>
	<li>Certains autres projets et fournisseurs sont tentés d'adopter les standards d'un produit "concurrent".
	</li>
</ul>
<h2>Le format d'exposition Prometheus</h2>
<p>Pour en savoir plus sur le format d'exposition, n'hésitez pas à consulter le <a href="https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md">
	référentiel Github Prometheus</a>. Mais pour l'heure, prenons un exemple.
 Disons que je dispose d'un exportateur, l'
	<a href="https://github.com/oliver006/redis_exporter">exportateur Redis d'Oliver006</a>, et que celui-ci publie des indicateurs sur le port&nbsp;9121 au niveau du point de terminaison /metrics. 
  Ci-dessous, je n'affiche que les informations relatives à l'indicateur Redis "instantaneous ops per second" (opérations instantanées par seconde).
  Nous y trouvons trois lignes de lecture&nbsp;:
</p>
<ol start="1">
	<li>Le texte d'aide (Help)</li>
	<li>Le type d'indicateur (en l'occurrence, il s'agit d'une jauge)</li>
	<li>Le serveur Redis mesuré (port localhost&nbsp;6379) et sa lecture actuelle (9&nbsp;opérations par seconde)
	</li>
</ol>
<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltdc2597dd9d329537/5cd475e29033f96a5b031b8b/roscigno-prometheus-exposition-format.png" data-sys-asset-uid="bltdc2597dd9d329537" alt="roscigno-prometheus-exposition-format.png">
</p>
<h2>L'observabilité vue par Elastic</h2>
<p>Je vous encourage vivement à découvrir <a href="/fr/blog/observability-with-the-elastic-stack">
	l'observabilité vue par Elastic</a>.En attendant, je ne résiste pas au plaisir de partager ici mon passage préféré dans cet article&nbsp;:
</p>
<blockquote>Lorsqu'on conçoit et qu'on fabrique un système "observable", l'objectif est de s'assurer que lorsqu'il est mis en production, les opérateurs soient capables de détecter les comportements indésirables (indisponibilité du service, erreurs, ou lenteur des réponses, par exemple) et qu'ils disposent d'informations exploitables pour déterminer la cause du problème avec efficacité (logs d'événements détaillés, informations granulaires sur l'utilisation des ressources, ou encore traces d'applications).
</blockquote>
<p>Je partage totalement cet avis et pense que pour exécuter, réparer et gérer les services que nous fournissons, nous avons besoin de l'ensemble des logs, des indicateurs et des informations de trace.
  En raison de son adoption généralisée et de sa communauté active, Prometheus constitue un élément essentiel de l'observabilité.
  Le standard OpenMetrics ne fera que le valoriser davantage&nbsp;: qu'ils soient réels ou imaginaires, il abolira les obstacles à l'adoption d'un format d'indicateurs conçu par et pour les opérations, qui s'est naturellement imposé dans le secteur.
</p>
<p>La plupart de mes interlocuteurs connaissent très bien la Suite&nbsp;Elastic, aussi connue sous le nom d'ELK, qu'ils utilisent pour le logging.
  Mais la Suite&nbsp;Elastic a plus d'un tour dans son sac&nbsp;: elle est aussi parfaitement adaptée aux indicateurs d'une manière générale, et aux indicateurs de performance applicative. Pour en savoir plus, je vous invite à consulter ces articles consacrés aux 
	<a href="/fr/blog/elasticsearch-as-a-time-series-database-for-telemetry-data-at-ns1">indicateurs</a>, ainsi qu'à <a href="/fr/solutions/apm">
	APM et au traçage distribué</a>.
</p>
<p>L'intégration poussée de la Suite&nbsp;Elastic et du mode d'exportation d'indicateurs propre à Prometheus présente un intérêt certain. Voici les principales raisons qui nous amènent à le penser&nbsp;:
</p>
<ul>
	<li>Association des indicateurs avec les logs et APM dans Elasticsearch pour les mettre en corrélation dans Kibana. Ce <a href="/fr/blog/elasticsearch-as-a-time-series-database-for-telemetry-data-at-ns1">témoignage</a> de l'entreprise&nbsp;NS1 vous en dit plus sur l'association des logs et des indicateurs dans la Suite&nbsp;Elastic.
	</li>
	<li>Utilisation d'Elasticsearch comme stockage à long terme pour les indicateurs collectés par le serveur Prometheus, qui ne permet pas nativement le clustering à l'heure actuelle.
	</li>
	<li>Vision d'ensemble de tous vos indicateurs, où que se trouvent vos instances Prometheus.Mais quelle est notre approche de ces intégrations&nbsp;? C'est ce que nous allons voir en détail dans la suite de l'article.
	</li>
</ul>
<h3>Exemple d'exportateur</h3>
<p>Pour cet environnement de démo, j'utilise Google Kubernetes&nbsp;Engine (GKE). J'exécute donc mon application (Metricbeat) et l'exportateur Prometheus dans Kubernetes.
  Voici un petit aperçu du manifeste d'Oliver006, où l'on voit comment déployer un exportateur Redis en tant que side-car avec l'image Redis.
  Comme vous pouvez le constater, l'exportateur publie sur le port&nbsp;9121, qui est le
	<a href="https://github.com/prometheus/prometheus/wiki/Default-port-allocations">numéro de port attribué par défaut</a> à l'exportateur Redis de Prometheus.
</p>
<pre class="prettyprint">...
  - name: redis-exporter
    image: oliver006/redis_exporter:latest
    resources:
      requests:
        cpu: 100m
        memory: 100Mi
    ports:
    - containerPort: 9121
...
</pre>
<p><a href="https://github.com/elastic/examples/blob/master/scraping-prometheus-k8s-with-metricbeat/guestbook.yaml">Intégralité du code source disponible sur GitHub</a>
</p>
<h3>Scraper les indicateurs via le module Prometheus de Metricbeat
</h3>
<p><a href="/fr/beats/metricbeat">
	Metricbeat</a> est l'agent de transfert léger Elastic conçu pour les indicateurs.  Le<a href="/guide/en/beats/metricbeat/7.0/metricbeat-module-prometheus.html">module Prometheus</a> fourni avec Metricbeat vous permet de collecter les indicateurs de trois façons&nbsp;:
</p>
<ol start="1">
	<li>Vous pouvez vous connecter au serveur Prometheus sur le port&nbsp;9090 et extraire les indicateurs déjà collectés grâce à l'API Prometheus&nbsp;Federation (qui permet d'obtenir les indicateurs que collecte Prometheus).
	</li>
	<li>Vous pouvez vous connecter au serveur Prometheus sur le port&nbsp;9090 via le point de terminaison /metrics (self-monitoring Prometheus).
	</li>
	<li>Vous pouvez vous connecter aux exportateurs Prometheus individuellement et analyser le format d'exposition.
	</li>
</ol>
<p>Comment savoir quelle approche à adopter&nbsp;? Cela dépend de votre niveau de maîtrise du serveur Prometheus. Si vous disposez déjà d'un serveur Prometheus configuré pour scraper les indicateurs, et que vous voulez directement interroger ces données à des fins d'intégration, vous pouvez commencer par les méthodes&nbsp;(1) et&nbsp;(2).
</p>
<ul>
	<li>
	</li>
	<li>En revanche, si vous ne disposez pas du serveur Prometheus ou que vous préférez scraper vos exportateurs en parallèle via différents outils, vous pouvez opter pour la méthode&nbsp;(3).
	</li>
</ul>
<p>Remarque&nbsp;: Certaines des fonctionnalités Metricbeat ci-dessus sont disponibles en version bêta dans
Metricbeat&nbsp;7.0.  Nous vous recommandons de 
	<a href="/fr/downloads ">télécharger la version bêta&nbsp;7.0</a>
	ou de copier les liens du conteneur depuis
	<a href="https://www.docker.elastic.co/">L'API Prometheus&nbsp;Federation
	https://www.docker.elastic.co/
	</a>, puis d'exécuter la version bêta dans un environnement qui n'est pas en production.
</p>
<h3></h3>
<p>D'une manière générale, on utilise une fédération pour permettre la montée en charge, regrouper des ensembles de données, ou copier les données disponibles à un autre emplacement (pour la reprise après sinistre).  Le serveur Prometheus propose un <a href="https://prometheus.io/docs/prometheus/latest/federation/">point de terminaison <code>/federation</code></a>. Elastic se connecte à ce point de terminaison pour copier les indicateurs collectés par Prometheus, pour toutes les raisons évoquées ci-dessus.
</p>
<pre class="prettyprint">...
  - module: prometheus
    period: 10s
    hosts: ["prometheus-service.monitoring.svc.cluster.local:9090"]
    metrics_path: '/federate'
    query:
      'match[]': '{__name__!=""}'
...
</pre>
<p><a href="https://github.com/elastic/examples/blob/master/scraping-prometheus-k8s-with-metricbeat/metricbeat-kube-state-and-prometheus-server.yaml">Intégralité du code source disponible sur GitHub</a><a href="https://github.com/elastic/examples/blob/master/scraping-prometheus-k8s-with-metricbeat/metricbeat-kube-state-and-prometheus-server.yaml"></a>
</p>
<p>Dans l'exemple ci-dessus, la requête est définie sur "tout ce qui a un nom non&nbsp;vide".  Si vous ne voulez pas tout copier, la documentation Prometheus vous explique comment définir une condition de correspondance plus restrictive.  L'exemple se connecte aussi au serveur Pometheus toutes les dix&nbsp;secondes (mon serveur de démo ne collecte des indicateurs que depuis quelques pods et kube-state-metrics), mais vous pouvez modifier cet intervalle.
</p>
<h3>La fonctionnalité de self-monitoring Prometheus</h3>
<p>Tout comme les exportateurs, Prometheus intègre un point de terminaison <code>/metrics</code>.  Cela vous permet de collecter des indicateurs au sujet du serveur Prometheus.  La configuration est la suivante&nbsp;:
</p>
<pre class="prettyprint">...
  - module: prometheus
    period: 10s
    hosts: ["prometheus-service.monitoring.svc.cluster.local:9090"]
    metrics_path: /metrics
...
</pre>
<p><a href="https://github.com/elastic/examples/blob/master/scraping-prometheus-k8s-with-metricbeat/metricbeat-kube-state-and-prometheus-server.yaml">Intégralité du code source disponible sur GitHub</a>
</p>
<h3>Scraping de l'exportateur Prometheus</h3>
<p>Cet aperçu de YAML provient d'un manifeste décrivant le déploiement d'un DaemonSet Metricbeat. Il demande à Metricbeat d'assurer la détection automatique avec <code>kubernetes.labels.app</code> ==&nbsp;<code>redis</code> et de lire les indicateurs depuis le port&nbsp;9121 de ce pod.
  Souvenez-vous que le containerPort défini pour l'exportateur Redis est&nbsp;9121.
</p>
<pre class="prettyprint">...
- condition.equals:
    kubernetes.annotations.prometheus.io/scrape: "true"
  config:
    - module: prometheus
      period: 10s
      # Redis pods
      hosts: ["${data.host}:9121"]
      metrics_path: /metrics
...
</pre>
<p>Une fois Metricbeat déployé, n'importe quel pod qui satisfait à la condition kubernetes.labels.app ==&nbsp;redis se voit appliquer le module Prometheus, et les indicateurs sont collectés depuis le side-car de l'exportateur, sur le port&nbsp;9121.
</p>
<p>Mais que serait K8s sans les métadonnées&nbsp;?  Nous allons donc exploiter les métadonnées et la fonctionnalité Autodiscover de Beats.
  Examinons ce code de remplacement de l'aperçu de YAML ci-dessus&nbsp;:
</p>
<pre class="prettyprint">...
- condition.equals:
    kubernetes.annotations.prometheus.io/scrape: "true"
  config:
    - module: prometheus
      period: 10s
      hosts: ["${data.host}:${data.kubernetes.annotations.prometheus.io/port}"]
      metrics_path: /metrics
...
</pre>
<p><a href="https://github.com/elastic/examples/blob/master/scraping-prometheus-k8s-with-metricbeat/metricbeat-prometheus-auto-discover.yaml">Intégralité du code source disponible sur GitHub</a>
</p>
<p>Cette fois, au lieu de rechercher des exportateurs pour des pods Redis, nous allons en rechercher pour n'importe quel pod dont l'annotation 
	<code>kubernetes.annotations.prometheus.io/scrape</code> est définie sur "true".
	  La fonctionnalité de détection automatique de Prometheus est aussi configurée ainsi.
  En général, la fonctionnalité Autodiscover de Metricbeat est liée à une annotation contenue dans l'espace de noms elastic.co. Mais comme cet article est consacré à la lecture depuis des exportateurs Prometheus, 
faisons honneurs aux annotations K8s standards associées à Prometheus.
  Examinons la liste d'hôtes présentée plus haut&nbsp;:
</p>
<p><code>hosts: ["${data.host}:${data.kubernetes.annotations.prometheus.io/port}"]</code>
</p>
<p>Vous aurez remarqué que nous ne codons plus le port&nbsp;9121 en dur, puisqu'il s'agit du port de l'exportateur Redis.
  L'annotation 
	<code>prometheus.io/port</code> est définie sur le numéro de port de l'exportateur.  Pour un aperçu plus complet, voici une portion de code du fichier guestbook.yaml où ces annotations étaient définies&nbsp;:
</p>
<pre class="prettyprint">...
kind: Deployment
metadata:
  name: redis-master
spec:
  replicas: 1
  template:
    metadata:
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "9121"
      labels:
        app: redis
...
</pre>
<p><a href="https://github.com/elastic/examples/blob/master/scraping-prometheus-k8s-with-metricbeat/guestbook.yaml">Intégralité du code source disponible sur GitHub</a>
</p>
<p>Quand je vous disait que K8s ne serait pas K8s sans les métadonnées...
</p>
<h3>Quand visualisation rime avec information</h3>
<p>Transférer des données vers la Suite&nbsp;Elastic, c'est bien. Pouvoir interagir avec ces données, c'est mieux.  Dans la vidéo ci-dessous, nous allons découvrir comment créer des visualisations utiles grâce aux indicateurs Redis scrapés par Prometheus (puis importés dans la Suite&nbsp;Elastic), mais aussi grâce aux événements Kubernetes collectés depuis kube-state-metrics directement avec Metricbeat.
</p>
<p>Pour aller plus loin et obtenir des instructions détaillées après avoir regardé la vidéo, n'hésitez pas à consulter ce <a href="https://github.com/elastic/examples/blob/master/scraping-prometheus-k8s-with-metricbeat/README.md">référentiel d'exemple</a>.
</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/kt1jkhu1sptWzV3Y1wrfwE.jpg" data-uuid="kt1jkhu1sptWzV3Y1wrfwE" data-v="4" data-type="inline">
</div>
<h2>Cap sur l'observabilité</h2>
<p>Au paragraphe précédent, nous avons créé une visualisation Kibana pour un indicateur Redis clé (opérations instantanées par seconde), exposé par l'exportateur Redis d'Oliver006. La prochaine étape sera de collecter des logs, puis de créer un tableau de bord, afin d'associer logs et indicateurs dans nos applications.
</p>
<p>Pour en savoir plus sur la collecte de logs dans un environnement Kubernetes, je vous suggère de suivre les instructions disponibles dans le référentiel GitHub <a href="https://github.com/elastic/examples/blob/master/MonitoringKubernetes/README.md">elastic/examples</a>.
	  En quelques minutes à peine, Filebeat, Metricbeat et Packetbeat pourront commencer à collecter les données et à les publier dans Elasticsearch.
  Les différents agents Beats intègrent des exemples de tableau de bord, mais vous pouvez bien sûr créer vos propres visualisations pour les données Prometheus, et associer les différentes visualisations pour créer vos propres tableaux de bord, adaptés à vos méthodes de travail.
 Et si vous rencontrez un problème ou que vous avez envie de parler d'observabilité, les 
	<a href="https://discuss.elastic.co">forums de discussion</a> sont là pour ça.
</p>

blog-roscigno-wide.jpg

blog-roscigno-thumb.png

Elasticsearch Observability: Embracing Prometheus and OpenMetrics Standards for Metrics

L'observabilité dans Elasticsearch : adopter les standards Prometheus et OpenMetrics pour les indicateurs

<p>Dans la version&nbsp;6.5 de la Suite&nbsp;Elastic, nous avons mis en place deux nouveaux outils permettant d’interagir avec vos données&nbsp;: les interfaces utilisateur Infrastructure et Logs. Ces deux interfaces sont encore en version bêta dans la version&nbsp;6.5, mais nous y reviendrons ultérieurement car nous comptons sur vous pour nous faire part de vos commentaires. Ce que j’aimerais faire auparavant, c’est vous expliquer les motivations qui ont conduit à la mise en place de ces interfaces, décrire l’expérience utilisateur qu’elles proposent et aborder leur configuration. Commençons avec l’interface utilisateur Logs.</p><h2>Interface utilisateur Logs</h2><h3>Motivation</h3><p>J’entends régulièrement dire&nbsp;: “Donne-moi juste les logs, je n’ai pas besoin de quelque chose de sophistiqué. Tout ce que je dois savoir se trouve dans les logs. Je veux juste les lire“. Nous en avons pris bonne note et c’est à vous que revient le choix. Que préférez-vous&nbsp;?</p><p>Une commande tail -f améliorée surveillant les derniers ajouts de lignes dans un fichier&nbsp;? Une expérience visuelle avec des tableaux, des graphiques, des nuages de mots-clés, etc.&nbsp;? Une vue tabulaire&nbsp;? Vous devez pouvoir travailler de la manière qui vous convient. Or, avec la flexibilité de la Suite&nbsp;Elastic, c’est possible.</p><table border="0" style="width: 100%;"><tbody><tr><td><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltf9bdf54b4eeab8bc/5c57d6fb85820dce0bcc2bf5/Logs-small.jpg" data-sys-asset-uid="bltf9bdf54b4eeab8bc" alt="Logs-small.jpg" style="background-color: initial;"/> </td><td><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt1af8714b20964974/5c57d6ef16a7de000c2b32a0/visuals-small.jpg" data-sys-asset-uid="blt1af8714b20964974" alt="visuals-small.jpg"/> </td><td><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt7193fa48ab952fe4/5c57d6e94c9f4feb0b4c5843/discover-small.jpg" data-sys-asset-uid="blt7193fa48ab952fe4" alt="discover-small.jpg"/> </td></tr></tbody></table><h3>Expérience utilisateur</h3><p>L’utilisation de l’IU Logs est similaire à l’utilisation d’une commande tail, sauf que dans le cas présent, ce sont tous les logs de tous vos systèmes qui sont surveillés dans une console. Au fur et à mesure que les logs sont générés, la partie inférieure de la vue affiche l’enregistrement le plus récent, comme si une commande tail -f était exécutée. Par défaut, l’IU Logs affiche l’ensemble des enregistrements de tous les logs répondant aux critères de configuration (que nous verrons plus en détail dans la prochaine section). Si vous travaillez sur un problème et que vous n’avez pas besoin de tous les logs de tous les services (qui apparaissent trop vite pour que vous puissiez tous les lire), servez-vous de la barre de recherche située en haut pour afficher ceux qui vous intéressent. Par exemple, si je veux voir uniquement les erreurs&nbsp;404 des pods httpd d’Apache avec le niveau de balise Kubernetes = “frontend”, je vais l’indiquer dans la barre de recherche et laisser la saisie semi-automatique m’aider à trouver les logs appropriés&nbsp;:</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt6f7988e6a847040c/5ca7ef626583cf3c4114a271/animated-gif-logs-ui-optimized.gif"/></p><p>Cela revient à ouvrir un terminal, vous authentifier avec votre fournisseur k8s, déterminer les pods dont vous avez besoin et exécuter kubectl logs -f … | grep 404 (ou, dans une approche sans conteneurs, déterminer les noms d’hôte, se connecter avec SSH, surveiller les dernières lignes des logs, etc.). Notre but est de vous faciliter la vie et de mettre à votre disposition les données dont vous avez besoin selon la méthode que vous souhaitez.</p><h3>Configuration</h3><p>La <a href="/guide/en/kibana/6.x/xpack-logs.html">documentation sur l’interface utilisateur Logs</a> se trouve à l’emplacement habituel. Toutefois, je voudrais attirer votre attention sur certaines options de configuration ici. Voici la configuration par défaut que vous pouvez coller dans config/kibana.yml, à laquelle vous pouvez apporter des modifications&nbsp;:</p><pre class="prettyprint">xpack.infra.sources.default.logAlias: "filebeat-*"<br/>xpack.infra.sources.default.fields.timestamp: "@timestamp"<br/>xpack.infra.sources.default.fields.message: ['message', '@message']<br/></pre><p>La configuration est assez simple et directement prête à l’emploi. Les lignes affichées dans l’interface utilisateur Logs représentent le champ message de chaque index correspondant à l’alias filebeat-*. Que faire si vous souhaitez ajouter tous vos index Logstash&nbsp;? Modifiez tout simplement xpack.infra.sources.default.logAlias en entrée config/kibana.yml comme ci-dessous et redémarrez Kibana&nbsp;:</p><pre class="prettyprint">#xpack.infra.sources.default.logAlias: "filebeat-*"<br/>xpack.infra.sources.default.logAlias: "filebeat-*,logstash-*"<br/></pre><p>N’oubliez pas de redémarrer Kibana&nbsp;! Ouvrez à nouveau l’interface utilisateur Logs et cliquez sur Stream Live (Streaming en direct). Vous devriez y voir tous vos logs Logstash et Filebeat s’afficher.</p><p><strong>Remarque&nbsp;:</strong> Si vous préférez utiliser les <a href="/guide/en/elasticsearch/reference/6.5/indices-aliases.html">alias Elasticsearch</a>, définissez tout simplement xpack.infra.sources.default.logAlias sur le nom de l’alias, puis mettez l’alias à jour selon vos besoins. Voici la procédure équivalente utilisant un alias de logs.</p><p>Créez l’alias&nbsp;:</p><pre class="prettyprint">curl -X POST "localhost:9200/_aliases" -H 'Content-Type: application/json' -d'<br/>{<br/>    "actions" : [<br/>        { "add" : { "indices" : ["logstash-*", "filebeat-*"], "alias" : "logs" } }<br/>    ]<br/>}<br/>'<br/></pre><p>Mettez à jour config/kibana.yml&nbsp;:</p><pre class="prettyprint">#xpack.infra.sources.default.logAlias: "filebeat-*"<br/>xpack.infra.sources.default.logAlias: "logs"<br/></pre><h2>Interface utilisateur Infrastructure</h2><h3>Motivation</h3><p>En matière de gestion de l’infrastructure, je considère qu’il existe trois niveaux de maturité de base&nbsp;:</p><ol><li>Déterminer que quelque chose ne fonctionne plus, puis ouvrir un système de monitoring pour approfondir l’analyse.</li><li><span></span>Représenter les indicateurs clés de tous les systèmes dans un grand tableau de bord, les observer, puis examiner les problèmes.</li><li>Automatiser les opérations à l’aide du Machine Learning qui apprend ce qu’est un comportement normal, détecte les problèmes émergents et alerte l’équipe opérationnelle.</li></ol><p>L’interface utilisateur Infrastructure a pour but d’aider l’équipe opérationnelle à “représenter les indicateurs clés dans un grand tableau de bord“. Je ne prendrai pas beaucoup de risques en disant que nous avons tous besoin de passer à l’étape “Automatisation avec le Machine Learning“. Pour en savoir plus, consultez cet article sur le <a href="/fr/products/stack/machine-learning">Machine Learning Elastic</a>. Si vous regardez la vidéo qui se trouve à la fin de l’article, vous verrez un workflow qui démarre par une alerte émise par une tâche de Machine Learning, puis qui évolue via l’APM et le traçage distribué, l’IU Infrastructure et l’IU Logs. Avec Elasticsearch, qui réunit les logs, les indicateurs, APM et le traçage distribué, vous pouvez tirer parti de tous les outils d’analyse et de visualisation sur l’ensemble de vos données.</p><p>Découvrons à présent l’IU Infrastructure. Dans cette vue, nous nous intéressons aux pods Kubernetes, qui sont regroupés par espace de nom. J’observe le trafic réseau entrant. En faisant un clic droit sur un pod, je peux accéder aux logs de ce pod ou à un tableau de bord d’indicateurs ayant subi une curation.</p><h3>Expérience utilisateur</h3><p>Aujourd’hui, trois types de dispositifs sont pris en charge&nbsp;: les hôtes, les pods Kubernetes (k8s) et les conteneurs Docker. Ce qui fait la puissance de l’IU Infrastructure, c’est que vous pouvez y voir l’état des indicateurs clés pour un grand nombre de dispositifs. Au niveau général, des carrés de couleur sont affichés sans texte, jusqu’à ce que vous décidiez d’explorer un sous-ensemble intéressant à l’aide de la barre de recherche ou en cliquant sur un groupe. Vous pouvez également examiner les logs d’un dispositif ou afficher un tableau de bord d’indicateurs.</p><p>Pour revenir aux “indicateurs clés“, en voici la liste. Ils proviennent tous de Metricbeat&nbsp;:</p><p style="margin-left: 20px;">Hôtes&nbsp;: processeur, mémoire, charge, trafic entrant, trafic sortant et taux de logging<br/>Kubernetes&nbsp;: processeur, mémoire, trafic entrant, trafic sortant<br/>Docker&nbsp;: processeur, mémoire, trafic entrant, trafic sortant</p><p>Le regroupement vous permet de zoomer sur la liste des dispositifs. Si vous prenez en charge une application spécifique déployée avec Kubernetes, effectuez un regroupement par espace de nom. C’est la solution qui vous conviendra le mieux. Si vous pensez qu’un problème est lié à la surcharge d’un nœud donné, vous pouvez effectuer un regroupement à la fois par espace de nom et par nœud. Voici une liste des regroupements actuels (vous pouvez en utiliser jusqu’à deux par type de dispositif)&nbsp;:</p><p style="margin-left: 20px;">Hôtes&nbsp;: zone de disponibilité, type de machine, ID de projet, fournisseur cloud<br/>Kubernetes&nbsp;: espace de nom, nœud<br/>Docker&nbsp;: hôte, zone de disponibilité, type de machine, ID de projet, fournisseur</p><p>Si aucun des regroupements ci-dessous ne vous permet d’interagir de la façon que vous souhaitez avec vos données, utilisez dans ce cas la barre de recherche. Commencez tout simplement à taper, et la fonctionnalité de saisie semi-automatique <a href="/guide/en/kibana/6.5/kuery-query.html">Kibana Query Language</a> vous guidera. J’ai fourni un exemple plus haut avec le GIF de l’IU Logs&nbsp;: quand j’ai commencé à taper kubernetes, Kibana m’a proposé labels (balises) et tier (niveau), puis m’a offert différents choix d’après les éléments indexés dans Elasticsearch.</p><p>Une fois les ressources regroupées, vous pouvez démarrer l’exploration d’un groupe en cliquant dessus. Vous verrez alors plus de détails sur ce groupe. Si un hôte, un pod ou un conteneur particulier vous intéresse, consultez alors les logs ou les indicateurs qui y sont associés. Voici une vue partielle des indicateurs d’un hôte&nbsp;:</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt0db77ee61091f61f/5d2848c18e6f797b0da2f02e/screenshot-metrics-infrastructure-monitoring-feature-page.jpg"/></p><h3>Configuration</h3><p>L’IU Infrastructure nécessite très peu de configuration. Déployez simplement Metricbeat et activez le <a href="/guide/en/beats/metricbeat/6.5/metricbeat-module-system.html">module System</a>. Si vous exécutez des conteneurs, activez également les modules <a href="/guide/en/beats/metricbeat/6.5/metricbeat-module-kubernetes.html">Kubernetes</a> et <a href="/guide/en/beats/metricbeat/6.5/metricbeat-module-docker.html">Docker</a>.</p><p>À moins que vous ayez modifié le modèle d'indexation par défaut (metricbeat-*), c’est fini&nbsp;! Si vous avez besoin de personnaliser certains éléments, la <a href="/guide/en/kibana/6.x/xpack-infra.html">documentation relative à l’IU Infrastructure</a> vous donnera des explications. De mon côté, je vous fournis les principales options ci-dessous&nbsp;:</p><pre class="prettyprint">xpack.infra.sources.default.metricAlias: "metricbeat-*"<br/>xpack.infra.sources.default.fields.host: "beat.hostname"<br/>xpack.infra.sources.default.fields.container: "docker.container.name"<br/>xpack.infra.sources.default.fields.pod: "kubernetes.pod.name"<br/></pre><h2>Vous aussi, vous avez votre mot à dire&nbsp;!</h2><p>Ces deux interfaces sont encore en version bêta. Qu’en pensez-vous&nbsp;? Faites-nous part de vos réflexions (même lorsque ces interfaces auront été lancées de façon générale). Dites-nous de quelle façon vous préférez interagir avec vos données. Les regroupements proposés dans la version bêta de l’IU Infrastructure sont-ils suffisants pour répondre aux besoins de votre équipe&nbsp;? Quels seraient ceux qui conviendraient&nbsp;? Les indicateurs déterminant les couleurs sont-ils appropriés&nbsp;? Souhaitez-vous une méthode différente pour filtrer les logs dans l’IU Logs&nbsp;? Lorsque vous consultez la vue des indicateurs à partir de l’IU Infrastructure, visualisez-vous les indicateurs qui vous intéressent&nbsp;?</p><p>Rendez-vous sur le <a href="https://discuss.elastic.co/c/kibana">forum de discussion de Kibana</a> et dites-nous ce que vous aimez, ce que vous n’aimez pas, ce dont vous avez besoin etc. Les développeurs lisent vos commentaires et y répondent, car il est important pour eux d’avoir votre avis. Vous pouvez également signaler un problème, soumettre une requête d’extraction, ou garder un œil sur l’un et l’autre dans <a href="https://github.com/elastic/kibana">GitHub</a>.</p><h2>À vous d’essayer&nbsp;!</h2><p>Notre <a href="https://demo.elastic.co/">système de démo</a> en direct contient des logs et des indicateurs que vous pouvez consulter, sur lesquels vous pouvez faire des recherches et avec lesquels vous pouvez interagir. Maintenant, c’est à vous de jouer. Cliquez sur la mosaïque Infrastructure pour lancer l’IU Infrastructure&nbsp;:</p><p><a href="https://demo.elastic.co"><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltc85a8861b14f7f05/5c57d682a669c2e50b763c45/JumpIn.jpg" data-sys-asset-uid="bltc85a8861b14f7f05" alt="JumpIn.jpg" width="200" height="187" style="width: 200;height: 187;"/></a></p><p>Vous pouvez basculer vers la vue Kubernetes ou Docker, faire des groupes d’objets à l’aide de l’IU, ou affiner la vue en vous servant de la barre de recherche. Cliquez avec le bouton gauche sur un hôte, un pod ou un conteneur, et lancez l’IU Logs pour cet objet. Et tant que vous êtes sur demo.elastic.co, jetez un œil aux tableaux de bord et visualisations proposés. À partir de la <a href="https://demo.elastic.co/">page d’accueil</a>, vous pouvez accéder à différentes zones.</p><h2>Démo</h2><p>Voici une vidéo qui présente le workflow de ces deux interfaces (ainsi que le Machine Learning et APM avec le traçage distribué). Merci encore de votre intérêt et merci d’avance pour vos commentaires&nbsp;!</p><div class="video embed-container" style="height: 478px;"><img style="width: 677;margin: auto;display: block;" class="vidyard-player-embed" src="https://play.vidyard.com/78EpMXQeU57jR7HrKsMXqK.jpg" data-uuid="78EpMXQeU57jR7HrKsMXqK" data-v="4" data-type="inline" width="677"/></div>

infrastructure-and-logs-background.jpg

infrastructure-and-logs-thumbnail.jpg

Infrastructure and Logs UI: New ways for Ops to interact with Elasticsearch

Interagissez différemment avec vos données grâce aux interfaces utilisateur Infrastructure et Logs

Monitorez les logs et les indicateurs Docker et K8s : envoyez les données avec Beats, analysez-les avec Elasticsearch et analyser-les dans Kibana.

<p>Ce blog présente le monitoring de l'environnement d'un conteneur, pouvant inclure <a href="https://cloud.google.com/kubernetes-engine/">Google Kubernetes Engine</a> (GKE), <a href="https://www.ibm.com/cloud/container-service">IBM Cloud Kubernetes Service</a> et tous les autres environnements Kubernetes (k8s) et&nbsp;Docker. Dans ce blog, j'utilise IBM Cloud Kubernetes Service.
</p>
<p>Vous vous demandez peut-être pourquoi le sujet de cet article est le monitoring des conteneurs Kubernetes et Docker. Les fournisseurs cloud gèrent l'infrastructure et je n'ai qu'à me soucier de mon application, n'est-ce pas&nbsp;? C'est peut-être vrai, mais je suis le genre de personne qui consulte les avis Yelp même si j'ai reçu des recommandations personnelles, et plus j'ai d'informations, mieux c'est. Je veux que tous les logs et indicateurs concernant mon application et son environnement soient disponibles. Je veux également pouvoir rechercher, visualiser et créer des alertes à leur sujet. Ce monitoring classique des conteneurs est génial, mais je vais aussi vous présenter une façon sympa d'utiliser les événements et les métadonnées Kubernetes&nbsp;pour annoter le diagramme de performances de mon application avec des notifications concernant la montée en charge ou les mises à niveau.
</p>
<p>Avant de poursuivre, définissons quelques termes.
</p>
<ul>
	<li><strong>Log&nbsp;:</strong> un horodatage et un message. Il pourrait comprendre des entrées de logs classiques telles que "NGINX started at 13:42" (NGINX a démarré à 13:42) ainsi que des événements k8s tels que "There was an NGINX container with a Back-off restarting failed container at 16:20" (Un conteneur NGINX&nbsp;a envoyé des messages plusieurs fois et n'a pas pu redémarrer à 16:20).</li>
	<li><strong>Indicateur&nbsp;:</strong> une mesure numérique collectée au cours d'une période définie. Par exemple, "Sales through the eCommerce site were $50,000 over the past ten minutes" (Les ventes sur le site d'e-commerce s'élevaient à 50&nbsp;000&nbsp;$ ces dix dernières minutes) ou "CPU utilization was 17% from 14:00:00&nbsp;to 14:00:10" (L'utilisation du processeur était de 17&nbsp;% de 14:00:00&nbsp;à 14:00:10).</li>
</ul>
<h2>Déploiement de l'application dans un cluster Kubernetes</h2>
<p>Pour mon exemple, je vais utiliser cette application basée sur Apache HTTP Server, PHP et Redis.
</p>
<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltb6c40127948a43cc/5c305565760e7f7a666d690f/k8s-module-1.png" data-sys-asset-uid="bltb6c40127948a43cc" alt="k8s-module-1.png">
</p>
<p>D'autre part, pour monitorer l'application et l'infrastructure du conteneur, nous avons&nbsp;:&nbsp;
</p>
<ul>
	<li>Un déploiement Elasticsearch Service hébergé sur Elastic Cloud.</li>
	<li><span></span>Les agents Beats, les agents légers de transfert de logs et d'indicateurs sont déployés comme un DaemonSet dans le même cluster Kubernetes. Notez que cela peut remplacer Fluentd qui est généralement déployé dans un cluster Kubernetes.</li>
</ul>
<h2>Logs et indicateurs</h2>
<p>L'application ci-dessus n'est qu'une partie d'un écosystème qui génère en permanence des informations que nous devrions collecter. Voici les niveaux à partir desquels nous collectons ces logs et indicateurs&nbsp;:
</p>
<ol>
	<li>Orchestration (Kubernetes)</li>
	<li><span></span>Hôtes</li>
	<li>Application</li>
	<li>Conteneur (Docker)</li>
</ol>
<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltd3029c1072fc382e/5c57e478bc5d07ed0b48c928/k8s-module-2.png" data-sys-asset-uid="bltd3029c1072fc382e" alt="k8s-module-2.png">
</p>
<p>Pour collecter les données, nous utilisons les agents&nbsp;<a href="/fr/products/beats">Beats</a> (Filebeat, Metricbeat et Packetbeat) et les modules System, Kubernetes et Docker ainsi que des modules pour l'application (Apache et Redis). Nous avons déployé un <a href="https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/">DaemonSet</a> pour chaque agent Beat et nous laissons Kubernetes&nbsp;les gérer. Si la liste semble longue, ne vous laissez pas effrayer. En effet, la fonctionnalité Autodiscover de Beats vous simplifie&nbsp;la&nbsp;tâche.&nbsp; Dans&nbsp;<a href="/fr/blog/monitoring-an-application-running-in-docker-containers-and-kubernetes-with-the-elastic-stack">ce blog</a>&nbsp;et dans la vidéo qui l'accompagne, vous trouverez les détails du déploiement des agents Beats pour monitorer une application.&nbsp; En fait, si vous souhaitez commencer par le commencement, consultez la <a href="/fr/docker-kubernetes-container-monitoring">page du monitoring des conteneurs</a>.<span></span>
</p>
<p>Pour indexer, stocker, rechercher, analyser et visualiser les données, j’ai utilisé <a href="/fr/cloud/elasticsearch-service/signup">Elasticsearch Service</a>&nbsp;hébergé sur Elastic Cloud.&nbsp;Le déploiement d’Elasticsearch Service sur Elastic Cloud est <a href="/fr/start">détaillé dans notre page "Getting Started"</a>&nbsp;tout&nbsp;comme le déploiement d’Elasticsearch et de Kibana dans un système que vous gérez vous-même.&nbsp;Dans tous les cas, ça fonctionne très bien.
</p>
<p>J'ai évoqué les agents Beats et les modules, et je pense que ceux-ci méritent une meilleure introduction. Un agent Beat est un agent léger qui envoie des données à Elasticsearch ou Logstash. Parfois, les agents Beats sont déployés à l'origine des données, comme sur un système physique ou virtuel. D'autres fois, ils sont déployés parallèlement aux sources, comme, par exemple, un DaemonSet (c’est ce que j'ai fait ici). Les modules simplifient la collecte, l'analyse, l'indexation et la visualisation des formats de logs les plus courants.
</p>
<p>Ce que je viens de vous présenter peut vous&nbsp;sembler un peu ennuyeux. Voyons les choses sous un autre angle&nbsp;: les modules Elastic propose une expérience prête à l'emploi. Imaginons que vous savez tout de la gestion d'Apache HTTPD Server, mais que vous ne connaissez pas NGINX. Vous pourriez aller voir quelqu'un qui s'y connaît en NGINX&nbsp;et lui demander "À quoi fais-tu attention dans les logs&nbsp;? À quels indicateurs fais-tu attention&nbsp;? Peux-tu me donner les greps de ton fichier d'historique&nbsp;?" Selon moi, les réponses à ces questions définissent les modules des agents Beats&nbsp;: tableaux de bord prédéfinis, recherches enregistrées, analyse et collecte pour des tas de choses comme Kubernetes, Docker, NGINX, Apache, systèmes d'exploitation, bases de données, etc. D'après mon expérience, il s'agit d'un ensemble de fonctionnalités très puissantes.
</p>
<p>Le <a href="https://www.elastic.co/guide/en/beats/metricbeat/current/metricbeat-module-kubernetes.html">module k8s</a> collecte des indicateurs relatifs aux pods, nœuds, volumes, ReplicaSets, déploiements, etc. Chaque indicateur possède un ensemble riche de métadonnées pour que vous puissiez relier les données à votre application. Par exemple, vous pourriez ne pas vous soucier du fait que le pod <em>xyz</em> soit proche de la limite d'utilisation de la mémoire, mais si cet indicateur est présenté en association avec le frontend de votre application, alors vous connaissez la valeur pour votre entreprise. Il collecte également des événements (souvenez-vous, j'avais inclus les événements Kubernetes dans la définition du log ci-dessus) que nous utilisons pour enrichir le diagramme de performances dans la vidéo ci-dessous.
</p>
<p>Le <a href="https://www.elastic.co/guide/en/beats/metricbeat/current/metricbeat-module-docker.html">module Docker</a> collecte des indicateurs relatifs aux conteneurs, aux hôtes, à la mémoire, au réseau, aux vérifications d'intégrité, etc. À l'instar du module Kubernetes, les métadonnées sont très précieuses pour comprendre les performances de votre application et de l'environnement.
</p>
<p>Il existe de nombreux autres <a href="https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-modules.html">modules pour Filebeat</a> et <a href="https://www.elastic.co/guide/en/beats/metricbeat/current/metricbeat-modules.html">Metricbeat</a>.&nbsp;En outre, <a href="https://www.elastic.co/guide/en/beats/packetbeat/current/visualizing-data-packetbeat.html">Packetbeat</a> est compatible avec de nombreux tableaux de bord pour des services tels que Cassandra, Flows, HTTP, MySQL, MongoDB, etc.
</p>
<p>Regardez cette vidéo et découvrez à quel point il est facile de transformer les données en renseignements exploitables. La vidéo traite les points suivants&nbsp;:
</p>
<ul>
	<li>Visualiser les événements&nbsp;Kubernetes&nbsp;avec les indicateurs de performance de l'application
	</li>
	<li>Découvrir l'ensemble d'indicateurs d'événements du module Metricbeat Kubernetes
	</li>
	<li>Naviguer dans les événements Kubernetes et créer la visualisation personnalisée</li>
</ul>
<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/FMHRF7JA2JhmPqpTNm4edp.jpg" data-uuid="FMHRF7JA2JhmPqpTNm4edp" data-v="4" data-type="inline">
</div>

Mashup-dashboards.jpg

MetricBeatDocker-Dash.png

Monitoring Kubernetes and Docker Containers with Beats: Logs, Metrics, and Metadata

Monitoring des conteneurs Kubernetes et Docker avec Beats : logs, indicateurs et métadonnées

Start free trial

Blog Footer CTA

Sign up for Elastic Cloud free trial

Customer Success Manager

Dan Roscigno

<p>By submitting you acknowledge that you've read and agree to our <a href="/legal/elastic-cloud-account-terms" target="_self">Terms of Service</a>, and you agree to receive the <a href="/legal/privacy-statement#how-we-use-the-information" target="_self">selected communications</a> at the contact details you provided above. See <a href="/legal/privacy-statement/" target="_self">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.</p>

Communication Preferences - ONLY for /communication-preferences

<p>En confirmant votre envoi, vous reconnaissez que vous avez lu et que vous acceptez nos <a href="/fr/legal/elastic-cloud-account-terms" target="_self">Conditions générales d'utilisation</a>, et vous acceptez de recevoir les <a href="/fr/legal/privacy-statement#how-we-use-the-information" target="_self">types de notification sélectionnés</a> à l'adresse que vous avez fournie plus haut. Pour en savoir plus ou pour revenir sur votre décision (possible à tout moment), consultez la <a href="/fr/legal/privacy-statement/" target="_self">Déclaration de confidentialité d'Elastic</a>.</p>

<p>By submitting you acknowledge that you've read and agree to our <a href="/legal/elastic-cloud-account-terms" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.</p><p>By submitting this form, I agree to Elastic sharing my contact information with Google Cloud. I also agree to Elastic giving my information to the vendor for the purpose of shipping my food package.</p>

GDPR Text + Google Cloud

<p>By submitting you acknowledge that you've read and agree to our <a href="/legal/serverless-preview-terms" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.</p>

Serverless GDPR Text

<p>En confirmant votre envoi, vous reconnaissez que vous avez lu et que vous acceptez nos <a href="/fr/legal/serverless-preview-terms" target="_self">Conditions générales d'utilisation</a>, et vous permettez à Elastic de <a href="/fr/legal/privacy-statement#how-we-use-the-information" target="_self">vous contacter</a> à propos de produits et services similaires en utilisant les informations que vous avez fournies plus haut. Pour en savoir plus ou pour revenir sur votre décision (possible à tout moment), consultez la <a href="/fr/legal/privacy-statement/" target="_self">Déclaration de confidentialité d'Elastic</a>.</p>

<p>By submitting you agree to <a href="/agreements/global/cloud-services-monthly" rel="nofollow">Elastic Cloud Terms of Service</a>. Your personal data will be processed in accordance with <a href="/legal/privacy-statement">Elastic's Privacy Statement</a>.</p>

Cloud Trial GDPR Text

<p>En envoyant votre demande d'inscription, vous acceptez les <a href="/fr/agreements/global/cloud-services-monthly" rel="nofollow">conditions générales d'utilisation d'Elastic Cloud</a>. Vos données personnelles seront traitées conformément à la <a href="/fr/legal/privacy-statement">déclaration de confidentialité d'Elastic</a>.
</p>

<p>By submitting you acknowledge that you've read and agree to our <a href="/legal/terms-of-use" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.</p>

Newsletter GDPR Text

<p>En confirmant votre envoi, vous reconnaissez que vous avez lu et que vous acceptez nos <a href="/fr/legal/terms-of-use" target="_self">Conditions générales d'utilisation</a>, et vous permettez à Elastic de <a href="/fr/legal/privacy-statement#how-we-use-the-information" target="_self">vous contacter</a> à propos de produits et services similaires en utilisant les informations que vous avez fournies plus haut. Pour en savoir plus ou pour revenir sur votre décision (possible à tout moment), consultez la <a href="/fr/legal/privacy-statement/" target="_self">Déclaration de confidentialité d'Elastic</a>.</p>

Explore similar demos

Overview

You'll also receive an email with related content.

You'll also receive an email with related content

Nous vous enverrons plus de contenu susceptible de vous intéresser.

Speakers

Close

The content on this page is not available in the selected language. As Elastic grows globally, we continue to support content in multiple languages.

The content on this page is not available in the selected language.

Le contenu de cette page n'est pas disponible dans la langue sélectionnée. Chez Elastic, nous mettons tout en œuvre pour vous proposer du contenu dans différentes langues. En attendant, nous vous remercions de votre patience !

See more insights

Articles by

Author

Learn more

Watch now (no PT)

Watch now

See all top stories

All (no PT translation)

Contact information

Press Release

Share on Reddit

Share this story

Share by Email

Thank you for your interest!

Contact Info

Follow us on Youtube

Load More

Share on LinkedIn

Follow us on LinkedIn

Search Integrations

All Solutions

Video for

Follow us on Twitter

See when this webinar starts in my time zone

Voir à quelle heure débute le webinar dans mon fuseau horaire

Register to Watch

Register now

See All Posts

Can't make it? Register and we'll send you the recording. You'll also receive an email with related content

Si vous ne pouvez pas vous libérer le jour J, inscrivez-vous et nous vous enverrons l'enregistrement. Vous recevrez aussi un e-mail contenant des ressources connexes.

Small image for

On-demand webinar

Featured webinar

Register to Attend

Share on Facebook

Reset all

Upcoming webinar

View more posts

Print

Hosted by

Sign In to Attend

View next

Follow us on Facebook

Share

Highlights

Read less

Thank you for registering. We will send you a confirmation email soon.

Nous vous remercions de votre inscription. Vous allez recevoir un e-mail de confirmation.

Author

Articles by Dan Roscigno

Customer Success Manager, Elastic

L'observabilité dans Elasticsearch : adopter les standards Prometheus et OpenMetrics pour les indicateurs

Interagissez différemment avec vos données grâce aux interfaces utilisateur Infrastructure et Logs

Monitoring des conteneurs Kubernetes et Docker avec Beats : logs, indicateurs et métadonnées