Come l'osservabilità e i log delle query lente proteggono la produzione

Perché i guasti in produzione sono difficili da intercettare presto

La produzione raramente “si rompe” in un singolo momento drammatico. Spesso degrada silenziosamente: alcune richieste cominciano a scadere, un job in background rimane indietro, la CPU aumenta lentamente e sono i clienti i primi a notare—perché il tuo monitoraggio mostra ancora “verde”.

I guasti si manifestano come sintomi, non come cause

La segnalazione dell'utente è di solito vaga: “Sembra lento.” È un sintomo condiviso da decine di cause radice—contesa di lock nel database, un nuovo piano di esecuzione, un indice mancante, un noisy neighbor, una tempesta di retry o una dipendenza esterna che fallisce a intermittenza.

Senza buona visibilità, i team finiscono per indovinare:

• Il rallentamento è globale o limitato a un endpoint?
• È iniziato dopo un deploy, una modifica di configurazione o un picco di traffico?
• È l'applicazione, il database o la rete nel mezzo?

Le tue dashboard non vedono ciò che sentono gli utenti

Molti team monitorano medie (latency media, CPU media). Le medie nascondono il dolore. Una piccola percentuale di richieste molto lente può rovinare l'esperienza mentre le metriche complessive sembrano a posto. E se monitori solo “su/giù”, perdi il lungo periodo in cui il sistema è tecnicamente up ma praticamente inutilizzabile.

Osservabilità + log delle query lente: segnali complementari

L'osservabilità ti aiuta a rilevare e restringere dove il sistema sta degradando (quale servizio, endpoint o dipendenza). I log delle query lente ti aiutano a provare cosa stava facendo il database quando le richieste si bloccavano (quale query, quanto è durata e spesso che tipo di lavoro ha eseguito).

Questa guida resta pratica: come ottenere un avviso più precoce, collegare la latenza lato utente a lavoro specifico nel database e risolvere i problemi in sicurezza—senza fare affidamento su promesse specifiche del vendor.

Fondamenti di osservabilità: metriche, log e trace

Osservabilità significa poter capire cosa fa il sistema guardando i segnali che produce—senza dover indovinare o “riprodurlo in locale.” È la differenza tra sapere che gli utenti sperimentano lentezza e poter individuare dove la lentezza avviene e perché è iniziata.

I tre pilastri (e a cosa servono)

Metriche sono numeri nel tempo (%, tasso di richieste, tasso di errori, latenza del database). Sono veloci da interrogare e ottime per individuare trend e picchi improvvisi.

Log sono record di eventi con dettagli (un messaggio di errore, il testo SQL, un ID utente, un timeout). Sono i migliori per spiegare cosa è successo in forma leggibile.

Trace seguono una singola richiesta mentre attraversa servizi e dipendenze (API → app → database → cache). Sono ideali per rispondere dove è stato speso il tempo e quale passo ha causato il rallentamento.

Un modello mentale utile: le metriche ti dicono che qualcosa non va, i trace mostrano dove, e i log spiegano esattamente cosa.

Le domande a cui una buona osservabilità dovrebbe rispondere

Una configurazione sana ti aiuta a rispondere agli incidenti con risposte chiare:

• Cosa si è rotto? (errori, timeout, saturazione)
• Dove? (quale endpoint, servizio, dipendenza o query)
• Perché adesso? (un deploy, cambio di traffico, feature flag, crescita dei dati)

Monitoring vs. osservabilità (un malinteso comune)

Il monitoring riguarda di solito controlli e alert predefiniti (“CPU > 90%”). L'osservabilità va oltre: ti permette di investigare nuovi, imprevisti modi di guasto affettando e correlando i segnali (per esempio, vedere che solo un segmento di clienti sperimenta checkout lenti legati a una chiamata DB specifica).

Questa capacità di porsi nuove domande durante un incidente è ciò che trasforma la telemetria grezza in troubleshooting più veloce e sereno.

