Auf Prometheus und OpenTelemetry aufgebaut
Kein Vendor Lock-in
Production-ready Kubernetes-Monitoring in 30 Sekunden
Vollständiges Kubernetes-Cluster-Monitoring für Nodes, Pods und Container
Ein Helm-Chart — kein Prometheus zu betreiben, kein Grafana zu warten, kein Storage zu verwalten. Bleemeo liefert volle Sicht auf Cluster, Nodes, Pods und Container — mit Alerts, die ab Tag eins funktionieren.
15 Tage kostenlos testen Keine Kreditkarte nötig Keine langfristige Bindung
Europäisches Unternehmen
Daten bleiben in der EU · DSGVO-konform
Über 500 Unternehmen vertrauen uns
In Europa und darüber hinaus
Über 500 Unternehmen vertrauen auf Bleemeo für ihr Infrastruktur-Monitoring
99,99 %
Plattform-SLA
<100 MB
Agent-Speicher
100+
Auto-Discoveries
Die Herausforderungen des Kubernetes-Monitorings
Eigenes Kubernetes-Monitoring mit dem Open-Source-Ökosystem aufzubauen wirkt kostenlos — bis man die Engineering-Zeit zusammenrechnet. Vier Kosten, die erst nach dem Rollout sichtbar werden:
Operative Komplexität
Prometheus, Grafana, Alertmanager, Exporter, ein Storage-Backend — jedes Stück ist selbst eine Kubernetes-Anwendung, die deployt, aktualisiert, gesichert und gepatcht werden muss. Der Monitoring-Stack, der Ihre Plattform gesund halten soll, wird zu einer ihrer lautesten Incident-Quellen.
Storage im Skalierungsfall
Pod-Labels werden zu Cardinality-Explosionen. Einzelne Prometheus-Instanzen laufen aus RAM und Disk, wenn der Cluster wächst. Der nächste Schritt bedeutet, sich auf Thanos, Cortex oder Mimir einzulassen — ein weiteres verteiltes System mit eigenem Object Storage, Queriern, Compactors und Store Gateways im Betrieb.
Alerting-Reife
Out-of-the-box Kubernetes-Alert-Regeln decken die Basics ab, doch sie auf Ihre Workloads zu tunen — falsche Positive bei Rolling Updates eliminieren, Rauschen über Repliken hinweg deduplizieren, On-Call kalibrieren — dauert monatelange Iteration. Die meisten Teams arbeiten mit Alerts, denen sie nicht vollständig vertrauen.
On-Call-Belastung
Wenn Ihr Monitoring-Stack innerhalb des Clusters läuft, den er überwachen soll, reißt ein Control-Plane-Incident die Alerts mit nach unten. Rechnen Sie die laufende Zeit für die Wartung von Prometheus, Grafana und Storage hinzu, und Ihr DevOps-Team überwacht am Ende sein eigenes Monitoring statt das Produkt.
Warum Bleemeo für Kubernetes
Kubernetes-Cluster-Monitoring auf Produktionsniveau, geliefert als Managed Service. Keine Plattform zu betreiben, kein Storage zu skalieren, kein Alert-Stack zu hüten.
Einrichtung in 30 Sekunden, nicht in 2 Tagen
Ein helm upgrade --install, ein DaemonSet, drei Umgebungsvariablen — fertig. Keine PVCs zu provisionieren, keine
Scrape-Configs zu schreiben, keine Dashboards zu importieren, keine Alert-Regeln zu verfassen. Auto-Discovery erkennt 100+ Services
ohne Konfiguration.
13 Monate Retention out of the box
Hochauflösende Metriken werden 13 Monate aufbewahrt — ohne Thanos, Cortex oder Mimir auszurollen. Capacity Planning, Post-Mortems, saisonale Trends — alles zugänglich, ohne separate Langzeit-Storage-Schicht.
99,99 % SLA — Monitoring, das läuft, wenn Ihre Infrastruktur es nicht tut
Bleemeo läuft außerhalb Ihres Clusters auf einer vollständig gemanagten Plattform mit einem Uptime-SLA von 99,99 %. Wenn etcd kollabiert oder Nodes auf NotReady gehen, erreichen Sie die Alerts trotzdem. Das einzige Monitoring-System, das Sie nicht mit Ihren eigenen Incidents lahmlegen können.
Spart 20-40 Stunden/Monat an Monitoring-Operations
Self-hosted Kubernetes-Monitoring frisst 20-40 Engineering-Stunden pro Monat: Storage-Wachstum, Prometheus-Restarts, Scrape-Config-Drift, Alert-Tuning, Grafana-Upgrades. Bleemeo gibt diese Zeit Ihrer Plattform- und Produktarbeit zurück.
Sie haben bereits Prometheus?
Bleemeo ist kein Prometheus-Ersatz — es ist der Managed Service, der den operativen Aufwand beseitigt.
PromQL-Queries, Recording Rules, Scrape-basierte Aufnahme: alles unterstützt. Glouton scrapt Ihre bestehenden
/metrics-Endpoints, Bleemeo speichert und queried sie, und Sie betreiben kein Storage mehr. Nichts zu deployen, nichts zu
warten. Wenn Ihr Cluster in Schwierigkeiten ist, läuft die Plattform außerhalb weiter — damit der kritische Alert, den Sie erhalten
müssen, Sie wirklich erreicht.
Was Kubernetes-Teams sagen
Bleemeo hat das Kubernetes-Monitoring überraschend einfach gemacht. Innerhalb von Minuten hatten wir Einblick in unsere Cluster, Pods und Workloads, ohne komplexe Dashboards selbst bauen zu müssen.
Von helm install zum Dashboard
Glouton landet auf einem frischen Cluster und das Dashboard füllt sich — unten festgehalten.
30 Sekunden vom Deploy zum Dashboard.
Führen Sie denselben Ablauf auf Ihrem eigenen Cluster aus — dieselben 30 Sekunden.
Kubernetes Performance Monitoring auf jeder Ebene
Von der Cluster-Gesundheit bis zu einzelnen Container-Metriken — erhalten Sie vollständige Sichtbarkeit in Ihre Kubernetes-Umgebung. Bleemeo ersetzt Ihren Kubernetes Metrics Server durch eine umfassende Monitoring-Lösung mit Langzeitspeicherung und intelligentem Alerting.
Cluster API, etcd, Scheduler
→
Nodes CPU, Speicher, Kubelet
→
Pods Lebenszyklus, Neustarts
→
Container CPU, Speicher, OOM
Cluster-Ebene
Control Plane-Gesundheit, API Server-Latenz, etcd-Leistung, Scheduler-Metriken
Node-Ebene
CPU, Speicher, Festplatte, Netzwerk, Kubelet-Status, Node-Zustände
Pod-Ebene
Pod-Lebenszyklus, Neustart-Zähler, Ressourcenanforderungen vs. Limits, Bereitschaft
Container-Ebene
CPU-Drosselung, Speichernutzung, OOM-Ereignisse, Container-Zustände
Netzwerk
Service-Endpunkte, Ingress-Traffic, DNS-Auflösung, Network Policies
Speicher
PersistentVolume-Nutzung, Claim-Status, StorageClass-Kapazität, Mount-Gesundheit
Kubernetes Container Metriken im Überblick
Control Plane
Überwachen Sie das Herzstück Ihres Kubernetes-Clusters für Zuverlässigkeit und Leistung.
- API Server-Anforderungslatenz
- etcd-Gesundheit und -Latenz
- Scheduler-Warteschlangentiefe
- Controller Manager-Metriken
- Zertifikatsablauf
Nodes & Kubelet
Verfolgen Sie Node-Gesundheit und Kubelet-Leistung in Ihrem gesamten Cluster.
- Node CPU, Speicher, Festplatte
- Kubelet-Gesundheitsstatus
- Node-Zustände (Ready, DiskPressure, etc.)
- Pod-Kapazität und -Zuweisung
- Container Runtime-Metriken
Pods & Container
Tiefe Einblicke in Workload-Leistung und Ressourcenverbrauch.
- CPU-Nutzung und -Drosselung
- Speichernutzung und OOM-Kills
- Neustart-Zähler und Crash-Loops
- Ressourcenanforderungen vs. Limits
- Container-Zustände und -Ereignisse
Services & Netzwerk
Überwachen Sie Service-Endpunkte und Netzwerkkonnektivität.
- Service-Endpunkt-Gesundheit
- Ingress-Traffic und -Latenz
- Effektivität von Network Policies
- DNS-Auflösungszeiten
- Service Mesh-Metriken (Istio, Linkerd)
Workload-Ressourcen
Verfolgen Sie Deployments, StatefulSets, DaemonSets und Jobs.
- Deployment-Replica-Status
- Rolling Update-Fortschritt
- StatefulSet-Reihenfolge
- DaemonSet-Abdeckung
- Job- und CronJob-Abschluss
Persistenter Speicher
Überwachen Sie PersistentVolumes und Speicherleistung.
- PV/PVC-Bindungsstatus
- Speicherkapazitätsnutzung
- E/A-Durchsatz und -Latenz
- StorageClass-Bereitstellung
- Volume-Mount-Fehler
Kubernetes-native Funktionen
🔍 Auto-Discovery
Automatische Erkennung und Überwachung von Pods, Services und Endpunkten. Keine manuelle Konfiguration erforderlich, wenn Workloads skalieren.
📊 Prometheus-kompatibel
Native PromQL-Unterstützung. Scrapen Sie vorhandene Prometheus-Endpunkte. Verwenden Sie Ihre bestehenden Recording Rules und Alerts.
🏷️ Label-bewusst
Filtern und aggregieren Sie nach Kubernetes-Labels und -Annotationen. Gruppieren Sie Metriken nach Namespace, Deployment oder benutzerdefinierten Labels.
📈 Ressourcenoptimierung
Dimensionieren Sie Ressourcenanforderungen und -limits basierend auf tatsächlicher Nutzung richtig. Identifizieren Sie über- und unterprovisionierte Workloads.
🔔 Intelligentes Alerting
Vorkonfigurierte Alerts für häufige K8s-Probleme: CrashLoopBackOff, ausstehende Pods, Node NotReady, Zertifikatsablauf.
🌐 Multi-Cluster
Überwachen Sie mehrere Kubernetes-Cluster von einem einzigen Dashboard aus. Vergleichen Sie die Leistung über Umgebungen hinweg.
📦 Helm-Deployment
Stellen Sie den Bleemeo-Agent mit einem einzigen Helm-Chart bereit. GitOps-bereit mit vollständigen Anpassungsoptionen.
🔗 OpenTelemetry
Erfassen Sie Metriken und Logs über OpenTelemetry. Korrelieren Sie Infrastruktur-Metriken mit Anwendungsdaten.
Wie ein Helm-Deploy aussieht
1
Bleemeo Helm Repository hinzufügen
Fügen Sie das offizielle Bleemeo Helm-Chart-Repository zu Ihrer Helm-Installation hinzu.
helm repo add bleemeo-agent https://packages.bleemeo.com/bleemeo-agent/helm-charts
helm repo update2
Agent installieren
Stellen Sie den Glouton-Agent als DaemonSet mit Ihren Kontoanmeldedaten bereit.
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
Cluster anzeigen
Nodes, Pods und Services erscheinen automatisch innerhalb von Sekunden in Ihrem Bleemeo-Dashboard.
DaemonSet-Deployment
Glouton wird als DaemonSet bereitgestellt und platziert automatisch einen Agent-Pod auf jedem Node in Ihrem Cluster — einschließlich Nodes, die von Autoscalern hinzugefügt werden.
- Ein Agent pro Node, immer
- Tolerations für alle Node-Typen
- Autoscaler-bewusste Abdeckung
- GitOps-bereites Helm-Chart
DaemonSet Agent-Architektur
Ein Glouton-Pod pro Node gewährleistet vollständige Cluster-Abdeckung, von der Control Plane-Gesundheit bis zu einzelnen Container-Metriken.
DaemonSet-Deployment-Modell
Glouton wird als DaemonSet via Helm bereitgestellt und platziert genau einen Agent-Pod auf jedem Node in Ihrem Cluster. Das Helm-Chart enthält Tolerations für alle Standard-Node-Typen — GPU-Nodes, System-Nodes und Autoscaler-verwaltete Nodes erhalten alle automatisch einen Agenten. Nur drei Umgebungsvariablen sind erforderlich: GLOUTON_ACCOUNT_ID, GLOUTON_REGISTRATION_KEY und GLOUTON_KUBERNETES_CLUSTERNAME. Der Agent-Pod fordert minimale Ressourcen an (weniger als 100 MB Speicher) und konkurriert nicht mit Ihren Produktions-Workloads.
Pod-Annotationen für feingranulare Kontrolle
Kubernetes-Annotationen auf Ihren Pods steuern, wie Glouton mit jedem Workload interagiert. Setzen Sie glouton.enable: "false", um einen Pod vollständig vom Monitoring auszuschließen. Verwenden Sie glouton.check.ignore.port.*, um Health-Checks auf bestimmten Ports zu überspringen (nützlich für Sidecar-Container oder Debug-Ports). Fügen Sie Standard-Prometheus-Annotationen (prometheus.io/scrape: "true", prometheus.io/port, prometheus.io/path) hinzu, um anwendungsspezifische Metriken freizugeben, die Glouton scrapt und zusammen mit Infrastruktur-Metriken an Bleemeo Cloud weiterleitet.
Umfassende Kubernetes-Metriken
Über grundlegende Pod- und Node-Zähler hinaus sammelt Glouton tiefgreifende Kubernetes-Metriken: Pod-Anzahl nach Status (Running, Pending, Failed, Succeeded), Neustart-Zähler pro Container, CPU- und Speichernutzung im Vergleich zu Requests und Limits, Node- und Namespace-Anzahl, Ablaufdaten von CA- und Node-Zertifikaten sowie API Server- und Kubelet-Gesundheitsindikatoren. Alle Metriken sind mit Namespace, Owner-Kind (Deployment, DaemonSet, StatefulSet) und Owner-Name gelabelt für leistungsstarkes Filtern und Aggregieren in Dashboards.
ConfigMap-Anpassung
Überschreiben Sie Glouton-Standardwerte pro Cluster mit einer Kubernetes ConfigMap. Schließen Sie ganze Namespaces vom Monitoring aus (z.B. kube-system oder CI-Runner-Namespaces), passen Sie Metrik-Scrape-Intervalle an, fügen Sie benutzerdefinierte Labels zu allen Metriken eines bestimmten Clusters hinzu oder konfigurieren Sie zusätzliche Prometheus-Scrape-Ziele. Der ConfigMap-Ansatz integriert sich natürlich in GitOps-Workflows — speichern Sie Ihre Monitoring-Konfiguration neben Ihren Anwendungsmanifests und lassen Sie ArgoCD oder Flux diese deklarativ verwalten.
Vorgefertigte Kubernetes-Alerts
Werden Sie über häufige Kubernetes-Probleme benachrichtigt, bevor sie Ihre Benutzer beeinträchtigen.
Pod-Probleme
- CrashLoopBackOff erkannt
- Pod bleibt in Pending hängen
- Hohe Neustart-Anzahl
- OOMKilled Container
Node-Probleme
- Node NotReady
- Hoher CPU-/Speicherdruck
- Festplattenplatz niedrig
- Zu viele Pods geplant
Cluster-Probleme
- API Server-Fehler
- etcd-Latenz hoch
- Zertifikat läuft ab
- PVC ausstehend
Workload-Probleme
- Deployment-Replicas nicht verfügbar
- StatefulSet nicht bereit
- Job fehlgeschlagen
- HPA bei maximalen Replicas
Funktioniert mit Ihrem Stack
Managed K8s EKS, GKE, AKS, DigitalOcean
Distributionen OpenShift, Rancher, k3s, k0s
Service Mesh Istio, Linkerd, Consul Connect
Ingress NGINX, Traefik, HAProxy, Kong
Speicher Ceph, Longhorn, OpenEBS, CSI
Observability Prometheus, Grafana, OpenTelemetry
CI/CD ArgoCD, Flux, Jenkins, GitLab
Datenbanken PostgreSQL, MySQL, MongoDB, Redis
Gebaut für Kubernetes-Operatoren
Echtzeit-Sichtbarkeit
Sehen Sie Pod-Erstellung, Skalierungsereignisse und Ausfälle in Echtzeit. Keine Verzögerung bei der Metrikenerfassung.
Kostenoptimierung
Identifizieren Sie Ressourcenverschwendung und dimensionieren Sie Ihre Workloads richtig. Reduzieren Sie Cloud-Ausgaben ohne Leistungseinbußen.
Leichtgewichtiger Agent
Glouton verwendet minimale Ressourcen. Weniger als 100 MB Speicher pro Node. Konkurriert nicht mit Ihren Workloads.
Was ist Kubernetes-Monitoring?
Kubernetes-Monitoring ist die Praxis des Sammelns, Analysierens und Alarmierens von Metriken aus jeder Schicht einer Kubernetes-Umgebung — von der Cluster Control Plane bis hinunter zu einzelnen Container-Prozessen. Im Gegensatz zum traditionellen Server-Monitoring bringt Kubernetes einzigartige Herausforderungen mit sich: Workloads sind kurzlebig, Pods werden ständig erstellt und zerstört, und eine einzelne Anwendung kann sich über Dutzende von Replicas auf mehreren Nodes erstrecken.
Effektives Kubernetes-Monitoring erfordert Sichtbarkeit auf vier verschiedenen Ebenen. Die Cluster-Ebene verfolgt die Control Plane-Gesundheit, API Server-Latenz, etcd-Leistung und Zertifikatsablauf. Die Node-Ebene überwacht CPU, Speicher, Festplatte und Kubelet-Status auf jedem Worker-Node. Die Workload-Ebene verfolgt Deployment-Replicas, StatefulSet-Reihenfolge, DaemonSet-Abdeckung und Job-Abschluss. Schließlich liefert die Pod- und Container-Ebene Ressourcennutzung, Neustart-Zähler, OOM-Ereignisse und CPU-Drosselung pro Container.
Ohne Multi-Layer-Monitoring sind Kubernetes-Betreiber gezwungen, kubectl-Befehle und manuelle Log-Inspektion zur Diagnose von Problemen zu verwenden — ein reaktiver Ansatz, der nicht skaliert. Eine geeignete Monitoring-Lösung wie Bleemeo sammelt automatisch Metriken aus allen vier Schichten über ein DaemonSet-Deployment, korreliert Daten über Schichten hinweg und bietet vorgefertigte Alerts für häufige Fehlermodi wie CrashLoopBackOff, ausstehende Pods und Zertifikatsablauf.
K8s Metriken im Detail
Pod-Metriken
Verfolgen Sie Pod-Anzahl nach Status (Running, Pending, Failed, Succeeded), Neustart-Zähler pro Container, CPU- und Speichernutzung im Vergleich zu Requests und Limits sowie Pod-Alter. Labels umfassen Namespace, Owner-Kind (Deployment, DaemonSet, StatefulSet) und Owner-Name für einfache Aggregation und Filterung.
Ressourcenanforderungen vs. Limits
Vergleichen Sie, was Pods angefordert haben (CPU- und Speicher-Requests) mit dem tatsächlichen Verbrauch. Identifizieren Sie überprovisionierte Workloads, die Ressourcen verschwenden, und unterprovisionierte, die Gefahr von CPU-Drosselung oder OOMKill laufen. Diese Daten sind essentiell für die richtige Dimensionierung der Ressourcendefinitionen in Ihren Deployment-Manifests.
Cluster-Gesundheit
Überwachen Sie die Gesamtzahl der Nodes, Ready vs. NotReady Nodes, Namespace-Anzahl und den Gesamt-Cluster-Status. Verfolgen Sie API Server-Verfügbarkeit, etcd-Latenz und Scheduler-Warteschlangentiefe. Diese Metriken helfen Ihnen, die allgemeine Gesundheit und Kapazität Ihrer Kubernetes-Infrastruktur zu beurteilen.
Zertifikatsablauf
Verfolgen Sie die Ablaufdaten von CA-Zertifikaten und Node-Zertifikaten, die für die interne Kubernetes-Kommunikation verwendet werden. Werden Sie alarmiert, bevor Zertifikate ablaufen — eine häufige Ursache für plötzliche Cluster-Ausfälle, die mit automatisiertem Monitoring vollständig vermeidbar ist.
Kubelet & Node-Zustände
Überwachen Sie den Kubelet-Gesundheitsstatus auf jedem Node, Node-Zustände (Ready, DiskPressure, MemoryPressure, PIDPressure) und Container Runtime-Gesundheit. Erkennen Sie degradierte Nodes, bevor sie beginnen, Pods zu eviktieren oder NotReady werden.
Netzwerk & Ingress
Verfolgen Sie pro Pod empfangene und gesendete Netzwerk-Bytes, verworfene Pakete und Fehler-Zähler. Überwachen Sie Ingress-Controller-Anforderungsraten, Antwort-Latenzen und HTTP-Fehlerquoten. Korrelieren Sie Netzwerk-Metriken mit Pod-Neustarts oder Service-Degradierung, um Konnektivitätsprobleme, DNS-Auflösungsfehler oder fehlkonfigurierte Network Policies zu identifizieren.
Anwendungsfälle
Fehlerbehebung bei Pod-Ausfällen
Wenn ein Pod in CrashLoopBackOff gerät, müssen Sie sofort wissen warum. Bleemeo zeigt den Neustart-Zähler, den letzten Exit-Code, Container-Logs und korrelierte Node-Metriken. Bestimmen Sie, ob der Absturz durch Anwendungsfehler, OOM-Kills oder zugrunde liegenden Node-Ressourcendruck verursacht wird — alles von einem einzigen Dashboard aus.
Richtige Dimensionierung von Workloads
Überprovisionierte Ressourcenanforderungen verschwenden Cluster-Kapazität und erhöhen Cloud-Kosten. Unterprovisionierte Anforderungen verursachen Drosselung und OOM-Kills. Nutzen Sie Bleemeos Metriken für Ressourcenanforderungen vs. tatsächliche Nutzung über die Zeit, um die optimalen CPU- und Speicher-Requests für jeden Workload zu identifizieren und so Verschwendung zu reduzieren und gleichzeitig Ressourcenkonflikte zu vermeiden.
Kapazitätsplanung
Verfolgen Sie Cluster-Ressourcennutzungstrends über Wochen und Monate. Identifizieren Sie, wann Nodes sich Kapazitätsgrenzen nähern, und planen Sie Skalierungsereignisse, bevor Pods aufgrund unzureichender Ressourcen ausstehen. Nutzen Sie 13 Monate historischer Daten, um saisonale Muster vorherzusagen und für Infrastrukturwachstum zu budgetieren.
Multi-Cluster-Verwaltung
Überwachen Sie Entwicklungs-, Staging- und Produktions-Cluster von einem einzigen Dashboard aus. Vergleichen Sie die Ressourcennutzung über Umgebungen hinweg, erkennen Sie Konfigurationsabweichungen zwischen Clustern und stellen Sie sicher, dass Staging-Cluster die Produktions-Dimensionierung widerspiegeln. Jeder Cluster wird durch seinen konfigurierten Namen für einfaches Filtern identifiziert.
GitOps-Deployment-Validierung
Nach einem Flux- oder ArgoCD-Deployment überwachen Sie den Rollout in Echtzeit. Verfolgen Sie die Erstellung neuer Pods, die Terminierung alter Pods und die Replica-Verfügbarkeit während Rolling Updates. Erkennen Sie fehlgeschlagene Deployments (hängende Rollouts, Crash-Loops in neuen Versionen) und korrelieren Sie Deployment-Timing mit Metrikänderungen, um zu validieren, dass Releases wie erwartet funktionieren.
Kostenoptimierung & Kostenzuordnung
Analysieren Sie den Ressourcenverbrauch pro Namespace, um Infrastrukturkosten Teams oder Projekten zuzuordnen. Identifizieren Sie Namespaces mit konstant niedriger CPU- und Speichernutzung, die überprovisioniert sind. Nutzen Sie historische Nutzungsdaten, um Cluster-Node-Pools richtig zu dimensionieren, zu Spot- oder Preemptible-Instanzen für tolerante Workloads zu wechseln und die gesamten Kubernetes-Infrastrukturausgaben zu reduzieren.
Best Practices für Kubernetes-Monitoring
1
Als DaemonSet bereitstellen
Führen Sie den Monitoring-Agent als DaemonSet aus, damit jeder Node automatisch einen Agent-Pod erhält — einschließlich Nodes, die von Autoscalern hinzugefügt werden. Dies garantiert vollständige Cluster-Abdeckung ohne manuellen Eingriff. Bleemeos Helm-Chart behandelt dies standardmäßig, einschließlich geeigneter Tolerations und Ressourcenlimits.
2
Prometheus-Annotationen für benutzerdefinierte Metriken verwenden
Fügen Sie prometheus.io/scrape: "true" zu Ihren Pod-Annotationen hinzu, um anwendungsspezifische Metriken im Prometheus-Format freizugeben. Bleemeos Agent entdeckt diese Endpunkte automatisch und sendet die Metriken in die Cloud. Dies ist der Standard-Kubernetes-native Ansatz für benutzerdefinierte Anwendungsmetriken ohne zusätzliche Konfiguration.
3
Immer Ressourcenanforderungen und -limits setzen
Pods ohne Ressourcenanforderungen können nicht richtig dimensioniert werden, da es keine Vergleichsbasis gibt. Setzen Sie immer CPU- und Speicher-Requests in Ihren Deployment-Manifests. Bleemeo vergleicht dann die tatsächliche Nutzung mit den angeforderten Ressourcen und ermöglicht datengestützte Dimensionierungsentscheidungen, die Verschwendung reduzieren und Ressourcenkonflikte verhindern.
4
Zertifikatsablauf überwachen
Kubernetes verwendet TLS-Zertifikate für die interne Kommunikation zwischen API Server, Kubelet und etcd. Abgelaufene Zertifikate verursachen plötzliche, vollständige Cluster-Ausfälle. Bleemeo verfolgt Zertifikatsablaufdaten und alarmiert Sie vor dem Ablauf, sodass Sie Zeit haben, Zertifikate proaktiv zu rotieren, anstatt das Problem während eines Ausfalls zu entdecken.
5
Metriken mit Container-Logs korrelieren
Ein steigender Pod-Neustart-Zähler sagt Ihnen, dass etwas nicht stimmt. Die Container-Logs sagen Ihnen genau was. Aktivieren Sie die Log-Erfassung neben Metriken für die schnellste Ursachenanalyse. Bleemeos Agent sammelt beides vom selben DaemonSet, und die Cloud-Plattform zeigt sie zusammen an, verknüpft durch Pod-Name und Zeitstempel.
Möchten Sie mehr erfahren?
Dokumentation lesenHäufig gestellte Fragen
Alles, was Sie über das Kubernetes-Monitoring von Bleemeo wissen müssen
Wie stelle ich Bleemeo in meinem Kubernetes-Cluster bereit?
Bleemeo wird über ein Helm-Chart als DaemonSet bereitgestellt, das einen Glouton-Agenten auf jedem Node platziert. Fügen Sie einfach das Bleemeo Helm-Repository hinzu und führen Sie dann helm upgrade --install mit Ihren Kontoanmeldedaten und dem Clusternamen aus. Der Agent erkennt automatisch alle Pods und Services. Sie können auch mit reinem kubectl unter Verwendung unserer bereitgestellten Manifests bereitstellen. GitOps-Tools wie ArgoCD und Flux werden vollständig unterstützt.
Welche Kubernetes-Metriken sammelt Bleemeo?
Bleemeo sammelt umfassende Metriken, darunter: Pod-Metriken (Anzahl nach Status, Neustart-Zähler, CPU-/Speichernutzung vs. Requests/Limits), Node-Metriken (CPU, Speicher, Festplatte, Netzwerk, Kubelet-Status), Cluster-Metriken (Node-Anzahl, Namespace-Anzahl, API-Status) und Zertifikatsablauf (CA- und Node-Zertifikate). Metriken werden nach Namespace, Owner-Kind (Deployment, DaemonSet) und Owner-Name für einfache Filterung gelabelt.
Erkennt Bleemeo automatisch Services in meinen Pods?
Ja, automatische Service-Erkennung ist eine Kernfunktion. Der Bleemeo-Agent erkennt alle laufenden Services in Ihren Pods (Datenbanken, Webserver, Message Queues, etc.) und beginnt, sie ohne manuelle Konfiguration zu überwachen. Er erkennt über 100 Services standardmäßig. Wenn Pods hoch- oder herunterskalieren, folgt das Monitoring automatisch — keine Neukonfiguration für kurzlebige Workloads erforderlich.
Kann ich Prometheus-Metriken von meinen Anwendungen scrapen?
Ja, Bleemeo unterstützt Prometheus-Style-Scraping über Pod-Annotationen. Fügen Sie prometheus.io/scrape: "true" zu Ihren Pods hinzu und geben Sie optional prometheus.io/path und prometheus.io/port für benutzerdefinierte Metrik-Endpunkte an. Der Agent erkennt und scrapt diese Endpunkte automatisch. Sie können auch PromQL verwenden, um Metriken in Ihren Dashboards abzufragen.
Was sind die Ressourcenanforderungen für den Agenten?
Der Glouton-Agent ist auf geringen Ressourcenverbrauch ausgelegt. Er verwendet typischerweise weniger als 100 MB Speicher und minimale CPU pro Node. Der Agent konkurriert nicht mit Ihren Produktions-Workloads um Ressourcen. Ressourcenanforderungen und -limits können bei Bedarf in den Helm-Werten angepasst werden. Der Agent ist für Umgebungen mit hoher Dichte und vielen Pods pro Node optimiert.
Wie unterscheidet sich Bleemeo davon, Prometheus + Grafana selbst zu betreiben?
Bleemeo ist kein Prometheus-Ersatz — es ist der Managed Service, der den operativen Aufwand beseitigt. PromQL, Recording Rules und Scrape-basierte Aufnahme: alles unterstützt. Glouton scrapt Ihre bestehenden /metrics-Endpoints, die Plattform speichert und queried sie, und Sie betreiben kein Storage mehr. Keine Prometheus-Server zu skalieren, kein Thanos- oder Mimir-Cluster zu betreiben, kein Grafana zu aktualisieren. Bleemeo läuft zudem außerhalb Ihres Clusters auf einer Plattform mit 99,99 % SLA, damit Alerts Sie auch dann erreichen, wenn Ihre Infrastruktur in Schwierigkeiten steckt.
Welche Kubernetes-Distributionen werden unterstützt?
Bleemeo funktioniert mit allen wichtigen Kubernetes-Distributionen: Managed Services (EKS, GKE, AKS, DigitalOcean Kubernetes), Selbst-verwaltet (kubeadm, k3s, k0s, microk8s) und Enterprise-Distributionen (OpenShift, Rancher, Tanzu). Wir unterstützen Kubernetes 1.19+. Der Agent passt sich an verschiedene Container-Runtimes an, einschließlich containerd, CRI-O und Docker.
Kann ich mehrere Kubernetes-Cluster überwachen?
Ja, Bleemeo unterstützt Multi-Cluster-Monitoring. Jeder Cluster erscheint als separate Entität in Ihrem Dashboard mit eigenem Namen (konfiguriert über config.kubernetes.clustername). Sie können alle Cluster in einem vereinheitlichten Dashboard anzeigen, Metriken clusterübergreifend vergleichen und in einzelne Cluster-Details eintauchen. Dies ist ideal für die Verwaltung von Entwicklungs-, Staging- und Produktionsumgebungen.
Welche Alarme sind für Kubernetes vorkonfiguriert?
Bleemeo enthält vorgefertigte Alarme für häufige Kubernetes-Probleme: Pod-Probleme (CrashLoopBackOff, ausstehende Pods, hohe Neustart-Anzahl, OOMKilled), Node-Probleme (NotReady, Festplatten-/Speicherdruck), Cluster-Probleme (API-Server-Fehler, ablaufende Zertifikate) und Workload-Probleme (Deployment-Replicas nicht verfügbar, fehlgeschlagene Jobs). Sie können Schwellenwerte anpassen oder zusätzliche Alarme erstellen.
Wie verfolge ich Ressourcenanforderungen vs. tatsächliche Nutzung?
Bleemeo sammelt sowohl Ressourcenanforderungen/-limits als auch tatsächliche Nutzung für CPU und Speicher. Dashboards zeigen den Vergleich zwischen dem, was Pods angefordert haben, und dem, was sie tatsächlich nutzen, und helfen, überprovisionierte Workloads (Ressourcenverschwendung) und unterprovisionierte (Drosselungs- oder OOM-Risiko) zu identifizieren. Dies ermöglicht effektive Dimensionierung Ihrer Workloads.
Überwacht Bleemeo Container-Logs?
Ja, mit aktivierter Log-Erfassung erfasst Glouton automatisch Logs von allen Containern in Ihrem Kubernetes-Cluster. Logs werden von Container stdout/stderr ohne zusätzliche Konfiguration gesammelt. Sie können benutzerdefinierte Parser und Filter über Pod-Annotationen anwenden (glouton.log_format, glouton.log_filter). Logs können mit Metriken für umfassende Fehlerbehebung korreliert werden.
Wie lange dauert die Einrichtung des Kubernetes-Monitorings?
Etwa 30 Sekunden tatsächliche Installation. Ein helm upgrade --install mit drei Umgebungsvariablen (Account-ID, Registration-Key, Cluster-Name) deployt Glouton als DaemonSet im gesamten Cluster. Auto-Discovery erkennt 100+ Services ohne Konfiguration; vorgefertigte Dashboards und Kubernetes-Alert-Regeln sind out-of-the-box dabei. Keine PVCs zu provisionieren, keine Scrape-Configs zu schreiben, keine Dashboards zu importieren, keine Alert-Regeln zu verfassen.
Starten Sie mit dem Monitoring Ihrer Kubernetes-Cluster
Deployment in Minuten. Vollständige Sichtbarkeit in Ihre K8s-Infrastruktur.