Prise en main de la Suite Elastic et de Docker Compose : deuxième partie

Par

Eddie Mitchell

blog-thumb-virtual-stack.png

Bienvenue dans la deuxième partie de notre série Prise en main de la Suite Elastic® et de Docker Compose. Dans la première partie, nous avons abordé les bases de Docker Compose et nous avons vu comment mettre en place un cluster à nœud unique, qui inclut Elasticsearch®, Kibana®, Logstash®, Metricbeat et Filebeat. Si vous n'avez pas lu ce premier article, nous vous invitons à le consulter avant de poursuivre.

Dans cet article, nous allons nous servir du cluster précédemment mis en place et nous allons y ajouter de nouvelles fonctionnalités, telles que Fleet, Elastic Agent, APM et une application de démonstration. Pour rappel, Docker Compose n'est pas recommandé en production, même si la taille du cluster est plus grande.

Bien entendu, si vous avez déjà de l'expérience et que vous souhaitez simplement coder, n'hésitez pas à passer directement au référentiel GitHub pour accéder aux fichiers.

Entrons dans le vif du sujet !

Elastic Agent, Fleet, APM... au fait, de quoi s'agit-il ?

Si vous ne connaissez pas ces termes ou ces produits, pas de problème ! Nous allons commencer par prendre quelques minutes pour vous présenter ces fonctionnalités et leurs avantages. 

Dans l'architecture initiale de notre cluster, nous sommes restés sur quelque chose de basique en ce qui concerne le monitoring et l'ingestion de fichiers. En voici une représentation.

Aperçu d'Elastic Agent

Commençons par nous intéresser à Elastic Agent et à certains termes qui lui sont associés.

Elastic Agent permet de monitorer différents types de données (logs, indicateurs, etc.) de manière unifiée sur les hôtes. Il offre également une protection contre les menaces de sécurité, permet d'interroger les données des systèmes d'exploitation, transfère les données de matériel ou de service à distance, pour ne citer que ces quelques tâches. Elastic Agent rationalise et accélère le déploiement du monitoring sur votre infrastructure. Chaque instance de cet agent est associée à des politiques qui peuvent être mises à jour afin d'incorporer les intégrations aux nouvelles sources de données, mesures de sécurité et fonctionnalités additionnelles.

Les intégrations Elastic sont conçues pour vous permettre de collecter des données avec rapidité et facilité à partir de sources externes afin de faire ressortir des informations exploitables. Ces intégrations utilisent souvent des paramètres prédéfinis, des tableaux de bord, des visualisations et des pipelines afin de tirer des informations des indicateurs, des logs et des événements. La page des intégrations est accessible dans votre instance Kibana locale. Il est donc très simple de rechercher une intégration, de l'installer et de la configurer conjointement avec Elastic Agent et les politiques applicables. Vous trouverez aussi une liste des intégrations disponibles sur le site web d'Elastic.

Les politiques sont des collections de paramètres et d'intégrations qui définissent le fonctionnement d'une instance Elastic Agent. Plusieurs intégrations peuvent être attribuées à une politique, ce qui confère une grande flexibilité aux agents de données par rapport aux éléments qu'ils peuvent capturer. En attribuant une politique à plusieurs instances Elastic Agent, vous pouvez gérer et configurer de nombreux agents à une plus grande échelle grâce à Fleet.

Fleet est l'interface utilisateur dans Kibana qui permet de gérer les instances Elastic Agent et les politiques associées de manière centralisée. Cette interface utilisateur vous offre la possibilité d'afficher l'intégrité de chaque instance Elastic Agent, la version installée, l'heure du dernier contrôle ou de la dernière activité, et les informations relatives aux politiques. La communication vers chaque instance Elastic Agent est facilitée par Fleet via le serveur Fleet. Il est ainsi possible d'appliquer les mises à jour des nouvelles politiques au moment du contrôle, ainsi que de mettre à niveau les binaires ou les intégrations des instances Elastic Agent.

Le serveur Fleet est une instance Elastic Agent qui s'exécute en tant que coordinateur de la communication entre Fleet et toutes les instances Elastic Agent déployées.

*Ouf !*

Pour en savoir plus sur tous ces sujets, sur Elastic Agent et sur Fleet, consultez la documentation Elastic.

