Perché i database a serie temporali sono importanti per metriche e observability

Metriche, Monitoring e Observability: le basi

Metriche sono numeri che descrivono cosa sta facendo il tuo sistema—misure che puoi mettere su un grafico, come latenza delle richieste, tasso di errori, utilizzo CPU, profondità delle code o utenti attivi.

Monitoring è la pratica di raccogliere quelle misure, metterle su dashboard e impostare alert quando qualcosa non va. Se il tasso di errori di un servizio di checkout schizza, il monitoring dovrebbe avvisarti in modo rapido e chiaro.

Observability va oltre: è la capacità di capire perché qualcosa sta succedendo guardando più segnali insieme—tipicamente metriche, log e trace. Le metriche ti dicono cosa è cambiato, i log dicono cosa è successo, e i trace mostrano dove è stato speso il tempo tra i servizi.

Perché i dati temporali sono diversi

I dati time-series sono “valore + timestamp”, ripetuti continuamente.

Quell’elemento temporale cambia il modo in cui usi i dati:

• Fai domande tipo “Qual è la tendenza negli ultimi 15 minuti?” o “È peggiorato dopo un deploy?”
• Ti interessa che i dati recenti siano veloci da interrogare per dashboard e alert.
• Spesso aggregi (avg/p95/somma) su finestre temporali invece di estrarre righe singole.

Cosa risolve un TSDB (e cosa no)

Un database a serie temporali (TSDB) è ottimizzato per ingerire molti punti con timestamp, memorizzarli in modo efficiente e interrogarli rapidamente su intervalli temporali.

Una TSDB non risolverà magicamente la mancanza di instrumentazione, SLO poco chiari o alert rumorosi. Non sostituisce log e trace; li completa rendendo i flussi metrici più affidabili ed economici.

Esempio rapido: latenza nel tempo

Immagina di tracciare il p95 della latenza della tua API ogni minuto. Alle 10:05 passa da 180ms a 900ms e resta alta. Il monitoring genera un alert; l’observability ti aiuta a collegare quel picco a una specifica regione, endpoint o deploy—partendo dalla tendenza della metrica e approfondendo nei segnali sottostanti.

Cosa rende unici i dati delle serie temporali

Le metriche time-series hanno una forma semplice, ma il loro volume e i pattern di accesso le rendono particolari. Ogni punto dati è tipicamente timestamp + label/tag + valore—per esempio: “2025-12-25 10:04:00Z, service=checkout, instance=i-123, p95_latency_ms=240”. Il timestamp ancora l’evento nel tempo, le label descrivono chi l’ha emesso, e il valore è ciò che misuri.

Un pattern di scrittura pensato per il flusso continuo

I sistemi di metriche non scrivono a intermittenza. Scrivono continuamente, spesso ogni pochi secondi, da molte sorgenti contemporaneamente. Questo crea uno stream di molte scritture piccole: counter, gauge, histogram e summary che arrivano senza sosta.

Anche ambienti modesti possono produrre milioni di punti al minuto quando moltiplichi intervalli di scrape per host, container, endpoint, regioni e feature flag.

Le letture sono quasi sempre “su un intervallo”

A differenza dei database transazionali dove prendi “l’ultima riga”, gli utenti di serie temporali di solito chiedono:

• “Cosa è successo negli ultimi 15 minuti?”
• “Confronta oggi vs ieri alla stessa ora.”
• “Mostra p95/p99 della latenza per servizio nell’ultima ora.”

Questo significa che le query comuni sono range scan, rollup (es. 1s → medie da 1m) e aggregazioni come percentili, rate e somme raggruppate.

I segnali stanno nella forma della linea

I dati time-series sono preziosi perché rivelano pattern difficili da vedere in eventi isolati: picchi (incidenti), stagionalità (cicli giornalieri/settimanali) e trend a lungo termine (aumento di capacità, regressioni graduali). Un database che comprende il tempo rende più semplice memorizzare questi stream in modo efficiente e interrogarli abbastanza rapidamente per dashboard e alerting.

Cos’è un Time-Series Database (TSDB)

Una TSDB è un database costruito specificamente per dati ordinati nel tempo—misure che arrivano continuamente e sono interrogate principalmente per tempo. Nel monitoring, questo di solito significa metriche come utilizzo CPU, latenza delle richieste, tasso di errori o profondità delle code, ciascuna registrata con un timestamp e un set di label (service, region, instance, ecc.).

