Container Monitoring
Docker, containerd und jeder Dienst, der in Ihren Containern läuft
Volle Sicht auf Ihre Container-Flotte — CPU, Speicher, I/O, Netzwerk und Health Checks pro Container, ergänzt durch die automatische Erkennung der im Inneren laufenden Dienste. Funktioniert auf jedem Docker- oder containerd-Host, mit oder ohne Kubernetes.
15 Tage kostenlose Testversion · Keine Kreditkarte erforderlich · Einrichtung in 30 Sekunden
Über 500 Unternehmen vertrauen uns die Überwachung ihrer Container an
Live-Ansicht jedes Containers auf jedem Host
Container sind von Natur aus flüchtig — sie starten, stoppen und wandern mehrfach täglich. Bleemeo verwandelt dieses Kommen und Gehen in eine stabile Observability-Schicht, indem es den Runtime-Socket direkt ausliest und jeden Container während seines gesamten Lebenszyklus verfolgt.
Runtime-agnostisch
Native Unterstützung für Docker und containerd. Verbinden Sie sich mit dem Socket und Bleemeo zählt jeden Container auf, ob laufend oder gestoppt.
Metriken pro Container
CPU, Speicher, Platten-I/O, Netzwerkdurchsatz und Health-Check-Status — jede Metrik ist mit Containername, Image und ID beschriftet.
Health Checks
Die Ergebnisse von Docker HEALTHCHECK werden als Metrik erster Klasse bereitgestellt und steuern Alarme automatisch.
Bereit für Docker Compose
Jedes Compose-Projekt wird erkannt und für ein einfaches Dashboarding zu einer einzigen Anwendung gruppiert.
Service Discovery
PostgreSQL, Redis, NGINX, RabbitMQ und über 100 Dienste werden innerhalb der Container erkannt und ohne jede Konfiguration überwacht.
Prometheus-nativ
Setzen Sie prometheus.io/scrape: "true" auf einem Container und der Agent scrapt dessen /metrics-Endpoint automatisch.
Was Bleemeo pro Container erfasst
Jede Metrik wird direkt aus der Container-Runtime gelesen — ohne Sidecar, ohne manuelle Instrumentierung.
CPU & Speicher
Verfolgen Sie, wie Container die Host-Ressourcen im Zeitverlauf nutzen — sowohl in Rohwerten als auch in Prozent.
-
container_cpu_used— CPU in Prozent -
container_mem_used— Speicher in Bytes -
container_mem_used_perc— Speicher in Prozent - Status-Metrik überschreitet konfigurierbare Schwellwerte
Platten-I/O
Lese- und Schreibdurchsatz pro Container, aggregiert über alle gemounteten Volumes.
-
container_io_read_bytes— gelesene Bytes/s -
container_io_write_bytes— geschriebene Bytes/s - Korrelieren Sie mit den Platten-Metriken des Hosts
- Erkennen Sie sofort einen einzelnen Container mit ausuferndem I/O
Netzwerk
Ein- und ausgehende Bandbreite pro Container, unabhängig von der Netzwerkkonfiguration des Containers.
-
container_net_bits_recv— empfangene Bits/s -
container_net_bits_sent— gesendete Bits/s - Bridge-, Host- und benutzerdefinierte Netzwerke unterstützt
- Verkehr mit Containername und Image beschriftet
Gesundheit & Lebenszyklus
Die Ausgabe der Docker-HEALTHCHECK-Direktive wird direkt bereitgestellt, zusammen mit dem Zustand des Containers.
-
container_health_status— starting / healthy / unhealthy - Zeitstempel created, started, stopped
- Restart-Zähler
- Kill- und OOM-Events
Metadaten
Eine Kopie der Docker-/containerd-inspect-Ausgabe wird angehängt, damit Sie stets wissen, was Sie betrachten.
- Containername und -ID
- Image-Name und -Tag
- Entrypoint und Command
- Labels und Compose-Projekt
Interne Anwendungsmetriken
Erkannte Dienste, die in Containern laufen, erhalten ihre eigenen spezifischen Metriken — Replikationsverzögerung bei Datenbanken, Queue-Tiefe bei Brokern, Request-Rate bei Webservern.
- Erkennung über Image und Prozess-Signatur
- Spezifische Metriken pro Diensttyp
- Keine Konfiguration erforderlich
- 100+ Dienste — siehe Katalog unten
In Containern automatisch erkannte Dienste
Wenn ein erkannter Dienst in einem Container läuft, identifiziert Bleemeo ihn über Image und Prozess-Signatur und beginnt, seine spezifischen Metriken zu erfassen — ohne Sidecars, ohne Exporter, ohne Konfiguration. Hier eine Auswahl beliebter Dienste; der Katalog umfasst 60+ mit Prometheus-nativer Integration und viele weitere über Telegraf.
Container-native Funktionen
🐳 Docker & containerd
Verbinden Sie sich mit /var/run/docker.sock oder /run/containerd/containerd.sock. Beide Runtimes sind Bürger erster Klasse, ohne Plugin.
🏷️ Konfiguration über Labels
Steuern Sie das Monitoring über Docker-Labels: glouton.enable, glouton.check.ignore.port.*, glouton.allow_metrics, glouton.deny_metrics.
🪶 Bereit für OpenTelemetry
Nehmen Sie OTLP-Traces und -Logs aus Ihren Containern neben den nativen Metriken auf. Nutzen Sie den Agenten als lokalen OpenTelemetry-Collector, ohne ein separates Binary auszurollen.
📊 Prometheus-Scraping
Annotieren Sie einen Container mit prometheus.io/scrape: "true" und sein /metrics-Endpoint fließt in dieselben Dashboards wie die Runtime-Metriken.
📜 Zentralisierte Logs
stdout und stderr der Container können erfasst und zentralisiert neben den Metriken gespeichert werden — für Debugging mit vollem Kontext.
🔔 Eingebaute Alarme
Vorkonfigurierte Alarme für Container-OOM, Restart-Loops, unhealthy-Status und Ressourcensättigung — ohne eine einzige Regel zu schreiben.
🧹 Filterung
Allow-/Deny-Liste mit Wildcards (bleemeo_*, *_builder) überspringt ephemere CI-Runner, Builder-Container und Debug-Sidecars.
⚡ Geringer Overhead
Der Agent läuft als einzelner Container (oder auf dem Host) und belegt weniger als 100 MB Arbeitsspeicher, selbst bei hunderten überwachten Containern.
Ausrollen in drei Schritten
Starten Sie den Agent-Container
Starten Sie den Glouton-Container auf jedem Host und binden Sie den Docker-Socket ein. Der Agent verbindet sich mit der Runtime und beginnt sofort, Container zu erkennen.
docker run -d --name="bleemeo-agent" --restart unless-stopped \
-v /var/lib/glouton:/var/lib/glouton \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /:/hostroot:ro \
-e GLOUTON_BLEEMEO_ACCOUNT_ID=your_account_id \
-e GLOUTON_BLEEMEO_REGISTRATION_KEY=your_registration_key \
--pid=host --net=host \
--cap-add SYS_PTRACE --cap-add SYS_ADMIN \
bleemeo/bleemeo-agentContainer erscheinen automatisch
Jeder laufende Container taucht innerhalb von Sekunden in der Web-Oberfläche auf, Metriken streamen live. Neue Container treten bei, sobald sie erstellt werden.
Feinabstimmung über Labels
Fügen Sie bei Bedarf Labels an Compose- oder reine Docker-Container, um eigene Metriken bereitzustellen oder bestimmte Container auszuschließen.
services:
api:
image: my/api
labels:
- prometheus.io/scrape=true
- prometheus.io/port=8080
ephemeral-worker:
image: my/worker
labels:
- glouton.enable=falseWie der Agent Ihre Container sieht
Glouton läuft einmal pro Host und verbindet sich mit der Runtime. Er fragt Container-Statistiken ab, abonniert Lebenszyklus-Events und leitet alles an die Bleemeo Cloud weiter.
Ein Agent, zwei Runtimes
Glouton ist es egal, ob der Host Docker, containerd oder beides gleichzeitig ausführt. Der Agent verbindet sich mit jedem verfügbaren Socket, dedupliziert Container, die in beiden erscheinen (auf Kubernetes-Knoten, die Docker aus historischen Gründen behalten, üblich), und stellt eine einzige konsolidierte Sicht bereit.
Konfiguration über Labels
Das Verhalten wird über Docker-Labels gesteuert: glouton.enable, um einen Container komplett auszuschließen, glouton.check.ignore.port.*, um einen falsch erkannten Service-Port zu überspringen, prometheus.io/scrape für eigene Metriken. Keine zentralen Config-Änderungen, keine Agent-Neustarts — einfach den Container neu ausrollen und die Änderung wirkt.
Lebenszyklus-Events in Echtzeit
Der Agent abonniert den Event-Stream der Runtime (start, stop, kill, destroy) und spiegelt ihn sofort in der Bleemeo-Plattform wider. Ein fehlerhafter Container meldet keine CPU-Metriken mehr und erzeugt ein sichtbares Event in der Timeline — Sie wissen also stets, ob eine Lücke auf einen Ausfall oder einen gestoppten Container zurückgeht.
Allow/Deny-Filterung
Nutzen Sie die container.filter-Konfiguration, um das Monitoring auf Produktions-Workloads zu konzentrieren. Allow- und Deny-Listen unterstützen Wildcards (bleemeo_*, *_builder), wobei die Deny-Liste immer gewinnt — perfekt, um ephemere CI-Runner, kurzlebige Builder oder Debug-Sidecars aus Ihrer Alarmierungsfläche zu entfernen.
Eingebaute Alarme für typische Container-Ausfälle
Werden Sie benachrichtigt, bevor ein einzelner Container den gesamten Stack herunterreißt — ohne eine einzige Alarmregel zu schreiben.
Lebenszyklus
- Container durch OOM beendet
- Unerwartetes Ende mit Exit-Code ≠ 0
- Restart-Loop erkannt
- Container gestoppt, obwohl er laufen sollte
Gesundheit
- Docker HEALTHCHECK unhealthy
- Instabiler Health-Status
- Automatisch erkannter Dienst nicht erreichbar
- Eigener TCP-/HTTP-Check schlägt fehl
Ressourcendruck
- CPU dauerhaft über dem Schwellwert
- Speicher in Prozent über dem Schwellwert
- Platten-I/O außer Kontrolle
- Netzwerksättigung
Runtime
- Docker-Daemon nicht erreichbar
- containerd-Socket nicht verfügbar
- Image-Pull fehlgeschlagen
- Storage-Driver-Fehler
Warum Container Monitoring mit Bleemeo?
Null-Konfig-Erkennung
Container erscheinen automatisch innerhalb von Sekunden. Keine Pod-Selektoren, keine Exporter, keine Scrape-Konfigurationen pro Container.
Ressourcen passend dimensionieren
Vergleichen Sie die tatsächliche CPU- und Speichernutzung mit den in Ihren Compose-Dateien gesetzten Limits und erkennen Sie über- oder unter-provisionierte Container.
Schlanker Agent
Weniger als 100 MB Arbeitsspeicher pro Host, selbst bei hunderten überwachten Containern. Ein Container, keine Sidecar-Schwemme.
Retention 13 Monate
Container-Historie lange genug aufbewahren — für Post-mortems, Kapazitätsplanung und Trendanalyse.
Was ist Container Monitoring?
Container Monitoring ist die Praxis, Gesundheit, Leistung und Ressourcennutzung containerisierter Workloads zu verfolgen — egal ob sie unter Docker, containerd, Podman oder CRI-O laufen. Weil Container flüchtig sind und den Host-Kernel teilen, erfordern sie einen anderen Ansatz als das klassische Server-Monitoring: Der Agent muss Container über die Runtime-API aufzählen, cgroup-Statistiken lesen und sie durch ihren gesamten Lebenszyklus hindurch verfolgen — start, stop, restart, kill, destroy.
Eine vollständige Container-Monitoring-Lösung deckt drei Ebenen ab. Erstens
Runtime-Metriken: Anzahl laufender Container, Daemon-Gesundheit, Image-Pull-Fehler. Zweitens
Pro-Container-Metriken: CPU in Prozent, Speicher in Bytes, Platten-I/O, Netzwerkdurchsatz und
das Ergebnis der HEALTHCHECK-Direktive. Drittens In-Container-Metriken: die
Anwendungen, die innen laufen — Datenbanken, Webserver, Message Queues — automatisch erkannt und mit
ihren spezifischen Plugins überwacht.
Container Monitoring unterscheidet sich vom Kubernetes-Monitoring: Sie brauchen keinen Orchestrator, um davon zu profitieren. Docker-Compose-Stacks, Docker-Server auf einem einzelnen Host, Podman-Pods und eigenständige containerd-Installationen profitieren alle von denselben Metriken und derselben Prometheus-kompatiblen Abfragefläche. Egal, ob Sie später Kubernetes einführen oder nicht — die Signale auf Container-Ebene bleiben das Fundament Ihres Observability-Stacks.
Container-Metriken im Detail
CPU-Nutzung
Ausgedrückt als Prozentsatz eines vollen Host-CPU-Kerns (container_cpu_used). Verfolgt die gesamte CPU-Zeit, die von allen Prozessen im Container verbraucht wird, normalisiert auf das CPU-Kontingent des Containers und die Anzahl verfügbarer Kerne. Hilft, ausufernde Worker oder schlecht eingestellte Thread-Pools zu erkennen.
Speichernutzung
Sowohl in Bytes (container_mem_used) als auch als Prozentsatz des Container-Limits (container_mem_used_perc) berichtet. Beinhaltet RSS und Cache. Ein Container nahe 100 % läuft Gefahr, per OOM beendet zu werden — Bleemeo alarmiert Sie rechtzeitig.
Platten-I/O
Lese- und Schreibdurchsatz in Bytes pro Sekunde (container_io_read_bytes, container_io_write_bytes). Aggregiert über jedes Block-Device, das der Container berührt. Wichtig, um I/O-gebundene Container zu erkennen, bevor sie die Host-Platte sättigen.
Netzwerkdurchsatz
Empfangene und gesendete Bits pro Sekunde (container_net_bits_recv, container_net_bits_sent). Funktioniert gleichermaßen auf Bridge-, Host- und benutzerdefinierten Netzwerken, indem die Schnittstellenzähler aus dem Netzwerknamespace des Containers gelesen werden.
Gesundheitszustand
Das Ergebnis der Docker-HEALTHCHECK-Direktive, bereitgestellt als container_health_status mit den Werten starting, healthy oder unhealthy. Alarme werden bei unhealthy automatisch ausgelöst, und Status-Flapping wird explizit nachverfolgt.
Globale Runtime
Aggregate auf Runtime-Ebene wie containers_count sowie Health-Fakten von Docker-Daemon und containerd. Nützlich, um kaputte Runtimes zu erkennen, bevor einzelne Container-Metriken aus Ihren Dashboards verschwinden.
Anwendungsfälle
Docker-Compose-Stacks
Jedes docker compose up wird über den Projektnamen automatisch zu einer Anwendung gruppiert. Entwicklungs- und kleine Produktions-Stacks erhalten ein vorgefertigtes Dashboard mit Dienststatus, CPU, Speicher und I/O pro Container — ohne Konfiguration.
Single-Host-Docker
Ideal für kleine SaaS-Produkte, Self-hosted-Tooling und Homelabs. Ein Host, eine Handvoll Container, alles aus einem Dashboard sichtbar — mit Alarmen bei OOM und unhealthy Health Checks sofort einsatzbereit.
Migration von VMs
Überwachen Sie die neue containerisierte Version parallel zur Legacy-VM. Vergleichen Sie CPU- und Speicher-Fußabdruck, Request-Latenzen und Fehlerraten, um den Umstieg mit echten Daten statt Bauchgefühl zu rechtfertigen.
containerd ohne Kubernetes
Betreiben Sie containerd direkt als schlanke Runtime für Multi-Tenant-Knoten, Edge-Server oder eigene Orchestrierungs-Skripte. Bleemeo hängt sich an den containerd-Socket und behandelt Ihre Container wie Docker-Container.
Kubernetes-Knoten-Unterbau
Selbst auf Kubernetes bleiben Container-Metriken wertvoll. Nutzen Sie die Container-Sicht von Bleemeo, um rogue Sidecars aufzuspüren, Restarts mit Kernel-Events zu korrelieren und Probleme zu debuggen, die die Kubernetes-Ebene wegabstrahiert.
Post-Incident-Review
Mit 13 Monate aufbewahrten Metriken und Lebenszyklus-Events rekonstruieren Sie während eines Ausfalls die exakte Abfolge von Starts, Restarts und OOM-Kills — ohne sich auf flüchtige Docker-Logs zu verlassen.
Best Practices für Container Monitoring
Deklarieren Sie in jedem Image einen HEALTHCHECK
Ein Docker-HEALTHCHECK ist die günstigste Methode, aus einem Black-Box-Container einen überwachten Workload zu machen. Fügen Sie in jedes Ihrer Dockerfiles einen hinzu — und sei es nur ein einfaches curl auf einen /health-Endpoint — und Bleemeo alarmiert kostenlos bei unhealthy.
Setzen Sie auf allen Containern Speicherlimits
Ohne Speicherlimits ist die Metrik container_mem_used_perc bedeutungslos: Der Container kann den gesamten Host verbrauchen, bevor er anstößt. Deklarieren Sie immer ein Limit in Compose oder im Docker-Run-Befehl, damit Dimensionierungsentscheidungen auf echten prozentualen Daten beruhen.
Ephemere Container ausschließen
CI-Runner, Image-Builder und einmalige Migrationsjobs überschwemmen Dashboards mit kurzlebigem Rauschen. Verwenden Sie Labels wie glouton.enable=false oder die Konfiguration container.filter.deny_list (*_builder, ci_runner_*), um das Signal auf langlebige Workloads zu konzentrieren.
Anwendungsmetriken über Labels bereitstellen
Fügen Sie bei Eigenentwicklungen die Labels prometheus.io/scrape: "true" und prometheus.io/port hinzu, um einen /metrics-Endpoint bereitzustellen. Bleemeo scrapt ihn automatisch und die Anwendungsmetriken erscheinen im selben Container-Dashboard wie CPU und Speicher.
Mit Container-Logs korrelieren
Ein steigender Restart-Zähler zeigt Ihnen, dass etwas nicht stimmt; die Container-Logs sagen Ihnen genau, was. Aktivieren Sie die Log-Erfassung neben den Metriken — Bleemeo erfasst stdout und stderr pro Container und verknüpft sie mit derselben Timeline wie Ihre Alarme.
Möchten Sie tiefer einsteigen?
Dokumentation lesenHäufig gestellte Fragen
Alles, was Sie über Container Monitoring wissen müssen
Was ist Container Monitoring?
Container Monitoring ist die Praxis, Gesundheit, Leistung und Ressourcennutzung containerisierter Workloads zu verfolgen — Docker, containerd, Podman oder CRI-O — zusammen mit den darin laufenden Anwendungen. Es liefert Metriken zu CPU, Speicher, I/O, Netzwerk und Health Checks pro Container sowie automatische Service-Erkennung, sodass jeder neue Container ohne manuelle Konfiguration überwacht wird.
Warum ist Container Monitoring wichtig?
Container sind flüchtig: Sie starten, stoppen, skalieren und wandern mehrfach täglich zwischen Hosts. Ohne Monitoring können Teams Vorfälle nicht mit Lebenszyklus-Events korrelieren, OOM Kills oder Restart-Loops nicht erkennen und Ressourcenlimits nicht passend dimensionieren. Gutes Container Monitoring zeigt Ressourcensättigung früh, verkürzt die mittlere Behebungszeit und macht aus einer Flotte kurzlebiger Container eine stabile Beobachtungsfläche.
Welche Metriken sollte ich für einen Docker-Container überwachen?
Der Grundumfang: CPU in Prozent, genutzter Speicher (absolut und in Prozent), Platten-I/O in Lese- und Schreibdurchsatz, Netzwerk-Bytes empfangen und gesendet, Restart-Zähler und der Health-Check-Status. Verfolgen Sie außerdem die Container-Events (start, stop, kill, OOM) und für jeden erkannten Dienst die relevanten Anwendungsmetriken wie Request-Rate und Latenz.
Was ist der Unterschied zwischen Container Monitoring und Kubernetes-Monitoring?
Container Monitoring konzentriert sich auf einzelne Container und deren Runtime (Docker oder containerd) — nützlich auf jedem Host, mit oder ohne Orchestrator. Kubernetes-Monitoring ergänzt Konzepte auf Cluster-Ebene: Pods, Nodes, Namespaces, API Server, etcd, Scheduler, DaemonSets. Container Monitoring funktioniert auf einem Kubernetes-Knoten, Kubernetes-Monitoring erfordert dagegen einen cluster-bewussten Agenten.
Funktioniert Container Monitoring ohne Kubernetes?
Ja. Container Monitoring gibt es länger als Kubernetes und ist besonders verbreitet bei Docker-Compose-Stacks, Docker-Deployments auf einem einzelnen Host, Podman-Umgebungen und reinen containerd-Installationen. Der Monitoring-Agent verbindet sich mit dem Socket der Container-Runtime (typischerweise /var/run/docker.sock oder dem containerd-Socket) und sammelt Metriken direkt, ganz ohne Orchestrator.
Wie überwache ich Docker Compose?
Docker-Compose-Monitoring funktioniert, indem man einen containerbewussten Agenten auf den Docker-Socket des Hosts richtet, auf dem der Compose-Stack läuft. Der Agent zählt jeden Container des Projekts auf und sammelt automatisch CPU-, Speicher-, I/O- und Health-Metriken pro Container. Moderne Agenten erkennen zudem das Label com.docker.compose.project und gruppieren jeden Dienst des Projekts in eine einzige Anwendungsansicht, sodass ein einziges docker compose up ohne manuelle Konfiguration ein fertiges Dashboard liefert.
Wie sammelt ein Monitoring-Agent Metriken eines Docker-Containers?
Der Agent fragt die Docker-Engine-API (oder die containerd-gRPC-API) ab, um Container aufzuzählen und deren Statistiken auf cgroup-Ebene zu lesen: CPU-Zeit, Speichernutzung, Block-I/O und Netzwerkzähler. Er liest auch das Ergebnis von Docker-HEALTHCHECK-Befehlen, inspiziert Container-Metadaten (Image, Command, Labels, Daten) und hört in Echtzeit auf Container-Events (start, stop, kill).
Wie überwache ich containerd-Container?
Richten Sie den Monitoring-Agenten auf den containerd-Socket (typischerweise /run/containerd/containerd.sock) und er zählt Namespaces und Container über die containerd-API auf und sammelt dieselben CPU-, Speicher-, I/O- und Netzwerkmetriken wie bei Docker. Das ist die übliche Konfiguration für Kubernetes-Knoten, die Docker abgelegt haben, funktioniert aber auch auf eigenständigen Hosts, die containerd direkt ausführen.
Wie filtere ich, welche Container überwacht werden?
Verwenden Sie Allow-/Deny-Listen von Container-Namen mit Wildcard-Unterstützung in der Agenten-Konfiguration und Docker-Labels (z. B. glouton.enable=false), um einzelne Container inline auszuschließen. Allow-Listen sind nützlich, wenn Sie nur eine Teilmenge überwachen möchten; Deny-Listen, um kurzlebige CI-Runner, Builder-Container oder ephemere Sidecars zu überspringen. Die Deny-Liste hat immer Vorrang vor der Allow-Liste.
Kann ich einen Dienst überwachen, der in einem Container läuft?
Ja. Moderne Monitoring-Agenten erkennen Dienste automatisch innerhalb von Containern — PostgreSQL, Redis, NGINX, RabbitMQ und hunderte weitere — indem sie das Image und die Prozess-Signatur inspizieren. Anschließend führen sie das passende Telegraf-Plugin aus oder scrapen einen Prometheus-Endpoint über IP und Port des Containers. Sie können auch Prometheus-Annotationen (prometheus.io/scrape: "true") setzen, um eigene Anwendungsmetriken bereitzustellen.
Was ist Docker-Health-Check-Monitoring?
Docker HEALTHCHECK ist eine Direktive in einem Dockerfile oder einer Compose-Datei, die einen Befehl in regelmäßigen Abständen ausführt, um zu prüfen, ob der Container gesund ist. Eine Monitoring-Plattform stellt das Ergebnis dieses Checks (starting, healthy, unhealthy) als Metrik bereit und löst einen Alarm aus, sobald der Container auf unhealthy wechselt — ohne zusätzliche Sondierungslogik außerhalb des Containers.
Wie überwache ich Container-Logs?
Container-Log-Monitoring erfasst die stdout- und stderr-Streams jedes Containers über die Log-API des Runtime (Docker-Engine-API, containerd-CRI). Eine vollständige Plattform leitet diese Logs zu den zentralisierten Logs neben den Metriken weiter, damit Sie eine Fehlerlogzeile mit dem CPU-Peak oder OOM-Kill korrelieren können, der sie verursacht hat. Fügen Sie einen Parser hinzu — JSON, CRI, syslog —, um strukturierte Felder zu extrahieren, und verwenden Sie Labels oder Annotationen, um bestimmte Log-Streams ein- oder auszuschließen.
Starten Sie mit dem Monitoring Ihrer Container
Ein Agent pro Host. Docker und containerd. Jede Metrik, jedes Event, jeder Dienst.