Questions fréquentes

Les conteneurs partagent le noyau de l'OS hôte, ils sont donc plus légers et rapides.

Oui, elle commence par les concepts de base pour évoluer vers l'orchestration avancée.

C'est un script texte contenant les instructions pour construire une image Docker.

Un outil pour définir et exécuter des applications Docker multi-conteneurs.

C'est un registre public où l'on peut trouver et partager des images Docker.

L'outil natif de Docker pour orchestrer un cluster de moteurs Docker.

Oui, sauf si vous utilisez des volumes Docker pour persister les données.

Pour réduire la taille de l'image finale en excluant les outils de compilation.

Oui, vous pouvez imposer des limites CPU et RAM lors du lancement.

Kubernetes utilise des conteneurs standard (souvent Docker ou containerd) pour l'orchestration.

Oui pour des déploiements simples sur quelques hôtes : Swarm est intégré à Docker, se configure en quelques commandes et la formation y consacre un projet complet. Pour des besoins plus larges, Kubernetes prend le relais.

Un Dockerfile avec plusieurs étapes FROM : on compile dans une image complète puis on ne copie que le binaire dans une image minimale. L'image finale est plus petite et plus sûre.

Non : Docker Engine sous Linux suffit, ou les machines virtuelles fournies avec Vagrant. Docker Desktop est pratique sous Windows et macOS, mais sa licence est payante pour les grandes entreprises.

Elle est entièrement gratuite : aucun financement n'est nécessaire pour la suivre.

Un service qui stocke et distribue les images de conteneurs : Docker Hub, GitHub Container Registry, GitLab, Harbor ou les registres des clouds (ECR, ACR, Artifact Registry). On y pousse une image avec docker push et on la récupère avec docker pull.

Oui pour des besoins simples : Swarm est intégré à Docker, se met en place en quelques commandes et réutilise les fichiers Compose. Kubernetes reste la référence pour les plateformes de grande taille.

C'est une plateforme d'observabilité complète basée sur l'intelligence artificielle.

SaaS est hébergé par Dynatrace, Managed est installé sur votre propre infrastructure.

Un agent unique qui s'installe sur vos hôtes pour collecter automatiquement toutes les métriques et traces.

L'IA causale Davis s'appuie sur la topologie Smartscape et les dépendances observées pour regrouper les anomalies liées en un seul problème et désigner la cause racine la plus probable, avec les éléments qui la justifient. La qualité de cette analyse dépend de la couverture de l'instrumentation.

Le data lakehouse de Dynatrace conçu spécifiquement pour les données d'observabilité unifiées.

Oui, Dynatrace s'intègre parfaitement avec Docker, Kubernetes et OpenShift.

L'outil 'Monitoring as Code' pour gérer vos configurations Dynatrace comme du code.

Oui, avec les moniteurs synthétiques (Synthetic Monitoring).

Grâce aux DDU (Davis Data Units) qui permettent de suivre la consommation des différentes métriques.

Oui, il existe plusieurs niveaux comme Associate, Advanced Observability, etc.

SaaS : hébergé par Dynatrace, toujours à jour, accès à Grail et aux nouvelles applications. Managed : cluster hébergé chez vous, pour des contraintes de localisation des données. Un article de la formation compare les deux.

Avec la Dynatrace Platform Subscription (DPS), un budget unique est consommé par chaque capacité selon une grille tarifaire, au lieu de quotas séparés (Host Units, DEM, DDU).

La ressource personnalisée de l'opérateur Dynatrace sur Kubernetes : elle décrit l'environnement, le mode de déploiement de OneAgent (cloud-native full-stack, application) et l'ActiveGate ; l'opérateur s'occupe du reste.

Les DDU étaient l'unité de consommation des données (logs, métriques personnalisées, événements). La Dynatrace Platform Subscription facture désormais chaque capacité selon une rate card (prix unitaires par Go ingéré, conservé ou requêté, par heure d'hôte…).

Vagrant est un outil en ligne de commande permettant de créer et de gérer des environnements de développement virtuels reproductibles, portables et faciles à configurer.

