Monitoring dei Container
Docker, containerd e ogni servizio che gira dentro i tuoi container
Visibilità completa sulla tua flotta di container — CPU, memoria, I/O, rete e health check per container, oltre alla scoperta automatica dei servizi in esecuzione all'interno. Funziona su qualsiasi host Docker o containerd, con o senza Kubernetes.
Prova gratuita 15 giorni · Nessuna carta di credito richiesta · Configurazione in 30 secondi
Più di 500 aziende si affidano a noi per monitorare i loro container
Una Vista in Tempo Reale di Ogni Container su Ogni Host
I container sono effimeri per natura — partono, si fermano e si spostano più volte al giorno. Bleemeo trasforma questo ricambio in uno strato di osservabilità stabile leggendo direttamente il socket del runtime e seguendo ogni container per tutto il suo ciclo di vita.
Agnostico al Runtime
Supporto nativo per Docker e containerd. Collegati al socket e Bleemeo enumera ogni container, in esecuzione o arrestato.
Metriche per Container
CPU, memoria, I/O disco, throughput di rete e stato dell'health check — ogni metrica è etichettata con nome del container, immagine e ID.
Health Check
I risultati di HEALTHCHECK Docker sono esposti come metrica di prima classe e guidano automaticamente gli avvisi.
Pronto per Docker Compose
Ogni progetto Compose viene riconosciuto e raggruppato in un'unica applicazione per un dashboarding immediato.
Scoperta dei Servizi
PostgreSQL, Redis, NGINX, RabbitMQ e oltre 100 servizi vengono rilevati all'interno dei container e monitorati senza alcuna configurazione.
Nativo Prometheus
Aggiungi prometheus.io/scrape: "true" su un container e l'agente ne scrape automaticamente l'endpoint /metrics.
Cosa Raccoglie Bleemeo per Ciascun Container
Ogni metrica viene raccolta direttamente dal runtime del container — nessun sidecar, nessuna strumentazione manuale.
CPU e Memoria
Traccia come i container consumano le risorse dell'host nel tempo, sia in valori assoluti che in percentuale.
-
container_cpu_used— percentuale CPU -
container_mem_used— memoria in byte -
container_mem_used_perc— percentuale memoria - Metrica di stato che attraversa soglie configurabili
I/O Disco
Throughput di lettura e scrittura per container, aggregato su tutti i volumi montati.
-
container_io_read_bytes— byte/s letti -
container_io_write_bytes— byte/s scritti - Correla con le metriche disco dell'host
- Individua all'istante un container con I/O fuori controllo
Rete
Banda in ingresso e uscita per container, qualunque sia la configurazione di rete del container.
-
container_net_bits_recv— bit/s ricevuti -
container_net_bits_sent— bit/s inviati - Reti bridge, host e user-defined supportate
- Traffico etichettato con nome container e immagine
Salute e Ciclo di Vita
L'output della direttiva Docker HEALTHCHECK è esposto direttamente, insieme allo stato del container.
-
container_health_status— starting / healthy / unhealthy - Timestamp created, started, stopped
- Conteggio dei riavvii
- Eventi kill e OOM
Metadati
Viene allegata una copia dell'output di Docker/containerd inspect così sai sempre cosa stai guardando.
- Nome e ID del container
- Nome e tag dell'immagine
- Entrypoint e comando
- Label e progetto Compose
Metriche Applicative Interne
I servizi riconosciuti in esecuzione nei container ottengono le loro metriche specifiche — ritardo di replica per i database, profondità coda per i broker, tasso di richieste per i web server.
- Rilevamento da immagine e firma del processo
- Metriche specifiche per tipo di servizio
- Nessuna configurazione richiesta
- 100+ servizi — vedi il catalogo qui sotto
Servizi Scoperti Automaticamente nei Container
Quando un servizio riconosciuto gira dentro un container, Bleemeo lo rileva da immagine e firma del processo e inizia a raccogliere le sue metriche specifiche — nessun sidecar, nessun exporter, nessuna configurazione. Ecco una selezione dei più popolari; il catalogo contiene 60+ con integrazione nativa Prometheus e molti altri tramite Telegraf.
Funzionalità Native per i Container
🐳 Docker e containerd
Collegati a /var/run/docker.sock o /run/containerd/containerd.sock. Entrambi i runtime sono cittadini di prima classe, senza bisogno di plugin.
🏷️ Configurazione tramite Label
Controlla il monitoring con i label Docker: glouton.enable, glouton.check.ignore.port.*, glouton.allow_metrics, glouton.deny_metrics.
🪶 Pronto per OpenTelemetry
Ingerisci tracce e log OTLP dai tuoi container insieme alle metriche native. Usa l'agente come collector OpenTelemetry locale senza distribuire un binario separato.
📊 Scraping Prometheus
Annota un container con prometheus.io/scrape: "true" e il suo endpoint /metrics viene integrato nelle stesse dashboard delle metriche del runtime.
📜 Log Centralizzati
Lo stdout e lo stderr dei container possono essere catturati e centralizzati accanto alle metriche per un debug con contesto completo.
🔔 Avvisi Integrati
Avvisi pre-configurati per OOM di container, cicli di riavvio, stato unhealthy e saturazione di risorse — senza scrivere alcuna regola.
🧹 Filtraggio
Lista allow/deny con wildcard (bleemeo_*, *_builder) per saltare CI runner effimeri, container builder e sidecar di debug.
⚡ Basso Overhead
L'agente gira come singolo container (o sull'host) e usa meno di 100 MB di memoria anche monitorando centinaia di container.
Distribuzione in Tre Passi
Avvia il Container dell'Agente
Avvia il container Glouton su ogni host, montando il socket Docker. L'agente si collega al runtime e inizia immediatamente a scoprire i container.
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-agentI Container Appaiono Automaticamente
Ogni container in esecuzione compare nell'interfaccia web in pochi secondi, con le metriche in tempo reale. I nuovi container si aggiungono non appena vengono creati.
Affina con i Label
Aggiungi opzionalmente label su container Compose o Docker standard per esporre metriche personalizzate o escludere container specifici.
services:
api:
image: my/api
labels:
- prometheus.io/scrape=true
- prometheus.io/port=8080
ephemeral-worker:
image: my/worker
labels:
- glouton.enable=falseCome l'Agente Vede i Tuoi Container
Glouton gira una volta per host e si collega al runtime. Interroga le statistiche dei container, si iscrive agli eventi di ciclo di vita e inoltra tutto a Bleemeo Cloud.
Un Agente, Due Runtime
A Glouton non importa se l'host esegue Docker, containerd o entrambi simultaneamente. Si collega a ogni socket disponibile, deduplica i container che appaiono in entrambi (comune sui nodi Kubernetes che mantengono Docker per motivi storici) ed espone un'unica vista consolidata.
Configurazione Guidata dai Label
Il comportamento è controllato tramite label Docker: glouton.enable per escludere un container interamente, glouton.check.ignore.port.* per saltare una porta di servizio rilevata erroneamente, prometheus.io/scrape per metriche personalizzate. Nessuna modifica alla configurazione centrale, nessun riavvio dell'agente — basta ridistribuire il container e la modifica ha effetto.
Eventi di Ciclo di Vita in Tempo Reale
L'agente si iscrive al flusso di eventi del runtime (start, stop, kill, destroy) e li riflette immediatamente nella piattaforma Bleemeo. Un container in errore smette di riportare metriche CPU e produce un evento visibile sulla timeline — sai sempre se un buco è dovuto a un'interruzione o a un container fermato.
Filtraggio Allow/Deny
Usa la configurazione container.filter per mantenere il monitoring concentrato sui workload di produzione. Le allow list e deny list supportano i wildcard (bleemeo_*, *_builder) e la deny list vince sempre — perfetta per escludere CI runner effimeri, builder di breve durata o sidecar di debug dalla tua superficie di allerta.
Avvisi Integrati per i Guasti Comuni dei Container
Ricevi una notifica prima che un singolo container trascini giù tutto lo stack — senza scrivere una sola regola di avviso.
Ciclo di Vita
- Container OOM-killed
- Uscita inattesa con codice non zero
- Ciclo di riavvio rilevato
- Container fermato ma che dovrebbe girare
Salute
- HEALTHCHECK Docker unhealthy
- Stato di salute instabile
- Servizio scoperto automaticamente non disponibile
- Check TCP/HTTP personalizzato in errore
Pressione sulle Risorse
- CPU sostenuta sopra la soglia
- Percentuale memoria sopra la soglia
- I/O disco fuori controllo
- Saturazione di rete
Runtime
- Daemon Docker non raggiungibile
- Socket containerd non disponibile
- Errore di pull dell'immagine
- Errore dello storage driver
Perché Scegliere Bleemeo per il Monitoring dei Container?
Scoperta Zero Config
I container appaiono automaticamente in pochi secondi. Niente pod selector, niente exporter, nessuna configurazione di scrape per container da mantenere.
Dimensionamento Ottimale
Confronta l'uso reale di CPU e memoria con i limiti impostati nei tuoi file Compose e individua i container sovra- o sotto-allocati.
Agente Leggero
Meno di 100 MB di memoria per host, anche monitorando centinaia di container. Un solo container, nessuna proliferazione di sidecar.
Retention 13 mesi
Mantieni lo storico dei container abbastanza a lungo per post-mortem, pianificazione della capacità e analisi di tendenza.
Cos'è il Monitoring dei Container?
Il monitoring dei container è la pratica di tracciare la salute, le prestazioni e l'uso di risorse dei workload containerizzati — che girino sotto Docker, containerd, Podman o CRI-O. Poiché i container sono effimeri e condividono il kernel dell'host, richiedono un approccio diverso dal monitoring di server tradizionale: l'agente deve enumerare i container dall'API del runtime, leggere le statistiche cgroup e seguire i container per tutto il loro ciclo di vita — start, stop, restart, kill, destroy.
Una soluzione completa di monitoring dei container copre tre livelli. Primo, le metriche
di runtime: numero di container in esecuzione, salute del daemon, errori di pull dell'immagine.
Secondo, le metriche per container: percentuale CPU, byte di memoria, I/O disco, throughput di
rete e risultato della direttiva HEALTHCHECK. Terzo, le metriche all'interno del
container: le applicazioni che girano dentro — database, web server, code di messaggi — scoperte
automaticamente e monitorate con i loro plugin specifici.
Il monitoring dei container è distinto dal monitoring di Kubernetes: non serve un orchestratore per beneficiarne. Stack Docker Compose, server Docker a host singolo, pod Podman e installazioni containerd autonome godono tutti delle stesse metriche e della stessa superficie di query compatibile con Prometheus. Che tu adotti Kubernetes in futuro o no, i segnali a livello di container restano la fondazione del tuo stack di osservabilità.
Le Metriche dei Container in Dettaglio
Uso CPU
Riportato come percentuale di un core CPU completo dell'host (container_cpu_used). Traccia il tempo CPU totale consumato da tutti i processi nel container, normalizzato rispetto alla quota CPU del container e al numero di core disponibili. Utile per individuare worker fuori controllo o thread pool mal configurati.
Uso Memoria
Riportato sia in byte (container_mem_used) sia in percentuale del limite del container (container_mem_used_perc). Include RSS e cache. Un container che si avvicina al 100% rischia l'OOM kill — Bleemeo ti avvisa prima che succeda.
I/O Disco
Throughput di lettura e scrittura in byte al secondo (container_io_read_bytes, container_io_write_bytes). Aggregato su ogni dispositivo a blocchi che il container tocca. Essenziale per individuare container I/O-bound prima che saturino il disco dell'host.
Throughput di Rete
Bit ricevuti e inviati al secondo (container_net_bits_recv, container_net_bits_sent). Funziona su reti bridge, host e user-defined leggendo i contatori di interfaccia dal namespace di rete del container.
Stato di Salute
Il risultato della direttiva Docker HEALTHCHECK, esposto come container_health_status con valori starting, healthy o unhealthy. Gli avvisi scattano automaticamente su unhealthy, e l'instabilità dello stato è tracciata esplicitamente.
Runtime Globale
Aggregati a livello di runtime come containers_count più fatti di salute del daemon Docker e di containerd. Utili per rilevare runtime rotti prima che le metriche dei singoli container inizino a scomparire dalle tue dashboard.
Casi d'Uso
Stack Docker Compose
Ogni docker compose up viene automaticamente raggruppato in un'applicazione tramite il nome del progetto. Gli stack di sviluppo e di piccola produzione ottengono una dashboard pronta con stato di servizio, CPU, memoria e I/O per container — senza configurazione.
Docker Single-Host
Ideale per piccoli prodotti SaaS, tooling self-hosted e homelab. Un host, una manciata di container, tutto visibile da un'unica dashboard — con avvisi su OOM e health check unhealthy nativi.
Migrazione dalle VM
Monitora la nuova versione containerizzata affianco alla VM legacy. Confronta l'impronta di CPU e memoria, le latenze delle richieste e i tassi di errore per giustificare il passaggio con dati reali invece che con il fiuto.
containerd senza Kubernetes
Esegui containerd direttamente come runtime leggero per nodi multi-tenant, server edge o script di orchestrazione personalizzati. Bleemeo si aggancia al socket containerd e tratta i tuoi container esattamente come quelli Docker.
Strato Inferiore dei Nodi Kubernetes
Anche su Kubernetes, le metriche a livello di container restano preziose. Usa la vista container di Bleemeo per individuare sidecar anomali, correlare i riavvii con eventi del kernel e fare debug di problemi che lo strato Kubernetes astrae.
Revisione Post-Incidente
Con 13 mesi di metriche ed eventi di ciclo di vita conservati, ricostruisci la sequenza esatta di start, riavvii e OOM kill dei container durante un'interruzione — senza dipendere dai log Docker volatili.
Best Practice per il Monitoring dei Container
Dichiara un HEALTHCHECK in Ogni Immagine
Un HEALTHCHECK Docker è il modo più economico per trasformare un container black-box in un workload monitorato. Aggiungine uno a ogni Dockerfile che possiedi — anche un semplice curl su un endpoint /health — e Bleemeo avviserà gratuitamente sullo stato unhealthy.
Imposta Limiti di Memoria su Tutti i Container
Senza limiti di memoria, la metrica container_mem_used_perc è priva di senso: il container può usare l'intero host prima di incontrare un muro. Dichiara sempre un limite in Compose o nel comando docker run affinché le decisioni di dimensionamento si basino su dati percentuali reali.
Escludi i Container Effimeri
CI runner, builder di immagini e job di migrazione one-shot inondano le dashboard di rumore di breve durata. Usa label glouton.enable=false o la configurazione container.filter.deny_list (*_builder, ci_runner_*) per mantenere il segnale concentrato sui workload di lunga durata.
Esponi le Metriche Applicative tramite Label
Per le applicazioni personalizzate, aggiungi i label prometheus.io/scrape: "true" e prometheus.io/port per esporre un endpoint /metrics. Bleemeo lo scrape automaticamente e le metriche applicative appaiono sulla stessa dashboard del container accanto a CPU e memoria.
Correla con i Log dei Container
Un conteggio dei riavvii che sale ti dice che qualcosa non va; i log del container ti dicono esattamente cosa. Abilita la raccolta dei log accanto alle metriche — Bleemeo cattura stdout e stderr per container e li collega alla stessa timeline dei tuoi avvisi.
Vuoi approfondire?
Leggi la documentazioneDomande Frequenti
Tutto quello che devi sapere sul monitoring dei container
Cos'è il monitoring dei container?
Il monitoring dei container è la pratica di tracciare la salute, le prestazioni e l'uso di risorse dei workload containerizzati — Docker, containerd, Podman o CRI-O — insieme alle applicazioni che vi girano dentro. Fornisce metriche di CPU, memoria, I/O, rete e health check per container, con scoperta automatica dei servizi, così ogni nuovo container è monitorato senza configurazione manuale.
Perché il monitoring dei container è importante?
I container sono effimeri: partono, si fermano, scalano e si spostano tra host più volte al giorno. Senza monitoring, i team non possono correlare gli incidenti agli eventi del ciclo di vita dei container, rilevare OOM kill o cicli di riavvio, né dimensionare correttamente i limiti di risorse. Un buon monitoring di container espone presto la saturazione, riduce il tempo medio di risoluzione e trasforma il parco di container effimeri in una superficie di osservabilità stabile.
Quali metriche monitorare per un container Docker?
Il set di base è: uso CPU in percentuale, memoria usata (assoluta e in percentuale), throughput I/O disco in lettura e scrittura, byte di rete ricevuti e inviati, conteggio riavvii e stato del health check. Traccia anche gli eventi a livello di container (start, stop, kill, OOM) e, per ogni servizio scoperto, le metriche applicative rilevanti come tasso di richieste e latenza.
Qual è la differenza tra monitoring dei container e monitoring Kubernetes?
Il monitoring dei container si concentra sui singoli container e sul loro runtime (Docker o containerd) — utile su qualsiasi host, con o senza orchestratore. Il monitoring Kubernetes aggiunge concetti a livello di cluster: pod, nodi, namespace, API server, etcd, scheduler, DaemonSet. Puoi fare monitoring di container su un nodo Kubernetes, ma il monitoring Kubernetes richiede un agente consapevole del cluster.
Il monitoring dei container funziona senza Kubernetes?
Sì. Il monitoring dei container precede Kubernetes ed è particolarmente comune per gli stack Docker Compose, i deployment Docker a singolo host, gli ambienti Podman e le installazioni containerd-only. L'agente di monitoring si collega al socket del runtime (tipicamente /var/run/docker.sock o il socket containerd) e raccoglie le metriche direttamente, senza alcun orchestratore.
Come monitoro Docker Compose?
Il monitoring Docker Compose funziona puntando un agente consapevole dei container al socket Docker sull'host che esegue il tuo stack Compose. L'agente enumera ogni container del progetto e raccoglie automaticamente metriche di CPU, memoria, I/O e health per container. Gli agenti moderni riconoscono anche il label com.docker.compose.project e raggruppano ogni servizio del progetto in un'unica vista applicativa, così un docker compose up produce una dashboard pronta senza configurazione manuale.
Come un agente di monitoring raccoglie le metriche di un container Docker?
L'agente interroga l'API Docker Engine (o l'API gRPC di containerd) per enumerare i container e leggere le loro statistiche a livello di cgroup: tempo CPU, uso memoria, I/O di blocco e contatori di rete. Legge anche il risultato dei comandi Docker HEALTHCHECK, ispeziona i metadati del container (immagine, comando, label, date) e ascolta in tempo reale gli eventi del container (start, stop, kill).
Come monitoro i container containerd?
Punta l'agente di monitoring al socket containerd (tipicamente /run/containerd/containerd.sock) e l'agente enumererà namespace e container tramite l'API containerd, raccogliendo le stesse metriche di CPU, memoria, I/O e rete di Docker. È la configurazione comune per i nodi Kubernetes che hanno abbandonato Docker, ma funziona anche su host autonomi che eseguono containerd direttamente.
Come filtrare i container da monitorare?
Usa liste allow/deny di nomi di container con supporto ai wildcard nella configurazione dell'agente, e label Docker (es. glouton.enable=false) per escludere specifici container inline. Le allow list sono utili quando vuoi monitorare solo un sottoinsieme; le deny list servono a saltare CI runner effimeri, container builder o sidecar di debug. La deny list ha sempre la precedenza sulla allow list.
Posso monitorare un servizio che gira dentro un container?
Sì. Gli agenti di monitoring moderni scoprono automaticamente i servizi all'interno dei container — PostgreSQL, Redis, NGINX, RabbitMQ e centinaia di altri — ispezionando l'immagine e la firma del processo. Eseguono poi il plugin Telegraf appropriato o scrapano un endpoint Prometheus sull'IP e la porta del container. Puoi anche aggiungere annotazioni Prometheus (prometheus.io/scrape: "true") per esporre metriche applicative personalizzate.
Cos'è il monitoring dei Docker health check?
Docker HEALTHCHECK è una direttiva in un Dockerfile o in un file Compose che esegue un comando a intervalli regolari per valutare se il container è sano. Una piattaforma di monitoring espone il risultato di quel check (starting, healthy, unhealthy) come metrica e scatena un avviso quando il container passa a unhealthy — senza richiedere logica di sondaggio extra all'esterno del container.
Come monitoro i log dei container?
Il monitoring dei log dei container cattura i flussi stdout e stderr di ogni container tramite l'API dei log del runtime (API Docker Engine, CRI containerd). Una piattaforma completa inoltra questi log verso i log centralizzati affianco alle metriche, così puoi correlare una riga di log di errore con il picco CPU o l'OOM kill che l'ha causato. Aggiungi un parser — JSON, CRI, syslog — per estrarre campi strutturati, e usa label o annotazioni per includere o escludere specifici flussi di log.
Inizia a Monitorare i Tuoi Container
Un agente per host. Docker e containerd. Ogni metrica, ogni evento, ogni servizio.