Ce mois-ci, XCP-ng et Xen Orchestra entrent dans le catalogue avec quatre connecteurs Vates développés en partenariat avec l'éditeur. Kubernetes gagne la supervision de la consommation CPU et mémoire par pod, et la bêta de la collection SNMP en Rust démarre officiellement avec trois connecteurs.
Pour en savoir plus, vous pouvez également consulter la documentation associée, contacter nos équipes commerciales ou poster un message sur The Watch.
Nouveautés connecteurs en quelques chiffres
- 7 nouveaux connecteurs ajoutés au catalogue
- 6 évolutions sur des connecteurs existants
- 5 corrections sur des connecteurs existants
Nouveautés à la une
[Nouveaux connecteurs] Vates XCP-ng & Xen Orchestra REST API
Pourquoi ça compte
XCP-ng est une plateforme de virtualisation open source basée sur l'hyperviseur Xen. Elle est généralement administrée via Xen Orchestra, l'interface web de gestion éditée par Vates. Jusqu'ici, aucun connecteur Centreon ne couvrait cet environnement. Le besoin avait été remonté sur The Watch.
Nous livrons quatre connecteurs, développés directement en partenariat avec les équipes Vates. Ils interrogent tous l'API REST de Xen Orchestra et couvrent chacun un niveau de l'infrastructure. Vous pouvez ainsi suivre votre environnement du plus global au plus fin, et situer rapidement l'origine d'un problème.
- Xen Orchestra, pour la vue d'ensemble.
- Pool, pour la santé du cluster.
- XCP-ng Host, pour chaque hyperviseur.
- VM, pour chaque machine virtuelle.
Cas d'usage typique
Vous exploitez un ou plusieurs pools XCP-ng administrés par Xen Orchestra. Vous voulez être alerté si une VM s'arrête de façon inattendue, si un hôte est désactivé, si le master du pool n'est plus en marche ou si un storage repository se remplit. Il suffit de déclarer l'hôte Xen Orchestra dans Centreon : les règles de découverte d'hôtes vous permettent de créer ensuite automatiquement les pools, les hyperviseurs et les VM à superviser.
Modes supervisés
- Xen Orchestra : status, vm-status, storage-repository
- Pool : status, cpu-overcommit
- XCP-ng Host : status, cpu, memory
- VM : status, cpu, memory
[Évolution] Kubernetes API : consommation CPU et mémoire par pod
Pourquoi ça compte
Le connecteur Kubernetes API suivait déjà l'état des objets du cluster, mais pas la consommation réelle de chaque pod. Le nouveau mode pod-usage récupère l'utilisation CPU (en millicores et pourcentage) et mémoire (bytes et pourcentage) de chaque pod via l'API metrics.k8s.io. Vous pouvez ainsi repérer un pod qui dépasse ce qui lui a été réservé, sans attendre qu'il atteigne sa limite. Une règle de découverte de services permet de créer automatiquement un service par pod.
Cas d'usage typique
Vous hébergez des applications sur un cluster Kubernetes et vous voulez suivre dans Centreon la consommation de certains pods, filtrés par namespace, par nom de pod ou par conteneur. Prérequis : metrics-server doit être installé et joignable dans le cluster.
Modes supervisés
- pod-usage
Collection SNMP en Rust : la bêta est ouverte
Annoncée cet été, la collecte SNMP basée sur un plugin écrit en Rust est désormais disponible en bêta à travers trois connecteurs :
- Generic SNMP (Rust)
- Linux SNMP (Rust)
- Windows SNMP (Rust)
Le plugin ne code pas les indicateurs en dur. Il s'appuie sur des collections décrites en JSON. Leur format est désormais documenté par un schéma publié, en français et en anglais, dans le dépôt GitHub. Ce schéma permet la complétion et la validation directement dans un éditeur comme VS Code ou PyCharm. Notez que le format de collection actuel (version 0) est celui de la bêta et peut encore évoluer jusqu'à la première version stable : une section changelog dans le groupe bêta The Watch permettra de suivre ces évolutions en cours de bêta.
Nous avons hâte d’avoir vos retours sur ce projet, n’hésitez pas à rejoindre le groupe bêta The Watch !
Information importante : sorties vides, OK → UNKNOWN
Jusqu'ici, dans certains cas on pouvait avoir un statut OK avec une sortie vide. Par exemple, c'était le cas avec un filtre trop restrictif, qui laissait la supervision muette sans alerter. Désormais dans ces situations un statut UNKNOWN devrait être correctement remonté.
Synthèse des mises à jour
Nouveaux connecteurs
Évolutions
Corrections d’anomalies
Pour en savoir plus, vous pouvez consulter la release note complète.
Et si vous voulez proposer des améliorations :
- vous pouvez proposer une idée sur The Watch.
- ou contribuer sur GitHub.
Rendez-vous le mois prochain pour de nouveaux connecteurs !