Cosa sono i log delle query lente e cosa rivelano

Un log delle query lente è un registro focalizzato sulle operazioni di database che hanno superato una soglia di “lentezza”. A differenza del logging generale delle query (che può essere travolgente), mette in evidenza le istruzioni più probabili a causare latenza visibile all'utente e incidenti in produzione.

Cosa registra tipicamente un log delle query lente

La maggior parte dei database può catturare un insieme core di campi simili:

• La query (spesso il testo SQL normalizzato)
• Durata (tempo totale impiegato, a volte con suddivisione)
• Timestamp (quando è iniziata e finita)
• Contesto come database/utente, host, nome dell'applicazione, righe esaminate/ritornate e a volte il piano di esecuzione o un plan hash

Quel contesto è ciò che trasforma “questa query è stata lenta” in “questa query è stata lenta per questo servizio, da questo pool di connessioni, a quest'ora esatta”, cruciale quando più app condividono lo stesso database.

Perché compaiono query lente

I log delle query lente raramente parlano di “SQL cattivo” isolatamente. Sono segnali che il database ha dovuto fare lavoro extra o è rimasto in attesa. Cause comuni includono:

• Indici mancanti o inefficaci, che costringono a scansioni complete o join costosi
• Piani di esecuzione subottimali (spesso scatenati da valori di parametro, statistiche obsolete o comportamento della cache del piano)
• Attese di lock e contesa, dove la query è veloce quando viene eseguita ma lenta quando rimane in attesa
• Picchi di carico, dove una query normalmente accettabile diventa lenta sotto concorrenza o pressione I/O

Un modello mentale utile: i log delle query lente catturano sia il lavoro (query pesanti di CPU/I/O) sia l'attesa (lock, risorse sature).

Definire “lento”: soglie e percentili

Una soglia singola (per esempio, “logga tutto > 500ms”) è semplice, ma può perdere il dolore quando la latenza tipica è molto più bassa. Considera di combinare:

• Una soglia fissa per catturare outlier davvero gravi
• Una vista basata sui percentili (p95/p99) nel tuo monitoring così noti regressioni anche quando i tempi assoluti sembrano “ok”

Questo mantiene il log delle query lente azionabile mentre le tue metriche mettono in luce i trend.

Nota sulla privacy: evita di loggare valori sensibili

I log delle query lente possono accidentalmente catturare dati personali se i parametri sono inlined (email, token, ID). Preferisci query parametrizzate e impostazioni che logghino la forma della query piuttosto che i valori grezzi. Quando non puoi evitarlo, aggiungi masking/redaction nella pipeline di log prima di archiviare o condividere i log durante la risposta all'incidente.

Come le query lente diventano outage e latenza visibile agli utenti

Una query lenta raramente resta “solo lenta”. La catena tipica è: latenza utente → latenza API → pressione sul DB → timeout. L'utente lo percepisce prima come pagine che si bloccano o schermate che girano. Poco dopo, le metriche API mostrano tempi di risposta elevati, anche se il codice dell'app non è cambiato.

Perché il problema del database sembra un problema dell'app

Visto dall'esterno, un database lento spesso appare come “l'app è lenta” perché il thread API è bloccato in attesa della query. CPU e memoria sui server applicativi possono sembrare normali, eppure la p95 e la p99 aumentano. Se guardi solo metriche a livello di app, puoi inseguire il sospetto sbagliato—handler HTTP, cache o deploy—mentre il vero collo di bottiglia è una singola regressione del piano di query.

Come le query lente possono sfociare in un outage

Una volta che una query rallenta, i sistemi cercano di far fronte—e quei meccanismi di coping possono amplificare il guasto:

• Retry da parte dei client o dei servizi interni moltiplicano il traffico, aumentando il carico DB.
• Esaurimento della pool di connessioni accade quando le richieste tengono le connessioni più a lungo, costringendo nuove richieste ad attendere.
• Accumulo di code si forma in worker e consumer di messaggi mentre la throughput cala.
• Timeout scattano, causando failure parziali che generano altri retry e lavoro duplicato.