Vagrant se concentre sur la gestion de machines virtuelles complètes (système d'exploitation isolé), alors que Docker gère des conteneurs qui partagent le noyau de l'hôte, les rendant plus légers mais moins isolés au niveau OS.

Une box est le format de packaging pour les environnements Vagrant. C'est une image de base compressée d'un système d'exploitation (ex: Ubuntu, CentOS) à partir de laquelle la VM est créée.

C'est le fichier central de configuration (en syntaxe Ruby) qui décrit le type de machine, les ressources (CPU, RAM), les dossiers partagés, le réseau et les scripts de configuration à exécuter.

Oui, Vagrant est agnostique. Bien que VirtualBox soit le standard, il supporte VMware, Hyper-V, Docker, et même des instances Cloud (AWS, Azure) via des plugins.

C'est l'étape d'automatisation où Vagrant installe les logiciels et configure la machine après son démarrage, utilisant des scripts Shell ou des outils comme Ansible, Chef ou Puppet.

C'est un reverse proxy et load balancer moderne, conçu pour les architectures microservices. Il découvre automatiquement la configuration de vos services.

Oui, il s'intègre nativement avec Let's Encrypt pour générer et renouveler automatiquement les certificats TLS.

La v2 a introduit les concepts de Routers, Middlewares et Services, offrant une configuration plus flexible et puissante que les frontends/backends de la v1.

Automatic Certificate Management Environment (RFC 8555) permet à un client (Traefik, certbot…) d'obtenir et de renouveler automatiquement des certificats auprès d'un serveur ACME comme Let's Encrypt, après avoir prouvé qu'il contrôle le domaine.

En HTTP-01, le serveur ACME lit un jeton sur http://domaine/.well-known/acme-challenge/ ; en DNS-01, il vérifie un enregistrement TXT _acme-challenge.domaine (seule méthode pour les certificats génériques) ; en TLS-ALPN-01, la preuve passe par le port 443.

On déclare un certificatesResolvers avec acme (e-mail, stockage acme.json et type de challenge), puis on l'associe au routeur : traefik.http.routers.app.tls.certresolver=le. Traefik renouvelle seul les certificats.

C'est un outil d'automatisation open-source pour la gestion de configuration, le déploiement d'applications et l'orchestration de tâches IT.

Non, Ansible est 'agentless'. Il communique avec les serveurs distants via SSH (pour Linux/Unix) ou WinRM (pour Windows).

C'est un fichier au format YAML qui décrit un ensemble de tâches ordonnées à exécuter sur un ou plusieurs serveurs cibles (l'inventaire).

La liste des machines gérées, regroupées par groupes (web, db…), au format INI ou YAML, statique ou dynamique (plugins AWS, Azure, GCP). On le vérifie avec ansible-inventory -i inventaire.yml --graph.

Un moteur de recherche et d'analyse distribué, basé sur Apache Lucene.

Une collection logique de documents JSON, découpée en shards (des index Lucene) répartis sur les nœuds du cluster. Ce n'est pas l'équivalent d'une base de données relationnelle : pas de tables ni de jointures, et un schéma (mapping) par index.

C'est une partition d'un index permettant de distribuer les données sur plusieurs nœuds.

C'est l'interface utilisateur pour visualiser et interagir avec les données d'Elasticsearch.

En utilisant les fonctionnalités de Role-Based Access Control (RBAC) et d'espaces Kibana.

Vous pouvez utiliser Query DSL via l'API, ou KQL (Kibana Query Language) dans l'interface.

Oui, via les Data Streams qui sont optimisés pour les données basées sur le temps.

Grâce aux Snapshots stockés dans un repository (NFS, S3, etc.) et gérés par des politiques SLM.

Oui, Elasticsearch supporte le Role Mapping avec des fournisseurs d'identité SAML, LDAP, etc.

Un nœud responsable de la gestion globale du cluster (création d'index, suivi des nœuds).

Une convention de nommage des champs (source.ip, user.name, event.category...) commune à toutes les données Elastic. Elastic SIEM s'appuie sur ECS pour appliquer les mêmes règles de détection à toutes les sources.

Index Lifecycle Management fait passer automatiquement les index par des phases (hot, warm, cold, frozen, delete) : rollover selon la taille ou l'âge, réduction des répliques, déplacement vers des nœuds moins chers puis suppression.

Elastic Cloud on Kubernetes est l'opérateur officiel qui déploie et administre Elasticsearch, Kibana et les agents Elastic sur Kubernetes (montées de version, certificats, mise à l'échelle).

ELK désigne historiquement Elasticsearch, Logstash et Kibana. Elastic Stack ajoute Beats et Elastic Agent pour la collecte : c'est le nom actuel de l'ensemble.

Un moteur de collecte de données open source permettant de traiter et d'enrichir des événements.

Une série d'étapes de traitement de données comprenant des inputs, filters et outputs.

Pour parser et structurer des textes non structurés en champs identifiables.

Beats est léger et collecte les données à la source, Logstash est un moteur lourd qui centralise et transforme la donnée.

