Come monitorare le prestazioni del database MongoDB

Rick Golba è ingegnere delle soluzioni presso Percona.

MongoDB è un database preferito dagli sviluppatori. Come opzione di database NoSQL, fornisce agli sviluppatori un ambiente di database che ha una progettazione dello schema flessibile, failover automatizzato e un linguaggio di input familiare agli sviluppatori, ovvero JSON.

Esistono molti tipi diversi di database NoSQL. Gli archivi chiave-valore archiviano e recuperano ogni elemento utilizzando il suo nome (noto anche come chiave). Gli archivi di colonne larghe sono una sorta di archivio di valori-chiave che utilizza colonne e righe (in modo molto simile a un database relazionale), solo i nomi delle colonne e delle righe in una tabella possono variare. I database a grafo utilizzano strutture a grafo per memorizzare reti di dati. I database orientati ai documenti archiviano i dati come documenti, fornendo una maggiore flessibilità strutturale rispetto ad altri database.

MongoDB è un database orientato ai documenti. È un database multipiattaforma che contiene i dati nei documenti in un formato JSON con codifica binaria (noto come JSON binario o BSON). Il formato binario aumenta sia la velocità che la flessibilità di JSON e aggiunge più tipi di dati.

I meccanismi di replica di MongoDB aiutano a fornire un'elevata disponibilità e il suo meccanismo di partizionamento orizzontale consente la scalabilità orizzontale. Molte delle principali società Internet come Facebook e eBay utilizzano MongoDB nel loro ambiente di database.

Perché monitorare MongoDB?

Il tuo ambiente di database MongoDB può essere semplice o complicato, locale o distribuito, in locale o nel cloud. Se si desidera garantire un database efficiente e disponibile, è necessario monitorare e monitorare le analisi al fine di:

  • Determina lo stato corrente del database
  • Rivedere i dati sulle prestazioni per identificare eventuali comportamenti anomali
  • Fornire alcuni dati diagnostici per risolvere i problemi identificati
  • Risolvi i piccoli problemi prima che si trasformino in problemi più grandi
  • Mantieni il tuo ambiente attivo e funzionante
  • Garantire disponibilità e successo continui

Il monitoraggio dell'ambiente del database in modo misurabile e regolare garantisce la possibilità di individuare eventuali discrepanze, comportamenti strani o problemi prima che influiscano sulle prestazioni. Un monitoraggio adeguato significa che è possibile individuare rapidamente rallentamenti, limitazioni delle risorse o altri comportamenti anomali e agire per risolvere questi problemi prima di subire le conseguenze di siti Web e applicazioni lenti, dati non disponibili o clienti frustrati.

Cosa dovremmo monitorare?

Ci sono molte cose che puoi monitorare in un ambiente MongoDB, ma alcune aree chiave ti avviseranno rapidamente se qualcosa non va. Dovresti analizzare le seguenti metriche:

  • Ritardo di replica . Il ritardo di replica si riferisce ai ritardi nella copia dei dati dal nodo primario a un nodo secondario.
  • Stato della replica . Lo stato della replica è un metodo per tenere traccia se i nodi secondari sono morti e se c'è stata l'elezione di un nuovo nodo primario.
  • Stato di blocco . Lo stato di blocco mostra quali blocchi di dati sono stati impostati e per quanto tempo sono stati in vigore.
  • Utilizzo del disco . L'utilizzo del disco si riferisce all'accesso al disco.
  • Utilizzo della memoria . L'utilizzo della memoria si riferisce alla quantità di memoria utilizzata e al modo in cui viene utilizzata.
  • Numero di connessioni . Il numero di connessioni che il database ha aperto per servire le richieste il più rapidamente possibile.

Approfondiamo alcuni dettagli.

Ritardo di replica

MongoDB utilizza la replica per soddisfare le sfide e gli obiettivi di disponibilità. La replica è la propagazione dei dati da un nodo primario a più nodi secondari, poiché le operazioni sul nodo primario modificano i dati. Questi nodi possono essere collocati insieme, in diverse posizioni geografiche o virtuali.

A parità di condizioni, la replica dei dati dovrebbe avvenire rapidamente e senza problemi. Possono accadere molte cose che impediscono il corretto funzionamento del processo di replica. Anche nelle migliori condizioni, le proprietà fisiche della rete limitano la velocità con cui i dati vengono replicati. Il ritardo tra l'avvio e il completamento della replica viene definito ritardo di replica.