Nous allons intégrer Elastic Agent et Fleet pour montrer comment il est possible de collecter les logs et les indicateurs tout en gérant les politiques. Ajoutons-les au diagramme de notre architecture et voyons à quoi elle ressemble.

Elastic APM et application web personnalisée

Elastic APM est un système de monitoring des performances applicatives basé sur la Suite Elastic. L'utilisation d'instances Elastic APM Agent pour instrumenter votre code peut aider à simplifier les questions de dépannage et de performance en collectant des indicateurs, des traces, des logs, des erreurs et des exceptions, et en les transférant dans Elasticsearch pour les rendre visibles dans l'interface utilisateur APM.

Elastic APM peut être configuré dans le cloud ou localement de manière autogérée. Lorsque vous gérez une instance locale d'APM, vous pouvez choisir de gérer un binaire autonome de serveur APM ou d'utiliser APM en tant qu'intégration via Elastic Agent.

Pour notre démonstration de faisabilité en local, nous allons mettre en œuvre Elastic APM géré par Elastic Agent et les services Fleet.

La capacité à monitorer les performances applicatives est inutile si vous n'avez aucune application à monitorer. Vous avez déjà à votre disposition un code que vous souhaiteriez instrumenter avec l'une de nos instances APM Agent ? C'est parfait ! Si ce n'est pas le cas, pas de panique. Le référentiel GitHub propose une petite application en Python qui peut servir pour effectuer quelques tests de base. C'est elle que nous allons utiliser.

Nouvelle architecture

Regardons à nouveau le diagramme de notre architecture et voyons comment tout s'articule.

Comme vous pouvez le voir ici, nous avons le nouveau conteneur Fleet-Serveur, qui exécute Elastic Agent en tant que point de communication central pour toutes les communications des agents avec le cluster Elastic. Elastic Agent exécute l'intégration Elastic APM pour collecter les informations télémétriques à partir de notre application web personnalisée et de Kibana.

Communication et accès

Parmi les difficultés courantes qui accompagnent généralement la prise en main de Docker, il y a le fait de comprendre comment les communications fonctionnent. Avec tous les conteneurs, ports, certificats et URL qui ont été mentionnés, revenons un peu en arrière et découvrons comment cette nouvelle architecture s'articule lorsque les différents éléments doivent se parler.

Dans notre fichier docker-compose.yml, vous avez vu le code que nous utilisons pour générer les certificats des différents conteneurs. Voici ce à quoi il ressemble :

echo "Creating certs";
echo -ne \
"instances:\n"\
"  - name: es01\n"\
"    dns:\n"\
"       - es01\n"\
"       - localhost\n"\
"    ip:\n"\
"      - 127.0.0.1\n"\
"  - name: kibana\n"\
"    dns:\n"\
"      - kibana\n"\
"      - localhost\n"\
"    ip:\n"\
"      - 127.0.0.1\n"\
"  - name: fleet-server\n"\
"    dns:\n"\
"      - fleet-server\n"\
"      - localhost\n"\
"    ip:\n"\
"      - 127.0.0.1\n"\
> config/certs/instances.yml;

Ce bloc de code entraîne la création d'un fichier appelé instances.yml, résidant sur le conteneur "setup". Il s'agit d'une liste de tous les noms de conteneurs, accompagnés de leurs entrées DNS au sein du moteur Docker Engine. Nous utilisons ce fichier conjointement avec l'utilitaire elasticsearch-certutil afin de créer un certificat pour chaque conteneur et de sécuriser la communication des conteneurs lorsqu'ils communiquent entre eux et lorsque vous communiquez avec eux.
 
Tous nos conteneurs communiquent entre eux à l'aide du réseau par défaut que nous avons configuré dans docker-compose.yml comme suit :

networks:
  default:
    name: elastic

Ce réseau est interne au moteur Docker Engine et permet à tous les conteneurs de communiquer les uns avec les autres et de résoudre les noms d'autres conteneurs. Pour que le trafic de votre navigateur atteigne un conteneur, nous spécifions les ports nécessaires dans chaque service. Par exemple :