Storage progettato per il tempo

A differenza dei database generalisti che memorizzano righe ottimizzate per molti pattern di accesso, le TSDB ottimizzano il carico di lavoro più comune delle metriche: scrivere nuovi punti man mano che il tempo avanza e leggere la cronologia recente rapidamente. I dati sono tipicamente organizzati in chunk/blocchi temporali così il motore può scansionare “ultimi 5 minuti” o “ultime 24 ore” senza toccare dati non rilevanti.

Compressione e codifica per serie numeriche

Le metriche sono spesso numeriche e cambiano gradualmente. Le TSDB sfruttano questo con tecniche di encoding e compressione specializzate (per esempio, delta encoding tra timestamp adiacenti, run-length, e memorizzazione compatta per set di label ripetuti). Il risultato: puoi conservare più storico con lo stesso budget di storage e le query leggono meno byte dal disco.

Perché le scritture append-only sono veloci

I dati di monitoring sono per lo più append-only: raramente aggiorni punti vecchi; ne aggiungi di nuovi. Le TSDB sfruttano questo pattern con scritture sequenziali e ingestione in batch. Questo riduce I/O casuale, abbassa l’write amplification e mantiene l’ingestione stabile anche quando molte metriche arrivano insieme.

API e stili di query comuni

La maggior parte delle TSDB espone primitive di query pensate per monitoring e dashboard:

• Range queries: “dammi questa metrica negli ultimi N minuti.”
• Group by time: raggruppa i dati in intervalli (es. 1m) per grafici e aggregazioni.
• Filtri per label: seleziona serie per tag/label (es. service="api", region="us-east").

Anche se la sintassi varia tra prodotti, questi pattern sono la base per costruire dashboard e valutazioni di alert affidabili.

Perché le TSDB sono adatte ai carichi di monitoring

Il monitoring è uno stream di piccoli fatti che non si ferma mai: tick di CPU ogni pochi secondi, conteggi di richieste ogni minuto, profondità delle code tutto il giorno. Una TSDB è costruita per quel pattern—ingestione continua più domande tipo “cosa è successo recentemente?”—quindi tende a essere più veloce e prevedibile rispetto a un database generalista quando la usi per metriche.

Risposte veloci a domande basate sul tempo

La maggior parte delle domande operative sono query su intervalli: “mostrami gli ultimi 5 minuti”, “confronta con le ultime 24 ore”, “cosa è cambiato dal deploy?” Lo storage e l’indicizzazione delle TSDB sono ottimizzati per scansionare range temporali in modo efficiente, mantenendo i grafici reattivi anche con dataset grandi.

Aggregazioni che rispecchiano il modo di pensare dei team

Dashboard e monitoraggio SRE si basano più sulle aggregazioni che sui punti grezzi. Le TSDB di solito rendono efficiente la matematica metrico-computazionale comune:

• Medie su finestre temporali (avg)
• Percentili di latenza (p95/p99)
• Operazioni sui counter come rate e increase

Queste operazioni sono essenziali per trasformare campioni rumorosi in segnali su cui allertare.

Time bucketing, rollup e costi prevedibili

Le dashboard raramente hanno bisogno di ogni datapoint grezzo per sempre. Le TSDB spesso supportano bucket temporali e rollup, così puoi conservare dati ad alta risoluzione per periodi recenti e pre-aggregare i dati più vecchi per tendenze a lungo termine. Ciò mantiene le query veloci e aiuta a controllare lo storage senza perdere il quadro generale.

Performance sotto ingestione continua

Le metriche non arrivano a lotti; arrivano continuamente. Le TSDB sono progettate in modo che i carichi di scrittura intensi non degradino rapidamente le letture, aiutando a mantenere le query “c’è qualcosa che non va adesso?” affidabili durante spike di traffico e incidenti.

Alta cardinalità: il fattore che crea o distrugge le metriche

Le metriche diventano potenti quando puoi scomporle per label (chiamate anche tag o dimensioni). Una singola metrica come http_requests_total potrebbe essere registrata con dimensioni come service, region, instance e endpoint—così puoi rispondere a domande come “L’EU è più lenta degli US?” o “Un’istanza si comporta male?”.

Cosa significa cardinalità (e perché esplode)