Uno scenario semplice

Immagina un endpoint di checkout che esegue SELECT ... FROM orders WHERE user_id = ? ORDER BY created_at DESC LIMIT 1. Dopo una soglia di crescita dei dati, l'indice non aiuta più abbastanza e il tempo della query passa da 20ms a 800ms. Con traffico normale è fastidioso. In un picco, le richieste API si accumulano in attesa delle connessioni DB, scadono a 2 secondi e i client ritentano. In pochi minuti, una “piccola” query lenta diventa errori visibili agli utenti e un incidente di produzione completo.

Le metriche che segnalano rapidamente problemi al database

Quando un database comincia a soffrire, i primi indizi di solito compaiono in un piccolo sottoinsieme di metriche. L'obiettivo non è tracciare tutto—ma individuare un cambiamento velocemente e poi restringere il campo.

Parti dai golden signals

Questi quattro segnali ti aiutano a capire se stai vedendo un problema al database, un problema applicativo o entrambi:

• Latenza: aumento della p95/p99 è spesso il primo sintomo visibile al cliente.
• Traffico: un picco di traffico può essere la causa (più carico) o il risultato (retry e thundering herd).
• Errori: tieni d'occhio timeout, 5xx e codici di errore del DB.
• Saturazione: un DB può essere “up” ma saturo—CPU, I/O, slot di connessione o contesa dei lock.

Metriche DB core da monitorare

Poche chart specifiche del DB possono dirti se il collo di bottiglia è esecuzione query, concorrenza o storage:

• Distribuzione della latenza delle query (non solo la media): cerca una coda più pesante (p95/p99) e varianza crescente.
• Connessioni e utilizzo della pool: aumento delle connessioni “attive”, code nella pool o esaurimento frequente.
• Lock e tempo di attesa: durata delle attese di lock e deadlock; spesso correlano a salti improvvisi di latenza.
• Cache hit rate / efficienza del buffer cache: un calo può significare che il working set non entra più in memoria, portando a più letture su disco.

Metriche a livello di servizio che implicano il DB

Abbina le metriche DB con l'esperienza del servizio:

• Tasso di richieste e timeout (inclusi timeout upstream).
• p95/p99 latency per endpoint: un singolo endpoint che degrada può indicare un pattern di query.
• Tasso di retry: i retry possono amplificare il carico e nascondere il trigger originale.

Dashboard che rispondono alle domande giuste

Progetta dashboard per rispondere velocemente:

• È nuovo? Confronta con lo stesso orario di ieri/ultima settimana.
• È isolato? Un endpoint, un tenant, un nodo, una AZ?
• Sta crescendo? La saturazione è in aumento e si stanno formando code?

Quando queste metriche si allineano—latency di coda in aumento, timeout in crescita, saturazione in salita—hai un forte segnale per passare ai log delle query lente e ai trace per individuare l'operazione esatta.

Tracciare il percorso della richiesta fino all'operazione lenta esatta

I log delle query lente ti dicono cosa è stato lento nel database. Il tracing distribuito ti dice chi l'ha richiesto, da dove e perché era importante.

Segui la richiesta, non l'ipotesi

Con il tracing in atto, un alert “database lento” diventa una storia concreta: un endpoint specifico (o un job) ha innescato una sequenza di chiamate, una delle quali ha passato la maggior parte del tempo in attesa di un'operazione DB.

Nella UI APM, parti da un trace ad alta latenza e cerca:

• La route o il nome del job che ha inizialmente fatto la richiesta (es. GET /checkout o billing_reconcile_worker).
• Uno span database con durata insolita o alto time-to-first-row.
• Se la lentezza è isolata a un tipo di richiesta o diffusa.

Tagga gli span in modo sicuro (senza esporre SQL)