es01:
  depends_on:
    setup:
      condition: service_healthy
  image: docker.elastic.co/elasticsearch/elasticsearch:${STACK_VERSION}
  labels:
    co.elastic.logs/module: elasticsearch
  volumes:
    - certs:/usr/share/elasticsearch/config/certs
    - esdata01:/usr/share/elasticsearch/data
  ports:
    - ${ES_PORT}:9200
  environment:
    - node.name=es01
    - cluster.name=${CLUSTER_NAME}
    - discovery.type=single-node
  ...

Plus spécifiquement, nous regardons la section "ports:". Celle-ci indique à Docker Compose de mapper les ports indiqués en utilisant le format "hôte:conteneur". Dans cet exemple, `${ES_PORT}` serait remplacé par 9200 dans notre fichier .env, et le port correspondant s'ouvrirait sur notre ordinateur (hôte). 9200 est aussi le numéro du port sur le conteneur auquel nous mappons notre hôte. Ainsi, lorsque vous accédez à https://localhost:9200 à partir de votre navigateur, votre trafic est envoyé vers le conteneur es01.

Par défaut, Elasticsearch ouvre aussi le port 9300 pour permettre la communication entre nœuds. Bien que les autres conteneurs de votre moteur Docker soient capables d'accéder à ce port si nécessaire, vous ne pourrez pas le faire depuis votre hôte car nous n'avons pas encore spécifié ce port.

Si nous souhaitions tester et visualiser ces concepts à l'aide de notre nouvelle architecture, voici ce à quoi elle ressemblerait :

Dans ce graphique, le conteneur `metricbeat01` est capable de résoudre les noms que nous avons donnés à "es01" et "logstash01", et même d'accéder au port de monitoring 9600 non spécifié sur "logstash01" car ils résident dans le même réseau Docker.

Toutefois, pour que vous puissiez atteindre Elasticsearch sur le port 9200 et Kibana sur le port 5601, vous devrez passer par l'hôte local ("localhost") afin que votre machine puisse acheminer le trafic dans le réseau Docker et vers les conteneurs appropriés.

Pour finir, le choix de l'adresse à utiliser pour faire référence à un service peut être un véritable casse-tête. Ce qu'il faut garder à l'esprit, c'est que lorsque l'un de vos conteneurs accède à un autre conteneur configuré avec le réseau Elastic, vous devez utiliser le nom de service/conteneur approprié. En ce qui concerne le trafic de votre machine hôte, s'il accède à l'un des conteneurs, vous devrez alors vérifier que le port approprié a été spécifié dans docker-compose.yml et vous devrez accéder à ce port via "localhost".

Remarque : ces configurations constituent une première étape pour se lancer dans le développement en local. Néanmoins, leur utilisation n'est pas recommandée dans les environnements de production.

Mise en œuvre

À présent, passons à la mise en œuvre.

Tout d'abord, nous allons passer rapidement en vue notre pile de base et mettre en évidence quelques changements, en commençant par notre structure de fichiers, le fichier .env et docker-compose.yml 

Structure de fichiers

Dans notre structure de fichiers, nous avons ajouté le dossier "app" pour conserver l'ensemble du code et la configuration de notre application web personnalisée, aux côtés d'un nouveau fichier kibana.yml , car nous allons ajouter des paramètres spécifiques concernant Elastic Agent et APM.

.env

Notre fichier .env (lien GitHub) n'est que très légèrement modifié, avec l'ajout de nouveaux ports pour Fleet, le serveur APM et un token secret APM comme indiqué ci-dessous.

Le token secret servira ultérieurement dans la mise en œuvre pour autoriser les requêtes vers le serveur APM. Pour en savoir plus, lisez la documentation.

# Port to expose Fleet to the host
FLEET_PORT=8220


# Port to expose APM to the host
APMSERVER_PORT=8200


# APM Secret Token for POC environments only
ELASTIC_APM_SECRET_TOKEN=supersecrettoken

Pour rappel, les mots de passe et clés mentionnés dans cet article sont fournis à titre d'exemple uniquement et doivent être modifiés immédiatement dans vos environnements.

docker-compose.yml

Pour notre fichier docker-compose.yml, nous avons ajouté quelques éléments à la pile de base, à savoir des conteneurs pour le serveur Fleet et l'application web. Nous avons également ajouté des volumes supplémentaires, ainsi que "fleet-server" à notre liste de serveurs pour la génération de certificats, comme indiqué ci-dessus.

Vous pouvez retrouver l'intégralité du fichier sur GitHub, mais nous n'aborderons ici que quelques-unes des modifications.

