TL;DR
Les métriques JMX, les clients de flux et un lab reproductible permettent d’observer latence, compactions, files, dropped messages et capacité. Cet épisode cherche à superviser Cassandra et tester un flux de données sans masquer saturation ou incohérence. La vidéo est intégrée dans l’article et les références ont été actualisées pour éviter de présenter une pratique historique comme une recommandation actuelle.
La vidéo de référence
Vidéo: https://www.youtube.com/watch?v=MhzUUI5BY7s
Playlist complète: https://www.youtube.com/playlist?list=PLn6POgpklwWqNNhhGIJyArMm-rDeGoZs1
Cet article correspond à l’épisode 18 sur 21. Le chapitre GitLab associé est 18-metriques-jmx-exporter. Les fichiers utiles détectés sont: 18-metriques-jmx-exporter/jmx-exporter.yaml, 18-metriques-jmx-exporter/slides.md.
Définition simple : Monitoring : prometheus & jmx exporter + dashboard
Les métriques JMX, les clients de flux et un lab reproductible permettent d’observer latence, compactions, files, dropped messages et capacité.
Pour raisonner correctement, séparez toujours la configuration déclarée, l’état réellement appliqué et la preuve observée. Une commande terminée sans erreur ne prouve pas à elle seule la disponibilité, la sécurité, la persistance ou la capacité de restauration.
Quel problème cet épisode résout-il ?
Le besoin concret consiste à superviser Cassandra et tester un flux de données sans masquer saturation ou incohérence. Le sujet doit être replacé dans son contexte: taille de l’environnement, version, niveau de criticité, dépendances et compétences de l’équipe.
Une bonne validation part d’un exemple minimal, observe les objets créés, provoque un changement contrôlé puis vérifie le résultat avec un outil indépendant de la commande de création.
Points clés du support Xavki
- définir précisément monitoring : prometheus & jmx exporter + dashboard
- relier le concept à un comportement observable
- distinguer configuration, état réel et preuve de fonctionnement
- documenter les hypothèses avant de généraliser le résultat
Ces éléments viennent du dépôt lorsqu’un chapitre correspondant existe. Ils servent de point de départ; la documentation officielle citée plus bas précise le comportement des versions actuelles.
Mise à jour par rapport à la vidéo
Le monitoring doit couvrir percentiles de latence, tombstones, compactions, capacité disque et état de chaque nœud, pas seulement le statut up/down.
Avant d’utiliser une commande en production, vérifiez la version installée, les notes de migration et les paramètres devenus obsolètes. Les exemples de formation restent utiles pour comprendre le modèle, mais une option ou une architecture peut avoir évolué.
Commandes et éléments pratiques
wget https://repo1.maven.org/maven2/io/prometheus/jmx/jmx_prometheus_javaagent/0.17.2/jmx_prometheus_javaagent-0.17.2.jar
sudo systemctl restart cassandra
curl -fsSL https://get.docker.com -o get-docker.sh 2>&1 >/dev/null
curl -fsSL "https://github.com/docker/compose/releases/download/1.25.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose 2>&1 >/dev/null
sudo apt-get update -qq >/dev/null
sudo apt-get install -qq -y wget unzip prometheus >/dev/null
sudo systemctl restart prometheus
sudo systemctl enable prometheusLes commandes extraites peuvent contenir des valeurs de lab. Adaptez chemins, adresses, credentials, versions et noms de ressources. Ne placez jamais un secret réel dans un dépôt, une variable affichée ou un state non protégé.
Méthode de diagnostic
- Noter la version exacte et la configuration effective.
- Vérifier le service, le processus ou l’objet cible avant le client applicatif.
- Lire les logs au moment précis du test.
- Contrôler réseau, permissions, stockage et dépendances séparément.
- Produire une preuve positive, puis tester un cas d’échec contrôlé.
- Documenter la procédure de retour arrière ou de restauration.
Cette méthode évite les diagnostics circulaires où le même outil crée et valide sa propre configuration. Pour une plateforme distribuée, contrôlez aussi quorum, réplication, latence, capacité et comportement pendant une perte partielle.
Pièges fréquents
- copier une commande ancienne sans vérifier la version actuelle;
- considérer le succès d’une commande comme une preuve de résilience;
- mélanger lab, développement et exigences de production;
- ignorer les données persistantes, secrets ou états intermédiaires;
- ajouter de la haute disponibilité sans tester le split brain ou la restauration;
- optimiser avant d’avoir défini une métrique et un objectif.
Bonnes pratiques
- versionner les fichiers de configuration et conserver un historique lisible;
- épingler les versions importantes et suivre les notes de publication;
- séparer accès administrateur et accès applicatif;
- appliquer le moindre privilège;
- sauvegarder les données et tester les restaurations;
- superviser la plateforme avec des signaux indépendants;
- automatiser uniquement après avoir compris le chemin manuel minimal.
Mini-lab conseillé
Reproduisez le scénario avec des noms dédiés au lab. Capturez l’état initial, appliquez une modification unique et comparez l’état final. Supprimez ou arrêtez ensuite une dépendance pour observer le comportement dégradé, puis restaurez le service avec la procédure documentée.
Références externes
- cassandra.apache.org/doc/latest/cassandra/operating/metrics.html
- prometheus.github.io/jmx_exporter
- cassandra.apache.org/doc/latest/cassandra/managing/tools/nodetool/nodetool.html
- cassandra.apache.org/doc/latest/cassandra/troubleshooting/index.html
Ces références sont volontairement limitées à des sources officielles ou primaires. Elles complètent la vidéo et le dépôt sans multiplier les liens génériques.
Liens Xavki
Continuer la série
- Épisode précédent: Cassandra 017 – TABLE : LES UUID, TIMESTAMPUUID ET COUNTER
- Épisode suivant: Cassandra 019 – Benthos : écritures et lectures pour…
FAQ
Cet article remplace-t-il la documentation officielle ?
Non. Il fournit un chemin pédagogique en français, relie la vidéo au support Xavki et signale les évolutions importantes. La référence comportementale reste la documentation de la version réellement installée.
Puis-je reprendre directement les commandes en production ?
Non sans adaptation. Vérifiez versions, chemins, permissions, réseau, secrets, capacité et stratégie de retour arrière. Commencez par un environnement de test représentatif.
Comment savoir si le lab est réellement réussi ?
Définissez une preuve avant le test: état attendu, requête, métrique, log, donnée persistante ou comportement lors d’une panne. Vérifiez ensuite cette preuve avec un outil indépendant.
Pourquoi conserver plusieurs liens externes ?
La vidéo explique la progression, le dépôt fournit les artefacts et les références externes documentent la version actuelle. Cette triangulation améliore la fiabilité pour le lecteur, les moteurs de recherche et les systèmes de recherche assistée par LLM.
Conclusion
L’épisode 18/21, Monitoring : prometheus & jmx exporter + dashboard, apporte une étape précise au parcours Cassandra. Retenez surtout le modèle mental, la preuve attendue et les limites de version. Une pratique devient fiable lorsqu’elle est reproductible, observable et restaurable.