SQL completo nei trace può essere rischioso (PII, segreti, payload grandi). Un approccio pratico è taggare gli span con un nome dell'operazione/query invece della statement completa:

• db.operation=SELECT e db.table=orders
• app.query_name=orders_by_customer_v2
• feature_flag=checkout_upsell

Questo mantiene i trace ricercabili e sicuri, pur indicando il percorso di codice.

Correlare tutto con ID

Il modo più veloce per collegare “trace” → “log app” → “voce slow query” è un identificatore condiviso:

• Propaga un trace ID nei log applicativi.
• Se possibile, aggiungi il trace ID (o request ID) al contesto del log delle query lente (o in un commento nella query quando è sicuro e supportato).

Ora puoi rispondere rapidamente a domande di alto valore:

• Quale route o worker innesca la chiamata lenta?
• È legato a un tenant/cliente, regione o piano specifico?
• È iniziato dopo un rilascio o una modifica di configurazione?
• È una singola query costosa, o un'ondata di molte piccole query (N+1)?

Configurare il logging delle query lente senza annegare nei dati

I log delle query lente sono utili solo se restano leggibili e azionabili. Lo scopo non è “loggare tutto per sempre”—ma catturare dettagli sufficienti per spiegare perché le query sono lente, senza aggiungere overhead percepibile o creare un problema di costi.

Scegli soglie che rispecchiano l'esperienza della tua app

Inizia con una soglia assoluta che rifletta le aspettative degli utenti e il ruolo del database nella richiesta.

• Esempi assoluti: >200ms per app OLTP, >500ms per workload misti

Poi aggiungi una vista relativa così noti i problemi anche quando l'intero sistema rallenta (e meno query superano la linea hard).

• Esempi relativi: “top 100 più lente al minuto” o “top 1% statement più lenti”

Usare entrambe evita punti ciechi: soglie assolute catturano query “sempre cattive”, quelle relative catturano regressioni durante i periodi intensi.

Campiona in modo intelligente e cattura il contesto che userai davvero

Loggare ogni statement lento in picco può danneggiare le prestazioni e generare rumore. Preferisci sampling (es. logga il 10–20% degli eventi lenti) e aumenta il campionamento temporaneamente durante un incidente.

Assicurati che ogni evento includa il contesto azionabile: durata, righe esaminate/ritornate, database/utente, nome applicazione e idealmente un request o trace ID se disponibile.

Normalizza le query così i pattern emergono

Le stringhe SQL grezze sono disordinate: ID e timestamp diversi fanno sembrare uniche query identiche. Usa la fingerprinting (normalizzazione) per raggruppare statements simili, es. WHERE user_id = ?.

Questo ti permette di rispondere: “Quale forma di query causa più latenza?” invece di inseguire esempi isolati.

Conservazione del piano attorno agli incidenti (e costi)

Conserva i log dettagliati delle query lente abbastanza a lungo da confrontare “prima vs dopo” nelle indagini—spesso 7–30 giorni è un punto di partenza pratico.

Se lo storage è un problema, downsample i dati più vecchi (conserva aggregati e top fingerprint) mantenendo log a piena fedeltà per la finestra più recente.

Allarmi che intercettano i rallentamenti prima degli utenti

Gli alert dovrebbero segnalare “gli utenti stanno per sentire questo” e dire dove guardare prima. Il modo più semplice è alertare su sintomi (cosa prova il cliente) e cause (cosa lo sta causando), con controlli sul rumore così l'on-call non impara a ignorare le pagine.

Allerta sui sintomi (impatto utente)

Inizia con un piccolo set di indicatori ad alto segnale che correlano con il dolore del cliente:

• Aumento di p95/p99 per endpoint chiave (non solo medie)
• Tasso di timeout (timeout app e upstream) e tasso di retry
• Profondità delle code / saturazione dei worker (thread pool, pool di connessioni)
• Attese di lock e transazioni bloccate (un precursore comune di “tutto è lento”)

