Banche dati
    Aggiornato il maggio 2026
    MongoDB logo

    MongoDB Monitoraggio

    Monitora in tempo reale le operazioni sui documenti MongoDB, lo stato dei replica set, le connessioni e le metriche di archiviazione senza alcuna configurazione.

    Perché monitorare MongoDB?

    MongoDB è il principale database documentale NoSQL, che supporta le applicazioni moderne grazie a schemi flessibili e scalabilità orizzontale. Il monitoraggio di MongoDB è fondamentale per tenere traccia delle prestazioni delle query, rilevare i ritardi di replica, gestire i pool di connessioni e prevenire l'esaurimento dello spazio di archiviazione. L'integrazione di MongoDB offerta da Xitoring garantisce una visibilità approfondita sullo stato di salute del cluster di database.

    Rilevamento automatico tramite Xitogent — nessuna configurazione manuale richiesta
    Metriche delle operazioni sui documenti in tempo reale (insert, update, delete, query)
    Monitoraggio dello stato dei replica set e del lag di replica
    Monitoraggio dell'utilizzo del pool di connessioni e delle connessioni attive
    Metriche di utilizzo della cache WiredTiger e di eviction
    Monitoraggio della dimensione dello storage e delle prestazioni degli indici
    Funziona sia su server Linux che Windows
    Intervalli di raccolta metriche di 1 minuto
    Cos'è il monitoraggio di MongoDB?

    Monitoraggio di MongoDB, spiegato

    Il monitoraggio di MongoDB intercetta lag di replicazione, collasso della finestra oplog, pressione sulla cache WiredTiger e query fuori controllo prima che causino failure delle replica, tempeste di fallback sui secondari o rallentamenti visibili agli utenti. Per stack MEAN/MERN, cluster sharded e qualsiasi deployment di replica-set, la visibilità per nodo è ciò che separa un failover graceful da un incidente di diverse ore. Xitoring rileva automaticamente MongoDB, interroga i comandi nativi server-status con il ruolo clusterMonitor e instrada le allerte su Slack, PagerDuty, Telegram o sul Suo sistema di on-call esistente.

    Indicatori

    Ciò che monitoriamo

    Operazioni sui documenti

    Tasso di operazioni insert, update, delete e query al secondo.

    Connessioni

    Connessioni attive, disponibili e totali correnti verso l'istanza MongoDB.

    Lag della replica

    Ritardo tra il membro primary e i membri secondary del replica set.

    Finestra Oplog

    Durata delle operazioni mantenute nell'oplog per la replica.

    Cache WiredTiger

    Byte attualmente in cache, byte dirty e rapporto di hit della cache.

    Page Fault

    Numero di page fault che indicano dati non in memoria.

    Cursori

    Numero di cursori aperti inclusi quelli senza timeout.

    I/O di rete

    Byte in entrata/uscita e numero di richieste verso l'istanza MongoDB.

    Coda di lock

    Numero di operazioni in attesa di acquisire lock di lettura o scrittura.

    Contatori indici

    Accessi, hit e miss degli indici che indicano l'efficacia degli indici.

    Dimensione dello storage

    Dimensione totale dei dati, dimensione degli indici e spazio libero su disco.

    Assertion

    Conteggio dei messaggi di assert inclusi regular, warning e rollover.

    Notifiche e avvisi

    Configurabile condizioni di attivazione

    Imposta dei trigger personalizzati nella tua dashboard per ricevere una notifica non appena le metriche dell{name}e superano le soglie da te definite.

    MongoDB pannello di controllo per la configurazione dei trigger di monitoraggio

    Lag della replica

    critico

    Si attiva quando i membri secondary restano indietro rispetto al primary, rischiando incoerenza dei dati durante il failover.

    Numero di connessioni

    avviso

    Si attiva quando le connessioni attive si avvicinano al massimo, indicando potenziale esaurimento del pool di connessioni.

    Utilizzo cache WiredTiger

    avviso

    Avvisa quando l'utilizzo della cache supera la soglia, causando maggior I/O disco e query più lente.

    Page Fault

    critico

    Si attiva quando il tasso di page fault sale rapidamente, indicando che il working set supera la memoria disponibile.

    Lunghezza della coda di lock

    avviso

    Si attiva quando le operazioni si accodano in attesa di lock, indicando contesa e potenziale degrado delle prestazioni.

    Spazio di storage

    critico

    Avvisa quando l'utilizzo dello spazio disco supera la soglia, rischiando il blocco delle scritture sul database.

    01

    Importanza del monitoraggio MongoDB

    MongoDB alimenta applicazioni mission-critical che gestiscono milioni di documenti. Senza monitoraggio, drift di replica, esaurimento delle connessioni e pressione sulla cache possono degradare silenziosamente le prestazioni e portare a perdita di dati.

    • Rileva il lag di replica prima che il failover causi incoerenza dei dati
    • Monitora i tassi di operazioni sui documenti per identificare colli di bottiglia di prestazioni
    • Tieni traccia dell'efficienza della cache WiredTiger per ottimizzare l'allocazione della memoria
    • Identifica l'esaurimento del pool di connessioni dai client applicativi
    • Garantisci la capacità di storage per operazioni di database ininterrotte
    Dashboard di monitoraggio MongoDB con operazioni sui documenti e metriche di replica set
    Avvisi di prestazioni MongoDB e monitoraggio delle connessioni
    02

    Perché scegliere Xitoring

    Xitoring offre un monitoraggio MongoDB di livello enterprise con configurazione zero-config. Il nostro agente leggero rileva automaticamente le tue istanze MongoDB, inizia a raccogliere metriche in meno di 60 secondi e si integra con i tuoi canali di notifica esistenti.

    • Installazione con un solo comando — niente YAML o file di configurazione complessi
    • Oltre 15 nodi di monitoraggio globali per controlli a bassa latenza
    • Dashboard unificata per server, database e uptime
    • Alerting flessibile tramite Slack, PagerDuty, Telegram e altri
    • Conservazione dei dati storici per pianificazione della capacità e audit
    Panoramica del monitoraggio del cluster MongoDB con Xitoring
    Configurazione dei canali di notifica delle allerte
    Casi d'uso

    Scenari comuni di monitoraggio MongoDB

    Dove MongoDB viene tipicamente eseguito oggi — e cosa potrebbe andare storto se nessuno lo monitora.

    Database self-hosted con copie di backup

    Le configurazioni di produzione eseguono diverse copie del database in modo che un guasto non possa bloccare l'applicazione. Quando una copia rimane silenziosamente indietro rispetto alle altre, la rete di sicurezza è più debole di quanto sembri. Cogliamo subito il problema in modo che il failover faccia ciò che deve: rimanere invisibile agli utenti.

    Database distribuiti su più server

    Quando i dati sono troppo grandi per un singolo server, vengono distribuiti su molti — ma se alcuni server finiscono per fare più lavoro di altri, l'intera applicazione rallenta. Rileviamo lo squilibrio in modo che il team possa ribilanciare il carico prima che un server sovraccarico diventi un problema per i clienti.

    Il database dietro un'app Node.js

    La maggior parte delle app Node.js sottopone MongoDB a un carico elevato e riutilizza un pool di connessioni al database per rimanere veloce. Quando l'app perde connessioni o esegue una query inefficiente, ogni richiesta rallenta. Rileviamo rapidamente la causa in modo che il team giusto possa risolverla.

    Prima di iniziare

    Prerequisiti per MongoDB

    Assicurati di avere tutto questo in posizione — la maggior parte delle installazioni dura 60 secondi una volta soddisfatte le condizioni.

    • MongoDB 4.x o successivo in esecuzione sul server
    • Un utente con il ruolo clusterMonitor (o readAnyDatabase nelle versioni legacy)
    • Raggiungibilità di rete da Xitogent verso l'istanza MongoDB
    Guida all'installazione

    Inizia con verbali

    1

    Installa Xitogent sul tuo server

    Se non l'hai già fatto, installa il leggero agente di monitoraggio Xitogent sul tuo server.

    curl -s https://xitoring.com/install.sh | sudo bash -s -- --key=YOUR_API_KEY
    2

    Crea un utente di monitoraggio in MongoDB

    Crea un utente MongoDB dedicato con il ruolo `clusterMonitor` in modo che Xitogent possa leggere serverStatus, stato della replicazione e metriche di archiviazione:

    use admin db.createUser({ user: "xitogent", pwd: "xitogent!", roles: [{ role: "clusterMonitor", db: "admin" }] })
    3

    Abilita l'integrazione MongoDB

    Usa la dashboard di Xitoring o la CLI per abilitare l'integrazione MongoDB. Xitogent rileverà automaticamente la tua istanza MongoDB.

    sudo xitogent integrate
    4

    Configura le soglie di allerta (opzionale)

    Imposta soglie personalizzate per metriche come Replication Lag, numero di connessioni o uso dell'archiviazione per essere avvisato quando qualcosa richiede attenzione.

    5

    Verifica che funzioni

    Esegui questo comando sul server per confermare che Xitogent ha rilevato l'integrazione. In circa 30 secondi nuove metriche cominceranno a comparire sulla tua dashboard.

    sudo xitogent status

    Spesso domande poste

    L'integrazione con MongoDB richiede l'autenticazione?
    Se la tua istanza MongoDB utilizza l'autenticazione, puoi configurare le credenziali nelle impostazioni di integrazione. Xitogent supporta entrambi i metodi di autenticazione SCRAM e x.509.
    Questa integrazione influirà sulle prestazioni di MongoDB?
    No. Xitogent utilizza il comando serverStatus, che è leggero e ha un impatto trascurabile sulle prestazioni. Si tratta dello stesso comando utilizzato dagli strumenti di monitoraggio di MongoDB.
    Posso monitorare MongoDB Atlas?
    Xitogent monitora le istanze MongoDB gestite in proprio. Per MongoDB Atlas, è possibile utilizzare il monitoraggio dell'uptime di Xitoring per tenere traccia della disponibilità degli endpoint e dei tempi di risposta.
    È possibile monitorare i cluster con sharding?
    Sì. Installa Xitogent su ogni mongos e su ogni membro dello shard per ottenere una visibilità completa del cluster su tutti i componenti.
    Quali versioni di MongoDB sono supportate?
    Xitoring supporta MongoDB 4.0 e versioni successive, comprese le ultime versioni di MongoDB 7.x.
    Con quale frequenza vengono raccolti i dati?
    Per impostazione predefinita, i dati vengono raccolti a intervalli di 1 minuto. È possibile modificare questa impostazione tramite la dashboard di Xitoring o la CLI.
    A cosa serve mongostat?
    `mongostat` è la CLI ufficiale di MongoDB per statistiche operative in tempo reale (simile a `iostat` per i dischi). Mostra in un unico output rotante i tassi di opcounter al secondo, l'I/O di rete, le connessioni, le code e la percentuale di dirty cache attiva. Xitogent espone le stesse metriche con trend di lungo periodo e allerte — `mongostat` serve per il triage live; Xitoring per cronologia, dashboard e notifiche.
    Come si monitora MongoDB Atlas rispetto al self-hosted?
    Per il self-hosted, Xitogent gira accanto a MongoDB e legge direttamente `serverStatus`. Per Atlas, è Atlas stesso a fornire Real-Time Performance Panel, Query Profiler e allerte integrate tramite l'Atlas Admin UI — Xitoring copre il lato rete ed endpoint (uptime, tempo di risposta, sonde regionali) per integrare le metriche interne al database di Atlas.
    Quali versioni di MongoDB sono supportate?
    MongoDB 7.0 LTS e 8.0 LTS (default attuale) sono pienamente supportate, oltre alle versioni 4.x/5.x/6.x più datate. La versione 8.0 ha aggiunto `optimeWritten` per lo stato di replicazione con write-acknowledge, le range query con queryable encryption, `bulkWrite` su più collection e il block processing per le time-series — Xitogent espone le nuove metriche quando presenti e degrada in modo graceful sulle versioni meno recenti.

    Inizia a monitorare MongoDB oggi

    Configurazione in meno di 60 secondi. Non è richiesta alcuna carta di credito. Statistiche complete fin dal primo giorno.

    Inizia la prova gratuita

    Continua a esplorare

    Correlati Integrazioni