TL;DR
Cette série construit progressivement une infrastructure cloud complète sur Infomaniak Public Cloud. Dans cet épisode, le sujet précis est: Monitoring : consul telemetry & exporter. Rendre observable le sujet "Monitoring : consul telemetry & exporter": collecte, stockage, règles, dashboards ou alertes selon l étape de la série.
La vidéo de référence
Vidéo: https://www.youtube.com/watch?v=vQ658IkxCj8
Playlist complète: https://www.youtube.com/playlist?list=PLn6POgpklwWpehxly1wOT6eB2NvZX9A-X
Le dépôt support est disponible ici: https://gitlab.com/xavki/infrastructure-cloud-infomaniak. Le chapitre correspondant est 56-monitoring-consul-metriques.
Objectif précis de l épisode
Rendre observable le sujet "Monitoring : consul telemetry & exporter": collecte, stockage, règles, dashboards ou alertes selon l étape de la série.
Concrètement, cet épisode sert à passer d une intention formulée dans le titre à une modification vérifiable dans l infrastructure. Le dépôt donne les fichiers, la vidéo donne l ordre de manipulation, et la vérification doit confirmer que la brique fonctionne vraiment.
Monitoring : consul telemetry & exporter: c est quoi exactement ?
Dans une infrastructure cloud réelle, chaque épisode ajoute une brique: réseau, compute, sécurité, automatisation, découverte de services, observabilité, sauvegardes ou orchestration. Ici, les outils détectés sont: openstack, ansible, consul, monitoring, traefik, logs, helm.
Dans cet épisode, il faut surtout regarder les éléments qui correspondent au titre: les ressources créées ou modifiées, les fichiers du chapitre, les services touchés et la preuve de fonctionnement. Les outils détectés donnent le contexte, mais le fil rouge reste Monitoring : consul telemetry & exporter.
Ce que la vidéo cherche à modifier
- déclarer ou utiliser les services Consul nécessaires
- relier DNS interne, checks et catalogue
- préparer l intégration avec proxy ou monitoring
- brancher les métriques utiles
- adapter la configuration de collecte ou de stockage
- rendre le résultat visible dans Grafana ou dans les règles d alerte
Indices extraits des slides
- Loki / Log quotes
- check_target
- traefik dashboard > tcp
- consul exporter = metrics for services / nodes
- telemetry of cluster = metrics from master nodes
Notions et définitions des outils
- openstack: OpenStack est la couche cloud IaaS: instances, réseaux, routeurs, IP flottantes, groupes de sécurité, volumes et images. Chez Infomaniak Public Cloud, il sert de socle programmable via GUI, CLI, Terraform et API.
- ansible: Ansible automatise la configuration des machines après leur création. Les playbooks, rôles, inventaires et variables transforment une VM brute en service exploitable.
- consul: Consul apporte service discovery, DNS interne, health checks et catalogue de services. Il relie machines, proxy, monitoring et automatisation.
- monitoring: Le monitoring collecte métriques, alertes et dashboards. Node exporter, vmagent, VictoriaMetrics, VMAlert, Alertmanager, Karma et Grafana couvrent collecte, stockage, règles, notification et visualisation.
- traefik: Traefik est un reverse proxy dynamique. Il route HTTP/HTTPS vers des backends et peut se configurer via Consul ou annotations Kubernetes.
- logs: La chaîne logs regroupe collecte, transformation, stockage et requêtes. Logrotate gère les fichiers locaux, Vector collecte/transforme, Loki indexe les labels et LogQL interroge.
- helm: Helm est le gestionnaire de packages de Kubernetes. Un chart regroupe templates, valeurs et dépendances; une release est une instance déployée de ce chart dans un cluster.
Ces définitions sont volontairement pratiques: elles expliquent à quoi sert l outil dans la chaîne, pas seulement ce qu il est sur le papier.
Points clés à retenir pour cet épisode
- Comprendre le rôle de Monitoring : consul telemetry & exporter dans la progression globale de l infrastructure.
- Identifier la couche concernée: cloud, automatisation, réseau, service, observabilité ou orchestration.
- Relier les fichiers du dépôt au résultat attendu sur les machines ou dans le cloud.
- Vérifier les inventaires, variables et rôles avant de lancer un playbook.
- Conserver une preuve de fonctionnement via métriques, dashboards ou alertes.
Approfondissement spécifique
Avec Monitoring : consul telemetry & exporter, Consul sert de tissu de découverte entre les machines. Le point spécifique est de comprendre quelle information entre dans le catalogue: nom du service, adresse, port, tags et health check.
Un service déclaré mais unhealthy ne doit pas être considéré comme disponible. Il faut suivre la chaîne DNS Consul -> catalogue -> check -> consommateur du service, par exemple Traefik, monitoring ou un autre composant applicatif.
Pour Monitoring : consul telemetry & exporter, le sujet précis est le trajet de la métrique: exposition par un exporter ou un composant, découverte par le collecteur, stockage, requête PromQL puis visualisation ou alerte.
Un dashboard ne valide pas à lui seul l observabilité. Il faut remonter à la target, vérifier la fraîcheur des séries, tester une requête représentative et s assurer que l alerte repose sur un signal actionnable.
Exemple de code ou configuration du dépôt
vars:
logrotate_frequency: daily
logrotate_keep: 7
logrotate_compress: yes
logrotate_log_files:
- name: example
path: "/var/log/example/*.log"
- name: btmp
path: /var/log/btmp
missingok: yes
frequency: monthly
create: yes
create_mode: "0660"
create_user: root
create_group: utmp
dateext: yes
dateformat: "-%Y-%m-%d"Cet extrait doit être lu comme un support pédagogique. Avant de l utiliser tel quel, vérifiez les variables, noms de réseau, plages CIDR, identifiants, secrets, régions, images et règles d exposition.
Chemin de diagnostic recommandé
- vérifier les membres Consul
- contrôler les entrées DNS et services
- regarder l état des health checks
- vérifier que les targets sont up
- contrôler une requête PromQL représentative
- ouvrir le dashboard ou l alerte concernée
- Comparer l état attendu dans le dépôt et l état réel dans le cloud, la machine ou le cluster.
- Documenter la commande, l écran ou la métrique qui prouve que l étape est fonctionnelle.
Répertoires et commandes utiles
- Répertoire support: 56-monitoring-consul-metriques
- Répertoire support: 56-monitoring-consul-metriques/code/ansible
- Répertoire support: 56-monitoring-consul-metriques/code/terraform
Pièges fréquents
- oublier les ports Consul
- déclarer un service sans health check utile
- dépendre du DNS sans tester la résolution
- déployer un exporter sans scrape
- créer un dashboard sans métrique stable
- alerter sur un signal trop bruité
Liens utiles externes
- Dépôt Xavki infrastructure-cloud-infomaniak
- Playlist YouTube Infra de A à Z
- docs.infomaniak.cloud
- docs.infomaniak.cloud/getting_started/first_project
- docs.infomaniak.cloud/compute/instances
- docs.infomaniak.cloud/orchestration/terraform
- docs.infomaniak.cloud/network/networks
- docs.infomaniak.cloud/network/security_groups
Liens internes conseillés
- Parcours Kubernetes pour relier la partie cluster et orchestration.
- Prometheus, Grafana et observabilité pour approfondir métriques et dashboards.
- Wazuh et logs sécurité pour comparer observabilité et détection sécurité.
Pour continuer, lire Infra A à Z 058 – Consul : calculs promql, alerts et dashboards.
FAQ
Pourquoi utiliser Terraform et Ansible ensemble ?
Terraform est adapté à la création et au cycle de vie des ressources cloud. Ansible est adapté à la configuration des machines et services. Les mélanger sans frontière claire rend les changements difficiles à relire.
Pourquoi Infomaniak/OpenStack dans cette série ?
Infomaniak Public Cloud expose des concepts OpenStack standards: compute, réseau, volumes, security groups, object storage, identity et orchestration. Cela permet d apprendre des notions transférables tout en travaillant sur un fournisseur concret.
Que faut-il sécuriser en premier ?
Les accès: credentials cloud, state Terraform, SSH, VPN, dashboards, secrets Ansible, tokens GitLab, consoles d administration et ports exposés publiquement. Une infrastructure automatisée amplifie aussi les erreurs de sécurité.
Comment savoir si une étape est terminée ?
Chaque étape doit produire une preuve: une ressource visible, un service joignable, une métrique collectée, un backup restaurable, une requête qui répond ou un déploiement qui converge.
Conclusion
L épisode 57 s inscrit dans une progression complète: construire, automatiser, sécuriser, observer et exploiter une infrastructure cloud. Le dépôt Xavki donne les exemples concrets, la documentation Infomaniak/OpenStack donne le cadre fournisseur, et le deep dive permet de comprendre le rôle des outils au lieu de seulement rejouer des commandes.