Monitoraggio e protezione di MongoDB con ClusterControl Advisors

La gestione delle operazioni del database consiste per l'80% nella lettura e nell'interpretazione dei sistemi di monitoraggio. Centinaia di metriche possono essere interpretate e combinate in vari modi per darti informazioni approfondite sui tuoi sistemi di database e su come ottimizzarli. Quando si eseguono più sistemi di database, il monitoraggio di questi sistemi può diventare piuttosto ingrato. Se l'interpretazione e la combinazione delle metriche richiedono molto tempo, non sarebbe fantastico se ciò potesse essere automatizzato in qualche modo?

Questo è il motivo per cui abbiamo creato consulenti di database in ClusterControl:piccoli script in grado di interpretare e combinare le metriche per te e darti consigli quando applicabile. Per MySQL abbiamo creato un'ampia libreria dei controlli di monitoraggio MySQL più comunemente utilizzati. Ma anche per MongoDB abbiamo un'ampia libreria di consulenti a tua disposizione. Per questo post sul blog, abbiamo selezionato per te i nove più importanti. Descriveremo ciascuno di essi in dettaglio.

I nove consulenti MongoDB di cui parleremo in questo post sul blog sono:

• Verifica delle opzioni di montaggio su disco
• Controllo numerico
• Percentuale di blocco raccolta (MMAP)
• Ritardo di replica
• Finestra di replica
• Raccolta e database non partizionati (solo cluster partizionati)
• Verifica autenticazione abilitata
• Controllo di integrità dell'autenticazione/autorizzazione
• Rilevamento degli errori (nuovo advisor)

Consulente per le opzioni di montaggio su disco

È molto importante che i tuoi dischi siano montati nel modo più ottimale. Con l'advisor delle opzioni di montaggio del disco di ClusterControl, esaminiamo più da vicino il tuo disco dati su base giornaliera. In questo advisor, esaminiamo il filesystem utilizzato, le opzioni di montaggio e le impostazioni dell'utilità di pianificazione io del sistema operativo.

Verifichiamo se i tuoi dischi sono stati montati con noatime e nodiratime. L'impostazione di questi ridurrà le prestazioni dei dischi, poiché ad ogni accesso a un file o una directory il tempo di accesso deve essere scritto su disco. Poiché ciò accade continuamente sui database, questa è una buona impostazione delle prestazioni e aumenta anche la durata dei tuoi SSD.

Per i file system consigliamo di utilizzare i moderni file system come xfs, zfs, ext4 o btrfs. Questi file system sono creati tenendo conto delle prestazioni. Si consiglia che lo scheduler io sia su noop o scadenza. Scadenza è stata l'impostazione predefinita per i database per anni, ma grazie a uno storage più veloce come gli SSD il noop scheduler ha più senso al giorno d'oggi.

Consulente per il controllo numerico

Per MongoDB abilitiamo il nostro NUMA consulente di controllo. Questo consulente verificherà se NUMA (Non-Uniform Access Memory) è stato abilitato sul tuo sistema e, in tal caso, per disattivarlo.

Quando la memoria ad accesso non uniforme è stata abilitata, la CPU del server è in grado di indirizzare solo la propria memoria direttamente e non le altre CPU della macchina. In questo modo la CPU è in grado di allocare memoria solo dal proprio spazio di memoria e l'allocazione di qualsiasi cosa in eccesso comporterà l'utilizzo dello scambio. Questa architettura offre un forte vantaggio in termini di prestazioni sulle applicazioni multiprocessore che allocano tutte le CPU, ma poiché MongoDB non è un'applicazione multiprocessore, diminuirà notevolmente le prestazioni e potrebbe portare a un enorme utilizzo di swap.

Percentuale di blocco raccolta (MMAP)

Come MMAP è un sistema di archiviazione basato su file, non supporta il blocco a livello di documento come si trova in WiredTiger e RocksDB. Invece il livello di blocco più basso per MMAP sono le serrature di raccolta. Ciò significa che qualsiasi scrittura su una raccolta (inserimento, aggiornamento o eliminazione) bloccherà l'intera raccolta. Se la percentuale di blocchi sta diventando troppo alta, ciò indica che hai problemi di contesa sulla raccolta. Se non affrontato correttamente, ciò potrebbe portare a una brusca interruzione del throughput di scrittura. Pertanto, avere un consulente che ti avverte in anticipo è molto utile.

Consulente del ritardo di replica MongoDB

Se stai ridimensionando MongoDB per le letture tramite i secondari, il ritardo di replica è molto importante da tenere d'occhio. I driver client MongoDB utilizzeranno solo secondari che non sono troppo indietro, altrimenti potresti rischiare di fornire dati non aggiornati.

