Monitoring d'Application
Un Tag, Un Tableau de Bord pour Chaque Service de Votre Application
Regroupez les services et les moniteurs d'uptime qui composent une application derrière un tag unique. Obtenez un tableau de bord unifié, la découverte automatique de services et une page de statut publique — sans reconstruire votre monitoring chaque fois que votre stack évolue.
Essai gratuit 15 jours · Sans carte bancaire · Installation en 30 secondes
500+ entreprises nous font confiance pour surveiller leurs applications
Une Vue de Votre Application Basée sur les Tags
Les applications dans Bleemeo reposent sur une idée simple : choisissez un tag, attachez-y services et moniteurs, et obtenez une vue en temps réel de l'ensemble du cluster. Ajouter ou retirer un service se fait en changeant un label, pas en réécrivant un tableau de bord.
Vue Cluster
Visualisez chaque service d'une application sur un seul graphique. Le statut remonte vers un indicateur unique de santé applicative.
Événements de Services
Chronologie dédiée des changements de statut pour chaque service de l'application, idéale pour les analyses post-incident.
Temps de Réponse
Attachez des moniteurs d'uptime au tag de l'application et obtenez automatiquement un widget de Temps de Réponse Applicatif.
Regroupement Compose Automatique
Glouton reconnaît chaque projet Docker Compose et crée une application correspondante sans aucune configuration.
Pages de Statut Publiques
Publiez la santé de votre application en temps réel sur status.bleemeo.com/<slug>/ pour vos clients.
Agnostique à la Stack
Fonctionne avec les exporters Prometheus, JMX, StatsD, les checks HTTP/TCP et 100+ services découverts automatiquement.
Comment Regrouper des Services dans une Application
Les tags peuvent provenir de n'importe où — découverte automatique, labels de conteneurs, annotations de pods, fichier de configuration Glouton ou interface elle-même. Choisissez la méthode qui correspond à votre façon de déployer.
Docker Compose (automatique)
Glouton utilise le label com.docker.compose.project pour regrouper chaque service d'un projet dans une application, sans aucun changement de configuration.
services:
web:
image: nginx
api:
image: my/api
# Regroupé automatiquement sous le nom du projetLabels Docker
Remplacez le regroupement par défaut ou fusionnez des services provenant de plusieurs projets Compose en définissant le label glouton.tags.
services:
payments:
image: my/payments
labels:
- glouton.tags=backend,paymentsAnnotations Kubernetes
Attachez des pods à une application via une simple annotation glouton.tags sur votre Deployment, StatefulSet ou DaemonSet.
spec:
template:
metadata:
annotations:
glouton.tags: "checkout"Configuration Glouton
Pour les installations bare-metal ou sur mesure, déclarez le service et ses tags directement dans un fichier de configuration Glouton.
services:
- type: "apache"
instance: "web-01"
tags:
- frontendInterface Web
Ajoutez ou retirez manuellement un tag sur n'importe quel service ou moniteur — utile pour un regroupement ponctuel ou pour taguer des moniteurs d'uptime qui n'existent que dans le cloud.
- Modification des tags directement depuis l'onglet Applications
- Source du tag visible (automatique, config, manuel)
- Aucun redémarrage de l'agent nécessaire
Moniteurs d'Uptime
Les moniteurs HTTP, TCP et ping peuvent porter le même tag que vos services afin que la disponibilité externe vive sur le même tableau de bord que la santé interne.
- Checks HTTP / TCP / ping
- Widget de Temps de Réponse Applicatif
- Alimentent la page de statut publique
Créer une Application en Trois Étapes
Ouvrez l'Onglet Applications
Dans le panneau Bleemeo, cliquez sur Applications dans la navigation gauche, puis sur le bouton +.
Nommez l'Application et Choisissez un Tag
Donnez un nom à l'application et choisissez un tag. Vous pouvez réutiliser un tag déjà présent sur vos services ou en créer un nouveau — chaque service ou moniteur portant ce tag sera regroupé sous l'application.
Attachez des Services et des Moniteurs
Ajoutez le tag à vos services via un label Docker, une annotation Kubernetes, la configuration Glouton ou l'interface web. Les nouveaux services portant le tag apparaissent automatiquement.
# Docker Compose
labels:
- glouton.tags=my-app
# Kubernetes
annotations:
glouton.tags: "my-app"Comment les Tags Construisent la Vue de Votre Application
Les tags voyagent avec vos services quelle que soit la façon dont ils sont déployés. La plateforme les réconcilie en temps réel en une entité application unique.
La Source du Tag Est Toujours Visible
Chaque service attaché à une application porte des métadonnées indiquant comment le tag a été appliqué : automatique (détecté par l'API, dérivé de Compose), configuration Glouton ou manuel (ajouté dans l'interface). Lors du diagnostic d'une appartenance inattendue, vous savez toujours où chercher.
Finis les Tableaux de Bord qui Dérivent
Les tableaux de bord traditionnels se dégradent au fil des arrivées et départs de services. Avec une application basée sur un tag, le tableau de bord suit le tag : les nouveaux services apparaissent, ceux qui disparaissent s'effacent, et la mise en page reste lisible. Le bouton Reset restaure la version auto-générée dès que les modifications manuelles ne vous conviennent plus.
Applications Multi-Tags
Un service peut porter plusieurs tags — courant pour les composants partagés comme une base de données qui sous-tend à la fois les applications checkout et catalog. Utilisez des valeurs séparées par des virgules (glouton.tags=checkout,catalog) dans les labels Docker ou les annotations Kubernetes, et chaque application voit le service partagé.
Les Pages de Statut Publiques Réutilisent le Même Modèle
Une page de statut publique n'est qu'une sélection d'applications affichée sans authentification sur status.bleemeo.com/<slug>/. Parce que la santé est calculée à partir des mêmes services et moniteurs tagués, ce que vous voyez en interne et ce que voient vos clients ne divergent jamais.
Ce que Couvre la Santé d'une Application
Le statut consolidé d'une application reflète tous les modes de défaillance de ses membres — des redémarrages de conteneurs aux échecs d'uptime externes.
Défaillances de Services
- Service découvert automatiquement hors service
- Check TCP ou HTTP personnalisé en échec
- Processus qui ne tourne plus
- Conteneur arrêté ou en redémarrage
Disponibilité Externe
- Moniteur HTTP d'uptime en échec
- Endpoint TCP inaccessible
- Check ping en timeout
- Temps de réponse dépassant le seuil
Code Applicatif
- Alerte sur métrique Prometheus personnalisée
- Seuil de métrique JMX franchi
- Anomalie sur un compteur StatsD
- Check Nagios retournant CRITICAL
Répercussions Infrastructure
- Hôte d'un service OOM-killed
- Disque plein sur le nœud d'un service
- Pod bloqué en CrashLoopBackOff
- Kubelet NotReady
Natif Prometheus, de l'Exporter à PromQL
Bleemeo est un backend compatible Prometheus prêt à l'emploi pour vos applications. Instrumentez votre code
avec les bibliothèques clientes officielles, scrapez n'importe quel endpoint /metrics existant,
et interrogez tout avec PromQL — le langage que votre équipe maîtrise déjà.
Instrumentez votre Code avec les Clients Prometheus Officiels
Utilisez les bibliothèques clientes Prometheus officielles maintenues par le projet Prometheus et l'écosystème CNCF. Exposez un endpoint /metrics et Glouton le scrape — aucun verrouillage propriétaire, aucun SDK propriétaire, aucune réinstrumentation à prévoir si vous changez plus tard.
from prometheus_client import Counter, start_http_server
checkout_total = Counter('checkout_total', 'Checkouts terminés')
start_http_server(8000) # /metrics servi sur :8000Endpoints /metrics Natifs Partout
Des milliers d'applications modernes exposent les métriques Prometheus nativement — sans exporter, sans sidecar, sans travail d'instrumentation. Activez l'annotation Prometheus (prometheus.io/scrape: "true") ou ajoutez une URL à la configuration de Glouton et les métriques arrivent dans Bleemeo.
Parcourir les 60+ intégrations prêtes à l'emploi → · Ou scraper vous-même n'importe quel endpoint Prometheus →
PromQL pour les Tableaux de Bord et les Alertes
Chaque widget de tableau de bord et chaque règle d'alerte Bleemeo parlent PromQL. Réutilisez les recording rules de votre installation Prometheus existante, mélangez les métriques applicatives et d'infrastructure dans la même requête, et exploitez toute la puissance de rate(), histogram_quantile() et sum by() pour exprimer ce qui compte pour votre équipe.
histogram_quantile(0.99,
sum by (le, handler) (
rate(http_request_duration_seconds_bucket{service="checkout"}[5m])
)
)Pages de Statut Publiques, Intégrées
Chaque application peut être publiée en tant que page de statut publique personnalisée sur status.bleemeo.com/<slug>/ en un clic. La page est non authentifiée, orientée client, et affiche la même disponibilité en temps réel que votre équipe d'astreinte voit en interne — ainsi, ce que lisent vos clients ne diverge jamais de la réalité.
- Réutilise vos applications existantes — aucune nouvelle configuration
- Plusieurs applications par page pour les suites produit
- Statut en temps réel calculé à partir des services et des moniteurs d'uptime
- Réduit la charge de support et apporte des preuves SLA
Pourquoi Choisir Bleemeo pour le Monitoring d'Application ?
Zéro Maintenance de Tableau de Bord
Le tableau de bord suit le tag. Déployez un nouveau service et il apparaît automatiquement — aucune réécriture Grafana.
Un Seul Signal pour l'Astreinte
Chaque défaillance de service remonte vers un statut de santé applicatif unique, réduisant la fatigue d'alertes.
Transparence Client
Publiez l'uptime applicatif sur status.bleemeo.com en un clic — aucun outil de page de statut séparé.
Rétention 13 mois
Conservez l'historique au niveau application pour les rapports SLA, les post-mortems et l'analyse de tendances.
Qu'est-ce que le Monitoring d'Application ?
Le monitoring d'application consiste à suivre la santé, la disponibilité et les performances d'une application logicielle dans son ensemble, plutôt que chaque serveur, conteneur ou service de manière isolée. Les applications modernes regroupent de nombreux composants — une base de données, une couche web, un worker en arrière-plan, une file de messages, souvent exécutés sur Kubernetes — et ce qui compte pour les utilisateurs, c'est de savoir si l'application fonctionne, pas si tel ou tel pod est en route.
Dans Bleemeo, une application est définie par un tag. Les services et les moniteurs d'uptime portant ce tag sont regroupés sous l'application, leurs statuts sont consolidés en un indicateur unique, et leurs métriques sont organisées sur un tableau de bord auto-généré. Le regroupement est dynamique : ajouter une nouvelle réplique, un nouveau microservice ou un nouveau check d'uptime ne demande que d'y poser le bon tag. La vue de l'application se met à jour d'elle-même.
Le modèle est entièrement compatible Prometheus, fonctionne avec les logs centralisés pour l'analyse de cause racine, et alimente les pages de statut publiques afin que vos clients voient la même image de la disponibilité que votre équipe d'astreinte — sans les détails internes. Une seule source de vérité pour l'observabilité interne et la communication externe.
Ce que Contient un Tableau de Bord d'Application
Widget de Statut des Services
Toujours présent sur le tableau de bord d'application, il liste chaque service portant le tag avec son état actuel. Les défaillances font passer le widget — et le statut applicatif — au rouge, pour que l'astreinte voie d'un coup d'œil quelle partie de l'application est dégradée.
Temps de Réponse Applicatif
Apparaît automatiquement dès qu'au moins un moniteur d'uptime porte le tag de l'application. Trace la latence dans le temps pour les checks HTTP, TCP ou ping afin de corréler les ralentissements visibles par l'utilisateur avec les événements des services backend.
Widgets par Service (Pro)
Avec le plan Professional, le tableau de bord est automatiquement peuplé d'un widget dédié par service reconnu dans l'application — CPU et mémoire pour une base de données, taux de requêtes pour un serveur web, profondeur de file pour un broker. Vous démarrez avec une mise en page utile au lieu d'une page blanche.
Onglet Application Information
Liste chaque service et moniteur attaché à l'application, regroupés par mode d'application du tag (automatique, configuration Glouton, manuel). Utilisez-le pour auditer l'appartenance et retirer les retardataires après un changement de déploiement.
Onglet Service Events
Un flux chronologique de chaque changement de statut au sein de l'application — redémarrage de conteneur, instabilité de check HTTP, processus disparu — avec horodatage. Le premier endroit à consulter après un incident, et le moyen le plus rapide de repérer une dépendance instable.
Alertes Consolidées
Chaque alerte sur un service de l'application contribue au statut de l'application. Votre équipe d'astreinte voit un signal par application au lieu d'une alerte par composant, avec drill-down vers le service exact en échec.
Cas d'Usage
Déploiements de Microservices
Regroupez tous les microservices d'un produit derrière un tag checkout. Quand un nouveau service rejoint le mesh, annotez-le et il s'ajoute automatiquement au tableau de bord d'application — aucun changement Grafana, aucune réécriture de règle d'alerte. Les agrégations exposent un signal de santé unique pour toute la fenêtre de rollout.
Stacks Docker Compose
Comme Glouton détecte automatiquement le projet Compose, chaque docker compose up devient une vue d'application prête à l'emploi — idéal pour les environnements de dev, les stacks de tests CI ou les petits déploiements auto-hébergés où monter un tableau de bord supplémentaire par projet serait excessif.
SLA Orientés Client
Publiez l'uptime applicatif sur une page de statut publique pour communiquer de manière transparente pendant les incidents, réduire les tickets de support et fournir des preuves de conformité SLA — le tout calculé à partir des mêmes services et moniteurs que vous avez déjà en interne.
Dépendances Partagées
Taguez une base de données partagée avec à la fois checkout et catalog. Si la base se dégrade, les deux applications le reflètent, et les équipes d'astreinte de chaque produit voient l'incident sur leurs tableaux de bord respectifs sans duplication d'infrastructure.
Intégrations SaaS Tierces
Ajoutez un moniteur HTTP d'uptime sur l'API d'un fournisseur de paiement, taguez-le avec votre application, et les pannes de dépendances externes apparaissent à côté des défaillances internes — fini les surprises « l'application est en panne mais tout est vert ».
Analyse Post-Incident
Utilisez l'onglet Service Events pour reconstruire la chronologie d'une dégradation : quel service a échoué en premier, lequel a propagé, lequel a récupéré. Avec 13 mois de métriques conservées, vous pouvez aussi analyser les régressions à effet lent, pas seulement les incidents aigus.
Bonnes Pratiques du Monitoring d'Application
Nommez les Tags d'Après les Domaines Métier
Un tag comme checkout ou billing reste pertinent malgré les évolutions techniques, alors qu'un tag comme node-app-v2 devient trompeur en un trimestre. Choisissez des noms qui correspondent à la rotation d'astreinte et au vocabulaire de la page de statut, pas à l'implémentation actuelle.
Attachez Toujours au Moins un Moniteur d'Uptime
La santé interne des services indique que les composants sont en marche ; les moniteurs d'uptime indiquent que l'application est joignable de l'extérieur. Un moniteur HTTP tagué vous offre gratuitement le widget Temps de Réponse Applicatif et donne du sens à votre page de statut publique.
Laissez Docker Compose se Regrouper Tout Seul
En dev et staging, fiez-vous au regroupement Compose automatique — aucune configuration, aucune dérive. Réservez les labels glouton.tags explicites aux déploiements de production où vous voulez surcharger le nom du projet ou joindre des services à travers plusieurs fichiers Compose.
Taguez Explicitement les Composants Partagés
Les bases de données, les caches et les brokers de messages servent souvent plusieurs applications. Ajoutez des tags séparés par des virgules (glouton.tags=checkout,catalog) pour que chaque application dépendante du service partagé voie sa santé et reçoive l'alerte en cas de dégradation.
Publiez une Page de Statut Publique Tôt
Même en bêta, une page de statut publique renforce la confiance et réduit la charge de support. Commencez avec une page par application orientée utilisateur et affinez le récit plus tard. Comme les données de santé proviennent de l'application elle-même, il n'y a aucun coût opérationnel supplémentaire.
Envie d'aller plus loin ?
Lire la documentationQuestions Fréquentes
Tout ce que vous devez savoir sur le monitoring d'application
Qu'est-ce que le monitoring d'application ?
Le monitoring d'application consiste à suivre la santé, la disponibilité et les performances d'une application logicielle dans son ensemble — à travers chaque service, conteneur et dépendance externe qui la fait fonctionner. Il transforme des signaux disparates par composant en une vue unique de la capacité réelle de l'application à servir ses utilisateurs, et fournit des métriques, logs et alertes pour diagnostiquer rapidement les problèmes.
Pourquoi le monitoring d'application est-il important ?
Le monitoring d'application détecte les problèmes avant les utilisateurs, raccourcit le temps de réponse aux incidents, produit des preuves de conformité SLA et guide la planification de capacité. Sans lui, les équipes réagissent aux plaintes des clients plutôt qu'aux alertes, et l'analyse de cause racine repose sur l'inspection manuelle des logs de dizaines de composants.
Quelle est la différence entre monitoring d'application et monitoring d'infrastructure ?
Le monitoring d'infrastructure suit les serveurs, conteneurs, disques et réseaux — la couche sur laquelle s'exécute votre application. Le monitoring d'application suit l'application elle-même : taux de requêtes, taux d'erreurs, latence, KPI métier, disponibilité externe. Les deux sont nécessaires, et une bonne plateforme les corrèle pour déterminer si un checkout lent vient du code ou de l'hôte.
Qu'est-ce que l'APM (Application Performance Monitoring) ?
L'APM est une sous-catégorie du monitoring d'application centrée sur la performance au niveau du code — temps de réponse, débit, taux d'erreurs et (dans certains outils) traces distribuées. L'APM basé sur les métriques repose sur des endpoints /metrics instrumentés, typiquement via les bibliothèques clientes Prometheus officielles, et c'est l'approche utilisée par les plateformes cloud-natives modernes.
Comment fonctionne Prometheus pour le monitoring d'application ?
Prometheus utilise un modèle pull : votre application expose un endpoint /metrics (généralement via une bibliothèque cliente officielle), et un agent le scrape à intervalles réguliers. Les métriques sont stockées en séries temporelles et interrogées avec PromQL. Parce que le format texte Prometheus est le standard de fait, des milliers d'applications exposent nativement /metrics, et tout backend compatible Prometheus peut les ingérer et les interroger.
Quelles bibliothèques clientes Prometheus puis-je utiliser ?
Le projet Prometheus maintient des bibliothèques clientes officielles pour Go (client_golang), Java (simpleclient, ainsi que Micrometer), Python (prometheus_client), Ruby (prometheus-client) et Rust (prometheus). Des bibliothèques communautaires couvrent Node.js, .NET, PHP, C++ et bien d'autres. Chaque bibliothèque permet de définir compteurs, jauges, histogrammes et résumés sur un endpoint /metrics.
Quelles métriques surveiller pour une application web ?
Le point de départ canonique est la méthode RED : Rate (requêtes par seconde), Errors (taux d'erreurs) et Duration (distribution de latence). Complétez avec USE pour les ressources — Utilization, Saturation, Errors — et quelques KPI métier (taux de complétion de checkout, taux d'inscription). Exposez-les sous forme d'histogrammes Prometheus et interrogez avec histogram_quantile() pour suivre p50, p95 et p99.
Comment surveiller des microservices ?
Regroupez les microservices associés derrière un identifiant partagé — typiquement un tag — afin que leur santé remonte vers un statut applicatif unique. Instrumentez chaque service avec une bibliothèque cliente Prometheus, exposez /metrics et laissez l'agent de monitoring les découvrir automatiquement. Ajoutez des moniteurs d'uptime externes sur le point d'entrée public et corrélez les métriques avec les logs pour l'analyse de cause racine.
Comment mesurer le temps de réponse d'une application ?
Deux approches complémentaires : les moniteurs d'uptime externes (HTTP, TCP, ping) mesurent le temps de réponse du point de vue de l'utilisateur, tandis que les histogrammes Prometheus internes comme http_request_duration_seconds le mesurent à l'intérieur de l'application. Utilisez la fonction histogram_quantile() de PromQL pour calculer p50, p95 et p99, et comparez-les aux mesures externes pour détecter les problèmes réseau ou CDN.
Qu'est-ce qu'une page de statut publique et pourquoi en ai-je besoin ?
Une page de statut publique est une URL orientée client qui affiche en temps réel la disponibilité de votre application et ses incidents en cours. Elle réduit la charge de support pendant les pannes, communique de manière transparente avec les clients et fournit des preuves de conformité SLA. Les meilleures pages de statut réutilisent les mêmes données de monitoring que vous utilisez en interne, afin que ce que voient les clients ne diverge jamais de la réalité vue par l'astreinte.
Démarrez le Monitoring de Vos Applications
Un tag pour regrouper vos services. Un tableau de bord. Une URL de statut publique.