In un insieme fluido di nodi primari e secondari (denominato "set di repliche"), i secondari copiano rapidamente le modifiche sul primario, replicando ogni gruppo di operazioni dall'oplog il più velocemente possibile (o il più vicino possibile) . L'obiettivo è mantenere il ritardo di replica vicino allo zero. Le letture dei dati da qualsiasi nodo dovrebbero essere coerenti. Se il nodo primario scelto si interrompe o diventa altrimenti non disponibile, un nodo secondario può assumere il ruolo principale senza influire sulla precisione dei dati per i client. I dati replicati devono essere coerenti con i dati primari prima che il primario si interrompesse.

Il ritardo di replica è il motivo per cui i nodi primari e secondari non sono sincronizzati. Se un nodo secondario viene scelto come primario e il ritardo di replica è elevato, la versione dei dati del secondario potrebbe non essere aggiornata. Uno stato di ritardo di replica elevato può verificarsi per diversi motivi non permanenti o indefiniti e correggersi. Tuttavia, se il ritardo di replica rimane elevato o inizia ad aumentare a una velocità regolare, questo è un segno di un problema sistemico o ambientale. In entrambi i casi, maggiore è il ritardo di replica, e più a lungo rimane alto, più i tuoi dati rischiano di non essere aggiornati per i client.

C'è solo un modo per analizzare questa metrica: monitorarla! Si tratta di una metrica che dovrebbe essere monitorata 24 ore su 24, 7 giorni su 7, 365 giorni l'anno, quindi è meglio utilizzare l'automazione e attivare avvisi per avvisare gli amministratori di database o gli amministratori di sistema di risposta non appena raggiunge una soglia indesiderata. La configurazione per questa soglia dipende dalla tolleranza dell'applicazione per il ritardo di replica. Per determinare la soglia corretta, utilizza uno strumento che rappresenti graficamente il ritardo nel tempo come Compass, MongoBooster, Studio 3T o Percona Monitoring and Management (PMM).

Stato della replica

La replica viene gestita tramite set di repliche. Un set di repliche è un insieme di nodi con un nodo primario eletto e diversi nodi secondari. Il nodo primario è il custode dei dati più aggiornati e tali dati vengono replicati sui secondari man mano che vengono apportate modifiche al primario.

Normalmente, un membro di un set di repliche è primario e tutti gli altri membri sono secondari. Lo stato assegnato cambia raramente. Se lo fa, vogliamo saperlo (di solito immediatamente). Il cambio di ruolo di solito avviene rapidamente e di solito senza interruzioni, ma è importante capire esattamente perché lo stato del nodo è cambiato, poiché potrebbe essere stato a causa di un errore hardware o di rete. Il passaggio dallo stato primario a quello secondario (noto anche come sbattimento) non è un evento normale e in un mondo perfetto dovrebbe avvenire solo per ragioni note (ad esempio, durante la manutenzione ambientale come l'aggiornamento del software o dell'hardware, o durante un incidente specifico come come interruzione di rete).

Stato di blocco

I database sono ambienti altamente concorrenti e volatili, con più client che effettuano richieste e avviano transazioni che vengono eseguite sui dati. Queste richieste e transazioni non avvengono in sequenza o in un ordine razionale. Possono verificarsi conflitti, ad esempio se le transazioni tentano di aggiornare lo stesso record o documento, se durante l'aggiornamento dei dati arriva una richiesta di lettura, ecc. " Il blocco si verifica quando una transazione impedisce che un record del database, un documento, una riga, una tabella e così via venga alterato o letto fino al termine dell'elaborazione della transazione corrente.

In MongoDB, il blocco viene eseguito a livello di raccolta o documento per evitare conflitti tra transazioni simultanee. Alcune operazioni possono anche richiedere un blocco del database globale (ad esempio, quando si rilascia una raccolta). Se il blocco si verifica troppo spesso, influisce sulle prestazioni facendo in modo che le transazioni (comprese le letture) attendono che le parti bloccate del database siano disponibili per la lettura o la modifica. Un'alta percentuale di blocco è un segno di altri problemi nel database: errore hardware, progettazione dello schema errata, indici configurati in modo errato, mancato utilizzo degli indici, ecc.

È importante monitorare la percentuale di blocco. È necessario sapere qual è una percentuale accettabile in relazione alle prestazioni e per quanto tempo la percentuale può essere mantenuta prima di influire sulle prestazioni. Se le prestazioni si degradano eccessivamente a causa di un'elevata percentuale di blocco, è possibile che si attivi un cambio di stato replicato tramite la mancata risposta del server.

Utilizzo del disco

Ogni DBA dovrebbe monitorare lo spazio disponibile su disco sui propri server di database. Quando un database utilizza lo spazio su disco sull'host, il server si arresta improvvisamente. Il dimensionamento proattivo dei dati e il monitoraggio delle dimensioni dei file di registro sono ottime tecniche per il dimensionamento del database.