Cardinalità è il numero di serie temporali uniche che le tue metriche creano. Ogni combinazione unica di valori di label è una serie diversa.

Per esempio, se tracci una metrica con:

• 20 servizi
• 5 regioni
• 200 istanze
• 50 endpoint

…hai già 20 × 5 × 200 × 50 = 1.000.000 di serie temporali per quella singola metrica. Aggiungi qualche altra label (status code, method, tipo utente) e può crescere oltre ciò che il tuo storage e motore di query possono gestire.

Cosa si rompe per primo quando la cardinalità è troppo alta

L’alta cardinalità di solito non fallisce in modo graduale. I primi punti critici sono:

• Pressione sulla memoria: il sistema deve mantenere le serie recenti e la metadata “calda”, e l’uso di memoria sale rapidamente.
• Crescita degli indici: l’indice delle label può diventare enorme, aumentando l’uso disco e rallentando le lookup.
• Latenza delle query: dashboard e valutazioni di alert possono dover scansionare o matchare molte più serie del previsto, causando pannelli lenti e alert ritardati.

Per questo la tolleranza all’alta cardinalità è un differenziatore chiave fra TSDB: alcuni sistemi sono progettati per gestirla; altri diventano instabili o costosi velocemente.

Scegliere le label: cosa tenere e cosa evitare

Una buona regola: usa label che siano bounded e a variabilità bassa-media, ed evita label effettivamente illimitate.

Preferisci:

• service, region, cluster, environment
• instance (se la dimensione del fleet è controllata)
• endpoint solo se è una route normalizzata (es. /users/:id, non /users/12345)

Evita:

• User ID, session ID, request ID, order ID
• URL completi con query string
• Messaggi di errore grezzi o stack trace

Se ti servono quei dettagli, conservali nei log o nei trace e collega una metrica tramite una label stabile. Così la TSDB resta veloce, le dashboard rimangono utilizzabili e gli alert arrivano puntuali.

Retention, downsampling e controllo dei costi

Tenere metriche “per sempre” suona attraente—fino a quando le bollette di storage non crescono e le query rallentano. Una TSDB ti aiuta a conservare i dati che ti servono, al dettaglio che ti serve, per il tempo che ti serve.

Perché la compressione conta

Le metriche sono naturalmente ripetitive (stessa serie, intervallo di campionamento costante, piccoli cambiamenti tra punti). Le TSDB sfruttano questo con compressione dedicata, spesso memorizzando storici lunghi a una frazione della dimensione grezza. Questo significa che puoi conservare più dati per l’analisi delle tendenze—pianificazione della capacità, pattern stagionali e “cosa è cambiato dall’ultimo trimestre?”—senza pagare dischi enormi.

Retention: dati raw vs aggregati

La retention è semplicemente la regola per quanto tempo i dati vengono conservati.

La maggior parte dei team divide la retention in due livelli:

• Raw (alta risoluzione): conserva dati per-secondo o per-10-secondi per una finestra più corta (es. 7–30 giorni) per fare debug con pieno dettaglio.
• Aggregated retention: conserva dati rollup (es. 1-minute, 10-minute, 1-hour) per finestre più lunghe (es. 6–24 mesi) per seguire tendenze a lungo termine.

Questo approccio evita che i dati ultra-granulari di ieri diventino l’archivio costoso di domani.

Downsampling / rollup: quando applicarli

Il downsampling (o rollup) sostituisce molti punti raw con punti riepilogativi—tipicamente avg/min/max/count su un bucket temporale. Applicalo quando:

• Ti servono soprattutto tendenze piuttosto che debugging punto-per-punto.
• Le dashboard coprono settimane o mesi e non giovano di dettaglio a livello di secondi.
• Vuoi query più veloci su range temporali ampi.

Alcuni team downsample automaticamente dopo la finestra raw; altri mantengono raw più a lungo per servizi “hot” e downsample più in fretta metriche rumorose o a basso valore.

I compromessi (precisione, storage, velocità)

Il downsampling salva storage e accelera le query a lungo raggio, ma perdi dettaglio. Per esempio, un breve spike di CPU può sparire in una media oraria, mentre rollup con min/max possono preservare il segnale che “qualcosa è successo” senza mantenere esattamente quando o quanto spesso.