Un pipeline comporte trois sections : input (d'où viennent les événements : beats, kafka, fichiers…), filter (transformation : grok, mutate, date…) et output (destination : elasticsearch, kafka, fichier…). Plusieurs pipelines se déclarent dans pipelines.yml.

Avec l'output elasticsearch : output { elasticsearch { hosts => ["https://es:9200"] index => "logs-%{+YYYY.MM.dd}" } }, en ajoutant l'authentification et le certificat de l'autorité de confiance.

Un système de supervision et d'alerting open source spécialisé dans les séries temporelles.

Il utilise un modèle 'pull' où le serveur vient récupérer les métriques sur les cibles.

Un agent qui traduit des métriques tierces au format compris par Prometheus.

Le langage d'interrogation puissant permettant de manipuler les séries temporelles.

En utilisant Pushgateway, car le modèle 'pull' n'est pas adapté pour les tâches très courtes.

Non, Prometheus gère uniquement les métriques. Logstash gère les logs.

Prometheus évalue les règles d'alerte et envoie les événements à Alertmanager.

Un outil pour collecter les métriques d'utilisation des conteneurs Docker/Kubernetes.

Oui, Prometheus est la source de données par défaut et la plus utilisée pour Grafana.

Oui, il intègre des mécanismes de découverte de services (Service Discovery).

Elle écoute sur le port 9090 (http://localhost:9090) ; sur Kubernetes, un kubectl port-forward vers le service Prometheus suffit. Elle sert à tester les requêtes PromQL et à vérifier les cibles.

Avec le Blackbox Exporter : sondes HTTP/HTTPS planifiées, mesure du temps de réponse et de la date d'expiration du certificat, et alertes associées.

Un opérateur Kubernetes qui déploie Prometheus et Alertmanager et génère leur configuration à partir de ressources ServiceMonitor, PodMonitor et PrometheusRule. Le chart kube-prometheus-stack l'installe avec Grafana.

C'est l'accès à la demande, via Internet, à des ressources informatiques partagées (serveurs, stockage, applications) avec un modèle de paiement à l'usage.

L'IaaS fournit l'infrastructure de base, le PaaS offre une plateforme pour les développeurs, et le SaaS propose des logiciels finis accessibles via navigateur.

C'est la capacité d'une infrastructure Cloud à augmenter ou réduire ses ressources automatiquement pour s'adapter à la charge en temps réel.

Selon le NIST, le cloud computing est un modèle d'accès à la demande, par le réseau, à un ensemble partagé de ressources informatiques configurables (serveurs, stockage, applications) rapidement fournies et libérées avec un effort de gestion minimal. Ses cinq caractéristiques : libre-service, accès réseau, mutualisation, élasticité et service mesuré.

En IaaS, le fournisseur gère le matériel et la virtualisation, vous gérez systèmes et applications (EC2, VM Azure). En PaaS, il gère aussi l'environnement d'exécution, vous déployez votre code (App Service, Cloud Run). En SaaS, vous utilisez une application prête à l'emploi (Microsoft 365, Salesforce). Le CaaS fournit des conteneurs managés, le DaaS des postes de travail virtuels.

Une infrastructure partagée par plusieurs organisations ayant des exigences communes (sécurité, conformité, secteur), gérée par elles ou par un tiers. C'est l'un des quatre modèles de déploiement du NIST avec le public, le privé et l'hybride.

Six stratégies de migration applicative : Rehost (lift and shift), Replatform (légère adaptation), Repurchase (passage au SaaS), Refactor (réécriture cloud native), Retire (abandon) et Retain (conservation sur site). AWS y ajoute Relocate (7R).

Une pratique qui associe finance, technique et métiers pour maîtriser la dépense cloud : visibilité des coûts par équipe (étiquettes), optimisation (dimensionnement, engagements, arrêt des ressources inutiles) et pilotage continu par des indicateurs.

C'est un standard et un ensemble d'outils open-source (API, SDK, Collector) pour l'instrumentation, la génération, la collecte et l'exportation de données de télémétrie (traces, métriques, logs).

C'est le protocole natif d'OpenTelemetry (OpenTelemetry Protocol) pour transporter les données de télémétrie de manière efficace et standardisée entre les différents composants.

Non, c'est l'un des avantages majeurs. OTel est agnostique et peut envoyer des données à de nombreux backends (Jaeger, Prometheus, Dynatrace, Datadog, etc.) via des exportateurs, vous évitant le 'vendor lock-in'.

Ce sont les noms standard des attributs, spans et métriques (par exemple http.request.method ou service.name). Elles rendent la télémétrie compréhensible par tous les outils ; un chapitre entier leur est consacré.

Oui, c'est le quatrième signal, encore en développement : OTLP le transporte et un profileur eBPF a été donné au projet. Le chapitre « Les profils » explique l'état actuel et comment relier un span à son profil dès aujourd'hui.

Ce sont les ports par défaut du protocole OTLP : 4317 pour OTLP/gRPC et 4318 pour OTLP/HTTP (chemins /v1/traces, /v1/metrics et /v1/logs).

OpenTelemetry Protocol, le protocole standard d'échange des traces, métriques et journaux entre SDK, Collector et back-ends (Tempo, Jaeger, Elastic, Datadog…).

C'est une plateforme open source de visualisation et d'analyse de métriques.

Grafana supporte de nombreuses sources comme Prometheus, Elasticsearch, InfluxDB, MySQL, PostgreSQL, etc.

Kibana est très lié à Elasticsearch pour les logs, Grafana est plus agnostique et excelle dans les métriques et l'intégration multi-sources.

Oui, Grafana dispose d'un système d'alerting puissant intégré.

Via l'authentification (LDAP, OAuth), le HTTPS et la gestion fine des permissions par dossier et tableau de bord.

Elle permet de rendre les tableaux de bord dynamiques (ex: filtrer par serveur ou environnement).

Oui, au format JSON pour les sauvegarder ou les partager.

Grafana Cloud est un service SaaS managé, l'auto-hébergement vous donne le contrôle total sur l'infrastructure.

Des marqueurs visuels sur les graphiques pour indiquer des événements (déploiements, pannes).

Oui, notamment avec Loki, la solution de logs intégrée à l'écosystème Grafana.

Loki (logs), Grafana (visualisation), Tempo (traces) et Mimir (métriques) : la pile d'observabilité open source de Grafana Labs, souvent alimentée par Grafana Alloy.

À interroger des API REST, du JSON, du CSV ou du XML directement depuis Grafana, sans base de données intermédiaire.

Prometheus, Loki, Tempo, Mimir, Elasticsearch, InfluxDB, PostgreSQL, MySQL, CloudWatch, Azure Monitor et des centaines d'autres via des plugins, dans un même tableau de bord.

C'est avant tout une culture de collaboration entre les équipes de développement (Dev) et d'opérations (Ops), soutenue par des pratiques (CI/CD, IaC) et des outils d'automatisation.

CI (Continuous Integration / Intégration Continue) est la pratique d'intégrer le code fréquemment dans un dépôt partagé. CD (Continuous Delivery/Deployment / Livraison/Déploiement Continu) est l'automatisation de la livraison ou du déploiement en production.

C'est la pratique de gérer et provisionner l'infrastructure (serveurs, réseaux, load balancers) via des fichiers de configuration versionnés (du code), comme avec Terraform ou Ansible, plutôt que par des configurations manuelles.

En livraison continue, chaque version validée peut partir en production en un clic ; en déploiement continu, elle y part automatiquement, sans intervention humaine. Le chapitre « CI/CD de bout en bout » détaille les deux.

C'est conseillé : les TP utilisent la ligne de commande, Docker et Git. La formation « Administration Linux » donne les bases nécessaires.

Ce sont des agents légers de la suite Elastic installés sur les serveurs pour collecter des données.

Filebeat collecte et envoie les logs de façon légère, Logstash est un moteur de transformation lourd.

Un agent dédié à la collecte des métriques système et services.

Elastic Agent est la nouvelle solution unifiée destinée à remplacer les Beats individuels.

L'interface centralisée dans Kibana pour configurer et mettre à jour massivement les Elastic Agents.

Oui, Winlogbeat est spécialement conçu pour les journaux d'événements Windows.

Principalement vers Elasticsearch ou Logstash, mais aussi Kafka ou Redis.

Non, ils sont écrits en Go et conçus pour être très légers.

Des configurations prêtes à l'emploi pour des systèmes courants (Nginx, MySQL) incluant des dashboards.

Oui, ils supportent le chiffrement SSL/TLS et l'authentification.

Les filebeat.prospectors ont été renommés filebeat.inputs (Filebeat 6.3). Depuis la version 8, l'input filestream remplace l'input log : chaque entrée a un id unique et la liste des chemins à lire.

C'est un système d'orchestration de conteneurs open-source qui automatise le déploiement, la mise à l'échelle et la gestion des applications conteneurisées.

Un Pod est la plus petite unité déployable dans Kubernetes, contenant un ou plusieurs conteneurs. Un Deployment est un objet de plus haut niveau qui gère des ReplicaSets, qui eux-mêmes s'assurent qu'un certain nombre de Pods identiques tournent en permanence.

C'est une abstraction qui définit un ensemble logique de Pods et une politique pour y accéder (via une IP et un port stables), agissant comme un point d'entrée et un load balancer interne.

ClusterIP (interne au cluster, par défaut), NodePort (port sur chaque nœud), LoadBalancer (équilibreur du fournisseur cloud) et ExternalName (alias DNS). Un article de la formation les détaille.

Flannel pour la simplicité, Calico pour les NetworkPolicies et le routage BGP, Cilium pour la performance eBPF, la sécurité et l'observabilité des flux.

Un volume de stockage du cluster, réservé par un pod au moyen d'un PersistentVolumeClaim et provisionné le plus souvent automatiquement par une StorageClass.

Pour la plupart des équipes, oui : EKS, AKS ou GKE gèrent le plan de contrôle et les mises à jour. La formation reste valable, car les objets Kubernetes sont les mêmes.

Les applications demandent du stockage par un PersistentVolumeClaim ; une StorageClass et son pilote CSI créent dynamiquement le PersistentVolume correspondant (disque cloud, NFS, Ceph…). Les StatefulSets associent un volume stable à chaque réplique.

C'est un collecteur de télémétrie open source et neutre vis-à-vis des fournisseurs, conçu pour remplacer Grafana Agent. Il est compatible Opentelemetry (OTel)

Oui, Alloy regroupe les fonctionnalités de Promtail, de Grafana Agent et intègre un support natif pour OpenTelemetry.

Alloy utilise une syntaxe déclarative basée sur River (similaire à HCL de Terraform) qui simplifie la création de pipelines.

Absolument, Alloy offre un support natif complet pour recevoir, traiter et exporter des données (Traces, Logs, Métriques) via le protocole OTLP.

L'interface web et l'API écoutent sur 12345 (127.0.0.1 par défaut, option --server.http.listen-addr). Les récepteurs ajoutent leurs propres ports, par exemple 4317 et 4318 pour OTLP.

Non : Alloy collecte et envoie (prometheus.scrape, prometheus.remote_write) vers Prometheus, Mimir ou un autre stockage compatible ; il ne stocke pas les métriques.

Avec le composant loki.source.syslog : un écouteur TCP ou UDP (par exemple 0.0.0.0:1514, format RFC 5424) dont la sortie est envoyée à loki.write, éventuellement après loki.relabel.

Plusieurs instances d'Alloy se répartissent automatiquement les cibles de collecte (scrape Prometheus, etc.) grâce à un hachage cohérent : on ajoute des instances pour monter en charge sans doublons.

HAProxy est réputé pour sa rapidité extrême et sa fiabilité. Contrairement à Nginx qui est un serveur web polyvalent, HAProxy est un pur spécialiste du load balancing avec des fonctions de santé et de persistance beaucoup plus fines.

Oui, parfaitement. Il peut soit faire du 'SSL Pass-through' (laisser le backend déchiffrer) soit de la 'Terminaison SSL' (HAProxy déchiffre et soulage les serveurs web).

Une ACL (Access Control List) permet de prendre des décisions de routage intelligentes basées sur des critères comme l'URL, l'adresse IP source ou des en-têtes HTTP.

En mode TCP, HAProxy lit le nom demandé (SNI) dans le message TLS et route sans déchiffrer : req.ssl_sni dans une règle use_backend. L'article Sécurité et SSL de la formation donne la configuration complète.

Le plan de contrôle d'HAProxy Technologies pour gérer et superviser centralement un parc d'instances HAProxy Enterprise.

nbthread adapté aux cœurs, maxconn dimensionné, keep-alive, HTTP/2 via ALPN, compression ciblée, et des ACL simples évaluées tôt.

La console de gestion centralisée d'HAProxy Enterprise : configuration, supervision et automatisation de flottes d'équilibreurs par API.

Un backend de traces distribuées de Grafana Labs qui n'exige qu'un stockage objet et s'intègre nativement à Grafana, Loki et Prometheus.

Tempo stocke dans un simple stockage objet sans index lourd et se requête avec TraceQL ; Jaeger s'appuie sur Elasticsearch ou Cassandra.

Le langage de requête de Tempo pour rechercher des spans par attributs, durée, statut et relations parent/enfant.

Via OTLP (gRPC 4317, HTTP 4318), directement depuis les SDK OpenTelemetry ou via Grafana Alloy.

Un système d'agrégation de logs de Grafana Labs, inspiré de Prometheus : il n'indexe que les labels des flux et stocke le contenu compressé dans un stockage objet, ce qui le rend économique.

Pour les logs d'applications et d'infrastructure, souvent oui. Si vous avez besoin de recherche plein texte sur de gros volumes sans contexte, Elasticsearch reste plus adapté.

LogQL, proche de PromQL : sélecteurs de labels, filtres de lignes, parsers et fonctions de métriques.

Grafana Alloy est le collecteur recommandé ; Promtail est déprécié.

La rétention est appliquée par le compactor : compactor.retention_enabled: true, puis limits_config.retention_period (par exemple 744h) ; retention_stream permet une durée différente par sélecteur de labels.

Le langage de requête de Loki, inspiré de PromQL : un sélecteur de flux {app="api"}, des filtres |= "error", des parseurs (| json, | logfmt) et des agrégations comme sum by (level) (rate({app="api"}[5m])).

À étendre Prometheus avec la haute disponibilité, une vue globale multi-clusters et un stockage long terme dans un stockage objet.

Non : Prometheus continue de collecter ; Thanos ajoute des composants autour (sidecar, query, store...).

Le sidecar est le modèle le plus simple (pull). Receive convient aux clusters isolés, au mode agent et au multi-tenant (push en remote write).

Deux compactors qui écrivent dans le même bucket risquent de corrompre les blocs.

Il tourne à côté de chaque Prometheus : il expose ses données récentes à Thanos Query et téléverse les blocs de 2 heures vers le stockage objet pour la rétention longue.

Il compacte les blocs du stockage objet, calcule le sous-échantillonnage (5 minutes, 1 heure) et applique la rétention. Une seule instance doit tourner par bucket.

Non : Prometheus (ou Alloy) continue de collecter les métriques ; Mimir les reçoit en remote_write, les stocke et les sert via la même API PromQL.

Thanos s'ajoute à des Prometheus existants (sidecar) et propose le downsampling ; Mimir centralise par remote_write et apporte un multi-tenant et des limites natives. Les deux stockent des blocs TSDB dans un stockage objet.

Non pour démarrer : le stockage en blocs classique fonctionne sans. Les versions récentes proposent une architecture d'ingestion via Kafka pour découpler lecture et écriture à grande échelle.

Oui, Mimir est open source (AGPLv3). Grafana Labs propose aussi une version gérée (Grafana Cloud Metrics) et une version entreprise.

Avec le chart Helm officiel : helm repo add grafana https://grafana.github.io/helm-charts puis helm install mimir grafana/mimir-distributed -n mimir --create-namespace, en configurant un stockage objet (S3, GCS, Azure ou MinIO).

Thanos s'ajoute à des Prometheus existants (sidecar, requêtes globales) ; Mimir reçoit les métriques par remote write dans un cluster multi-tenant conçu pour une très grande échelle. Les deux stockent à long terme dans un stockage objet.

C'est l'échantillonnage permanent, en production, des piles d'appels des processus, pour savoir quelles fonctions consomment CPU, mémoire ou temps d'attente.

En général 1 à 3 % de CPU, grâce à l'échantillonnage. eBPF est encore plus léger.

Non avec eBPF (profils CPU) ; oui avec les SDK, qui apportent labels métier, profils mémoire et liens vers les traces.

Go, Java, Python, Ruby, Node.js, .NET et Rust via les SDK ; tous les langages compilés et plusieurs interprétés via eBPF.

Non : Prometheus (ou Mimir, Loki, Grafana) évalue les règles ; Alertmanager reçoit les alertes et gère regroupement, routage et notifications.

Alertmanager déduplique les alertes identiques ; en cluster, les membres se coordonnent pour n'envoyer qu'une notification.

Alertmanager pour les règles Prometheus gérées comme du code ; Grafana Alerting pour des règles multi-sources. Gardez un seul endroit pour les routes.

Alerter sur les symptômes, regrouper, inhiber, couper les warnings la nuit et revoir chaque semaine les alertes non actionnables.

Prometheus évalue les règles et envoie les alertes ; Alertmanager les déduplique, les regroupe, les route vers la bonne équipe (e-mail, Slack, PagerDuty, webhook) et gère silences et inhibitions.

Le SLO est un objectif interne mesuré ; le SLA est un engagement contractuel avec des pénalités. Le SLO est plus strict que le SLA.

Non : c'est impossible et très coûteux. On fixe un objectif adapté aux attentes des utilisateurs et on utilise la marge comme budget.

La vitesse à laquelle le budget d'erreur est consommé : 1 l'épuise exactement sur la fenêtre, 14,4 en un peu plus de deux jours sur 30.

Les deux génèrent des règles Prometheus équivalentes ; Pyrra ajoute une interface web, Sloth une CLI simple et des dashboards Grafana.

Le SLI est la mesure (part des requêtes réussies en moins de 300 ms), le SLO l'objectif interne (99,9 % sur 30 jours) et le SLA l'engagement contractuel, assorti de pénalités, généralement moins exigeant que le SLO.

Non : les programmes eBPF s'attachent au noyau et aux processus existants. C'est tout l'intérêt de l'approche.

Le vérificateur du noyau empêche un programme de planter le noyau, mais les agents eBPF sont privilégiés : ils doivent être traités comme des composants sensibles.

5.8 au minimum pour la plupart des outils modernes, 5.15 ou plus recommandé, avec BTF activé.

Non, il le complète : eBPF couvre tout le parc sans effort, les SDK OpenTelemetry apportent le détail métier.

Une technologie du noyau Linux qui exécute de petits programmes vérifiés en réaction à des événements (appels système, paquets réseau, fonctions) : elle sert à l'observabilité, à la sécurité et au réseau (Cilium) sans modifier les applications.

Oui, k6 est open source (AGPLv3). Grafana Cloud propose en plus une exécution distribuée gérée et du monitoring synthétique.

Des bases de JavaScript suffisent : les scripts sont courts et les exemples de la formation sont complets.

Plusieurs milliers de VU HTTP sur une machine correcte ; au-delà, on distribue avec k6-operator.

k6 privilégie les scripts en code, versionnés et automatisés en CI, avec une faible consommation de ressources ; JMeter propose une interface graphique et un large écosystème de plugins.

Oui, le SDK Faro est open source, et le récepteur fait partie de Grafana Alloy. Grafana Cloud propose une version gérée (Frontend Observability).

Le SDK est léger et envoie ses données par lots ; l'impact est négligeable pour la plupart des sites.

Cela dépend des données collectées et de leur finalité : en cas de doute, initialisez Faro après consentement et minimisez les données.

Non : Faro mesure performance et erreurs pour les équipes techniques ; ce n'est pas un outil d'audience marketing.

Fluent Bit, écrit en C, consomme quelques mégaoctets de mémoire : il est fait pour les agents sur chaque nœud. Fluentd, en Ruby, reste utile comme agrégateur avec ses nombreux plugins, mais les nouveaux déploiements privilégient Fluent Bit.

Oui : il reçoit et émet de l'OTLP (input et output opentelemetry) pour les logs, les métriques et les traces.

Non : il interroge Elasticsearch et y enregistre ses propres objets (dashboards, règles, data views).

KQL filtre des documents ; ES|QL enchaîne filtres, calculs et agrégations. On utilise souvent KQL dans Discover et ES|QL pour l'analyse.

Kibana est utilisable gratuitement ; certaines fonctions (connecteurs tiers, sécurité au niveau document, SLO avancés) dépendent de la licence.

Oui : Elastic Observability ingère l'OTLP et publie ses distributions OpenTelemetry (EDOT).

Kibana Query Language est le langage de filtre de Kibana : service.name : "api" and http.response.status_code >= 500. Pour transformer et agréger les données, on utilise ES|QL.

La brique de traces et de performance applicative d'Elastic : agents ou SDK OpenTelemetry envoient transactions et spans, consultés dans Kibana avec les journaux et métriques associés.

Il peut remplacer son stockage (remote write) ou Prometheus entier avec vmagent et vmalert, tout en gardant PromQL et les mêmes fichiers de configuration.

Grâce à un format de stockage et une compression optimisés et à une faible mémoire par série active.

Rarement au début : le single-node gère plusieurs millions de séries actives. Le cluster sert au très grand volume et au multi-tenant.

Oui, c'est un sur-ensemble : les requêtes PromQL fonctionnent, avec des fonctions en plus.

Thanos prolonge Prometheus avec un stockage objet et des requêtes globales ; VictoriaMetrics est une base de séries temporelles autonome, très économe en ressources, qui reçoit les métriques par remote write ou vmagent et stocke sur disque.

La v2, fondée sur l'OpenTelemetry Collector, est la version actuelle ; la v1 est en fin de vie.

Non : on utilise les SDK OpenTelemetry, et Jaeger reçoit l'OTLP nativement.

Elasticsearch, OpenSearch ou Cassandra, éventuellement avec Kafka en tampon ; jamais la mémoire.

Tempo est plus économique et s'intègre à Grafana ; Jaeger offre une interface autonome et s'appuie sur des bases indexées.

La version auto-hébergée est open source ; une offre cloud payante et une édition entreprise existent.

Oui : l'instrumentation repose sur OpenTelemetry, il suffit de changer la destination du Collector.

Les deux stockent la télémétrie OpenTelemetry dans ClickHouse. SigNoz est une plateforme APM complète (services, alertes, tableaux de bord) ; ClickStack, de ClickHouse Inc., associe HyperDX à ClickHouse et met l'accent sur l'exploration en SQL et la recherche de journaux à grande échelle.

Oui, Zabbix est open source (AGPLv3 depuis la 7.0) ; l'éditeur vend du support et des services.

Zabbix excelle pour l'infrastructure classique, le réseau et SNMP avec une interface tout-en-un ; Prometheus pour les environnements cloud-native et Kubernetes. Ils cohabitent bien.

L'agent 2 (en Go) est recommandé : mêmes clés, plus des plugins (Docker, bases de données) et une meilleure gestion des contrôles actifs.

PostgreSQL avec TimescaleDB pour les grandes installations ; MySQL/MariaDB est aussi pris en charge.

Non : l'essai gratuit de 14 jours suffit pour tous les TP.

Oui, l'agent reçoit l'OTLP et Datadog convertit les attributs standard en tags.

Maîtriser la cardinalité des métriques, filtrer et échantillonner les logs, suivre l'usage avec des monitors dédiés.

Les deux sont des plateformes SaaS complètes ; Datadog mise sur la flexibilité et l'écosystème d'intégrations, Dynatrace sur l'automatisation et l'IA causale. Voir aussi la formation Dynatrace.

Installez l'opérateur (helm install datadog-operator datadog/datadog-operator), créez un secret contenant la clé d'API puis une ressource DatadogAgent : l'opérateur déploie l'agent sur chaque nœud et le Cluster Agent.

À mêler graphiques en direct, requêtes de logs et texte pour une enquête, un post-mortem ou un runbook partagé avec l'équipe.

Un plan de contrôle pour collecteurs OpenTelemetry : il construit les pipelines, les déploie par rollouts via OpAMP et mesure les volumes envoyés aux backends.

Non. Le serveur pousse les configurations et reçoit des mesures ; la télémétrie va directement des collecteurs aux destinations.

Non : l'offre Free (jusqu'à 10 collecteurs et 100 Go/jour) suffit pour tous les TP. Une clé de licence gratuite est nécessaire.

Alloy est une distribution du collecteur avec sa propre syntaxe ; Bindplane est un plan de contrôle qui gère des flottes de collecteurs. Un article de la formation les compare en détail.

Un éditeur d'outils d'observabilité et d'évaluation pour l'IA générative : Phoenix (open source) et Arize AX (plateforme).

Des conventions et instrumentations OpenTelemetry pour tracer LLM, RAG et agents, utilisées par Phoenix et Arize AX.

Non : un modèle local Ollama, via son API compatible OpenAI, suffit. Une clé OpenAI donne de meilleurs juges pour les évaluations.

Phoenix pour développer, évaluer et expérimenter, auto-hébergé ; Arize AX pour surveiller la production à grande échelle.

Oui : la grande majorité des serveurs, des conteneurs et des nœuds Kubernetes tournent sous Linux. Savoir lire des journaux, gérer des services, des droits et le réseau est la base de tous les métiers d'exploitation.

Les TP utilisent Ubuntu 24.04 LTS. Les équivalents Red Hat (dnf, firewalld, SELinux) sont donnés dans les cours : les concepts sont identiques.

Une machine virtuelle locale suffit (Multipass, Vagrant, VirtualBox) ou une petite instance cloud. Utilisez une machine jetable : certains TP modifient le pare-feu, SSH et les disques.

Elle couvre l'essentiel des programmes LFCS (Linux Foundation) et RHCSA (Red Hat) : utilisateurs, stockage, services, réseau, sécurité et scripts. Les examens étant pratiques, refaites les TP sans la correction.

Unix est un système né en 1969 dont dérivent des systèmes commerciaux (AIX, Solaris, macOS). Linux est un noyau libre créé en 1991 qui reprend les principes d'Unix ; le premier chapitre détaille ces différences.

Vector est un projet open source (licence MPL 2.0) maintenu par Datadog ; il envoie ses données vers des dizaines de destinations, pas seulement Datadog.

Oui pour tirer parti de Vector : VRL est un langage simple, typé et vérifié avant l'exécution, qui remplace les expressions régulières dispersées dans les configurations.

Le stockage en colonnes compresse fortement la télémétrie et accélère les agrégations, même à haute cardinalité.

Non pour la recherche courante dans HyperDX ; le SQL devient un atout pour les analyses avancées et les jointures avec vos données métier.

Non : les travaux pratiques utilisent LocalStack, qui émule les services AWS sur votre machine avec Docker. Vous pourrez ensuite reproduire les mêmes commandes sur un vrai compte (offre gratuite) en retirant simplement le préfixe « local ».

L'édition communautaire couvre S3, Lambda, API Gateway, DynamoDB, SQS, SNS, CloudFormation, IAM (sans application des politiques), EC2 simulé, etc. Certaines fonctions (application stricte d'IAM, RDS réel, EKS) demandent l'édition payante ou un vrai compte.

