Quando si verifica un problema in un’istanza di MongoDB, il file di log può rivelarsi una risorsa fondamentale per risolvere il problema. Questo potrebbe sembrare ovvio, ma c’è di più. In MongoDB, per impostazione predefinita, ogni query che impiega più di 100 ms viene registrata nel file di log (con il parametro slowms). Queste query vengono registrate con un livello di gravità “I” (informativo) e sono generalmente accompagnate dal messaggio “Slow query”.
In questo articolo, esploreremo l’importanza di monitorare e analizzare questi log per garantire il corretto funzionamento del tuo database.
Analisi dei log Scripting innovative
Dalla versione 4.4, MongoDB ha introdotto una novità significativa: tutto l’output dei log è ora scritto in formato JSON.
Questa modifica semplifica notevolmente l’analisi dei log, poiché rende più facile elaborare ogni riga come un oggetto strutturato, anziché come semplice testo (che potrebbe essere troncato o difficile da manipolare).
Un SORINTiano ha creato uno script che legge ogni riga di un gruppo specifico di file di log, converte i dati (in formato JSON) in oggetti, maschera i dati sensibili (ad esempio, applicando un filtro su una query find), e raggruppa le istruzioni simili per namespace, operazione, modello di query e piano di esecuzione. In questo modo, il team ha accesso a informazioni dettagliate sulle operazioni più gravose in termini di prestazioni e può agire di conseguenza per ottimizzare le query più problematiche.
Questo approccio ci permette di ottenere un riepilogo delle query più lente, consentendo di concentrarsi su quelle che hanno un impatto maggiore sulle prestazioni dell’istanza. In particolare, lo script gestisce vari comandi come find, getMore, aggregate, count, distinct, insert, update, findAndModify, remove e createIndexes. Ad esempio, per il comando find, il componente (indicato come “c”) è identificato come COMMAND, l’attributo type è impostato su command, e all’interno di attr.command è presente il tasto “find”.
Da qui, è possibile estrarre dettagli importanti, come:
- namespace: value of the “att.command.find”,
- filter: value of “attr.command.filter”. The filter was masked, and named as “query pattern”.
- sort: value of “attr.command.sort”
- limit: value of “attr.command.limit”
- Execution plan: value of “attr.command.planSummary”
- execution statistics: “attr.command.keysExamined”, “attr.command.docsExamined” and “attr.command.nRetuned”
- execution time: “attr.command.durationMillis”
Per l’istruzione “find”, possiamo monitorare una vasta gamma di comandi rilevanti e sviluppare script personalizzati per soddisfare esigenze specifiche. Un aspetto interessante è che, nel registro, possiamo anche ottenere informazioni dettagliate sullo storage, come i tempi di lettura e scrittura dei dati, nonché i tempi di attesa associati a ciascuna istruzione. Questo ci consente di avere una visione completa delle operazioni e di ottimizzare ulteriormente le performance del sistema.
Gli script di Ken Chen, noti come “keyhole”, sono strumenti utili per l’analisi delle prestazioni che consentono di valutare le performance del cluster MongoDB. Sebbene questi strumenti siano popolari per guidare lo sviluppo, è importante sapere che tutte le informazioni necessarie sono già disponibili nel registro. Inoltre, è possibile abilitare il profiler per esaminare le query lente. I dati registrati nella raccolta “system.profile” seguono un formato simile a quello del file dei messaggi di log, il che significa che, con un paio di parametri, è possibile creare uno script unico per raccogliere e analizzare tutte le informazioni necessarie.
Avere un riepilogo delle istruzioni “che richiedono molto tempo” è fondamentale per un’analisi delle prestazioni efficace. Il vero valore di implementare un controllo periodico del file dei messaggi di registro risiede nella possibilità di agire in modo proattivo, identificando e risolvendo potenziali problemi prima che diventino critici. Questo approccio diventa ancora più cruciale quando si gestiscono organizzazioni con migliaia di istanze. In questi casi, può davvero fare la differenza e trasformare il modo in cui si affrontano le sfide legate alle prestazioni.
Crediti
Danilo Pala – Esperto DB