Questa guida spiega (e ti aiuterà a evitare) le 10 principali insidie del monitoraggio delle prestazioni dei database in cui cadono comunemente ingegneri, amministratori di database e team (*Ops). Questi errori di monitoraggio possono portare a prestazioni scadenti del database e permettere ad altri problemi che possono compromettere l’affidabilità o l’integrità dei dati di sfuggire, causando query lente, tempi di inattività, problemi agli utenti e potenzialmente minacciando la redditività del tuo prodotto o della tua azienda.
1. Affidarsi solo a metriche predefinite e di alto livello
Il monitoraggio dell’uso della CPU e della memoria è insufficiente per identificare i problemi di prestazioni del database. Anche le prestazioni delle singole query, dell’indicizzazione e di altri fattori devono essere registrate e monitorate per identificare se, quando e perché il database ha prestazioni insufficienti.
Altre metriche da monitorare sono le prestazioni degli indici e della cache, la latenza di lettura/scrittura, i timeout di connessione e le prestazioni del disco.
2. Non registrare le metriche di performance di base
Non puoi sapere se le misure adottate per ottimizzare le prestazioni del database funzionano, a meno che tu non abbia un punto di riferimento da cui partire per misurarle. Ciò significa effettuare misurazioni regolari mentre il database funziona in modo ottimale e confrontarle con le misurazioni precedenti.
Una volta stabilito un punto di riferimento delle prestazioni, sarà più semplice identificare anomalie e regressioni, assicurandoti così di lavorare nella giusta direzione per risolvere eventuali problemi.
3. Monitoraggio troppo poco frequente o con troppo ritardo
Un approccio programmato al monitoraggio, in cui le metriche vengono acquisite periodicamente (ad esempio, ogni ora), e l’elaborazione in batch dei file di registro, possono essere un’alternativa economicamente vantaggiosa al monitoraggio in tempo reale per alcuni scenari.
Tuttavia, un monitoraggio troppo poco frequente o l’elaborazione dei dati di registro con un notevole ritardo possono far sì che i problemi (soprattutto quelli transitori di prestazioni) vengano trascurati o non risolti prima che possano causare effetti successivi in altri punti dell’infrastruttura. Devi configurare accuratamente il monitoraggio delle prestazioni del tuo database in modo che i problemi vengano segnalati tempestivamente quando necessario, permettendoti così di intervenire efficacemente.
4. Ignorare il monitoraggio a livello di query
Query inefficienti e strutture di database mal ottimizzate possono mettere in ginocchio anche i server più potenti. Prima di aumentare le specifiche (e i costi) dei tuoi server di database, assicurati di monitorare le prestazioni dell’esecuzione delle query, in modo da poter risolvere e ottimizzare le query lente.
Il monitoraggio a livello di query e la comprensione del modo in cui il sistema di database scelto esegue le query internamente (compresi il piano di esecuzione delle query e l’ordine di accesso alle tabelle del database) sono fondamentali per questo scopo.
5. Non impostare soglie e avvisi adeguati
Se un sistema di monitoraggio delle prestazioni del database ben progettato, mantenuto correttamente e ben sintonizzato invia un avviso che non viene mai letto o eseguito, tanto vale che non esista. Gli avvisi devono raggiungere la persona responsabile e la loro gravità deve essere evidente: soglie di avviso che riempiono la casella email di notifiche poco rilevanti fanno sì che quelle importanti vengano sommerse, oppure generano un’affaticamento da avviso che porta a trascurarle.
Anche le persone giuste devono essere informate: i membri del team devono essere responsabili di aspetti specifici dell’infrastruttura del database e devono comprendere l’impatto di una particolare metrica fuori range e il modo migliore per risolvere il problema. Una cultura della proattività e regolari revisioni delle procedure di rilevamento e risposta consentono di raggiungere questo obiettivo.
6. Concentrarsi solo sulle metriche lato server
Un database veloce dietro una connessione lenta apparirà agli utenti finali come un database lento. Il monitoraggio delle prestazioni end-to-end, così come l’analisi lato client, ti aiuterà a identificare i problemi di prestazioni causati da un codice front-end mal ottimizzato o da colli di bottiglia di rete che potrebbero essere completamente invisibili alle soluzioni di monitoraggio solo lato server.
7. Mancanza di analisi e approfondimento dei dati storici
Stabilire un punto di riferimento, identificare periodi di intensa attività per prevedere esigenze future e isolare problemi transitori dipendono tutti dall’accesso ai dati storici delle prestazioni del database con cui effettuare confronti. La valutazione dei tempi di riparazione dipende anche dagli approfondimenti storici, dalla capacità di identificare quando si è verificato un problema e da chi è stato avvisato.
I dati storici sulla sicurezza sono utili anche per diagnosticare i problemi di prestazioni: prestazioni scarse potrebbero essere causate dallo sfruttamento delle risorse IT, mentre il rallentamento delle prestazioni delle applicazioni potrebbe essere indice di un incidente di cybersecurity.
8. Trascurare i problemi di indicizzazione e di progettazione dello schema
La struttura dello schema del database influisce notevolmente sulle metriche delle prestazioni. La sotto indicizzazione e la sovra indicizzazione possono avere un impatto negativo sulle prestazioni, mentre tecniche come la denormalizzazione e la cache possono contribuire a migliorare le prestazioni senza richiedere risorse aggiuntive.
9. Trascurare i problemi di contesa delle risorse e di blocco
La contesa delle risorse e il blocco (deadlock, sessioni bloccanti) si verificano quando più query devono modificare gli stessi dati. Le operazioni devono attendere il completamento delle precedenti, il che può aumentare il tempo totale di esecuzione di una query e talvolta può causare ritardi indefiniti. Questo problema può essere mitigato con un’attenta progettazione dello schema e delle query.
10. Errata configurazione degli strumenti ed eccessiva dipendenza da un singolo strumento
Le configurazioni predefinite degli strumenti di monitoraggio e gestione dei database non sono adatte a soluzioni di database di qualsiasi complessità. Devi valutare la tua infrastruttura di dati e scegliere lo strumento (o gli strumenti) in grado di fornire gli approfondimenti e le fasi di correzione richieste dal tuo progetto, piuttosto che affidarti a un unico prodotto che lascia delle lacune di visibilità.
Gli strumenti di monitoraggio, gli avvisi e le dashboard devono essere configurati in modo mirato e così che le informazioni importanti non vengano perse tra le informazioni superflue. L’analisi dei registri può essere utilizzata a posteriori per ottenere approfondimenti più ampi, mentre le notifiche in tempo reale dovrebbero essere riservate alle azioni critiche da intraprendere, per evitare che vengano trascurate.
Una strategia di monitoraggio olistica e stratificata può proteggere da molti problemi dei database
Questo elenco non è esaustivo, poiché le insidie del monitoraggio delle prestazioni più dannose dipendono anche da ciò che è importante per il tuo progetto: il funzionamento, i dati e le query gestite dal database e i risultati previsti. Un approccio olistico e stratificato al monitoraggio dei database può aiutare a proteggerti sia dalle insidie note che da quelle specifiche dei tuoi dati e della tua infrastruttura.
Gli strumenti di intelligenza artificiale possono essere di grande aiuto in questo senso, grazie a una maggiore automazione e al rilevamento delle anomalie, spesso sono in grado di individuare i problemi analizzando grandi quantità di dati di registro che richiederebbero molto tempo a un essere umano. Il coordinamento tra amministratori di database, ingegneri DevOps e team di sviluppo contribuisce inoltre a garantire l’identificazione e la riduzione di tutti i potenziali problemi.
La documentazione del database è fondamentale anche per la manutenzione continua di qualsiasi progetto. I problemi possono essere identificati e risolti più rapidamente quando gli ingegneri sanno come funziona qualcosa, invece di dover decodificare l’ingegnoso hack di qualcun altro. Anche la documentazione non è un compito da svolgere una tantum: le correzioni, le patch e le continue modifiche alla configurazione del database, le query e il codice dell’applicazione devono essere documentati in modo ben strutturato, in modo da poter trovare rapidamente le informazioni pertinenti. Questo vale anche per il tuo apparato di monitoraggio: dovrà essere continuamente aggiornato e man mano che evolve incontrerà, a sua volta, bug e problemi.
Le prestazioni devono essere verificate regolarmente, con la frequenza necessaria per garantire che soddisfino sempre la domanda (di solito settimanalmente o mensilmente, ma più frequentemente se necessario). Le query che sono diventate lente a causa di cambiamenti nell’input o nell’output possono essere identificate e ottimizzate man mano che i casi d’uso si evolvono e il monitoraggio delle prestazioni potrebbe dover essere modificato per adattarle.
Perché il monitoraggio delle prestazioni dei database è importante
Un sistema di monitoraggio del database che non misura le metriche giuste e non avvisa le persone giuste può portare a un ROI inferiore sull’infrastruttura IT e sullo sviluppo del software. Le scarse prestazioni del database creano anche conseguenze incidentali per il resto dell’infrastruttura IT e di hosting e, infine, per gli utenti finali. Aumentare il Mean Time to Repair (MTTR) porta a una riduzione dei ricavi e a un aumento dei costi di manutenzione, poiché gli effetti di un problema di dati possono rapidamente amplificarsi anche in architetture di app semplici.
Gli utenti si aspettano un’elevata disponibilità e applicazioni che rispondano rapidamente, e la fiducia può venir rapidamente meno se questa aspettativa non viene soddisfatta, soprattutto quando si forniscono servizi aziendali. Ciò richiede un ridimensionamento rapido, informato da sistemi di monitoraggio in grado di garantire che i costi dell’infrastruttura non vengano sprecati per un uso inefficiente del database e di fornire le informazioni necessarie per bilanciare le prestazioni con i costi dell’infrastruttura di scaling.
Strumenti e tecniche di monitoraggio dei database consigliati
Gli strumenti che utilizzi per monitorare le prestazioni e lo stato di salute del tuo database dipenderanno in larga misura dalle esigenze specifiche del tuo progetto, bilanciando strumenti open source con servizi gestiti, in base alle competenze interne e alle risorse disponibili.
Gli strumenti più diffusi per il monitoraggio delle prestazioni dei database includono:
Alcune note piattaforme di database gestiti in cloud sono:
Questi strumenti forniranno anche i propri strumenti nativi per il monitoraggio delle prestazioni, della sicurezza e dell’integrità.
Puoi utilizzare anche strumenti di amministrazione dei database open source, come pgAdmin e DBADash, se soddisfano le tue esigenze.
L’osservabilità e l’integrazione con il monitoraggio dell’infrastruttura IT esistente sono anch’esse fondamentali, in modo che i problemi di prestazioni vengano rapidamente identificati alla fonte o in base al loro effetto su altri servizi, e gli stakeholder responsabili vengano informati. NinjaOne può monitorare le prestazioni dei server SQL come parte della sua soluzione di gestione unificata IT, e puoi anche creare i tuoi script personalizzati che monitorano le metriche importanti per il tuo progetto.
Domande frequenti
Qual è la differenza tra il monitoraggio e la profilazione di un database?
Il monitoraggio dei database è un processo continuo e in tempo reale che controlla le prestazioni, l’integrità, la sicurezza e la reattività di un sistema di database. La profilazione del database è l’esame periodico di un database per capire come si comporta e quali ottimizzazioni sono necessarie alla struttura del database o alle query per migliorarne l’efficienza e le prestazioni.
Con quale frequenza devo rivedere la mia strategia di monitoraggio del database?
Devi rivedere regolarmente la strategia di monitoraggio del database. Questo dovrebbe comportare revisioni settimanali o mensili della configurazione per garantire che rimanga appropriata per il caso d’uso e che non si sia verificata una deriva della configurazione. Inoltre, dovresti assicurarti che gli avvisi vengano inviati (e ricevuti) con successo e che venga fatto un backup della configurazione di monitoraggio del database. Anche i registri di sicurezza e di audit dovrebbero essere rivisti periodicamente per garantire che tutti gli eventi significativi siano stati catturati e che chi è responsabile sia stata informato.
Posso monitorare i database del cloud allo stesso modo dei database on-premise?
Sì, per monitorare i database cloud si possono usare gli stessi strumenti dei database on-premise. Le piattaforme cloud possono anche fornire ulteriori strumenti di monitoraggio delle prestazioni dei database per i loro servizi gestiti, che possono essere usati anche per monitorare l’utilizzo delle macchine virtuali che ospitano il tuo software di database.