Se puoi, limita gli alert ai “golden paths” (checkout, login, ricerca) così non ricevi pagine per route poco importanti.

Allerta sulle cause (da indagare)

Accoppia gli alert sui sintomi con alert orientati alla causa per ridurre il tempo di diagnosi:

• Top fingerprint di query lente che superano una soglia (es. p95 o tempo totale)
• Cambi di piano (improvviso aumento di righe esaminate, nuove scansioni full table, indice non usato)
• Picchi di errore dal layer DB (deadlock, troppe connessioni, query cancellate)

Questi alert di causa dovrebbero idealmente includere la fingerprint della query, parametri di esempio (sanitizzati) e un riferimento diretto alla dashboard o alla vista trace rilevante.

Ridurre il rumore senza perdere incidenti reali

Usa:

• Burn-rate alerts sugli SLO (pagina veloce per regressioni rapide, pagina lenta per degradazione sostenuta)
• Check multi-finestra (es. 5m e 30m) per evitare flapping
• Deduping e raggruppamento (un incidente per servizio/db + fingerprint)

Ogni pagina dovrebbe includere “cosa fare dopo?”—richiama un runbook come /blog/incident-runbooks e specifica le prime tre verifiche (pannello latenza, lista query lente, grafici lock/connessioni).

Un workflow pratico per gli incidenti: dallo spike alla causa radice

Quando la latenza schizza, la differenza tra un recupero veloce e un lungo outage è avere un workflow ripetibile. L'obiettivo è passare da “qualcosa è lento” a una query specifica, endpoint e cambiamento che l'ha causata.

1) Rilevare → confermare che è reale

Parti dal sintomo utente: latenza più alta, timeout o aumento degli errori.

Conferma con un piccolo set di indicatori ad alto segnale: p95/p99 latency, throughput e salute del database (CPU, connessioni, code/tempi di attesa). Evita di inseguire anomalie su singolo host—cerca un pattern sul servizio.

2) Delimitare → chi e cosa è colpito

Restringi il raggio d'azione:

• Quali endpoint sono lenti (top route per p95)?
• È per tutti i clienti o un sottoinsieme (tenant, regione, piano)?
• È iniziato a un confine temporale (deploy, job batch, spostamento di traffico)?

Questa fase evita di ottimizzare la cosa sbagliata.

3) Isolare → usa i trace per trovare l'operazione lenta

Apri i trace distribuiti per gli endpoint lenti e ordina per durata.

Cerca lo span che domina la richiesta: una chiamata DB, una attesa di lock o query ripetute (N+1). Correlare i trace con tag come versione release, tenant ID e nome endpoint per vedere se la lentezza coincide con un deploy o un carico cliente specifico.

4) Confermare → collegare i trace ai log delle query lente

Ora valida la query sospetta nei log delle query lente.

Concentrati sulle “fingerprint” (query normalizzate) per trovare i peggiori colpevoli per tempo totale e conteggio. Poi annota le tabelle e i predicati interessati (filtri e join). Qui spesso scopri un indice mancante, un nuovo join o un cambiamento del piano.

5) Mitigare → ridurre l'impatto utente in sicurezza

Scegli la mitigazione meno rischiosa per prima: rollback del rilascio, disabilitare feature flag, shed del carico o aumentare i limiti della pool di connessioni solo se sei sicuro che non peggiorerà la contesa. Se devi cambiare la query, mantieni la modifica piccola e misurabile.

Un consiglio pratico se la tua pipeline supporta: tratta il “rollback” come un bottone di prima classe, non come un'azione eroica. Piattaforme come Koder.ai supportano snapshot e workflow di rollback, riducendo il tempo di mitigazione quando un rilascio introduce accidentalmente pattern di query lenti.

6) Documentare → rendere il prossimo incidente più breve

