Kubernetes-Monitoring
Vollständige Observability für Ihre Kubernetes-Cluster. Überwachen Sie Nodes, Pods, Container und Services mit automatischer Erkennung, Prometheus-Kompatibilität und intelligentem Alerting.
Full-Stack Kubernetes-Observability
Von der Cluster-Gesundheit bis zu einzelnen Container-Metriken — erhalten Sie vollständige Sichtbarkeit in Ihre Kubernetes-Umgebung.
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
Was wir überwachen
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.
Schnelle Einrichtung mit Helm
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 updateAgent 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"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
Warum Bleemeo für Kubernetes?
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.
13 Monate Aufbewahrung
Behalten Sie historische Daten für Kapazitätsplanung und Trendanalyse. Vergleichen Sie die Leistung im Zeitverlauf.
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.
Detaillierte Kubernetes-Metriken
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
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.
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.
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.
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.
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.
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.
Starten Sie mit dem Monitoring Ihrer Kubernetes-Cluster
Deployment in Minuten. Vollständige Sichtbarkeit in Ihre K8s-Infrastruktur.