Remarque concernant les variables d'environnement

Il existe un certain nombre de variables d'environnement dans les services existants pour lesquelles des certificats ont été spécifiés et transmis au conteneur ou au fichier de configuration correspondant.

Comme pour notre fichier .env, les variables d'environnement dans docker-compose.yml nous permettent de transmettre des variables à nos conteneurs. Dans cette optique, nous définissons une fois la variable `CA_CERT` dans notre conteneur. Celle-ci équivaut au chemin du certificat, ce qui fait que dans le fichier metricbeat.yml, nous pourrons ensuite utiliser cette variable quand nous en aurons besoin. Par la suite, si nous souhaitons mettre à jour CA_CERT, nous n'aurons besoin de mettre à jour le chemin qu'une seule fois dans docker-compose.yml, puis de redéployer le conteneur metricbeat.

Le conteneur metricbeat01 et le fichier metricbeat.yml illustrent bien la façon dont la variable d'environnement `CA_CERT` est transmise, puis utilisée plusieurs fois dans le fichier yml. 

Pour en savoir plus sur la définition et l'utilisation des variables d'environnement, cliquez ici.

docker-compose.yml (conteneur "fleet-server")

Avec l'ajout d'un conteneur `fleet-server` dans le fichier docker-compose.yml (lien GitHub), nous disposons d'un conteneur supplémentaire qui extrayait l'image Elastic Agent. Cette image permet de collecter des données en périphérie et sert d'image de base pour configurer le serveur de gestion Fleet.

Veuillez garder à l'esprit qu'il s'agit ici d'une démonstration de faisabilité en local, et que dans cette optique, les contrôles que nous appliquons concernant les certificats sont plus souples. Dans un environnement de production, il est impératif de procéder à une vérification stricte des certificats émis et utilisés.

Comme mentionné ci-dessus, nous spécifions deux ports pour les communications. 

ports:
  - ${FLEET_PORT}:8220
  - ${APMSERVER_PORT}:8200
  • Le port 8220 gère tout le trafic destiné aux communications Elastic Agent/Fleet.
  • Le port 8200 gère tout le trafic qui sera utilisé par le serveur APM étant donné que notre instance Elastic Agent héberge l'intégration APM.

Voici quelques-unes des principales configurations d'environnement :

Remarque : si vous souhaitez également configurer et exécuter des tests synthétiques, vous devrez utiliser l'image Docker `docker.elastic.co/beats/elastic-agent-complete:${STACK_VERSION}` à la place. Nous n'aborderons pas ce sujet dans cet article. Néanmoins, si vous souhaitez en savoir plus, consultez notre documentation.

docker-compose.yml (conteneur "kibana")

Pour le conteneur "kibana" (lien GitHub), deux changements sont nécessaires. Le premier concerne la connexion essentielle entre le fichier docker-compose.yml et le fichier kibana.yml dans la section "volumes". Cette ligne indique à Docker de monter le fichier kibana.yml de façon liée dans le conteneur à utiliser.

- ./kibana.yml:/usr/share/kibana/config/kibana.yml:ro

Le deuxième est un changement simple apporté à la fin des variables d'environnement, qui nous permet de passer via le token secret APM que nous avons initialement défini dans le fichier .env.

- ELASTIC_APM_SECRET_TOKEN=${ELASTIC_APM_SECRET_TOKEN}

kibana.yml

Nous ajoutons un nouveau fichier .yml pour configurer Kibana afin d'incorporer Fleet et Elastic Agent (lien GitHub).

Concrètement, xpack.fleet.packages nous permet d'indiquer que les packages collecteront automatiquement leurs actifs :

xpack.fleet.packages:
  - name: fleet_server
    version: latest
  - name: system
...

..tandis que xpack.fleet.agentPolicies permet de définir les politiques de base à utiliser pour les instances Fleet et Elastic Agent initiales :

xpack.fleet.agentPolicies:
  - name: Fleet-Server-Policy
    id: fleet-server-policy
    namespace: default
    monitoring_enabled: 
      - logs
      - metrics
...

Pour en savoir plus sur la configuration de politiques sans interface utilisateur, consultez notre documentation.

Nous ajoutons également une politique pour prendre en charge Elastic APM et les actifs des packages APM associés :