Una regola pratica: conserva i raw abbastanza a lungo per fare debug degli incidenti recenti e mantieni i rollup abbastanza a lungo per rispondere a domande di prodotto e capacità.

Gli alert necessitano di query affidabili e tempestive

Gli alert sono utili quanto le query che li sottendono. Se il tuo sistema di monitoring non riesce a rispondere a “questo servizio è sano adesso?” in modo rapido e consistente, o perdi incidenti o vieni svegliato per rumore.

Come sono fatte le query di alert

La maggior parte delle regole di alert si riduce a pochi pattern di query:

• Threshold checks: “CPU > 90% per 10 minuti”, o “error rate > 2%.”
• Rate e ratio checks: “5xx al secondo”, “errors / requests”, “profondità code in aumento.” Questi spesso si basano su funzioni come rate() su counter.
• Controlli in stile anomalia: “la latenza è insolitamente alta rispetto all’ultima ora/giorno”, o “il traffico è sceso sotto il previsto.” Tipicamente confrontano una finestra corrente con una baseline.

Una TSDB conta qui perché queste query devono scansionare dati recenti velocemente, applicare aggregazioni correttamente e restituire risultati nei tempi previsti.

Finestre di valutazione: perché il timing conta

Gli alert non si valutano su singoli punti; si valutano su finestre (per esempio, “ultimi 5 minuti”). Piccoli problemi di timing possono cambiare l’esito:

• Ingestione tardiva può far sembrare sano un sistema rotto (o nascondere un outage reale).
• Finestre mal allineate possono causare regole che “squillano quasi sempre” quando il traffico è spike.
• Se le query sono lente, il ciclo di alerting si sposta e le decisioni arrivano in ritardo.

Insidie comuni (e come ridurle)

Gli alert rumorosi spesso nascono da dati mancanti, campionamento irregolare o soglie troppo sensibili. Il flapping—passare rapidamente tra firing e resolved—di solito indica che la regola è troppo vicina alla varianza normale o la finestra è troppo corta.

Gestisci esplicitamente il “no data” (è un problema o un servizio inattivo?), e preferisci alert su rate/ratio piuttosto che conteggi grezzi quando il traffico varia.

Rendi gli alert azionabili

Ogni alert dovrebbe linkare a una dashboard e a un breve runbook: cosa verificare per primo, cosa significa “bene” e come mitigare. Anche un semplice /runbooks/service-5xx e un link a una dashboard possono ridurre i tempi di risposta in modo significativo.

Dove si collocano le TSDB nello stack di observability

L’observability combina solitamente tre tipi di segnale: metriche, log e trace. Una TSDB è l’archivio specializzato per le metriche—punti indicizzati per tempo—perché è ottimizzata per aggregazioni veloci, rollup e risposte a domande tipo “cosa è cambiato negli ultimi 5 minuti?”.

Metriche: rilevamento rapido e monitoraggio SLO

Le metriche sono la prima linea di difesa. Sono compatte, economiche da interrogare a scala e ideali per dashboard e alerting. Così i team tracciano SLO come “99.9% delle richieste sotto 300ms” o “tasso di errori sotto 1%.”

Una TSDB tipicamente alimenta:

• Dashboard in tempo reale (salute del servizio, latenza, saturazione)
• Valutazioni di alert (soglie, burn rate, controlli in stile anomalia)
• Report storici (tendenze settimanali, pianificazione della capacità)

Log e trace: contesto dopo il rilevamento

Le metriche dicono che qualcosa non va, ma non sempre perché.\n\n- Log forniscono record dettagliati degli eventi (errori, avvisi, eventi di business). Rispondono a “cosa è successo?” e “quale richiesta ha fallito?”\n- Traces mostrano il percorso end-to-end delle richieste tra servizi. Rispondono a “dove è andato il tempo?” e “quale dipendenza ha causato il rallentamento?”

Un workflow semplice: detect → triage → deep-dive

1. Detect (TSDB + alert): un alert scatta per tasso di errore o latenza elevata.
2. Triage (dashboard TSDB): restringi il campo per servizio, regione, versione o endpoint usando le dimensioni metriche.
3. Deep-dive (log/trace): pivot verso log e trace correlati alla finestra temporale per trovare la root cause.

Nella pratica, una TSDB sta al centro del monitoraggio “segnale veloce”, mentre i sistemi di log e trace forniscono le prove dettagliate da consultare una volta che le metriche indicano dove guardare.