Cloud Practitioner (CLF-C02) valide les fondamentaux ; Solutions Architect Associate (SAA-C03) est la certification technique la plus demandée. Les deux ont un parcours de préparation à la fin de la formation.

Non pour les travaux pratiques : Azurite émule Blob, Queue et Table, les Functions s'exécutent localement et Bicep se compile et se teste localement. Un abonnement d'essai permet ensuite de déployer réellement.

Une émulation Azure par LocalStack existe en préversion ; la formation privilégie les émulateurs officiels de Microsoft (Azurite, émulateur Cosmos DB, Functions Core Tools), stables et gratuits.

AZ-900 valide les fondamentaux, sans prérequis ; AZ-104 valide les compétences d'administrateur et demande de la pratique. Les deux ont un parcours de préparation à la fin de la formation.

Non : les TP utilisent les émulateurs officiels de Pub/Sub et Firestore (fournis avec gcloud) et fake-gcs-server pour Cloud Storage. Le même code fonctionne ensuite sur Google Cloud en retirant les variables d'émulateur.

Les concepts sont proches ; Google Cloud se distingue par son VPC mondial, son équilibreur à IP anycast, BigQuery et un Kubernetes (GKE) de référence.

Hébergement européen, offres qualifiées SecNumCloud, tarifs prévisibles et standards ouverts (OpenStack, S3, Kubernetes) qui facilitent la réversibilité. Le catalogue de services managés est plus restreint : à évaluer selon vos besoins.