- name: apm-1
        package:
          name: apm
        inputs:
        - type: apm
          enabled: true
          vars:
          - name: host
            value: 0.0.0.0:8200
          - name: secret_token
            value: ${ELASTIC_APM_SECRET_TOKEN}

Nous configurons l'URL du serveur et le token secret pour veiller à ce que nos applications puissent communiquer de manière appropriée. 

En bonus, telemetry.enabled: "true" nous permet d'exécuter Elastic APM sur notre propre instance Kibana afin d'avoir des détails supplémentaires sur le fonctionnement d'APM.

docker-compose.yml (conteneur "webapp")

 webapp:
    build:
      context: app
    volumes:
      - "/var/lib/docker/containers:/var/lib/docker/containers:ro"
      - "/var/run/docker.sock:/var/run/docker.sock:ro"
      - "/sys/fs/cgroup:/hostfs/sys/fs/cgroup:ro"
      - "/proc:/hostfs/proc:ro"
      - "/:/hostfs:ro"
    ports:
      - 8000:8000

Pour notre exemple d'application web, nous utilisons un fichier dockerfile pour nous aider à créer notre application et à la déployer dans Docker.

Cette configuration de conteneur s'appuie en grande partie sur la commande de création `context: app`. Docker part du principe que "app" est un dossier, et c'est dans ce dossier que se trouve notre fichier Dockerfile. Ces attributs peuvent être plus spécifiques, mais dans le cadre de cet article, les hypothèses par défaut conviennent parfaitement.

Lorsque Docker Compose crée ce conteneur, il lit dans le dossier "app" et récupère le fichier dockerfile pour obtenir les instructions concernant la création de l'image à utiliser dans le conteneur.

Nous indiquons aussi que nous souhaitons spécifier le port 8000 et que nous voulons transférer certains "volumes" correspondant aux disponibilités de Metricbeat afin de monitorer les ressources.

app/dockerfile

# syntax=docker/dockerfile:1


FROM python:3.9-slim-buster


WORKDIR /app


COPY requirements.txt requirements.txt


RUN pip3 install -r requirements.txt


COPY main.py main.py


CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000", "--log-level", "info", "--workers", "1"]

Notre fichier dockerfile va désormais utiliser l'image "python:3.9-slim-buster" comme base à extraire. De là, il va créer le dossier /app, copier le fichier requirements.txt à partir de notre emplacement, puis procéder à l'installation via pip3.

Ensuite, il va copier notre application main.py et tenter d'exécuter l'application Uvicorn, qui se trouve dans main.py.

Remarque : l'ordre des opérations est important dans un fichier dockerfile par rapport à la mise en cache. Si vous modifiez l'un des fichiers cités dans le fichier dockerfile, le cache sera alors supprimé et une nouvelle extraction du fichier aura lieu. De manière générale, il est préférable de placer les fichiers qui sont souvent modifiés plus loin dans le fichier dockerfile, afin que les fichiers plus lents ou non modifiés puissent rester en cache pendant le processus de création.

app/main.py

L'application main.py (GitHub) est une application très simple qui combine FastAPI et NiceGUI. Cette application a été instrumentée avec l'instance Elastic APM Agent et Starlette. Quelques boutons permettent d'effectuer des appels qui enverront à dessein des erreurs et des messages dans notre environnement APM.

Python :

from elasticapm.contrib.starlette import ElasticAPM, make_apm_client

apm = make_apm_client({
      'SERVICE_NAME': 'my_python_service',
      'SECRET_TOKEN': 'supersecrettoken',
      'SERVER_URL': 'http://fleet-server:8200',
      'ENVIRONMENT': 'development'
  })

app = FastAPI()
app.add_middleware(ElasticAPM, client=apm)

apm.capture_message(f"Custom Message: {message}")

@app.get("/error")
async def throw_error():
    try:
        1 / 0
    except Exception as e:
        apm.capture_exception()
    return {"message": "Failed Successfully :)"}

Dans les extraits de code ci-dessus, nous avons importé la bibliothèque APM, créé le client APM et ajouté le middleware à notre application FastAPI.

Cette application n'est qu'un exemple pour montrer comment interagir avec Elastic APM.

Docker Compose up

Maintenant que tout est configuré, assemblons le cluster !

