Logo
Overview
Un Talos européen de qualité - Part VII - Métriques

Un Talos européen de qualité - Part VII - Métriques

October 31, 2025
13 min read
part-07

Objectif 🎯

La mise en place des backups et base de données étant faite, il nous manque les derniers composants critiques d’un cluster de production, à savoir tout ce qui concerne l’observabilité à tous les niveaux, à savoir le triptyque métriques, logging, et traçabilité.

Networking

Cilium fourni déjà son propre outil d’observabilité réseau temps réel, que l’on a déjà installé à l’étape 3.

Pour Cilium il s’agit de Hubble, accessible sur https://hubble.dev.ohmytalos.io, son outil de visualisation eBPF, très utile pour visualiser les interactions réseau entre les composants. Exemple sur le namespace CrowdSec :

Cilium Hubble

Métriques 📊

Sur l’ensemble des charts helm préalablement installés, nous nous sommes assurés d’activer tous les ServiceMonitor afin que Prometheus puisse aller scraper les métriques exposées par tous les composants critiques du système sans que l’on ait à définir de configuration supplémentaire. Il nous reste plus qu’à installer un cluster Prometheus, de préférence sur nos nœuds de storage.

L’architecture de la stack Prometheus :

Schéma prometheus

clusters/dev-kube/module-monitoring.tf
module "kube_monitoring" {
source = "../../modules/kube/monitoring"
internal_domain = local.internal_domain
control_planes_ips = [
for s in data.hcloud_servers.control_planes.servers : tolist(s.network)[0].ip
]
smtp_host = "smtp.tem.scaleway.com:465"
alertmanager_smtp_username = var.alertmanager_smtp_username
alertmanager_smtp_password = var.alertmanager_smtp_password
alertmanager_from = "prom.dev@ohmytalos.io"
alertmanager_to = "me@ohmytalos.io"
}
Explanation

Afin de scraper les métriques des composants centraux du kubernetes, notamment l’etcd, le scheduler ainsi que le controller manager, nous avons besoin d’envoyer au chart prometheus les IPs privées des nœuds de control plane. Nous utilisons donc la data source hcloud_servers déjà déclaré lors du chapitre sur l’ingress pour récupérer ces informations dynamiquement.

Nous configurons également les informations nécessaires pour qu’Alertmanager puisse envoyer des notifications par email via SMTP.

Déployer tout ça et aller sur l’interface web de Prometheus via https://prom.dev.ohmytalos.io.

Prometheus Dashboard

Le plus intéressant dans l’immédiat est d’aller voir dans la section Targets pour vérifier que tous les endpoints sont bien scrappés, tout devrait déjà être à UP.

Prometheus Targets

Faites également un tour sur https://am.dev.ohmytalos.io (attention pas de dark mode !) et allez dans l’onglet Status pour vérifier que le mode cluster est bien actif et que l’alerte email est bien appliquée dans la partie configuration.

Testons le bon fonctionnement des alertes en créant une règle prometheus fake et lancer kaf test-alert.yaml pour l’appliquer :

test-alert.yaml
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: test-alert
namespace: monitoring
labels:
app: kube-prometheus-stack
release: prometheus
spec:
groups:
- name: test.rules
rules:
- alert: TestCriticalAlert
expr: vector(1)
for: 1m
labels:
namespace: monitoring
severity: critical
annotations:
summary: "Test alert for email notification"

Après quelques instants, vous devriez voir l’alerte apparaître dans Prometheus, onglet Alerts, qui liste l’ensemble des règles Prometheus actives, avec un état Pending.

Prometheus Alerts Pending

C’est le mode intermédiaire avant que l’alerte ne soit déclenchée, ce qui se produit lorsque la condition de la règle est vraie pendant toute la durée spécifiée dans le champ for. Dans notre cas, la condition est toujours juste puisque l’expression vector(1) renvoie toujours 1, et la durée est fixée à 1 minute.

Passé ce délai, l’alerte passera à l’état Firing.

Prometheus Alerts Firing

Vous devriez la voir apparaître dans Alertmanager, groupé dans monitoring/email/email-notifications, confirmant que l’alerte est bien passé dans la bonne route et le bon receiver.

Alertmanager Alerts

Si votre SMTP est bien configuré, vous devriez recevoir un email d’alerte dans votre boîte de réception, avec les bonnes URLs configurées, grâce aux paramètres externalUrl.

Alertmanager Email

Supprimer l’alerte fake via kdel -f test-alert.yaml.

Dashboard 📈

Bien que Prometheus fournisse des fonctionnalités pour la visualisation des métriques, cela reste pour une utilisation avancée nécessitant des connaissances en PromQL. Pour une expérience plus riche et interactive, nous allons installer Grafana, l’outil dataviz de prédilection pour la visualisation de tous types de métriques.

Bien que Grafana soit inclus dans le chart kube-prometheus-stack (en tant que subchart), ce dernier est de base extrêmement lourd à installer et à configurer, et y inclure Grafana ne ferait que nous faire perdre notre temps. Je préfère donc le gérer séparément pour plus de flexibilité en termes de mise à jour.

clusters/dev-kube/module-monitoring.tf
module "kube_monitoring" {
// ...
grafana_smtp_username = var.grafana_smtp_username
grafana_smtp_password = var.grafana_smtp_password
grafana_from = "grafana.dev@ohmytalos.io"
grafana_dashboards = {
traefik = {
gnetId = 17347
revision = 9
},
longhorn = {
gnetId = 16888
revision = 9
},
crowdsec = {
url = "https://raw.githubusercontent.com/crowdsecurity/grafana-dashboards/master/dashboards_v5/Crowdsec%20Overview.json"
datasource = "prometheus"
}
}
}
Explanation

Rien de bien particulier à part la configuration du SMTP pour l’envoi de notifications par email.

Nous rajoutons quelques dashboards additionnels pour Traefik, Longhorn, et Crowdsec. Libre à vous d’en ajouter d’autres selon vos besoins. Les ids et les révisions peuvent être récupérés sur le site de Grafana Labs.

On déploie comme d’habitude et aller sur https://grafana.dev.ohmytalos.io et loguez-vous via le compte admin. Utiliser kgsec -n grafana -o yaml grafana | yq -r '.data."admin-password"' | base64 -d pour récupérer le mot de passe admin autogénéré. Allez dans la section dashboards :

Grafana Dashboards

Vous y trouverez plein de dashboards déjà inclus :

  • Ceux de Kubernetes, fournis par le chart kube-prometheus-stack.
  • Ceux de Cilium, qui inclus ses propres charts
  • Ceux de CloudNativePG
  • Ceux additionnels téléchargés via le sidecar download-dashboards.

Dashboards Kubernetes

etcd

Dashboards Ressources

Compute Cluster

Dashboards additionnels

Cilium

Conclusion

Nous voilà déjà avec tout plein de dashboards. La partie métrique et dataviz étant vue, il nous reste la collecte des logs et traces, des données assez massives à collecter. Suite dans la section suivante.