All'interno di MongoDB il primario terrà traccia dello stato di replica dei suoi secondari. L'advisor recupererà le informazioni sulla replica e proteggerà il ritardo di replica. Se il ritardo diventa troppo alto, verrà inviato un avviso o un messaggio di stato critico.

Consulente finestra di replica MongoDB

Accanto al ritardo di replica, la finestra di replica è una metrica importante da tenere d'occhio. L'oplog MongoDB è una singola raccolta, che è stata limitata in una dimensione (preimpostata). Una volta che l'oplog raggiunge la fine e una nuova transazione deve essere archiviata, eliminerà la transazione più vecchia per fare spazio alla nuova transazione. La finestra di replica riflette il numero di secondi tra la transazione più vecchia e quella più recente nell'oplog.

Questa metrica è molto importante in quanto è necessario sapere per quanto tempo è possibile rimuovere un secondario da replicaSet, prima che non sia più in grado di recuperare il ritardo con il master a causa del ritardo nella replica. Inoltre, se un secondario inizia a rimanere indietro, sarebbe utile sapere per quanto tempo possiamo tollerarlo prima che il secondario non sia più in grado di recuperare.

Nella shell MongoDB è disponibile una funzione per calcolare la finestra di replica. Questo advisor in ClusterControl utilizza la funzione per eseguire lo stesso calcolo. Il vantaggio sarebbe che ora puoi essere avvisato su una finestra di replica troppo breve.

Consulente per raccolte e database non partizionati MongoDB

In un cluster MongoDB con partizionamento orizzontale, tutti i database e le raccolte non partizionati vengono assegnati a uno shard primario predefinito dal router shard MongoDB. Questo shard primario può variare tra i database e le raccolte, ma in generale sarebbe lo shard con la maggior parte dello spazio disponibile su disco.

Avere un database o una raccolta non partizionati non rappresenta immediatamente un rischio per il tuo cluster. Tuttavia, se un'applicazione o un utente inizia a scrivere grandi volumi di dati su uno di questi, lo shard primario potrebbe riempirsi rapidamente e creare un'interruzione su questo shard. Poiché il database o la raccolta non sono partizionati, non sarà in grado di utilizzare altri frammenti.

Per questo motivo abbiamo creato un consulente che impedirà che ciò accada. L'advisor eseguirà la scansione di tutti i database e le raccolte e ti avviserà se non è stato suddiviso in partizioni.

Verifica autenticazione abilitata

Senza abilitare l'autenticazione in MongoDB, qualsiasi utente che accede verrà trattato come un amministratore. Questo è un rischio serio poiché le normali attività di amministrazione, come la creazione di utenti o l'esecuzione di backup, ora sono diventate disponibili per chiunque. Questo, combinato con i server MongoDB esposti, ha portato ai recenti hack di riscatto MongoDB, mentre una semplice abilitazione dell'autenticazione avrebbe impedito la maggior parte di questi casi.

Abbiamo implementato un advisor che verifica se i tuoi server MongoDB hanno l'autenticazione abilitata. Questo può essere fatto in modo esplicito impostandolo nella configurazione o in modo implicito abilitando il file di chiavi di replica. Se questo advisor non riesce a rilevare che l'autenticazione è stata abilitata, dovresti agire immediatamente in base a ciò, poiché il tuo server è vulnerabile a essere compromesso.

Controllo di integrità dell'autenticazione/autorizzazione

Oltre all'advisor abilitato all'autenticazione, abbiamo anche creato un advisor che esegue un controllo di integrità sia per l'autenticazione che per l'autorizzazione in MongoDB.

In MongoDB l'autenticazione e l'autorizzazione non sono collocate in una posizione centrale, ma vengono eseguite e archiviate a livello di database. Normalmente gli utenti si connettono al database, autenticandosi rispetto al database che intendono utilizzare. Tuttavia, con le assegnazioni corrette, è anche possibile eseguire l'autenticazione rispetto ad altri database (non correlati) e continuare a utilizzare un altro database. Normalmente questo va benissimo, a meno che un utente non abbia diritti eccessivi (come il ruolo di amministratore) su un altro database.

In questo advisor, verifichiamo se questi ruoli eccessivi sono presenti e se possono rappresentare una minaccia. Controlliamo anche password deboli e facili da indovinare.

Rilevamento errori (nuovo consulente)

In MongoDB, qualsiasi errore riscontrato verrà conteggiato o registrato. All'interno di MongoDB c'è una grande varietà di possibili errori:asserzioni dell'utente, asserzioni regolari, avvisi e persino eccezioni interne del server. Se sono presenti tendenze in questi errori, è probabile che si tratti di un'errata configurazione o di un problema dell'applicazione.

Questo consulente esaminerà le statistiche degli errori di MongoDB (asserzioni) e ne darà un senso. Interpretiamo le tendenze trovate e consigli su come ridurre gli errori nel tuo ambiente MongoDB!