MongoDB diagnostics tool conserva tre mesi di cronologia
Un MongoDB diagnostics tool chiamato mongo-health è progettato per rispondere a una domanda operativa ricorrente: perché il database era lento diversi giorni fa, anche se non è scattato alcun avviso e nessuno ha svolto un'indagine in quel momento? Percona afferma che lo strumento open source conserva per tre mesi una cronologia diagnostica dettagliata di MongoDB, la valuta ogni ora mediante 68 controlli e presenta un unico verdetto complessivo per ciascun cluster.
Le evidenze sottostanti provengono da Full Time Diagnostic Data Capture, o FTDC, la raccolta integrata in MongoDB delle misurazioni operative. Ogni processo mongod, il programma che esegue un server di database MongoDB, registra le proprie metriche una volta al secondo in una directory diagnostic.data. Questi dati possono rivelare query inefficienti, operazioni di storage ritardate e problemi di rete che potrebbero non comparire nel log del database. Percona ha rilevato che un Atlas M10 sottoposto a traffico di produzione conservava soltanto da due a cinque giorni di FTDC: ciò significa che le evidenze di giovedì potevano già non essere più disponibili quando un team avviava un'indagine il lunedì.
Senza un'analisi automatizzata, un amministratore deve aprire i file rimanenti in un visualizzatore ed esaminare i grafici relativi all'orario segnalato. Una causa evidente potrebbe comparire tra i primi dieci grafici, mentre una meno visibile potrebbe richiedere l'esame di altri 40. I dati acquisiti possono mostrare una query che legge 10 milioni di documenti per ogni risultato, operazioni di storage che impiegano 400 millisecondi per scrittura per tre minuti oppure un membro del replica set che perde pacchetti per 30 secondi. Un replica set è un gruppo di server MongoDB che conserva copie degli stessi dati per garantirne la disponibilità. Il problema non è necessariamente la mancanza di evidenze, ma la difficoltà di individuare il segnale rilevante prima che i file scadano.
mongo-health conserva ogni secondo di FTDC per tre mesi e indica che cosa è successo, quale membro è stato interessato, quanto è durato l'evento e il grafico associato. Percona afferma che il software è distribuito con licenza Apache 2.0, viene eseguito in tre container Docker su un laptop o un server e non installa nulla sugli host del database. Le istruzioni su GitHub descrivono un'installazione tramite quattro comandi. Nel test di Percona su Atlas M10, l'interfaccia conteneva 29,92 giorni di FTDC. Se un cluster smette di fornire dati, il suo stato cambia in “Not being watched” anziché continuare a mostrare un verdetto positivo ormai obsoleto.
Ogni risultato include un grafico, un breve suggerimento su dove indagare e la posizione dell'incidente nella cronologia del cluster. Un operatore può contrassegnare un risultato come risolto e aggiungere una nota. Il risultato viene quindi rimosso dal report attivo, ma un'eventuale ricomparsa viene identificata come recidiva. I 68 controlli riguardano code di lavoro, slot di elaborazione disponibili noti come ticket, cache e memoria, storage, replicazione, connessioni, query, configurazione e incidenti precedenti. Il README del progetto raggruppa i controlli, mentre docs/rules.md ne documenta le soglie.
Percona ha dimostrato cinque guasti creati deliberatamente su un replica set a tre membri basato su Percona Server for MongoDB 8.0 e ne ha documentato un sesto verificatosi autonomamente su un Atlas M10. Nel primo test, una query priva di un index utilizzabile è iniziata alle 20:53. Per dieci minuti, il server ha esaminato circa 10 milioni di documenti per ciascun documento restituito, per poi ripetere il comportamento alle 21:54. La regola si attiva oltre un rapporto di 100 a uno. L'operazione non è fallita e non ha lasciato nulla di utile nel log, ma il risultato ha individuato un probabile index mancante e il minuto di inizio, consentendo un confronto con un deployment dell'applicazione.
Un test dello storage è iniziato alle 22:13 ed è durato tre minuti. Le scritture su tutti e tre i membri hanno raggiunto i 400 millisecondi, ben oltre la soglia di 10 millisecondi prevista dalla regola. mongo-health lo ha classificato come il terzo evento di questo tipo nel cluster e ha fornito collegamenti ai due precedenti. Questa cronologia può distinguere un rallentamento isolato da un problema ricorrente dello storage.
L'esempio di Atlas ha invece indicato la rete. Il 5 ottobre alle 08:25, un membro ha ritrasmesso fino a 30 TCP segments al secondo per circa 30 secondi. I TCP segments sono parti di dati inviate attraverso una rete e la ritrasmissione solitamente indica che non sono arrivate correttamente. Il controllo si attiva a partire da cinque ritrasmissioni al secondo. Poiché il server di database stesso ha risposto rapidamente, le evidenze indicavano una perdita di pacchetti durante il transito anziché una query lenta, fornendo all'operatore un grafico da allegare a una richiesta di assistenza.
Un altro carico di lavoro di laboratorio ha riscritto ripetutamente grandi quantità di dati. I checkpoint, operazioni periodiche che rendono permanenti le modifiche archiviate, normalmente venivano completati in meno di un secondo, ma hanno raggiunto tempi compresi tra sei e 11 secondi su tutti e tre i membri. Questo è accaduto due volte in dieci minuti. La regola richiede tempi di checkpoint superiori a un secondo per due minuti, impedendo che un singolo ritardo isolato venga classificato come risultato. Percona osserva che questi brevi blocchi potrebbero non essere visibili in un grafico del throughput.
Un test separato ha evidenziato un rischio prima che gli utenti si lamentassero. Il replica set gestiva circa 250 scritture al secondo, ma ogni scrittura sostituiva un intero documento da 20 KB e aggiungeva circa 20 KiB al journal, il record delle modifiche di MongoDB utilizzato per il ripristino. La regola si attiva a partire da 3,91 KiB per operazione. A quel ritmo, l'oplog, la cronologia ordinata utilizzata per copiare le modifiche tra i membri del replica set, si sarebbe riempito in un'ora anziché in un giorno. Un server secondario rimasto indietro di un'ora avrebbe quindi richiesto una risincronizzazione completa. La risposta utile consiste nel correggere lo schema di aggiornamento prima che la replicazione perda la propria finestra di ripristino.
Per il test finale, Percona ha ridotto la WiredTiger cache a 128 MB e ha eseguito la scansione di una collection da 1,9 GB. WiredTiger è lo storage engine di MongoDB e la sua cache mantiene in memoria i dati del database necessari più frequentemente. Per quattro minuti ha recuperato dal disco tra 20.000 e 68.000 pagine al secondo, superando la soglia di 10.000 prevista dalla regola. I dati richiesti non entravano in memoria. Anziché dichiarare che il problema fosse esclusivamente la memoria, il risultato invita gli operatori a esaminare la latenza del disco e i read ticket disponibili prima di decidere se la soluzione appropriata sia aggiungere memoria oppure usare una query più efficiente.
I metodi di raccolta dipendono dal deployment. Un replica set autogestito richiede un utente a cui sia assegnato il ruolo clusterMonitor, che concede l'accesso alle informazioni di monitoring. Il poller chiama getDiagnosticData su ogni membro a intervalli di dieci secondi. Atlas richiede una chiave API con Project Read Only, descritto come il suo ruolo con i privilegi più bassi, e recupera i file FTDC attraverso Atlas Admin API. Gli operatori possono inoltre caricare una directory diagnostic.data estratta da un support bundle.
Lo strumento è retrospettivo e non è un sistema di avviso per le emergenze. Legge FTDC una volta all'ora, quindi un problema potrebbe avere quasi un'ora quando viene visualizzato, e non invia mai una notifica urgente a un operatore. Il monitoring in tempo reale e gli avvisi esistenti restano pertanto necessari. Attualmente supporta soltanto i replica set, non gli sharded clusters, che distribuiscono i dati tra più gruppi di server. Le sue regole provengono da Big Hole e il repository documenta ciascuna di esse.