Monitoring delle Applicazioni
Un Tag, una Dashboard per Ogni Servizio della Tua Applicazione
Raggruppa i servizi e i monitor di uptime che compongono un'applicazione dietro un unico tag. Ottieni una dashboard unificata, la scoperta automatica dei servizi e una pagina di stato pubblica — senza ricostruire il tuo monitoring ogni volta che il tuo stack evolve.
Prova gratuita 15 giorni · Nessuna carta di credito richiesta · Configurazione in 30 secondi
Più di 500 aziende si affidano a noi per il monitoring delle loro applicazioni
Una Vista della Tua Applicazione Basata sui Tag
Le applicazioni in Bleemeo poggiano su un'idea semplice: scegli un tag, allegaci servizi e monitor, e ottieni una vista in tempo reale dell'intero cluster. Aggiungere o rimuovere un servizio è una modifica di un'etichetta, non una riscrittura della dashboard.
Vista Cluster
Visualizza ogni servizio di un'applicazione su un unico grafico. Lo stato si consolida in un singolo indicatore di salute applicativa.
Eventi dei Servizi
Timeline dedicata dei cambi di stato per ogni servizio dell'applicazione, perfetta per la revisione post-incidente.
Tempo di Risposta
Allega monitor di uptime al tag dell'applicazione e ottieni automaticamente un widget Tempo di Risposta dell'Applicazione.
Raggruppamento Compose Automatico
Glouton riconosce ogni progetto Docker Compose e crea un'applicazione corrispondente senza alcuna configurazione.
Pagine di Stato Pubbliche
Pubblica la salute della tua applicazione in tempo reale su status.bleemeo.com/<slug>/ per i tuoi clienti.
Agnostico allo Stack
Funziona con gli exporter Prometheus, JMX, StatsD, check HTTP/TCP e oltre 100 servizi scoperti automaticamente.
Modi per Raggruppare i Servizi in un'Applicazione
I tag possono provenire da ovunque — scoperta automatica, label dei container, annotazioni dei pod, file di configurazione Glouton o il pannello stesso. Scegli quello che si adatta al modo in cui già esegui il deploy.
Docker Compose (automatico)
Glouton usa l'etichetta com.docker.compose.project per raggruppare ogni servizio di un progetto in un'applicazione, senza modifiche di configurazione.
services:
web:
image: nginx
api:
image: my/api
# Raggruppato automaticamente sotto il nome del progettoLabel Docker
Sovrascrivi il raggruppamento predefinito o unisci servizi di più progetti Compose impostando l'etichetta glouton.tags.
services:
payments:
image: my/payments
labels:
- glouton.tags=backend,paymentsAnnotazioni Kubernetes
Allega pod a un'applicazione con una singola annotazione glouton.tags sul tuo Deployment, StatefulSet o DaemonSet.
spec:
template:
metadata:
annotations:
glouton.tags: "checkout"Configurazione Glouton
Per installazioni bare-metal o personalizzate, dichiara il servizio e i suoi tag direttamente in un file di configurazione Glouton.
services:
- type: "apache"
instance: "web-01"
tags:
- frontendInterfaccia Web
Aggiungi o rimuovi manualmente un tag da qualsiasi servizio o monitor — utile per raggruppamenti puntuali o per taggare monitor di uptime che vivono solo nel cloud.
- Modifica i tag direttamente dalla scheda Applications
- Origine del tag visibile (automatico, config, manuale)
- Nessun riavvio dell'agente necessario
Monitor di Uptime
I monitor HTTP, TCP e ping possono portare lo stesso tag dei tuoi servizi, così la disponibilità esterna vive sulla stessa dashboard della salute interna.
- Check HTTP / TCP / ping
- Widget Tempo di Risposta dell'Applicazione
- Alimentano la pagina di stato pubblica
Crea un'Applicazione in Tre Passi
Apri la Scheda Applications
Nel pannello Bleemeo, clicca su Applications nella navigazione di sinistra, poi sul pulsante +.
Nomina l'Applicazione e Scegli un Tag
Dai un nome all'applicazione e un tag. Puoi riutilizzare un tag già presente sui tuoi servizi o crearne uno nuovo — ogni servizio o monitor che porta quel tag sarà raggruppato sotto l'applicazione.
Allega Servizi e Monitor
Aggiungi il tag ai tuoi servizi tramite label Docker, annotazione Kubernetes, configurazione Glouton o interfaccia web. I nuovi servizi con il tag appaiono automaticamente.
# Docker Compose
labels:
- glouton.tags=my-app
# Kubernetes
annotations:
glouton.tags: "my-app"Come i Tag Costruiscono la Vista della Tua Applicazione
I tag viaggiano con i tuoi servizi indipendentemente da come vengono distribuiti. La piattaforma li riconcilia in tempo reale in un'unica entità applicazione.
L'Origine del Tag È Sempre Visibile
Ogni servizio allegato a un'applicazione porta metadati su come è stato applicato il tag: automatico (rilevato dall'API, derivato da Compose), configurazione Glouton, o manuale (aggiunto nel pannello). Quando indaghi su un'appartenenza inattesa, sai sempre dove guardare.
Basta con la Deriva delle Dashboard
Le dashboard tradizionali si deteriorano con l'arrivo e la partenza di servizi. Con un'applicazione basata su tag, la dashboard segue il tag: i nuovi servizi appaiono, quelli ridimensionati scompaiono, e il layout rimane leggibile. Il pulsante Reset ripristina la versione auto-generata ogni volta che le modifiche manuali non ti servono più.
Applicazioni Multi-Tag
Un servizio può portare più tag — tipico per i componenti condivisi come un database che supporta sia l'applicazione checkout che catalog. Usa valori separati da virgola (glouton.tags=checkout,catalog) nelle label Docker o nelle annotazioni Kubernetes, e ogni applicazione vede il servizio condiviso.
Le Pagine di Stato Pubbliche Riutilizzano lo Stesso Modello
Una pagina di stato pubblica è solo una selezione curata di applicazioni resa senza autenticazione su status.bleemeo.com/<slug>/. Poiché la salute è calcolata dagli stessi servizi e monitor taggati, ciò che vedi internamente e ciò che vedono i tuoi clienti non divergono mai.
Cosa Copre la Salute di un'Applicazione
Lo stato consolidato dell'applicazione riflette ogni modalità di guasto dei suoi membri — dai riavvii dei container ai fallimenti di uptime esterni.
Guasti dei Servizi
- Servizio scoperto automaticamente non disponibile
- Check TCP o HTTP personalizzato in errore
- Processo non più in esecuzione
- Container terminato o in riavvio
Disponibilità Esterna
- Monitor HTTP di uptime in errore
- Endpoint TCP irraggiungibile
- Check ping in timeout
- Tempo di risposta oltre la soglia
Codice Applicativo
- Avviso su metrica Prometheus personalizzata
- Soglia metrica JMX superata
- Anomalia su contatore StatsD
- Check Nagios che restituisce CRITICAL
Ricadute dall'Infrastruttura
- Host di un servizio OOM-killed
- Disco pieno sul nodo di un servizio
- Pod bloccato in CrashLoopBackOff
- Kubelet NotReady
Nativo Prometheus, dall'Exporter a PromQL
Bleemeo è un backend compatibile con Prometheus pronto all'uso per le tue applicazioni. Strumenta il tuo
codice con le librerie client ufficiali, scrapa qualsiasi endpoint /metrics esistente e
interroga tutto con PromQL — lo stesso linguaggio che il tuo team conosce già.
Strumenta il Codice con i Client Prometheus Ufficiali
Usa le librerie client Prometheus ufficiali mantenute dal progetto Prometheus e dall'ecosistema CNCF. Esponi un endpoint /metrics e Glouton lo scrapa — nessun vendor lock-in, nessun SDK proprietario, nessuna ri-strumentazione se un giorno cambi.
from prometheus_client import Counter, start_http_server
checkout_total = Counter('checkout_total', 'Checkout completati')
start_http_server(8000) # /metrics servito su :8000Endpoint /metrics Nativi Ovunque
Migliaia di applicazioni moderne espongono metriche Prometheus nativamente — nessun exporter, nessun sidecar, nessun lavoro di strumentazione. Abilita l'annotazione Prometheus (prometheus.io/scrape: "true") o aggiungi un URL alla configurazione di Glouton e le metriche arrivano in Bleemeo.
Sfoglia tutte le 60+ integrazioni di servizi pronte all'uso → · Oppure scrapa tu stesso qualsiasi endpoint Prometheus →
PromQL per Dashboard e Avvisi
Ogni widget di dashboard e regola di avviso Bleemeo parla PromQL. Riutilizza le recording rule del tuo setup Prometheus esistente, mescola metriche applicative con metriche di infrastruttura nella stessa query e usa tutta la potenza di rate(), histogram_quantile() e sum by() per esprimere ciò che conta per il tuo team.
histogram_quantile(0.99,
sum by (le, handler) (
rate(http_request_duration_seconds_bucket{service="checkout"}[5m])
)
)Pagine di Stato Pubbliche, Integrate
Ogni applicazione può essere pubblicata come pagina di stato pubblica personalizzata su status.bleemeo.com/<slug>/ in un clic. La pagina è non autenticata, rivolta al cliente, e mostra la stessa disponibilità in tempo reale che vede internamente il tuo team di reperibilità — così ciò che leggono i clienti non diverge mai dalla realtà.
- Riutilizza le tue applicazioni esistenti — nessuna nuova configurazione
- Più applicazioni per pagina per le suite di prodotti
- Stato in tempo reale calcolato da servizi e monitor di uptime
- Riduce il carico di supporto e fornisce prove SLA
Perché Scegliere Bleemeo per il Monitoring delle Applicazioni?
Zero Manutenzione delle Dashboard
La dashboard segue il tag. Distribuisci un nuovo servizio e appare automaticamente — nessuna riscrittura Grafana.
Un Solo Segnale per la Reperibilità
Ogni guasto di servizio si consolida in un unico stato di salute applicativa, riducendo la fatica da avvisi.
Trasparenza verso i Clienti
Pubblica l'uptime applicativo su status.bleemeo.com in un clic — nessuno strumento di status page separato.
Retention 13 mesi
Mantieni lo storico a livello applicativo per reportistica SLA, post-mortem e analisi di tendenza.
Cos'è il Monitoring delle Applicazioni?
Il monitoring delle applicazioni è la pratica di tracciare lo stato di salute, la disponibilità e le prestazioni di un'applicazione software nel suo insieme, piuttosto che di ogni server, container o servizio in isolamento. Le applicazioni moderne abbracciano molte parti in movimento — un database, un livello web, un worker in background, una coda, spesso eseguiti su Kubernetes — e ciò che conta per gli utenti è se l'applicazione funziona, non se un dato pod è attivo.
In Bleemeo, un'applicazione è definita da un tag. I servizi e i monitor di uptime che portano il tag sono raggruppati sotto l'applicazione, i loro stati sono consolidati in un singolo indicatore e le loro metriche sono disposte su una dashboard auto-generata. Il raggruppamento è dinamico: aggiungere una nuova replica, un nuovo microservizio o un nuovo check di uptime richiede solo di apporvi il tag giusto. La vista applicativa si aggiorna da sola.
Il modello è completamente compatibile con Prometheus, funziona con i log centralizzati per l'analisi della causa principale e alimenta le pagine di stato pubbliche, in modo che i tuoi clienti vedano la stessa immagine della disponibilità che vede il tuo team di reperibilità — meno i dettagli interni. Un'unica fonte di verità per l'osservabilità interna e la comunicazione esterna.
Cosa Contiene la Dashboard di un'Applicazione
Widget Stato dei Servizi
Sempre presente sulla dashboard dell'applicazione, elenca ogni servizio che porta il tag dell'applicazione con il suo stato attuale. I guasti rendono il widget — e lo stato applicativo — rosso, così la reperibilità vede a colpo d'occhio quale parte dell'applicazione è degradata.
Tempo di Risposta dell'Applicazione
Appare automaticamente quando almeno un monitor di uptime porta il tag dell'applicazione. Traccia la latenza nel tempo per i check HTTP, TCP o ping, così puoi correlare i rallentamenti visibili all'utente con gli eventi dei servizi backend.
Widget per Servizio (Pro)
Sul piano Professional, la dashboard è popolata automaticamente con un widget dedicato per ogni servizio riconosciuto nell'applicazione — CPU e memoria per un database, tasso di richieste per un server web, profondità coda per un broker. Inizi con un layout significativo invece di una pagina vuota.
Scheda Application Information
Elenca ogni servizio e monitor allegato all'applicazione, raggruppati per modalità di applicazione del tag (automatico, configurazione Glouton, manuale). Usalo per verificare l'appartenenza e rimuovere ritardatari dopo una modifica di deploy.
Scheda Service Events
Un flusso cronologico di ogni cambio di stato all'interno dell'applicazione — riavvio container, instabilità di check HTTP, processo scomparso — con timestamp. Il primo posto da consultare dopo un incidente, e il modo più rapido per individuare una dipendenza instabile.
Avvisi Consolidati
Ogni avviso su un servizio dell'applicazione contribuisce allo stato dell'applicazione. Il tuo team di reperibilità vede un segnale per applicazione invece di un avviso per componente, con drill-down al servizio esatto in errore.
Casi d'Uso
Rilasci di Microservizi
Raggruppa tutti i microservizi di un prodotto dietro un tag checkout. Quando un nuovo servizio viene aggiunto alla mesh, annotalo e si unisce automaticamente alla dashboard dell'applicazione — nessuna modifica Grafana, nessuna riscrittura di regole di avviso. Le aggregazioni espongono un singolo segnale di salute per l'intera finestra di rollout.
Stack Docker Compose
Poiché Glouton rileva automaticamente il progetto Compose, ogni docker compose up diventa una vista applicativa pronta — ideale per ambienti di sviluppo, stack di test CI o piccoli deploy self-hosted dove allestire una dashboard extra per progetto sarebbe eccessivo.
SLA verso il Cliente
Pubblica l'uptime applicativo su una pagina di stato pubblica per comunicare in modo trasparente durante gli incidenti, ridurre i ticket di supporto e fornire prove di conformità SLA — tutto calcolato dagli stessi servizi e monitor che hai già internamente.
Dipendenze Condivise
Tagga un database condiviso con sia checkout che catalog. Se il database si degrada, entrambe le applicazioni lo riflettono e i team di reperibilità di ogni prodotto vedono l'incidente sulle rispettive dashboard senza duplicare l'infrastruttura.
Integrazioni SaaS di Terze Parti
Aggiungi un monitor HTTP di uptime su un'API di un fornitore di pagamenti, taggalo con la tua applicazione e i guasti delle dipendenze esterne appaiono accanto ai guasti dei servizi interni — basta sorprese del tipo "l'app è giù ma tutto è verde".
Revisione Post-Incidente
Usa la scheda Service Events per ricostruire la timeline di un degrado: quale servizio è fallito per primo, quale ha propagato, quale si è ripreso. Con 13 mesi di metriche conservate, puoi analizzare anche regressioni a lenta combustione, non solo incidenti acuti.
Best Practice del Monitoring delle Applicazioni
Nomina i Tag in Base ai Domini di Business
Un tag come checkout o billing rimane rilevante nonostante il ricambio tecnologico, mentre un tag come node-app-v2 diventa fuorviante in un trimestre. Scegli nomi che corrispondano alla rotazione di reperibilità e al linguaggio della pagina di stato, non all'implementazione attuale.
Allega Sempre Almeno un Monitor di Uptime
La salute interna dei servizi indica che i componenti sono attivi; i monitor di uptime indicano che l'applicazione è raggiungibile dall'esterno. Un monitor HTTP taggato ti regala il widget Tempo di Risposta dell'Applicazione e dà significato alla tua pagina di stato pubblica.
Lascia che Docker Compose si Raggruppi da Solo
In dev e staging, affidati al raggruppamento Compose automatico — nessuna configurazione, nessuna deriva. Riserva le label glouton.tags esplicite ai deploy di produzione dove vuoi sovrascrivere il nome del progetto o unire servizi su più file Compose.
Tagga Esplicitamente i Componenti Condivisi
Database, cache e message broker spesso supportano più applicazioni. Aggiungi tag separati da virgola (glouton.tags=checkout,catalog) in modo che ogni applicazione dipendente dal servizio condiviso ne veda la salute e riceva l'avviso in caso di degrado.
Pubblica Presto una Pagina di Stato Pubblica
Anche in beta, una pagina di stato pubblica costruisce fiducia e riduce il carico di supporto. Inizia con una pagina per applicazione rivolta all'utente e affina la narrazione più tardi. Poiché i dati di salute provengono dall'applicazione stessa, non c'è alcun costo operativo aggiuntivo.
Vuoi approfondire?
Leggi la documentazioneDomande Frequenti
Tutto quello che devi sapere sul monitoring delle applicazioni
Cos'è il monitoring delle applicazioni?
Il monitoring delle applicazioni è la pratica di tracciare la salute, la disponibilità e le prestazioni di un'applicazione software nel suo insieme — attraverso ogni servizio, container e dipendenza esterna che la fa funzionare. Trasforma segnali disparati per componente in un'unica vista che indica se l'applicazione sta effettivamente servendo i suoi utenti, e fornisce metriche, log e avvisi per diagnosticare rapidamente i problemi.
Perché il monitoring delle applicazioni è importante?
Il monitoring delle applicazioni rileva i problemi prima degli utenti, riduce il tempo di risposta agli incidenti, produce prove di conformità SLA e guida la pianificazione della capacità. Senza di esso, i team reagiscono ai reclami dei clienti invece che agli avvisi, e l'analisi della causa principale si basa sull'ispezione manuale dei log di decine di componenti.
Qual è la differenza tra monitoring delle applicazioni e monitoring dell'infrastruttura?
Il monitoring dell'infrastruttura traccia server, container, dischi e reti — il livello su cui gira la tua applicazione. Il monitoring delle applicazioni traccia l'applicazione stessa: tasso di richieste, tasso di errori, latenza, KPI di business, disponibilità esterna. Entrambi sono necessari, e una buona piattaforma li correla per dirti se un checkout lento è causato dal codice o dall'host.
Cos'è l'APM (Application Performance Monitoring)?
L'APM è un sottoinsieme del monitoring delle applicazioni focalizzato sulle prestazioni a livello di codice — tempo di risposta, throughput, tassi di errore e (in alcuni strumenti) tracce distribuite. L'APM basato su metriche si affida a endpoint /metrics strumentati, tipicamente alimentati dalle librerie client Prometheus ufficiali, ed è l'approccio utilizzato dalle moderne piattaforme cloud-native.
Come funziona Prometheus per il monitoring delle applicazioni?
Prometheus usa un modello pull: la tua applicazione espone un endpoint /metrics (di solito tramite una libreria client ufficiale), e un agente lo interroga a intervalli regolari. Le metriche sono memorizzate come serie temporali e interrogate con PromQL. Poiché il formato testuale di Prometheus è lo standard de facto, migliaia di applicazioni espongono nativamente /metrics, e qualsiasi backend compatibile con Prometheus può ingestirle e interrogarle.
Quali librerie client Prometheus posso usare?
Il progetto Prometheus mantiene librerie client ufficiali per Go (client_golang), Java (simpleclient, e Micrometer), Python (prometheus_client), Ruby (prometheus-client) e Rust (prometheus). Librerie della community coprono Node.js, .NET, PHP, C++ e molte altre. Ogni libreria permette di definire contatori, gauge, istogrammi e riepiloghi su un endpoint /metrics.
Quali metriche dovrei monitorare per un'applicazione web?
Il punto di partenza canonico è il metodo RED: Rate (richieste al secondo), Errors (tasso di errori) e Duration (distribuzione della latenza). Complementalo con USE per le risorse — Utilization, Saturation, Errors — e una manciata di KPI di business (tasso di completamento del checkout, tasso di registrazione). Esponili come istogrammi Prometheus e interroga con histogram_quantile() per tracciare p50, p95 e p99.
Come monitoro i microservizi?
Raggruppa i microservizi correlati dietro un identificatore condiviso — tipicamente un tag — in modo che la loro salute si consolidi in un unico stato dell'applicazione. Strumenta ogni servizio con una libreria client Prometheus, esponi /metrics e lascia che l'agente di monitoring li scopra automaticamente. Aggiungi monitor di uptime esterni sul punto di ingresso pubblico e correla metriche e log per l'analisi della causa principale.
Come misuro il tempo di risposta dell'applicazione?
Due approcci complementari: i monitor di uptime esterni (HTTP, TCP, ping) misurano il tempo di risposta dal punto di vista dell'utente, mentre gli istogrammi Prometheus interni come http_request_duration_seconds lo misurano all'interno dell'applicazione. Usa la funzione histogram_quantile() di PromQL per calcolare p50, p95 e p99, e confrontali con le misurazioni esterne per rilevare problemi di rete o CDN.
Cos'è una pagina di stato pubblica e perché ne ho bisogno?
Una pagina di stato pubblica è un URL rivolto al cliente che mostra in tempo reale la disponibilità della tua applicazione e gli incidenti in corso. Riduce il carico di supporto durante i guasti, comunica in modo trasparente con i clienti e fornisce prove di conformità SLA. Le migliori pagine di stato riutilizzano gli stessi dati di monitoring usati internamente, in modo che ciò che vedono i clienti non diverga mai dalla realtà del team di reperibilità.
Inizia a Monitorare le Tue Applicazioni
Un tag per raggruppare i tuoi servizi. Una dashboard. Un URL di stato pubblico.