Costruito su Prometheus e OpenTelemetry
Nessun vendor lock-in
Monitoraggio Kubernetes pronto per la produzione in 30 secondi
Monitoraggio Cluster Kubernetes per Nodi, Pod e Container
Un chart Helm, nessun Prometheus da gestire, nessun Grafana da mantenere, nessuno storage da amministrare. Bleemeo ti offre piena visibilità su cluster, nodi, pod e container — con alert che funzionano dal primo giorno.
Prova gratuita 15 giorni Senza carta di credito Senza impegno a lungo termine
Azienda europea
Dati conservati nell'UE · Conforme al GDPR
Oltre 500 aziende si fidano di noi
In tutta Europa e oltre
Oltre 500 aziende si affidano a Bleemeo per monitorare la propria infrastruttura
99,99%
SLA della piattaforma
<100 MB
Memoria Agente
100+
Auto-Discovery
Le sfide del monitoraggio Kubernetes
Costruire il proprio monitoraggio Kubernetes con l'ecosistema open source sembra gratuito — finché non si conta il tempo di ingegneria. Quattro costi che emergono solo dopo il rollout:
Complessità operativa
Prometheus, Grafana, Alertmanager, exporter, un backend di storage — ogni componente è a sua volta un'applicazione Kubernetes da distribuire, aggiornare, mettere in sicurezza e patchare. Lo stack di monitoraggio che dovrebbe mantenere sana la tua piattaforma finisce per essere una delle sue principali fonti di incidenti.
Storage su larga scala
Le label dei pod si trasformano in esplosioni di cardinalità. Le istanze Prometheus singole esauriscono RAM e disco con la crescita del cluster. Andare oltre significa impegnarsi con Thanos, Cortex o Mimir — un altro sistema distribuito con il proprio object storage, querier, compactor e store gateway da gestire.
Maturità degli alert
Le regole di alert Kubernetes pronte all'uso coprono le basi, ma adattarle ai tuoi workload — eliminando i falsi positivi sui rolling update, deduplicando il rumore tra repliche, calibrando l'on-call — richiede mesi di iterazione. La maggior parte dei team gira con alert di cui non può fidarsi completamente.
Carico dell'on-call
Quando il tuo stack di monitoraggio vive dentro il cluster che dovrebbe sorvegliare, un incidente del control plane porta giù anche gli alert. Aggiungi il tempo ricorrente per mantenere Prometheus, Grafana e lo storage, e il tuo team DevOps finisce per monitorare il proprio monitoraggio invece del prodotto.
Perché Bleemeo per Kubernetes
Monitoraggio del cluster Kubernetes di livello production, erogato come servizio gestito. Nessuna piattaforma da gestire, nessuno storage da scalare, nessuno stack di alert da accudire.
Setup in 30 secondi, non in 2 giorni
Un helm upgrade --install, un DaemonSet, tre variabili d'ambiente — fatto. Nessun PVC da provisionare, nessuna scrape
config da scrivere, nessuna dashboard da importare, nessuna regola di alert da scrivere. La scoperta automatica riconosce più di 100
servizi senza configurazione.
13 mesi di retention out of the box
Metriche ad alta risoluzione conservate per 13 mesi senza dover distribuire Thanos, Cortex o Mimir. Capacity planning, post-mortem, trend stagionali — tutto accessibile senza un layer separato di storage a lungo termine.
SLA 99,99% — il monitoraggio che funziona quando la tua infrastruttura non funziona
Bleemeo gira fuori dal tuo cluster, su una piattaforma completamente gestita con SLA di uptime del 99,99%. Quando etcd crolla o i nodi passano a NotReady, gli alert ti raggiungono comunque. L'unico sistema di monitoraggio che non puoi mandare giù con i tuoi stessi incidenti.
Risparmia 20-40 ore/mese sull'operatività del monitoraggio
Un monitoraggio Kubernetes self-hosted consuma 20-40 ore-ingegnere al mese: crescita dello storage, riavvii di Prometheus, scrape config che derivano, tuning degli alert, upgrade di Grafana. Bleemeo restituisce quel tempo al tuo lavoro su piattaforma e prodotto.
Hai già Prometheus?
Bleemeo non è un sostituto di Prometheus — è il servizio gestito che elimina il carico operativo.
Query PromQL, recording rule, ingestione tramite scrape: tutto supportato. Glouton raccoglie i tuoi endpoint
/metrics esistenti, Bleemeo li archivia e li interroga, e smetti di gestire storage. Nulla da distribuire, nulla da mantenere.
Se il tuo cluster è in difficoltà, la piattaforma continua a girare al di fuori — così l'alert critico che devi ricevere ti arriva davvero.
Cosa dicono i team Kubernetes
Bleemeo ha reso il monitoraggio di Kubernetes sorprendentemente facile. In pochi minuti avevamo visibilità sui nostri cluster, pod e workload senza dover costruire dashboard complessi da soli.
Da helm install alla dashboard
Glouton atterra su un cluster nuovo e la dashboard si riempie — catturato qui sotto.
30 secondi dal deploy alla dashboard.
Riproduci lo stesso flusso sul tuo cluster — sempre 30 secondi.
Monitoraggio delle Performance Kubernetes a Ogni Livello
Dalla salute del cluster alle metriche dei singoli container, il nostro server di metriche kubernetes vi offre visibilità completa sul vostro ambiente Kubernetes.
Cluster API, etcd, scheduler
→
Nodi CPU, memoria, kubelet
→
Pod Ciclo di vita, riavvii
→
Container CPU, memoria, OOM
Livello Cluster
Salute del control plane, latenza API server, performance etcd, metriche scheduler
Livello Nodo
CPU, memoria, disco, rete, stato kubelet, condizioni dei nodi
Livello Pod
Ciclo di vita dei pod, conteggio riavvii, richieste risorse vs limiti, readiness
Livello Container
CPU throttling, utilizzo memoria, eventi OOM, stati dei container
Networking
Endpoint dei servizi, traffico ingress, risoluzione DNS, network policy
Storage
Utilizzo PersistentVolume, stato dei claim, capacità storage class, salute dei mount
Metriche dei Container Kubernetes Raccolte
Control Plane
Monitorate il cuore del vostro cluster Kubernetes per affidabilità e performance.
- Latenza richieste API Server
- Salute e latenza etcd
- Profondità coda Scheduler
- Metriche Controller manager
- Scadenza certificati
Nodi e Kubelet
Monitorate la salute dei nodi e le performance del kubelet in tutto il cluster.
- CPU, memoria, disco del nodo
- Stato di salute Kubelet
- Condizioni del nodo (Ready, DiskPressure, ecc.)
- Capacità e allocazione pod
- Metriche container runtime
Pod e Container
Visibilità approfondita sulle performance dei workload e il consumo di risorse.
- Utilizzo CPU e throttling
- Utilizzo memoria e OOM kill
- Conteggio riavvii e crash loop
- Richieste risorse vs limiti
- Stati ed eventi dei container
Servizi e Networking
Monitorate gli endpoint dei servizi e la connettività di rete.
- Salute endpoint servizi
- Traffico e latenza Ingress
- Efficacia network policy
- Tempi di risoluzione DNS
- Metriche service mesh (Istio, Linkerd)
Risorse Workload
Monitorate Deployment, StatefulSet, DaemonSet e Job.
- Stato repliche Deployment
- Progresso rolling update
- Ordinamento StatefulSet
- Copertura DaemonSet
- Completamento Job e CronJob
Storage Persistente
Monitorate PersistentVolume e performance dello storage.
- Stato binding PV/PVC
- Utilizzo capacità storage
- Throughput e latenza I/O
- Provisioning StorageClass
- Errori mount volume
Funzionalità Kubernetes-Native
🔍 Auto-Discovery
Scoprite e monitorate automaticamente pod, servizi ed endpoint. Nessuna configurazione manuale necessaria quando i workload scalano.
📊 Compatibile Prometheus
Supporto nativo PromQL. Scraping degli endpoint Prometheus esistenti. Usate le vostre recording rule e alert esistenti.
🏷️ Label-Aware
Filtrate e aggregate per label e annotation Kubernetes. Raggruppate le metriche per namespace, deployment o label personalizzate.
📈 Ottimizzazione Risorse
Dimensionate correttamente richieste e limiti delle risorse basandovi sull'utilizzo reale. Identificate workload sovra e sotto-dimensionati.
🔔 Alerting Intelligente
Alert preconfigurati per problemi comuni K8s: CrashLoopBackOff, pod pending, nodi NotReady, scadenza certificati.
🌐 Multi-Cluster
Monitorate più cluster Kubernetes da un'unica dashboard. Confrontate le performance tra ambienti diversi.
📦 Deploy con Helm
Distribuite l'agente Bleemeo con un singolo chart Helm. Pronto per GitOps con opzioni di personalizzazione complete.
🔗 OpenTelemetry
Ingerite metriche e log via OpenTelemetry. Correlate le metriche dell'infrastruttura con i dati applicativi.
Com'è un deploy Helm
1
Aggiungete il Repository Helm Bleemeo
Aggiungete il repository ufficiale del chart Helm Bleemeo alla vostra installazione Helm.
helm repo add bleemeo-agent https://packages.bleemeo.com/bleemeo-agent/helm-charts
helm repo update2
Installate l'Agente
Distribuite l'agente Glouton come DaemonSet con le credenziali del vostro account.
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
Visualizzate il Vostro Cluster
Nodi, pod e servizi appaiono automaticamente nella vostra dashboard Bleemeo in pochi secondi.
Deploy DaemonSet
Glouton si distribuisce come DaemonSet, posizionando automaticamente un pod agente su ogni nodo del vostro cluster, inclusi i nodi aggiunti dagli autoscaler.
- Un agente per nodo, sempre
- Toleration per tutti i tipi di nodo
- Copertura autoscaler-aware
- Chart Helm pronto per GitOps
Architettura Agente DaemonSet
Un pod Glouton per nodo garantisce una copertura completa del cluster, dalla salute del control plane alle metriche dei singoli container.
Modello di Deploy DaemonSet
Glouton si distribuisce come DaemonSet tramite Helm, posizionando esattamente un pod agente su ogni nodo del vostro cluster. Il chart Helm include toleration per tutti i tipi di nodo standard: nodi GPU, nodi di sistema e nodi gestiti dall'autoscaler ricevono tutti un agente automaticamente. Sono richieste solo tre variabili d'ambiente: GLOUTON_ACCOUNT_ID, GLOUTON_REGISTRATION_KEY e GLOUTON_KUBERNETES_CLUSTERNAME. Il pod agente richiede risorse minime (meno di 100 MB di memoria) e non compete con i vostri workload di produzione.
Annotation Pod per Controllo Granulare
Le annotation Kubernetes sui vostri pod controllano come Glouton interagisce con ogni workload. Impostate glouton.enable: "false" per escludere un pod dal monitoraggio completamente. Usate glouton.check.ignore.port.* per saltare i controlli di salute su porte specifiche (utile per container sidecar o porte di debug). Aggiungete le annotation Prometheus standard (prometheus.io/scrape: "true", prometheus.io/port, prometheus.io/path) per esporre metriche specifiche dell'applicazione che Glouton raccogliera e inviera a Bleemeo Cloud insieme alle metriche dell'infrastruttura.
Metriche Kubernetes Complete
Oltre ai semplici conteggi di pod e nodi, Glouton raccoglie metriche Kubernetes approfondite: conteggio pod per stato (Running, Pending, Failed, Succeeded), conteggio riavvii per container, utilizzo CPU e memoria confrontati con richieste e limiti, conteggio nodi e namespace, date di scadenza dei certificati per CA e certificati dei nodi, e indicatori di salute di API server e kubelet. Tutte le metriche sono etichettate con namespace, owner kind (Deployment, DaemonSet, StatefulSet) e owner name per un filtraggio e aggregazione potenti nelle dashboard.
Personalizzazione ConfigMap
Sovrascrivete i default di Glouton per cluster usando una ConfigMap Kubernetes. Escludete interi namespace dal monitoraggio (es. kube-system o namespace CI runner), regolate gli intervalli di scraping delle metriche, aggiungete label personalizzate a tutte le metriche di un cluster specifico, o configurate target Prometheus aggiuntivi. L'approccio ConfigMap si integra naturalmente con i workflow GitOps: archiviate la vostra configurazione di monitoraggio insieme ai manifest applicativi e lasciate che ArgoCD o Flux la gestiscano in modo dichiarativo.
Alert Kubernetes Preconfigurati
Ricevete notifiche sui problemi comuni di Kubernetes prima che impattino i vostri utenti.
Problemi Pod
- CrashLoopBackOff rilevato
- Pod bloccato in Pending
- Conteggio riavvii elevato
- Container OOMKilled
Problemi Nodo
- Nodo NotReady
- Pressione CPU/memoria elevata
- Spazio disco insufficiente
- Troppi pod schedulati
Problemi Cluster
- Errori API server
- Latenza etcd elevata
- Certificato in scadenza
- PVC pending
Problemi Workload
- Repliche Deployment non disponibili
- StatefulSet non pronto
- Job fallito
- HPA al massimo delle repliche
Funziona con il Vostro Stack
K8s Managed EKS, GKE, AKS, DigitalOcean
Distribuzioni OpenShift, Rancher, k3s, k0s
Service Mesh Istio, Linkerd, Consul Connect
Ingress NGINX, Traefik, HAProxy, Kong
Storage Ceph, Longhorn, OpenEBS, CSI
Osservabilità Prometheus, Grafana, OpenTelemetry
CI/CD ArgoCD, Flux, Jenkins, GitLab
Database PostgreSQL, MySQL, MongoDB, Redis
Pensato per gli operator Kubernetes
Visibilità in Tempo Reale
Visualizzate creazione pod, eventi di scaling e failure nel momento in cui accadono. Nessun ritardo nella raccolta delle metriche.
Ottimizzazione Costi
Identificate sprechi di risorse e dimensionate correttamente i vostri workload. Riducete la spesa cloud senza impattare le performance.
Agente Leggero
Glouton utilizza risorse minime. Meno di 100MB di memoria per nodo. Non compete con i vostri workload.
Cos'è il Monitoraggio Kubernetes?
Il monitoraggio Kubernetes è la pratica di raccogliere, analizzare e generare alert sulle metriche di ogni livello di un ambiente Kubernetes, dal control plane del cluster fino ai singoli processi dei container. A differenza del monitoraggio server tradizionale, Kubernetes introduce sfide uniche: i workload sono effimeri, i pod vengono creati e distrutti costantemente, e una singola applicazione può estendersi su decine di repliche distribuite su più nodi.
Un monitoraggio Kubernetes efficace richiede visibilità su quattro livelli distinti. Il livello cluster monitora la salute del control plane, la latenza dell'API server, le performance di etcd e la scadenza dei certificati. Il livello nodo monitora CPU, memoria, disco e stato del kubelet su ogni worker node. Il livello workload monitora le repliche dei Deployment, l'ordinamento degli StatefulSet, la copertura dei DaemonSet e il completamento dei Job. Infine, il livello pod e container fornisce utilizzo risorse, conteggio riavvii, eventi OOM e CPU throttling per container.
Senza monitoraggio multi-livello, gli operatori Kubernetes sono costretti a usare comandi kubectl e ispezione manuale dei log per diagnosticare i problemi, un approccio reattivo che non scala. Una soluzione di monitoraggio adeguata come Bleemeo raccoglie metriche da tutti e quattro i livelli automaticamente tramite deploy DaemonSet, correla i dati tra i livelli e fornisce alert preconfigurati per le modalità di failure comuni come CrashLoopBackOff, pod pending e scadenza certificati.
Metriche K8s in Dettaglio
Metriche Pod
Monitorate i conteggi pod per stato (Running, Pending, Failed, Succeeded), conteggio riavvii per container, utilizzo CPU e memoria rispetto a richieste e limiti, e eta dei pod. Le label includono namespace, owner kind (Deployment, DaemonSet, StatefulSet) e owner name per aggregazione e filtraggio semplici.
Richieste Risorse vs Limiti
Confrontate ciò che i pod hanno richiesto (richieste CPU e memoria) con ciò che consumano effettivamente. Identificate workload sovra-provisionati che sprecano risorse e quelli sotto-provisionati a rischio di CPU throttling o OOMKill. Questi dati sono essenziali per il right-sizing delle definizioni risorse nei vostri manifest di deployment.
Salute del Cluster
Monitorate il conteggio totale dei nodi, nodi Ready vs NotReady, conteggio namespace e stato complessivo del cluster. Monitorate la disponibilità dell'API server, la latenza etcd e la profondità della coda dello scheduler. Queste metriche vi aiutano a valutare la salute e la capacità complessiva della vostra infrastruttura Kubernetes.
Scadenza Certificati
Monitorate le date di scadenza dei certificati CA e dei certificati dei nodi utilizzati per la comunicazione interna di Kubernetes. Ricevete alert prima che i certificati scadano, una causa comune di failure improvvisi del cluster che è interamente prevenibile con il monitoraggio automatizzato.
Kubelet e Condizioni dei Nodi
Monitorate lo stato di salute del kubelet su ogni nodo, le condizioni dei nodi (Ready, DiskPressure, MemoryPressure, PIDPressure) e la salute del container runtime. Rilevate nodi degradati prima che inizino a evacuare pod o diventino NotReady.
Network & Ingress
Monitorate byte ricevuti e trasmessi per pod, pacchetti persi e conteggio errori. Monitorate le request rate del controller Ingress, le latenze di risposta e i rapporti di errore HTTP. Correlate le metriche di rete con i riavvii dei pod o il degrado dei servizi per identificare problemi di connettività, failure di risoluzione DNS o network policy mal configurate.
Casi d'Uso
Troubleshooting Failure dei Pod
Quando un pod entra in CrashLoopBackOff, dovete sapere il perché immediatamente. Bleemeo mostra il conteggio riavvii, l'ultimo codice di uscita, i log del container e le metriche correlate a livello di nodo. Determinate se il crash è causato da errori applicativi, OOM kill o pressione sulle risorse del nodo sottostante, tutto da un'unica dashboard.
Right-Sizing dei Workload
Richieste di risorse sovra-provvisionate sprecano capacità del cluster e aumentano i costi cloud. Richieste sotto-provvisionate causano throttling e OOM kill. Usate le metriche di Bleemeo sulle richieste risorse vs utilizzo effettivo nel tempo per identificare le richieste CPU e memoria ottimali per ogni workload, riducendo gli sprechi e prevenendo la contesa di risorse.
Capacity Planning
Monitorate i trend di utilizzo risorse del cluster su settimane e mesi. Identificate quando i nodi si avvicinano ai limiti di capacità e pianificate gli eventi di scaling prima che i pod restino in pending per risorse insufficienti. Usate 13 mesi di dati storici per prevedere pattern stagionali e pianificare il budget per la crescita dell'infrastruttura.
Gestione Multi-Cluster
Monitorate cluster di sviluppo, staging e produzione da un'unica dashboard. Confrontate l'utilizzo risorse tra ambienti, rilevate derive di configurazione tra cluster e assicuratevi che i cluster di staging rispecchino il dimensionamento della produzione. Ogni cluster e identificato dal nome configurato per un filtraggio semplice.
Validazione Deploy GitOps
Dopo un deploy con Flux o ArgoCD, monitorate il rollout in tempo reale. Monitorate la creazione dei nuovi pod, la terminazione dei vecchi pod e la disponibilità delle repliche durante i rolling update. Rilevate deploy falliti (rollout bloccati, crash loop nelle nuove versioni) e correlate la tempistica del deploy con le variazioni delle metriche per verificare che i rilasci funzionino come previsto.
Ottimizzazione Costi & Chargeback
Analizzate il consumo di risorse per namespace per allocare i costi dell'infrastruttura a team o progetti. Identificate namespace con utilizzo CPU e memoria costantemente basso che sono sovra-provisionati. Usate i dati storici di utilizzo per dimensionare correttamente i pool di nodi del cluster, passare a istanze spot o preemptible per workload tolleranti, e ridurre la spesa complessiva dell'infrastruttura Kubernetes.
Best Practice per il Monitoraggio Kubernetes
1
Deploy come DaemonSet
Eseguite l'agente di monitoraggio come DaemonSet in modo che ogni nodo riceva automaticamente un pod agente, inclusi i nodi aggiunti dagli autoscaler. Questo garantisce una copertura completa del cluster senza intervento manuale. Il chart Helm di Bleemeo gestisce questo per default, incluse le toleration appropriate e i limiti delle risorse.
2
Usate le Annotation Prometheus per Metriche Personalizzate
Aggiungete prometheus.io/scrape: "true" alle annotation dei vostri pod per esporre metriche specifiche dell'applicazione tramite il formato Prometheus. L'agente Bleemeo scopre questi endpoint automaticamente e invia le metriche al cloud. Questo e l'approccio Kubernetes-native standard per le metriche applicative personalizzate senza richiedere configurazione aggiuntiva.
3
Impostate Sempre Richieste e Limiti delle Risorse
I pod senza richieste di risorse non possono essere dimensionati correttamente perché non esiste una baseline con cui confrontarsi. Impostate sempre le richieste CPU e memoria nei vostri manifest di deployment. Bleemeo confronta poi l'utilizzo effettivo con le risorse richieste, permettendo decisioni di right-sizing basate sui dati che riducono gli sprechi e prevengono la contesa di risorse.
4
Monitorate la Scadenza dei Certificati
Kubernetes utilizza certificati TLS per la comunicazione interna tra API server, kubelet e etcd. Certificati scaduti causano failure totali e improvvisi del cluster. Bleemeo monitora le date di scadenza dei certificati e vi avvisa prima che scadano, dandovi il tempo di ruotare i certificati in modo proattivo invece di scoprire il problema durante un'interruzione.
5
Correlate Metriche con i Log dei Container
Un conteggio riavvii dei pod in aumento vi dice che qualcosa non va. I log dei container vi dicono esattamente cosa. Abilitate la raccolta log insieme alle metriche per l'analisi delle cause più rapida. L'agente Bleemeo raccoglie entrambi dallo stesso DaemonSet, e la piattaforma cloud li visualizza insieme, collegati per nome del pod e timestamp.
Volete approfondire?
Leggete la DocumentazioneDomande Frequenti
Tutto quello che dovete sapere sul monitoraggio Kubernetes di Bleemeo
Come faccio a deployare Bleemeo nel mio cluster Kubernetes?
Bleemeo si deploya tramite chart Helm come DaemonSet, posizionando un agente Glouton su ogni nodo. Basta aggiungere il repository Helm di Bleemeo, poi eseguire helm upgrade --install con le credenziali del vostro account e il nome del cluster. L'agente scopre automaticamente tutti i pod e i servizi. Potete anche deployare usando kubectl con i manifest che forniamo. Gli strumenti GitOps come ArgoCD e Flux sono pienamente supportati.
Quali metriche Kubernetes raccoglie Bleemeo?
Bleemeo raccoglie metriche complete incluse: Metriche pod (conteggi per stato, conteggi riavvii, uso CPU/memoria vs richieste/limiti), Metriche nodi (CPU, memoria, disco, rete, stato kubelet), Metriche cluster (conteggio nodi, conteggio namespace, stato API), e Scadenza certificati (certificati CA e nodi). Le metriche sono etichettate per namespace, owner kind (Deployment, DaemonSet), e owner name per un filtraggio semplice.
Bleemeo scopre automaticamente i servizi nei miei pod?
Sì, l'auto-discovery dei servizi è una funzionalità principale. L'agente Bleemeo rileva tutti i servizi in esecuzione nei vostri pod (database, web server, code messaggi, ecc.) e inizia a monitorarli senza configurazione manuale. Riconosce oltre 100 servizi out of the box. Man mano che i pod scalano su o giù, il monitoraggio segue automaticamente - nessuna riconfigurazione necessaria per workload effimeri.
Posso fare scraping delle metriche Prometheus dalle mie applicazioni?
Sì, Bleemeo supporta lo scraping stile Prometheus tramite annotation sui pod. Aggiungete prometheus.io/scrape: "true" ai vostri pod, e opzionalmente specificate prometheus.io/path e prometheus.io/port per endpoint metriche personalizzati. L'agente scopre e fa scraping automaticamente di questi endpoint. Potete anche usare PromQL per interrogare le metriche nelle vostre dashboard.
Quali sono i requisiti di risorse per l'agente?
L'agente Glouton è progettato per essere leggero. Tipicamente usa meno di 100MB di memoria e CPU minima per nodo. L'agente non compete con i vostri workload di produzione per le risorse. Le richieste e i limiti delle risorse possono essere personalizzati nei valori Helm se necessario. L'agente è ottimizzato per ambienti ad alta densità con molti pod per nodo.
In che cosa Bleemeo è diverso dal gestire Prometheus + Grafana da soli?
Bleemeo non è un sostituto di Prometheus — è il servizio gestito che elimina il carico operativo. PromQL, recording rule e ingestione tramite scrape: tutto supportato. Glouton raccoglie i tuoi endpoint /metrics esistenti, la piattaforma li archivia e li interroga, e smetti di gestire storage. Nessun server Prometheus da scalare, nessun cluster Thanos o Mimir da gestire, nessun Grafana da aggiornare. Bleemeo gira anche al di fuori del tuo cluster su una piattaforma SLA 99,99%, così gli alert ti arrivano anche quando la tua infrastruttura è in difficoltà.
Quali distribuzioni Kubernetes sono supportate?
Bleemeo funziona con tutte le principali distribuzioni Kubernetes: Servizi managed (EKS, GKE, AKS, DigitalOcean Kubernetes), Self-managed (kubeadm, k3s, k0s, microk8s), e Distribuzioni enterprise (OpenShift, Rancher, Tanzu). Supportiamo Kubernetes 1.19+. L'agente si adatta a diversi container runtime inclusi containerd, CRI-O e Docker.
Posso monitorare più cluster Kubernetes?
Sì, Bleemeo supporta il monitoraggio multi-cluster. Ogni cluster appare come entità separata nella vostra dashboard con il proprio nome (configurato tramite config.kubernetes.clustername). Potete visualizzare tutti i cluster in una dashboard unificata, confrontare le metriche tra cluster, e approfondire i dettagli dei singoli cluster. Questo è ideale per gestire ambienti di sviluppo, staging e produzione.
Quali alert sono preconfigurati per Kubernetes?
Bleemeo include alert preconfigurati per problemi comuni Kubernetes: Problemi pod (CrashLoopBackOff, pod pending, conteggi riavvii elevati, OOMKilled), Problemi nodo (NotReady, pressione disco/memoria), Problemi cluster (errori API server, certificati in scadenza), e Problemi workload (repliche deployment non disponibili, job falliti). Potete personalizzare le soglie o creare alert aggiuntivi.
Come faccio a monitorare le richieste risorse vs l'uso effettivo?
Bleemeo raccoglie sia le richieste/limiti delle risorse che l'uso effettivo per CPU e memoria. Le dashboard mostrano il confronto tra ciò che i pod hanno richiesto e ciò che stanno effettivamente usando, aiutandovi a identificare workload sovra-provisionati (che sprecano risorse) e sotto-provisionati (a rischio di throttling o OOM). Questo permette un right-sizing efficace dei vostri workload.
Bleemeo monitora i log dei container?
Sì, con la raccolta log abilitata, Glouton cattura automaticamente i log da tutti i container nel vostro cluster Kubernetes. I log vengono raccolti da stdout/stderr dei container senza configurazione aggiuntiva. Potete applicare parser e filtri personalizzati usando annotation sui pod (glouton.log_format, glouton.log_filter). I log possono essere correlati con le metriche per un troubleshooting completo.
Quanto tempo richiede il setup del monitoraggio Kubernetes?
Circa 30 secondi di installazione effettiva. Un helm upgrade --install con tre variabili d'ambiente (account ID, registration key, nome del cluster) distribuisce Glouton come DaemonSet su tutto il tuo cluster. La scoperta automatica riconosce più di 100 servizi senza configurazione; dashboard e regole di alert Kubernetes arrivano pronti all'uso. Nessun PVC da provisionare, nessuna scrape config da scrivere, nessuna dashboard da importare, nessuna regola di alert da scrivere.
Iniziate a Monitorare i Vostri Cluster Kubernetes
Deploy in pochi minuti. Ottenete visibilità completa sulla vostra infrastruttura K8s.