Scalabilità e considerazioni di affidabilità

I dati di monitoring sono più preziosi durante un incidente—proprio quando i sistemi sono sotto stress e le dashboard sono prese d’assalto. Una TSDB deve continuare a ingerire e rispondere alle query anche quando parti dell’infrastruttura sono degradate, altrimenti perdi la timeline necessaria per diagnosticare e ripristinare.

Scalare orizzontalmente: sharding e replica

La maggior parte delle TSDB scala orizzontalmente shardando i dati tra nodi (spesso per range temporali, nome metrica o hash delle label). Questo distribuisce il carico di scrittura e consente di aggiungere capacità senza riprogettare il monitoring.

Per restare disponibili in caso di failure, le TSDB usano la replica: scrivono copie degli stessi dati su più nodi o zone. Se una replica diventa non disponibile, letture e scritture possono continuare sulle repliche sane. I buoni sistemi supportano anche il failover così pipeline di ingestione e router di query reindirizzano automaticamente il traffico con gap minimi.

Gestire spike di ingestione: buffering e backpressure

Il traffico delle metriche è bursty—deploy, autoscaling o outage possono moltiplicare i campioni. Le TSDB e i loro collector usano tipicamente buffer di ingestione (code, WAL o spooling su disco locale) per assorbire spike brevi.

Quando la TSDB non riesce a tenere il passo, il backpressure è importante. Invece di scartare silenziosamente dati, il sistema dovrebbe segnalare ai client di rallentare, dare priorità alle metriche critiche o ridurre l’ingestione non essenziale in modo controllato.

Realtà multi-tenant: team e ambienti

In organizzazioni grandi, una TSDB spesso serve più team e ambienti (prod, staging). Funzionalità multi-tenant—namespace, quote per tenant e limiti di query—aiutano a prevenire che una dashboard rumorosa o un job mal configurato impattino tutti. Una chiara isolazione semplifica anche chargeback e controllo accessi mentre il programma di monitoring cresce.

Sicurezza e governance dei dati metrici

Le metriche spesso sembrano “non sensibili” perché sono numeri, ma le label e la metadata possono rivelare molto: identificatori clienti, host interni, perfino indizi su incidenti. Una buona configurazione TSDB tratta i dati metrici come qualsiasi altro dataset di produzione.

Ingestione sicura: proteggi i dati in transito

Inizia dalle basi: cifra il traffico dagli agent e collector alla TSDB con TLS e autentica ogni writer. La maggior parte dei team usa token, API key o credenziali a breve durata emesse per servizio o ambiente.

Regola pratica: se un token viene compromesso, il blast radius deve essere piccolo. Preferisci credenziali di scrittura separate per team, cluster o namespace—così puoi revocare l’accesso senza rompere tutto.

Controllo accessi: chi può leggere quali metriche

La lettura delle metriche può essere sensibile quanto la scrittura. La tua TSDB dovrebbe supportare controllo accessi che rifletta l’organizzazione:

• Gli SRE potrebbero aver bisogno di visibilità ampia sui sistemi.
• I team prodotto potrebbero aver bisogno solo delle metriche del proprio servizio.
• I team security o compliance potrebbero richiedere accesso in sola lettura più report.

Cerca controllo accessi basato sui ruoli e scoping per progetto, tenant o namespace. Questo riduce l’esposizione accidentale dei dati e mantiene dashboard e alert allineati alla proprietà.

Minimizzazione dei dati: tieni fuori informazioni sensibili dalle label

Molte “fughe” di metriche avvengono tramite label: user_email, customer_id, URL completi o frammenti di payload. Evita di mettere dati personali o identificativi unici nelle label metriche. Se ti serve debug a livello utente, usa log o trace con controlli più stretti e retention più corta.

Auditabilità per ambienti regolamentati

Per la conformità potresti dover rispondere a: chi ha accesso a quali metriche e quando? Preferisci TSDB (e gateway attorno) che producano audit log per autenticazione, modifiche di configurazione e accessi in lettura—così indagini e revisioni si basano su prove, non su supposizioni.

Come scegliere una TSDB per il tuo team

Scegliere una TSDB è meno una questione di marchio e più di aderenza alla tua realtà di metriche: quanta dati generi, come li interroghi e cosa serve al tuo team on-call alle 2 di notte.