L'exécution de la commande docker compose up permet de rassembler tous les conteneurs et de vous connecter à Kibana sur https://localhost:5601. Pour rappel, comme nous utilisons désormais des certificats pour Kibana, vous devrez utiliser le protocole HTTPS. Il est possible que votre navigateur affiche des avertissements, auquel cas il faudra cliquer dessus.
Une fois connecté, accédez à Fleet via le menu déroulant -> Management (Gestion) -> Fleet.

Comme vous pouvez le constater, dans le menu Agents, il n'y a qu'un seul hôte. C'est sur cette page Fleet que vous pouvez consulter chacun des agents enregistrés dans votre cluster. Vous pouvez aussi créer ou modifier les politiques, enregistrer de nouveaux agents et mettre à jour les configurations Fleet générales.

Toutefois, vous remarquerez que les champs CPU (Processeur) et Memory (Mémoire) n'ont pas été mis à jour. De même, si vous cliquez sur le lien Host (Hôte), il semblerait que les logs n'aient pas non plus été renseignés. Après une vérification plus poussée, nous remarquons des erreurs dans les logs du conteneur fleet-server, telles que :

{"log.level":"info","message":"Attempting to reconnect to backoff(elasticsearch(http://localhost:9200)) with 17 reconnect attempt(s)","component":{"binary":"metricbeat","dataset":"elastic_agent.metricbeat","id":"http/metrics-monitoring","type":"http/metrics"},"log":{"source":"http/metrics-monitoring"},"log.origin":{"file.line":139,"file.name":"pipeline/client_worker.go"},"service.name":"metricbeat","ecs.version":"1.6.0","log.logger":"publisher_pipeline_output","ecs.version":"1.6.0"}
{"log.level":"error","message":"Error dialing dial tcp 127.0.0.1:9200: connect: connection refused","component":{"binary":"metricbeat","dataset":"elastic_agent.metricbeat","id":"http/metrics-monitoring","type":"http/metrics"},"log":{"source":"http/metrics-monitoring"},"service.name":"metricbeat","ecs.version":"1.6.0","log.logger":"esclientleg","log.origin":{"file.line":38,"file.name":"transport/logging.go"},"network":"tcp","address":"localhost:9200","ecs.version":"1.6.0"}

Ceci s'explique par le fait que, par défaut, notre instance Elastic Agent tente de logger des données dans une instance Elasticsearch locale, ce qui ne convient pas pour notre environnement Docker.

Nous devons effectuer quelques mises à jour dans l'interface Fleet -> Settings (Paramètres) pour résoudre ce problème. 

Regardons tout cela en détail.

Configuration de la sortie et ajout de certificat

Maintenant que nous avons accédé à Fleet -> Settings (Paramètres), la section qui nous intéresse est la section Outputs (Sorties). De là, nous cliquons sur le bouton Edit (Modifier) sous l'en-tête Actions :

Un curseur de défilement à droite nous permet de modifier la sortie par défaut.

Nous voulons modifier les champs "Hosts" (Hôtes) et "Elasticsearch CA trusted fingerprint" (Empreinte vérifiée de l'AC Elasticsearch), ainsi que la section "Advanced YAML configuration" (Configuration YAML avancée).

Néanmoins, nous n'avons pas encore toutes ces informations en notre possession. Accédons à un terminal pour les récupérer.

En premier lieu, nous devons extraire le certificat de l'AC à partir du cluster. La commande que nous utilisons est la même que dans la première partie :

docker cp es-cluster-es01-1:/usr/share/elasticsearch/config/certs/ca/ca.crt /tmp/.

Remarque : cette commande variera selon le répertoire à partir duquel vous exécutez le fichier docker-compose.yml ou selon la variable COMPOSE_PROJECT_NAME indiquée dans le fichier .env.

Ensuite, nous devons obtenir l'empreinte du certificat. Pour cela, nous pouvons utiliser une commande OpenSSL :

openssl x509 -fingerprint -sha256 -noout -in /tmp/ca.crt | awk -F"=" {' print $2 '} | sed s/://g

La valeur générée sera similaire à la valeur ci-dessous : 

5A7464CEABC54FA60CAD3BDF16395E69243B827898F5CCC93E5A38B8F78D5E72

Pour finir, nous devons disposer du certificat intégral au format yml. Pour cela, nous pouvons utiliser une commande `cat` ou simplement ouvrir le certificat dans un éditeur de texte :

cat /tmp/ca.crt

Une fois que nous avons le texte du certificat, nous l'enregistrons au format yml, puis nous entrons toutes les informations collectées dans l'écran Fleet -> Settings (Paramètres).

Pour le champ "Hosts" (Hôtes), nous indiquons https://es01:9200. En effet, le conteneur qui héberge le serveur Fleet comprend comment communiquer avec le conteneur es01 pour envoyer des données.

Entrons l'empreinte générée pour le champ "Elasticsearch CA trusted fingerprint" (Empreinte vérifiée de l'AC Elasticsearch).

