Construit sur Prometheus & OpenTelemetry
Sans verrouillage fournisseur
Monitoring Kubernetes prêt pour la production en 30 secondes
Monitoring de Cluster Kubernetes pour Nodes, Pods et Conteneurs
Un chart Helm, aucun Prometheus à opérer, aucun Grafana à maintenir, aucun stockage à gérer. Bleemeo vous offre une visibilité complète sur cluster, nœuds, pods et conteneurs — avec des alertes qui fonctionnent dès le premier jour.
Essai gratuit 15 jours Sans carte bancaire Sans engagement
Entreprise européenne
Données hébergées dans l'UE · Conforme RGPD
500+ entreprises nous font confiance
À travers l'Europe et au-delà
Plus de 500 entreprises font confiance à Bleemeo pour surveiller leur infrastructure
99,99 %
SLA plateforme
<100 Mo
Mémoire de l'agent
100+
Découvertes automatiques
Les défis du monitoring Kubernetes
Construire son monitoring Kubernetes en interne avec l'écosystème open source semble gratuit — jusqu'à ce qu'on compte le temps d'ingénierie. Quatre coûts qui n'apparaissent qu'après le déploiement :
Complexité opérationnelle
Prometheus, Grafana, Alertmanager, exporters, un backend de stockage — chaque brique est elle-même une application Kubernetes à déployer, mettre à jour, sécuriser et patcher. La stack de monitoring censée garder votre plateforme en bonne santé finit par être l'une de ses plus bruyantes sources d'incidents.
Stockage à grande échelle
Les labels de pods se transforment en explosions de cardinalité. Les instances Prometheus uniques manquent de RAM et de disque à mesure que le cluster grandit. Aller plus loin, c'est s'engager dans Thanos, Cortex ou Mimir — un autre système distribué avec ses propres object storages, queriers, compactors et store gateways à opérer.
Maturité de l'alerting
Les règles d'alerte Kubernetes prêtes à l'emploi couvrent les bases, mais les affiner à vos workloads — éliminer les faux positifs lors des rolling updates, dédupliquer le bruit entre réplicas, calibrer l'astreinte — demande des mois d'itération. La plupart des équipes tournent avec des alertes auxquelles elles ne peuvent pas vraiment se fier.
Charge d'astreinte
Quand votre stack de monitoring vit à l'intérieur du cluster qu'elle est censée surveiller, un incident du control plane emporte aussi les alertes. Ajoutez le temps récurrent passé à maintenir Prometheus, Grafana et le stockage, et votre équipe DevOps finit par surveiller son propre monitoring au lieu du produit.
Pourquoi Bleemeo pour Kubernetes
Du monitoring de cluster Kubernetes de niveau production, livré en service managé. Aucune plateforme à opérer, aucun stockage à mettre à l'échelle, aucune stack d'alerte à surveiller.
Installation en 30 secondes, pas en 2 jours
Un helm upgrade --install, un DaemonSet, trois variables d'environnement — c'est fait. Aucun PVC à provisionner,
aucune scrape config à écrire, aucun tableau de bord à importer, aucune règle d'alerte à rédiger. La découverte automatique
reconnaît plus de 100 services sans configuration.
13 mois de rétention dès le départ
Métriques haute résolution conservées pendant 13 mois sans déployer Thanos, Cortex ou Mimir. Capacity planning, post-mortems, tendances saisonnières — tout reste accessible sans tiers de stockage long terme séparé.
SLA 99,99 % — un monitoring qui fonctionne quand votre infra ne fonctionne plus
Bleemeo tourne en dehors de votre cluster, sur une plateforme entièrement managée avec un SLA d'uptime de 99,99 %. Quand etcd s'effondre ou que des nœuds passent NotReady, les alertes vous parviennent quand même. Le seul système de monitoring que vous ne pouvez pas faire tomber avec vos propres incidents.
20 à 40 heures/mois économisées sur l'opérationnel monitoring
Un monitoring Kubernetes auto-hébergé consomme 20 à 40 heures-ingénieur par mois : croissance du stockage, redémarrages Prometheus, scrape configs qui dérivent, ajustement des alertes, mises à jour de Grafana. Bleemeo rend ce temps à votre travail plateforme et produit.
Vous avez déjà Prometheus ?
Bleemeo n'est pas un remplacement de Prometheus — c'est le service managé qui supprime la charge opérationnelle.
Requêtes PromQL, recording rules, ingestion par scraping : tout est supporté. Glouton collecte vos endpoints
/metrics existants, Bleemeo les stocke et les interroge, et vous arrêtez d'opérer du stockage. Rien à déployer,
rien à maintenir. Si votre cluster est en panne, la plateforme continue de tourner en dehors — pour que l'alerte critique
que vous devez recevoir vous parvienne réellement.
Ce que disent les équipes Kubernetes
Bleemeo a rendu le monitoring Kubernetes étonnamment simple. En quelques minutes, nous avions une visibilité sur nos clusters, pods et workloads sans avoir à construire des tableaux de bord complexes nous-mêmes.
De helm install au dashboard
Glouton atterrit sur un cluster vierge et le tableau de bord se remplit — capturé ci-dessous.
30 secondes du déploiement au dashboard.
Refaites le même flux sur votre cluster — toujours en 30 secondes.
Monitoring de Performance Kubernetes à Chaque Couche
De la santé du cluster aux métriques individuelles des conteneurs, obtenez une visibilité complète sur votre environnement Kubernetes. Bleemeo agit comme un remplacement de serveur de métriques Kubernetes complet, collectant et centralisant toutes vos données d'observabilité.
Cluster API, etcd, scheduler
→
Nœuds CPU, mémoire, kubelet
→
Pods Cycle de vie, redémarrages
→
Conteneurs CPU, mémoire, OOM
Niveau Cluster
Santé du control plane, latence de l'API server, performances etcd, métriques du scheduler
Niveau Nœud
CPU, mémoire, disque, réseau, statut kubelet, conditions des nœuds
Niveau Pod
Cycle de vie des pods, compteurs de redémarrage, requests vs limits, readiness
Niveau Conteneur
Throttling CPU, utilisation mémoire, événements OOM, états des conteneurs
Réseau
Endpoints de services, trafic ingress, résolution DNS, network policies
Stockage
Utilisation des PersistentVolumes, statut des claims, capacité des storage classes, santé des montages
Métriques des Conteneurs Kubernetes Collectées
Control Plane
Supervisez le cœur de votre cluster Kubernetes pour la fiabilité et les performances.
- Latence des requêtes API Server
- Santé et latence etcd
- Profondeur de file du scheduler
- Métriques du controller manager
- Expiration des certificats
Nœuds et Kubelet
Suivez la santé des nœuds et les performances du kubelet dans votre cluster.
- CPU, mémoire, disque des nœuds
- Statut de santé du kubelet
- Conditions des nœuds (Ready, DiskPressure, etc.)
- Capacité et allocation des pods
- Métriques du container runtime
Pods et Conteneurs
Visibilité approfondie sur les performances des workloads et la consommation de ressources.
- Utilisation CPU et throttling
- Utilisation mémoire et OOM kills
- Compteurs de redémarrage et crash loops
- Requests vs limits des ressources
- États et événements des conteneurs
Services et Réseau
Supervisez les endpoints de services et la connectivité réseau.
- Santé des endpoints de services
- Trafic et latence Ingress
- Efficacité des network policies
- Temps de résolution DNS
- Métriques service mesh (Istio, Linkerd)
Ressources Workload
Suivez les Deployments, StatefulSets, DaemonSets et Jobs.
- Statut des replicas de deployment
- Progression des rolling updates
- Ordonnancement des StatefulSets
- Couverture des DaemonSets
- Complétion des Jobs et CronJobs
Stockage Persistant
Supervisez les PersistentVolumes et les performances de stockage.
- Statut de liaison PV/PVC
- Utilisation de la capacité de stockage
- Débit et latence I/O
- Provisionnement StorageClass
- Erreurs de montage de volumes
Fonctionnalités Natives Kubernetes
🔍 Découverte Automatique
Découvrez et supervisez automatiquement les pods, services et endpoints. Aucune configuration manuelle nécessaire lors de la mise à l'échelle des workloads.
📊 Compatible Prometheus
Support natif PromQL. Collectez les endpoints Prometheus existants. Utilisez vos recording rules et alertes existantes.
🏷️ Gestion des Labels
Filtrez et agrégez par labels et annotations Kubernetes. Groupez les métriques par namespace, deployment ou labels personnalisés.
📈 Optimisation des Ressources
Dimensionnez correctement les requests et limits des ressources selon l'utilisation réelle. Identifiez les workloads sur-provisionnés et sous-provisionnés.
🔔 Alertes Intelligentes
Alertes pré-configurées pour les problèmes K8s courants : CrashLoopBackOff, pods en attente, nœud NotReady, expiration de certificat.
🌐 Multi-Cluster
Supervisez plusieurs clusters Kubernetes depuis un tableau de bord unique. Comparez les performances entre environnements.
📦 Déploiement Helm
Déployez l'agent Bleemeo avec un seul chart Helm. Prêt pour GitOps avec options de personnalisation complètes.
🔗 OpenTelemetry
Ingérez métriques et logs via OpenTelemetry. Corrélez les métriques d'infrastructure avec les données applicatives.
À quoi ressemble un déploiement Helm
1
Ajouter le dépôt Helm Bleemeo
Ajoutez le dépôt officiel de charts Helm Bleemeo à votre installation Helm.
helm repo add bleemeo-agent https://packages.bleemeo.com/bleemeo-agent/helm-charts
helm repo update2
Installer l'agent
Déployez l'agent Glouton en tant que DaemonSet avec vos identifiants de compte.
helm upgrade --install glouton bleemeo-agent/glouton \
--set account_id="your_account_id" \
--set registration_key="your_registration_key" \
--set config.kubernetes.clustername="my_k8s_cluster_name" \
--set namespace="default"3
Visualisez votre cluster
Les nœuds, pods et services apparaissent automatiquement dans votre tableau de bord Bleemeo en quelques secondes.
Déploiement DaemonSet
Glouton se déploie en tant que DaemonSet, plaçant automatiquement un pod agent sur chaque nœud de votre cluster — y compris les nœuds ajoutés par les autoscalers.
- Un agent par nœud, toujours
- Tolerations pour tous types de nœuds
- Couverture compatible autoscaler
- Chart Helm prêt pour GitOps
Architecture de l'agent DaemonSet
Un pod Glouton par nœud assure une couverture complète du cluster, de la santé du control plane aux métriques individuelles des conteneurs.
Modèle de déploiement DaemonSet
Glouton se déploie en tant que DaemonSet via Helm, plaçant exactement un pod agent sur chaque nœud de votre cluster. Le chart Helm inclut des tolerations pour tous les types de nœuds standard — nœuds GPU, nœuds système et nœuds gérés par autoscaler reçoivent tous un agent automatiquement. Seules trois variables d'environnement sont requises : GLOUTON_ACCOUNT_ID, GLOUTON_REGISTRATION_KEY et GLOUTON_KUBERNETES_CLUSTERNAME. Le pod agent demande un minimum de ressources (moins de 100 Mo de mémoire) et ne concurrence pas vos workloads de production.
Annotations de pods pour un contrôle précis
Les annotations Kubernetes sur vos pods contrôlent la façon dont Glouton interagit avec chaque workload. Définissez glouton.enable: "false" pour exclure un pod de la supervision. Utilisez glouton.check.ignore.port.* pour ignorer les vérifications de santé sur des ports spécifiques (utile pour les conteneurs sidecar ou les ports de débogage). Ajoutez les annotations Prometheus standard (prometheus.io/scrape: "true", prometheus.io/port, prometheus.io/path) pour exposer les métriques applicatives que Glouton collectera et transmettra à Bleemeo Cloud aux côtés des métriques d'infrastructure.
Métriques Kubernetes complètes
Au-delà des simples compteurs de pods et de nœuds, Glouton collecte des métriques Kubernetes approfondies : comptage de pods par état (Running, Pending, Failed, Succeeded), compteurs de redémarrage par conteneur, utilisation CPU et mémoire comparée aux requests et limits, comptage de nœuds et de namespaces, dates d'expiration des certificats CA et des certificats de nœuds, et indicateurs de santé API server et kubelet. Toutes les métriques sont étiquetées avec le namespace, le type de propriétaire (Deployment, DaemonSet, StatefulSet) et le nom du propriétaire pour un filtrage et une agrégation puissants dans les tableaux de bord.
Personnalisation par ConfigMap
Surchargez les paramètrès par défaut de Glouton par cluster en utilisant une ConfigMap Kubernetes. Excluez des namespaces entiers de la supervision (par ex. kube-system ou les namespaces de runners CI), ajustez les intervalles de collecte de métriques, ajoutez des labels personnalisés à toutes les métriques d'un cluster spécifique, ou configurez des cibles de scrape Prometheus supplémentaires. L'approche ConfigMap s'intègre naturellement aux workflows GitOps — stockez votre configuration de supervision aux côtés de vos manifests applicatifs et laissez ArgoCD ou Flux la gérer de façon déclarative.
Alertes Kubernetes Pré-Configurées
Soyez notifié des problèmes Kubernetes courants avant qu'ils n'impactent vos utilisateurs.
Problèmes de Pods
- CrashLoopBackOff détecté
- Pod bloqué en Pending
- Nombre élevé de redémarrages
- Conteneurs OOMKilled
Problèmes de Nœuds
- Nœud NotReady
- Pression CPU/mémoire élevée
- Espace disque faible
- Trop de pods planifiés
Problèmes de Cluster
- Erreurs API server
- Latence etcd élevée
- Certificat expirant
- PVC en attente
Problèmes de Workload
- Replicas de deployment indisponibles
- StatefulSet non prêt
- Job échoué
- HPA au maximum de replicas
Compatible avec votre stack
K8s Managés EKS, GKE, AKS, DigitalOcean
Distributions OpenShift, Rancher, k3s, k0s
Service Mesh Istio, Linkerd, Consul Connect
Ingress NGINX, Traefik, HAProxy, Kong
Stockage Ceph, Longhorn, OpenEBS, CSI
Observabilité Prometheus, Grafana, OpenTelemetry
CI/CD ArgoCD, Flux, Jenkins, GitLab
Bases de données PostgreSQL, MySQL, MongoDB, Redis
Conçu pour les équipes Kubernetes
Visibilité Temps Réel
Voyez la création des pods, les événements de mise à l'échelle et les échecs en temps réel. Aucun délai dans la collecte des métriques.
Optimisation des Coûts
Identifiez le gaspillage de ressources et dimensionnez correctement vos workloads. Réduisez vos dépenses cloud sans impacter les performances.
Agent Léger
Glouton utilise un minimum de ressources. Moins de 100 Mo de mémoire par nœud. Ne concurrence pas vos workloads.
Qu'est-ce que la supervision Kubernetes ?
La supervision Kubernetes est la pratique consistant à collecter, analyser et alerter sur les métriques de chaque couche d'un environnement Kubernetes — du control plane du cluster jusqu'aux processus individuels des conteneurs. Contrairement à la supervision traditionnelle de serveurs, Kubernetes introduit des défis uniques : les workloads sont éphémères, les pods sont créés et détruits en permanence, et une seule application peut s'étendre sur des dizaines de replicas répartis sur plusieurs nœuds.
Une supervision Kubernetes efficace nécessite une visibilité sur quatre couches distinctes. La couche cluster surveille la santé du control plane, la latence de l'API server, les performances d'etcd et l'expiration des certificats. La couche nœud supervise le CPU, la mémoire, le disque et le statut kubelet sur chaque nœud worker. La couche workload suit les replicas de Deployment, l'ordonnancement des StatefulSets, la couverture des DaemonSets et la complétion des Jobs. Enfin, la couche pod et conteneur fournit l'utilisation des ressources, les compteurs de redémarrage, les événements OOM et le throttling CPU par conteneur.
Sans supervision multi-couche, les opérateurs Kubernetes sont contraints d'utiliser des commandes kubectl et l'inspection manuelle des logs pour diagnostiquer les problèmes — une approche réactive qui ne passe pas à l'échelle. Une solution de supervision adaptée comme Bleemeo collecte automatiquement les métriques des quatre couches via un déploiement DaemonSet, corrèle les données entre les couches et fournit des alertes pré-configurées pour les modes de défaillance courants comme CrashLoopBackOff, les pods en attente et l'expiration des certificats.
Métriques K8s en Détail
Métriques de Pods
Suivez le comptage de pods par état (Running, Pending, Failed, Succeeded), les compteurs de redémarrage par conteneur, l'utilisation CPU et mémoire par rapport aux requests et limits, et l'âge des pods. Les labels incluent le namespace, le type de propriétaire (Deployment, DaemonSet, StatefulSet) et le nom du propriétaire pour une agrégation et un filtrage faciles.
Requests vs Limits de ressources
Comparez ce que les pods ont demandé (requests CPU et mémoire) avec ce qu'ils consomment réellement. Identifiez les workloads sur-provisionnés qui gaspillent des ressources et les sous-provisionnés qui risquent le throttling CPU ou l'OOMKill. Ces données sont essentielles pour dimensionner correctement les définitions de ressources dans vos manifests de déploiement.
Santé du Cluster
Supervisez le nombre total de nœuds, les nœuds Ready vs NotReady, le nombre de namespaces et le statut global du cluster. Suivez la disponibilité de l'API server, la latence d'etcd et la profondeur de file du scheduler. Ces métriques vous aident à évaluer la santé globale et la capacité de votre infrastructure Kubernetes.
Expiration des certificats
Suivez les dates d'expiration des certificats CA et des certificats de nœuds utilisés pour la communication interne de Kubernetes. Soyez alerté avant l'expiration des certificats — une cause fréquente de pannes soudaines de cluster qui est entièrement évitable avec une supervision automatisée.
Kubelet et conditions des nœuds
Supervisez le statut de santé du kubelet sur chaque nœud, les conditions des nœuds (Ready, DiskPressure, MemoryPressure, PIDPressure) et la santé du container runtime. Détectez les nœuds dégradés avant qu'ils ne commencent à évincer des pods ou ne deviennent NotReady.
Réseau et Ingress
Suivez les octets réseau reçus et transmis par pod, les paquets perdus et les compteurs d'erreurs. Supervisez les taux de requêtes du contrôleur Ingress, les latences de réponse et les ratios d'erreurs HTTP. Corrélez les métriques réseau avec les redémarrages de pods ou la dégradation de service pour identifier les problèmes de connectivité, les échecs de résolution DNS ou les network policies mal configurées.
Cas d'utilisation
Dépannage des échecs de pods
Quand un pod entre en CrashLoopBackOff, vous devez savoir pourquoi immédiatement. Bleemeo montre le compteur de redémarrage, le dernier code de sortie, les logs du conteneur et les métriques corrélées au niveau du nœud. Déterminez si le crash est causé par des erreurs applicatives, des OOM kills ou une pression de ressources du nœud sous-jacent — le tout depuis un seul tableau de bord.
Dimensionnement des workloads
Des requests de ressources sur-provisionnées gaspillent la capacité du cluster et augmentent les coûts cloud. Des requests sous-provisionnées causent du throttling et des OOM kills. Utilisez les métriques de requests vs utilisation réelle de Bleemeo dans le temps pour identifier les requests CPU et mémoire optimales pour chaque workload, réduisant le gaspillage tout en prévenant la contention de ressources.
Planification de capacité
Suivez les tendances d'utilisation des ressources du cluster sur des semaines et des mois. Identifiez quand les nœuds approchent des limites de capacité et planifiez les événements de mise à l'échelle avant que les pods ne se retrouvent en attente par manque de ressources. Utilisez 13 mois de données historiques pour prévoir les schémas saisonniers et budgéter la croissance de l'infrastructure.
Gestion multi-cluster
Supervisez vos clusters de développement, staging et production depuis un seul tableau de bord. Comparez l'utilisation des ressources entre environnements, détectez les dérives de configuration entre clusters et vérifiez que les clusters de staging reflètent le dimensionnement de production. Chaque cluster est identifié par son nom configuré pour un filtrage facile.
Validation de déploiement GitOps
Après un déploiement Flux ou ArgoCD, supervisez le déploiement en temps réel. Suivez la création de nouveaux pods, la terminaison des anciens pods et la disponibilité des replicas pendant les rolling updates. Détectez les déploiements échoués (rollouts bloqués, crash loops dans les nouvelles versions) et corrélez le timing de déploiement avec les changements de métriques pour valider que les releases fonctionnent comme prévu.
Optimisation des coûts et refacturation
Analysez la consommation de ressources par namespace pour allouer les coûts d'infrastructure aux équipes ou projets. Identifiez les namespaces avec une utilisation CPU et mémoire constamment faible qui sont sur-provisionnés. Utilisez les données d'utilisation historiques pour dimensionner correctement les pools de nœuds du cluster, basculer vers des instances spot ou préemptibles pour les workloads tolérants, et réduire les dépenses globales d'infrastructure Kubernetes.
Bonnes pratiques de supervision Kubernetes
1
Déployer en DaemonSet
Exécutez l'agent de supervision en tant que DaemonSet pour que chaque nœud reçoive automatiquement un pod agent — y compris les nœuds ajoutés par les autoscalers. Cela garantit une couverture complète du cluster sans intervention manuelle. Le chart Helm de Bleemeo gère cela par défaut, incluant les tolerations et limites de ressources appropriées.
2
Utiliser les annotations Prometheus pour les métriques personnalisées
Ajoutez prometheus.io/scrape: "true" aux annotations de vos pods pour exposer les métriques applicatives au format Prometheus. L'agent de Bleemeo découvre automatiquement ces endpoints et envoie les métriques vers le cloud. C'est l'approche standard Kubernetes-native pour les métriques d'application personnalisées sans nécessiter de configuration supplémentaire.
3
Toujours définir les requests et limits de ressources
Les pods sans requests de ressources ne peuvent pas être correctement dimensionnés car il n'y a pas de base de comparaison. Définissez toujours les requests CPU et mémoire dans vos manifests de déploiement. Bleemeo compare ensuite l'utilisation réelle aux ressources demandées, permettant des décisions de dimensionnement basées sur les données qui réduisent le gaspillage et préviennent la contention de ressources.
4
Surveiller l'expiration des certificats
Kubernetes utilise des certificats TLS pour la communication interne entre l'API server, le kubelet et etcd. Des certificats expirés causent une panne soudaine et totale du cluster. Bleemeo suit les dates d'expiration des certificats et vous alerte avant leur expiration, vous donnant le temps de renouveler les certificats de manière proactive au lieu de découvrir le problème pendant une panne.
5
Corréler les métriques avec les logs des conteneurs
Un compteur de redémarrage de pod qui augmente vous dit que quelque chose ne va pas. Les logs du conteneur vous disent exactement quoi. Activez la collecte de logs en parallèle des métriques pour l'analyse de cause racine la plus rapide. L'agent de Bleemeo collecte les deux depuis le même DaemonSet, et la plateforme cloud les affiche ensemble, liés par le nom du pod et l'horodatage.
Vous voulez aller plus loin ?
Lire la documentationQuestions fréquemment posées
Tout ce que vous devez savoir sur la supervision Kubernetes de Bleemeo
Comment déployer Bleemeo dans mon cluster Kubernetes ?
Bleemeo se déploie via un chart Helm en tant que DaemonSet, plaçant un agent Glouton sur chaque nœud. Ajoutez simplement le dépôt Helm Bleemeo, puis exécutez helm upgrade --install avec vos identifiants de compte et le nom du cluster. L'agent découvre automatiquement tous les pods et services. Vous pouvez aussi déployer avec des manifests kubectl standard. Les outils GitOps comme ArgoCD et Flux sont entièrement supportés.
Quelles métriques Kubernetes Bleemeo collecte-t-il ?
Bleemeo collecte des métriques complètes incluant : Métriques de pods (compteurs par état, compteurs de redémarrage, utilisation CPU/mémoire vs requests/limits), Métriques de nœuds (CPU, mémoire, disque, réseau, statut kubelet), Métriques de cluster (nombre de nœuds, nombre de namespaces, statut API), et Expiration des certificats (CA et certificats de nœuds). Les métriques sont étiquetées par namespace, type de propriétaire (Deployment, DaemonSet) et nom de propriétaire pour un filtrage facile.
Bleemeo découvre-t-il automatiquement les services dans mes pods ?
Oui, la découverte automatique de services est une fonctionnalité centrale. L'agent Bleemeo détecte tous les services en cours d'exécution dans vos pods (bases de données, serveurs web, files d'attente, etc.) et commence à les surveiller sans configuration manuelle. Il reconnaît plus de 100 services nativement. Lorsque les pods montent ou descendent en charge, la supervision suit automatiquement - aucune reconfiguration nécessaire pour les workloads éphémères.
Puis-je collecter les métriques Prometheus de mes applications ?
Oui, Bleemeo supporte la collecte de métriques style Prometheus via les annotations de pods. Ajoutez prometheus.io/scrape: "true" à vos pods, et optionnellement spécifiez prometheus.io/path et prometheus.io/port pour les endpoints de métriques personnalisés. L'agent découvre et collecte automatiquement ces endpoints. Vous pouvez également utiliser PromQL pour interroger les métriques dans vos tableaux de bord.
Quels sont les besoins en ressources de l'agent ?
L'agent Glouton est conçu pour être léger. Il utilise généralement moins de 100 Mo de mémoire et un minimum de CPU par nœud. L'agent ne concurrence pas vos workloads de production pour les ressources. Les requests et limits de ressources peuvent être personnalisés dans les valeurs Helm si nécessaire. L'agent est optimisé pour les environnements à haute densité avec de nombreux pods par nœud.
En quoi Bleemeo diffère-t-il de Prometheus + Grafana auto-hébergés ?
Bleemeo n'est pas un remplacement de Prometheus — c'est le service managé qui supprime la charge opérationnelle. PromQL, recording rules et ingestion par scraping : tout est supporté. Glouton collecte vos endpoints /metrics existants, la plateforme les stocke et les interroge, et vous arrêtez d'opérer du stockage. Aucun serveur Prometheus à scaler, aucun cluster Thanos ou Mimir à opérer, aucun Grafana à mettre à jour. Bleemeo tourne aussi en dehors de votre cluster sur une plateforme SLA 99,99 %, pour que les alertes vous parviennent même quand votre infrastructure est en difficulté.
Quelles distributions Kubernetes sont supportées ?
Bleemeo fonctionne avec toutes les principales distributions Kubernetes : Services managés (EKS, GKE, AKS, DigitalOcean Kubernetes), Auto-hébergé (kubeadm, k3s, k0s, microk8s) et Distributions entreprise (OpenShift, Rancher, Tanzu). Nous supportons Kubernetes 1.19 et ultérieur. L'agent s'adapte aux différents runtimes de conteneurs incluant containerd, CRI-O et Docker.
Puis-je surveiller plusieurs clusters Kubernetes ?
Oui, Bleemeo supporte la surveillance multi-cluster. Chaque cluster apparaît comme une entité séparée dans votre tableau de bord avec son propre nom (configuré via config.kubernetes.clustername). Vous pouvez visualiser tous les clusters dans un tableau de bord unifié, comparer les métriques entre clusters et explorer les détails de chaque cluster. C'est idéal pour gérer les environnements de développement, staging et production.
Quelles alertes sont pré-configurées pour Kubernetes ?
Bleemeo inclut des alertes pré-construites pour les problèmes Kubernetes courants : Problèmes de pods (CrashLoopBackOff, pods en attente, nombre élevé de redémarrages, OOMKilled), Problèmes de nœuds (NotReady, pression disque/mémoire), Problèmes de cluster (erreurs API server, expiration de certificat) et Problèmes de workloads (replicas de deployment indisponibles, jobs échoués). Vous pouvez personnaliser les seuils ou créer des alertes supplémentaires.
Comment suivre les requests de ressources vs l'utilisation réelle ?
Bleemeo collecte à la fois les requests/limits de ressources et l'utilisation réelle pour le CPU et la mémoire. Les tableaux de bord montrent la comparaison entre ce que les pods ont demandé et ce qu'ils utilisent réellement, vous aidant à identifier les workloads sur-provisionnés (gaspillage de ressources) et sous-provisionnés (à risque de throttling ou OOM). Cela permet un dimensionnement optimal de vos workloads.
Bleemeo surveille-t-il les logs des conteneurs ?
Oui, avec la collecte de logs activée, Glouton capture automatiquement les logs de tous les conteneurs de votre cluster Kubernetes. Les logs sont collectés depuis stdout/stderr des conteneurs sans configuration supplémentaire. Vous pouvez appliquer des parsers et filtres personnalisés via les annotations de pods (glouton.log_format, glouton.log_filter). Les logs peuvent être corrélés avec les métriques pour un dépannage complet.
Combien de temps prend la mise en place du monitoring Kubernetes ?
Environ 30 secondes d'installation réelle. Un helm upgrade --install avec trois variables d'environnement (account ID, registration key, nom du cluster) déploie Glouton en DaemonSet sur tout votre cluster. La découverte automatique reconnaît plus de 100 services sans configuration ; les tableaux de bord et règles d'alerte Kubernetes sont livrés prêts à l'emploi. Aucun PVC à provisionner, aucune scrape config à écrire, aucun tableau de bord à importer, aucune règle d'alerte à rédiger.
Commencez à superviser vos clusters Kubernetes
Déploiement en quelques minutes. Obtenez une visibilité complète sur votre infrastructure K8s.