Parti da alcune domande concrete

Prima di confrontare vendor o opzioni open-source, rispondi a queste domande:

• Tasso di ingestione: quante campioni al secondo ingestisci ora e quale crescita prevedi (nuovi servizi, nuovi ambienti, più label)?
• Cardinalità: qual è il tuo numero attuale e worst-case di serie uniche (es. per-pod, per-container, per-customer)?
• Retention: quanto a lungo devi mantenere i dati raw? Ti servono mesi di dettaglio o solo pochi giorni più rollup a lungo termine?
• Esigenze di query: costruisci soprattutto dashboard, indagini ad-hoc o query di alert che devono terminare rapidamente?

Managed vs self-hosted: scegli il compromesso operativo

TSDB gestite riducono la manutenzione (upgrade, scaling, backup), spesso con SLA prevedibili. Il compromesso è costo, meno controllo sugli interni e talvolta vincoli su feature di query o egress dei dati.

TSDB self-hosted possono costare meno a scala e dare flessibilità, ma devi occuparti di capacity planning, tuning e risposta agli incidenti per il database stesso.

Non ignorare le integrazioni

Una TSDB raramente è isolata. Conferma la compatibilità con:

• Collector/agent che già usi (Prometheus, OpenTelemetry Collector, Telegraf)
• Dashboard (Grafana) e come si configurano le data source
• Alert manager e le feature del linguaggio di query necessarie per alert affidabili

Esegui un proof-of-concept con metriche di successo

Limita nel tempo un PoC (1–2 settimane) e definisci criteri di successo/fallimento:

• Ingesta delle tue metriche reali (o un campione rappresentativo) ai picchi previsti
• Ricreare 5–10 dashboard “must-have” e le query di alert principali
• Misurare latenza di query, tasso di errore, uso risorse/costo e sforzo operativo (tempo passato a tuning, debug, scaling)

La “migliore” TSDB è quella che soddisfa requisiti di cardinalità e query mantenendo costo e carico operativo accettabili per il tuo team.

Passi pratici per migliorare il monitoring con una TSDB

Una TSDB conta per l’observability perché rende le metriche usabili: query veloci per dashboard, valutazioni di alert prevedibili e la capacità di gestire molti dati etichettati (inclusi carichi ad alta cardinalità) senza trasformare ogni nuova label in sorpresa di costo e performance.

Una breve checklist “per cominciare”

Inizia in piccolo e rendi visibili i progressi:

• Scegli 5–10 servizi critici (a contatto con il cliente o che impattano il fatturato).
• Definisci i tuoi “golden signals” per servizio (latenza, errori, traffico, saturazione).
• Conferma il percorso di ingestione (agent/collector → TSDB) e valida timestamp, unità e set di label.
• Imposta retention e rollup (raw per debug a breve termine; downsampled per tendenze a lungo termine).
• Crea una dashboard di base per ogni servizio più una panoramica di sistema.
• Aggiungi 3–5 alert che mappino l’impatto utente (non “CPU alta” a meno che non correlata a outage).

Se costruisci e rilasci servizi rapidamente con un flusso rapido di sviluppo (ad esempio, generando un’app React + backend Go con PostgreSQL), vale la pena trattare l’observability come parte del percorso di delivery—non come un ripensamento. Piattaforme come Koder.ai aiutano i team a iterare velocemente, ma vuoi comunque nomi metrici coerenti, label stabili e un pacchetto standard di dashboard/alert così le nuove feature non arrivano “dark” in produzione.

Documenta le convenzioni metriche (ripaga in fretta)

Scrivi una guida di una pagina e tienila semplice:

• Naming: service_component_metric (es. checkout_api_request_duration_seconds).
• Unità: includi sempre seconds, bytes o percent.
• Label: definisci i valori consentiti ed evita label non bounded (es. user ID grezzi).
• Ownership: ogni dashboard/alert ha un proprietario e una cadenza di revisione.

Passi suggeriti

Instrumenta prima i percorsi di richiesta chiave e i job in background, poi amplia la copertura. Dopo aver creato le dashboard di base, esegui una breve “review di observability” in ogni team: i grafici rispondono a “cosa è cambiato?” e “chi è impattato?” Se no, affina le label e aggiungi poche metriche ad alto valore invece di aumentare il volume a caso.