Enfin, ajoutons le texte du certificat dans la section "Advanced YAML configuration" (Configuration YAML avancée). Étant donné qu'il s'agit d'une configuration yml, elle renverra une erreur si l'espacement n'est pas correct. 

Commençons par :

ssl:
certificate_authorities:
- |

Puis, collons le texte du certificat en nous assurant que l'espacement est correct.

Par exemple :

N'oubliez pas de cliquer sur "Save and Apply Settings" (Enregistrer et appliquer les paramètres) -> "Save and Deploy" (Enregistrer et déployer).

Examen des données Elastic Agent

Une fois que l'enregistrement et le déploiement ont été effectués, revenez à l'onglet Agents et cliquez sur le nom de votre agent. À présent, les champs CPU (Processeur) et Memory (Mémoire) devraient correctement s'afficher, tout comme les logs.

De là, vous pouvez aussi cliquer sur View more agent metrics (Voir plus d'indicateurs sur l'agent) pour accéder aux tableaux de bord de l'agent et afficher des données supplémentaires.

Consultez la documentation pour en savoir plus sur le monitoring des agents.

Examen des données Elastic APM

À partir du menu déroulant -> Observability (Observabilité) -> Overview (Aperçu), vous verrez aussi que des indicateurs Elastic APM commencent à circuler.

Plus précisément, accédez à APM -> Services : vous verrez Kibana et notre application de démonstration.

Vous pourrez ainsi plonger dans les détails des services et vous familiariser avec les types d'informations qu'Elastic APM capture.

Dépannage et scaling en toute fluidité avec la Suite Elastic

La deuxième partie de notre série Prise en main de la Suite Elastic et de Docker Compose s'est intéressée à de nouveaux aspects de la sécurité, ainsi qu'à des fonctionnalités telles qu'Elastic Agent, Fleet et Elastic APM. L'ajout d'une application personnalisée via un fichier Dockerfile nous a permis d'illustrer la mise en œuvre d'Elastic APM. 

Nous disposons ainsi d'une super plateforme locale d'apprentissage pour développer et tester nos fonctionnalités.

En instrumentant vos applications avec des instances Elastic APM Agent, vous pourrez plus facilement les monitorer, les améliorer et les dépanner par la suite. Elastic Agent et les services Fleet, quant à eux, faciliteront le scaling de votre instrumentation.

Pour rappel, même si nous nous sommes penchés ici sur l'utilisation d'Elastic Agent et d'APM, cette configuration permet également de tester des configurations OTel !

Lorsque vous vous sentirez prêt à utiliser un cluster en production, nous vous recommandons de vous lancer avec Elastic Cloud, qui vous permettra d'effectuer une transition fluide en appliquant ce que vous avez appris au niveau local dans un environnement prêt pour la production avec de nombreuses intégrations.

Tous les fichiers que nous avons mentionnés dans cet article sont disponibles sur GitHub. Vous avez des questions ? Des requêtes d'extraction ? Elles sont toutes les bienvenues !

La publication et la date de publication de toute fonctionnalité ou fonction décrite dans le présent article restent à la seule discrétion d'Elastic. Toute fonctionnalité ou fonction qui n'est actuellement pas disponible peut ne pas être livrée à temps ou ne pas être livrée du tout.

Inscrivez-vous à un essai gratuit d'Elastic Cloud

Optez pour un déploiement ultra-complet sur la plateforme cloud de votre choix. En tant que créateurs d'Elasticsearch, nous mettons nos fonctionnalités et notre support technique au service de vos clusters Elastic dans le cloud.

Démarrer un essai gratuit