Spesso il database potrebbe dover crescere automaticamente. In questi casi, è necessario garantire che non diventi troppo grande per l'hardware. La revisione periodica dello spazio su disco può aiutare a prevenire arresti imprevisti del server di database, nonché a individuare problemi di progettazione scadenti (come le query che richiedono una scansione completa della raccolta).

Utilizzo della memoria

Mantenere tutti i dati nella RAM accelera i tempi di risposta del database. Ma cosa significa e come fai a sapere quando c'è qualcosa nella RAM?

Il modo in cui il database utilizza la memoria può essere alquanto poco chiaro. Gran parte della memoria utilizzata da un server è per il pool di buffer (dati). Può essere difficile scoprire quale database utilizza la porzione più grande della memoria del pool di buffer e ancora più difficile scoprire quali raccolte o documenti si trovano effettivamente nella memoria del pool di buffer. Conoscere queste informazioni è utile quando si bilancia il carico del database su più server (tramite partizionamento orizzontale) o si identificano i dati ottimali per il consolidamento in un'istanza del server.

L'utilizzo di strumenti per determinare quali istanze utilizzano maggiormente la memoria e per quali dati può aiutarti a ottimizzare il tuo ambiente.

Numero di connessioni

Le transazioni di database vengono solitamente avviate da applicazioni e processi tramite "connessioni". Il numero di connessioni aperte può influire sulle prestazioni del database. In teoria, una volta completata una transazione, la connessione dovrebbe essere terminata. In pratica, tuttavia, molte delle connessioni rimangono aperte. È normale che un database mantenga attive alcune connessioni per facilitare determinate transazioni, ma se ne vengono lasciate troppe aperte può limitare il numero disponibile nel pool di connessioni.

Come best practice, un database dovrebbe mantenere le connessioni aperte per il minor tempo necessario per completare una richiesta. Ciò consente a un piccolo pool di connessioni di soddisfare un numero enorme di richieste di transazione. In caso contrario, le richieste di transazione dell'applicazione rimarranno bloccate in attesa di una connessione aperta. È necessario monitorare il numero di connessioni aperte nel database per verificare che vengano chiuse e che nel pool sia rimasto un numero integro di connessioni per le richieste in arrivo.

Strumenti forniti con MongoDB

Ora che sappiamo cosa dovremmo monitorare, la prossima domanda è: come? Fortunatamente, MongoDB viene fornito con alcuni strumenti facili da usare per il monitoraggio delle statistiche del server.

mongostat

Questa utilità fornisce statistiche globali sull'utilizzo della memoria, lo stato del set di repliche e altro, aggiornate ogni secondo (per impostazione predefinita).

L' mongostatutilità offre una panoramica dell'istanza del server MongoDB. Se stai eseguendo una singola istanza "mongod", ti vengono mostrate le statistiche per quella singola istanza. Se stai eseguendo un ambiente cluster MongoDB, restituisce le statistiche per l'istanza "mongos". mongostatè utilizzato al meglio per guardare una singola istanza per un evento specifico (ad esempio, cosa succede quando arriva una richiesta di applicazione specifica). È possibile utilizzare questo comando per monitorare le statistiche di base del server:

  • processore
  • Memoria
  • Disco IO
  • Traffico di rete

Consulta la documentazione di MongoDB su mongostatper le specifiche sull'utilizzo.

mongotop

Questa utility fornisce statistiche a livello di raccolta sull'attività di lettura e scrittura.

Il mongotopcomando tiene traccia del tempo necessario per completare le operazioni di lettura e scrittura su un'istanza del server MongoDB. Fornisce statistiche a livello di raccolta. mongotoprestituisce valori ogni secondo per impostazione predefinita, ma è possibile regolare l'intervallo di tempo in base alle esigenze.

Tutte le metriche al secondo sono relative alla configurazione del server e all'architettura del cluster. Per istanze singole eseguite localmente e utilizzando la porta predefinita, tutto ciò che devi fare è immettere il mongotopcomando. Se si esegue in un ambiente cluster con più istanze di mongod e mongos, sarà necessario fornire un nome host e un numero di porta con il comando.

Consulta la documentazione di MongoDB su mongotopper le specifiche sull'utilizzo.

rs.status()

Questo comando fornisce lo stato del set di repliche.

È possibile utilizzare il rs.status()comando per ottenere informazioni su un set di repliche in esecuzione. Questo comando può essere eseguito dalla console di qualsiasi membro di qualsiasi set e restituirà lo stato del set di repliche come visto dal membro in questione.

Consulta la documentazione di MongoDB su rs.status()per le specifiche sull'utilizzo.