Connectez tout ce que vous surveillez
Bleemeo s'intègre parfaitement avec l'ensemble de votre stack technologique, prenant en charge plus de 100 technologies avec de nouvelles ajoutées régulièrement. Des bases de données aux serveurs web, en passant par les conteneurs et les plateformes cloud, bénéficiez d'une surveillance complète grâce à la découverte automatique. L'agent Glouton détecte automatiquement les services en cours d'exécution à l'aide de sondes TCP, sans aucune configuration manuelle de votre part. Dès qu'un service est détecté, il reçoit immédiatement des métriques dédiées, des alertes préconfigurées et des tableaux de bord conçus spécifiquement pour cette technologie. Vous pouvez également apporter vos propres métriques personnalisées via des endpoints Prometheus, OpenMetrics, StatsD et des plugins Nagios pour une observabilité complète sur toutes les couches de votre infrastructure.
Comment fonctionne la découverte automatique
Lorsque vous installez l'agent Glouton sur un serveur, il commence immédiatement à scanner les
services en cours d'exécution à l'aide de vérifications de sockets TCP exécutées toutes les 60 secondes.
Il n'y a rien à configurer : Glouton sonde les ports connus et identifie la technologie derrière
chaque socket ouvert, que ce soit MySQL sur le port 3306, Nginx sur le port 80 ou Redis sur le port 6379.
Chaque service détecté reçoit une métrique service_status qui rapporte l'une des quatre
valeurs : 0 (OK), 1 (Avertissement), 2 (Erreur) ou 3 (Inconnu/timeout). Cela vous donne un indicateur
de santé instantané pour chaque service s'exécutant sur l'hôte.
Entre les intervalles de sondage, Glouton maintient des connexions keep-alive vers les services critiques. Cela signifie que si un service plante ou devient inaccessible, la détection de panne est immédiate plutôt que d'attendre le prochain cycle de 60 secondes. Les services détectés sont automatiquement tagués avec des métadonnées telles que le nom du service, le port et l'hôte, de sorte qu'ils apparaissent dans vos tableaux de bord Bleemeo et vos règles d'alerte sans aucune configuration manuelle. Vous obtenez une visibilité complète dès le moment où l'agent commence à fonctionner.
Lorsque vous avez besoin de plus de contrôle, vous pouvez personnaliser le comportement de la
découverte à l'aide de fichiers de configuration YAML placés dans /etc/glouton/conf.d/.
Pour les environnements conteneurisés, les labels Docker tels que glouton.SETTING_NAME
vous permettent d'ajuster la surveillance par conteneur. Les utilisateurs de Kubernetes peuvent
s'appuyer sur les annotations de pods pour configurer le scraping et la détection de services au
niveau de l'orchestration. Les variables d'environnement avec le préfixe GLOUTON_
(par exemple, GLOUTON_LOGGING_LEVEL) sont également prises en charge, ce qui facilite
l'ajustement des paramètres dans les déploiements cloud où la configuration par fichier n'est pas
pratique. Avec le plan gratuit, vous obtenez des vérifications de disponibilité pour tous les
services découverts ; le passage au plan professionnel débloque des métriques spécifiques aux
services comme les taux de requêtes, les ratios de hits de cache et l'utilisation des pools de connexions.
Ce qui se passe après la détection
Lorsque l'agent Glouton détecte un service, plusieurs choses se produisent automatiquement. Premièrement, le service reçoit une métrique service_status qui suit la disponibilité avec des valeurs de 0 (OK) à 3 (inconnu/timeout). Cette métrique déclenche des alertes par défaut si le service devient indisponible, sans aucune configuration nécessaire.
Deuxièmement, l'agent commence à collecter des métriques spécifiques au service qui vont bien au-delà de la simple disponibilité. Pour une base de données MySQL, vous obtenez les requêtes par seconde, les requêtes lentes, l'utilisation du pool de connexions, le ratio de hits du buffer pool et le retard de réplication. Pour Nginx, vous obtenez les connexions actives, les requêtes par seconde, les codes de statut de réponse et les temps de réponse upstream. Pour Redis, vous obtenez l'utilisation mémoire, les taux d'éviction de clés, les clients connectés et la latence des commandes. Chaque intégration dispose de son propre ensemble de métriques sélectionnées, conçues par des ingénieurs monitoring qui comprennent ce qui compte pour cette technologie.
Troisièmement, Bleemeo crée automatiquement un tag pour chaque service détecté. Les tags facilitent le filtrage des tableaux de bord, la portée des règles d'alerte et l'organisation de votre infrastructure. Un serveur exécutant MySQL, Nginx et Redis obtient automatiquement trois tags de service, que vous pouvez utiliser pour créer des règles de notification ciblées : envoyez les alertes de base de données à l'équipe DBA et les alertes de serveur web à l'équipe plateforme.
Enfin, des tableaux de bord préconfigurés se remplissent avec les métriques collectées dès que les données commencent à affluer. Vous n'avez pas besoin de créer des tableaux de bord à partir de zéro pour les services courants. Le tableau de bord de l'agent pour chaque serveur inclut un onglet Services montrant tous les services détectés et leurs métriques clés en un coup d'œil.
Systèmes d'exploitation
AlmaLinux
CentOS
Debian
Fedora
Oracle Linux
Red Hat
Rocky Linux
TrueNAS CORE
TrueNAS SCALE
Ubuntu
Windows Server
Bases de données
Cassandra
CouchBase
CouchDB
Elasticsearch
InfluxDB
MariaDB
Memcached
MongoDB
MySQL
PostgreSQL
Redis
RethinkDB
Riak
SQL Server
Valkey
Serveurs web et proxies
Apache HTTP
Caddy
HAProxy
Nginx
Squid
Traefik
Varnish
Files de messages et brokers
Conteneurs et orchestration
Docker
Kubernetes
Monitoring et observabilité
Graphite
Nagios Plugins
OpenTelemetry
Prometheus
StatsD
Telegraf
Serveurs d'applications et runtimes
Gestion de configuration
Communication et messagerie
Asterisk
Dovecot
eJabberd
Exim
Postfix
Services d'infrastructure
Consul
FreeRADIUS
libvirt
OpenLDAP
OpenVPN
PowerDNS
ZooKeeper
Alertes et notifications
Discord
MessageBird
OpsGenie
OVH SMS
PagerDuty
Slack
Microsoft Teams
Telegram
Twilio
VictorOps
Webhooks
Rocket.Chat
Plateformes cloud
AWS CloudWatch
AWS EC2
AWS ELB
AWS DynamoDB
AWS RDS
AWS S3
Développement et collaboration
Bitbucket
Confluence
GitLab
Jenkins
JIRA
GitHub
Applications mobiles
Android
Autres
VMware
NVIDIA
Flexibilité de configuration
Remplacez les paramètres par défaut quand vous en avez besoin, ou laissez la découverte automatique tout gérer
Configuration YAML
Remplacez n'importe quel paramètre de service via des fichiers YAML dans /etc/glouton/conf.d/. Les fichiers sont lus dans l'ordre lexicographique et fusionnés, ce qui vous permet de superposer les valeurs par défaut de l'équipe avec des surcharges spécifiques à l'environnement. Les modifications sont détectées automatiquement sans redémarrage de l'agent. Utilisez des préfixes à deux chiffres (par ex. 30-mysql.conf, 50-custom.conf) pour contrôler l'ordre de fusion des fichiers.
Labels Docker
Configurez la surveillance par conteneur à l'aide de labels Docker comme glouton.check.ignore.port.8080=true pour ignorer des ports spécifiques, ou glouton.enable=false pour exclure entièrement des conteneurs. Les labels sont détectés en temps réel au démarrage et à l'arrêt des conteneurs. Cette approche fonctionne parfaitement avec Docker Compose, Swarm et les conteneurs autonomes.
Annotations Kubernetes
Utilisez les annotations de pods pour contrôler la surveillance au niveau Kubernetes. Activez le scraping Prometheus avec prometheus.io/scrape, spécifiez des ports personnalisés avec prometheus.io/port et filtrez par namespace. Toutes les modifications s'appliquent sans redéployer le DaemonSet Glouton. Les annotations sont évaluées en temps réel, de sorte que la surveillance s'adapte instantanément lorsque les pods sont créés, mis à l'échelle ou terminés.
Variables d'environnement
Remplacez n'importe quel paramètre de configuration avec des variables d'environnement préfixées GLOUTON_. Idéal pour les déploiements cloud où la configuration par fichier n'est pas pratique. Prend en charge les chaînes, les entiers, les booléens et même les paramètres imbriqués. C'est l'approche recommandée pour les déploiements conteneurisés et les pipelines CI/CD où la configuration est injectée au moment de l'exécution.
Votre technologie n'est pas listée ?
Bleemeo supporte les métriques personnalisées via les protocoles Prometheus, OpenMetrics, StatsD et les plugins Nagios. Si vous exécutez un service qui n'est pas dans notre catalogue, il y a de fortes chances que vous puissiez tout de même le surveiller. Utilisez notre API pour une flexibilité totale, ou contactez-nous pour demander le support natif de votre technologie.