Les TP simulent les briques ouvertes : MinIO pour l'API S3, k3d pour Kubernetes et les fournisseurs simulés de terraform test pour valider le code Terraform. Les mêmes commandes s'appliquent ensuite au vrai Public Cloud.

OpenTofu est un fork open source de Terraform, largement compatible. Les notions et la plupart des commandes de cette formation s'appliquent aux deux.

Non : les TP utilisent LocalStack (API AWS émulées), MinIO (backend S3) et les fournisseurs simulés de terraform test.

Non, ils se complètent : Terraform crée l'infrastructure (réseaux, VM, services managés), Ansible configure les systèmes et les applications.

Une variable (variable) est une entrée fournie de l'extérieur (tfvars, -var, TF_VAR_). Une valeur locale (locals) est calculée à l'intérieur de la configuration pour éviter les répétitions : local.prefixe = "${var.projet}-${var.environnement}".

L'édition open source est sous licence AGPL-3.0. Une édition Enterprise ajoute notamment le SSO et les rôles personnalisés : consultez la page officielle pour ses conditions.

OpenObserve vise la simplicité et un stockage peu coûteux en colonnes, interrogé en SQL. Elasticsearch offre une recherche plein texte plus riche, au prix d'une exploitation plus lourde.

Non : un seul binaire ou conteneur suffit. La haute disponibilité demande Kubernetes, un stockage objet et PostgreSQL.

Oui pour les métriques : OpenObserve expose une API compatible avec Prometheus.

Oui, tous ses composants sont sous licence Apache 2.0, y compris la sécurité et l'alerting.

Ils partagent une origine et de nombreux concepts, mais ont divergé. OpenSearch offre une licence Apache 2.0 et des plugins inclus ; comparez les fonctions dont vous avez besoin.

Largement : index, shards, DSL et mapping restent proches. ISM remplace ILM, et il faut utiliser les clients OpenSearch.

Non : un pipeline d'ingestion suffit pour des transformations simples. Data Prepper sert aux traitements lourds et à l'OpenTelemetry.