Cattura: cosa è cambiato, come l'hai rilevato, la fingerprint esatta, endpoint/tenant impattati e cosa l'ha risolto. Trasforma questo in follow-up: aggiungi un alert, un pannello dashboard e una guardia di performance (es. “nessuna fingerprint di query sopra X ms a p95”).

Correggere le query lente in sicurezza in produzione

Quando una query lenta sta già danneggiando gli utenti, l'obiettivo è ridurre prima l'impatto e poi migliorare le prestazioni—senza peggiorare l'incidente. I dati di osservabilità (campioni dei log delle query lente, trace e metriche DB chiave) ti dicono quale leva è più sicura da usare.

1) Stabilizzare con mitigazioni a basso rischio

Inizia con cambiamenti che riducono il carico senza modificare il comportamento dei dati:

• Feature flag: disabilita temporaneamente endpoint costosi, report, filtri di ricerca o pannelli “recent activity” che scatenano query pesanti.
• Rate limit / quote: limita la route o il segmento cliente mostrato nei trace che genera più traffico.
• Caching: aggiungi caching a breve durata per endpoint in lettura intensa (anche 30–120 secondi riducono dramaticamente il carico DB). Preferisci caching a livello di richiesta o applicazione prima di cambiamenti a livello DB.
• Disabilitare percorsi costosi: rimuovi JOIN opzionali, “order by relevance” o paginazioni profonde dietro flag.

Queste mitigazioni comprano tempo e dovrebbero mostrare miglioramenti immediati in p95 e nelle metriche CPU/IO del DB.

2) Fix DB: mirati e testabili

Una volta stabilizzato, correggi il pattern di query:

• Aggiungi un indice che corrisponda a filtro + sort della query. Valida con EXPLAIN e conferma la riduzione delle righe scansionate.
• Riscrivi la query per limitare i dati scansionati (seleziona meno colonne, evita SELECT *, aggiungi predicati selettivi, sostituisci subquery correlate).
• Riduci pattern N+1 raggruppando ID, aggiungendo prefetch o usando una singola query con JOIN attentamente scelti.

Applica i cambiamenti gradualmente e conferma i miglioramenti usando lo stesso span/trace e la stessa signature della query lenta.

3) Mitigazioni operative quando il codice non può cambiare subito

• Aumenta capacità (repliche di lettura, istanze più grandi) per fermare l'emorragia.
• Tuna la pool di connessioni per prevenire code e esaurimento dei thread.
• Regola i timeout così il sistema fallisce velocemente invece di accumulare richieste bloccate.

Rollback: revert vs hotfix

Effettua rollback quando la modifica aumenta errori, contesa di lock o sposta il carico in modo imprevedibile. Applica hotfix quando puoi isolare il cambiamento (una query, un endpoint) e hai telemetria chiara before/after per validare un miglioramento sicuro.

Prevenire ricorrenze con SLO e guardrail di performance

Dopo aver risolto una query lenta in produzione, il vero successo è fare in modo che lo stesso pattern non torni in forma leggermente diversa. Qui SLO chiari e alcuni guardrail leggeri trasformano un incidente in affidabilità duratura.

Lega gli SLO a ciò che gli utenti percepiscono

Inizia con SLI che mappano direttamente all'esperienza cliente:

• p95 (e p99) latency per endpoint chiave e segmentata per tenant
• Tasso di errore (timeout, 5xx e “soft errors” come risultati vuoti causati da cancellazioni)
• Segnali di saturazione che correlano ai rallentamenti (CPU DB, tempo di attesa nella pool)

Imposta un SLO che riflette performance accettabile, non perfetta. Es: “p95 checkout sotto 600ms per il 99.9% dei minuti.” Quando l'SLO è minacciato, hai una ragione obiettiva per fermare deploy rischiosi e concentrarti sulla performance.

Traccia regressioni per release, non a sentimento

La maggior parte degli incidenti ripetuti sono regressioni. Rendi facile individuarle confrontando prima/dopo per ogni release:

• Confronta trace per lo stesso endpoint e cerca uno span nuovo che domina il tempo totale.
• Confronta fingerprint delle query lente (pattern normalizzati) per rilevare una nuova forma di query, un indice mancante o un salto improvviso nelle righe scansionate.

La chiave è rivedere i cambiamenti nella distribuzione (p95/p99), non solo le medie.

Aggiungi test di performance per i percorsi critici

Scegli un piccolo set di endpoint “da non rallentare” e le loro query critiche. Aggiungi controlli di performance in CI che falliscono quando latenza o costo della query superano una soglia (anche una baseline + drift permesso). Questo cattura bug N+1, scansioni full table accidentali e paginazioni non limitate prima che vengano distribuiti.

Se costruisci servizi velocemente (per esempio con un app builder come Koder.ai, dove frontend React, backend Go e schemi PostgreSQL possono essere generati e iterati rapidamente), questi guardrail contano ancora di più: la velocità è un valore, ma solo se si integra la telemetria (trace ID, fingerprint delle query e logging sicuro) fin dalla prima iterazione.

Crea ownership e cadenza di revisione

Fai della revisione delle query lente il lavoro di qualcuno, non un ripensamento:

• Assegna un owner per servizio/database.
• Revisiona i report delle query lente con cadenza fissa (settimanale è sufficiente per molti team).
• Mantieni un backlog corto: fingerprint della query, causa sospetta, azione successiva e impatto previsto.

Con gli SLO che definiscono “come deve andare” e i guardrail che intercettano le deviazioni, la performance smette di essere un'emergenza ricorrente e diventa una parte gestita della delivery.

Cosa cercare in una configurazione di osservabilità per database

Una configurazione focalizzata sul database dovrebbe aiutarti a rispondere velocemente a due domande: “Il database è il collo di bottiglia?” e “Quale query (e quale chiamante) l'ha causato?” Le migliori configurazioni rendono la risposta ovvia senza costringere gli ingegneri a cercare nei log grezzi per ore.

Checklist pratica

Metriche richieste (idealmente suddivise per istanza, cluster e ruolo/replica):

• Latenza query (p50/p95/p99), throughput (QPS) e tasso di errori
• Utilizzo pool di connessioni, connessioni attive/inattive, tempo di attesa
• Lock: tempo di attesa lock, deadlock, contesa per row lock
• Segnali di risorsa: CPU, memoria, disk I/O, hit ratio della cache
• Lag di replica (se applicabile)

Campi di log richiesti per i log delle query lente:

• Timestamp, durata, database/schema, user/role, identificatore client/app
• Query normalizzata o fingerprint, più un modo sicuro per vedere il testo completo quando permesso
• Righe esaminate/ritornate, hash del piano (se disponibile)

Tag di trace per correlare richieste e query:

• service.name, endpoint/route, environment, version
• db.system, db.name, db.statement fingerprint, db.operation
• request_id / trace_id esposto nei log

Dashboard e alert che dovresti aspettarti:

• Overview “DB pain”: p95 latency + QPS + attese di connessione + attese di lock
• Top N fingerprint di query per tempo totale e per p95
• Alert su aumento sostenuto di p95/p99, picchi di attesa lock e saturazione della pool (non solo CPU)

Domande da fare a uno strumento o vendor

Può correlare un picco di latenza endpoint a una specifica fingerprint di query e versione di release? Come gestisce il sampling così mantieni le query rare e costose? Deduplica statements rumorosi (fingerprinting) e mette in evidenza regressioni nel tempo?

Gestione dei dati su cui non scendere a compromessi

Cerca redaction integrata (PII e literal), controllo accessi basato sui ruoli e limiti di retention chiari per log e trace. Assicurati che l'export verso warehouse/SIEM non aggiri questi controlli.

Se il team sta valutando opzioni, aiuta allineare i requisiti presto—condividi una shortlist internamente e coinvolgi i vendor. Se vuoi un confronto rapido o una guida, vedi /pricing o contatta /contact.