#MongoDB

Plugin: go.d.plugin Module: mongodb

#Overview

This collector monitors MongoDB servers.

Executed queries:

• serverStatus
• dbStats
• replSetGetStatus

This collector is supported on all platforms.

This collector supports collecting metrics from multiple instances of this integration, including remote instances.

#Default Behavior

#Auto-Detection

This integration doesn't support auto-detection.

#Limits

The default configuration for this integration does not impose any limits on data collection.

#Performance Impact

The default configuration for this integration is not expected to impose a significant performance impact on the system.

#Setup

You can configure the mongodb collector in two ways:

Method	Best for	How to
UI	Fast setup without editing files	Go to Nodes → Configure this node → Collectors → Jobs, search for mongodb, then click + to add a job.
File	If you prefer configuring via file, or need to automate deployments (e.g., with Ansible)	Edit go.d/mongodb.conf and add a job.

:::important

UI configuration requires paid Netdata Cloud plan.

:::

#Prerequisites

#Create a read-only user

Create a read-only user for Netdata in the admin database.

• Authenticate as the admin user:

  use admin
  db.auth("admin", "<MONGODB_ADMIN_PASSWORD>")

• Create a user:

  db.createUser({
  "user":"netdata",
  "pwd": "<UNIQUE_PASSWORD>",
  "roles" : [
  {role: 'read', db: 'admin' },
  {role: 'clusterMonitor', db: 'admin'},
  {role: 'read', db: 'local' }
  ]
  })

#Configuration

#Options

The following options can be defined globally: update_every, autodetection_retry.

Config options

| Group | Option | Description | Default | Required | |:------|:-----|:------------|:--------|:---------:| | **Collection** | update_every | Data collection interval (seconds). | 5 | no | | | autodetection_retry | Autodetection retry interval (seconds). Set 0 to disable. | 0 | no | | **Target** | uri | MongoDB connection string. See [URI syntax](https://www.mongodb.com/docs/manual/reference/connection-string/). | mongodb://localhost:27017 | yes | | | timeout | Query timeout (seconds). | 1 | no | | **Filters** | databases | Database selector. Defines which databases to collect metrics from. | | no | | **Functions** | functions.top_queries.disabled | Disable the [top-queries](#top-queries) function. | no | no | | | functions.top_queries.timeout | Query timeout (seconds). Uses collector timeout if not set. | | no | | | functions.top_queries.limit | Maximum number of queries to return. | 500 | no | | **Virtual Node** | vnode | Associates this data collection job with a [Virtual Node](https://learn.netdata.cloud/docs/netdata-agent/configuration/organize-systems-metrics-and-alerts#virtual-nodes). | | no |

#via UI

Configure the mongodb collector from the Netdata web interface:

1. Go to Nodes.
2. Select the node where you want the mongodb data-collection job to run and click the :gear: (Configure this node). That node will run the data collection.
3. The Collectors → Jobs view opens by default.
4. In the Search box, type mongodb (or scroll the list) to locate the mongodb collector.
5. Click the + next to the mongodb collector to add a new job.
6. Fill in the job fields, then click Test to verify the configuration and Submit to save.
   • Test runs the job with the provided settings and shows whether data can be collected.
   • If it fails, an error message appears with details (for example, connection refused, timeout, or command execution errors), so you can adjust and retest.

#via File

The configuration file name for this integration is go.d/mongodb.conf.

The file format is YAML. Generally, the structure is:

update_every: 1
autodetection_retry: 0
jobs:
  - name: some_name1
  - name: some_name2

You can edit the configuration file using the edit-config script from the Netdata config directory.

cd /etc/netdata 2>/dev/null || cd /opt/netdata/etc/netdata
sudo ./edit-config go.d/mongodb.conf

#Examples

#TCP socket

An example configuration.

Config

```yaml jobs: - name: local uri: mongodb://netdata:password@localhost:27017 ```

#With databases metrics

An example configuration.

Config

```yaml jobs: - name: local uri: mongodb://netdata:password@localhost:27017 databases: includes: - "* *" ```

#Multi-instance

Note: When you define multiple jobs, their names must be unique.

Local and remote instances.

Config

```yaml jobs: - name: local uri: mongodb://netdata:password@localhost:27017 - name: remote uri: mongodb://netdata:password@203.0.113.0:27017 ```

#Alerts

There are no alerts configured by default for this integration.

#Metrics

Metrics grouped by scope.

The scope defines the instance that the metric belongs to. An instance is uniquely identified by a set of labels.

• WireTiger metrics are available only if WiredTiger is used as the storage engine.
• Sharding metrics are available on shards only for mongos.

#Per MongoDB instance

These metrics refer to the entire monitored application.

This scope has no labels.

Metrics:

Metric	Dimensions	Unit
mongodb.operations_rate	reads, writes, commands	operations/s
mongodb.operations_latency_time	reads, writes, commands	milliseconds
mongodb.operations_by_type_rate	insert, query, update, delete, getmore, command	operations/s
mongodb.document_operations_rate	inserted, deleted, returned, updated	operations/s
mongodb.scanned_indexes_rate	scanned	indexes/s
mongodb.scanned_documents_rate	scanned	documents/s
mongodb.active_clients_count	readers, writers	clients
mongodb.queued_operations_count	reads, writes	operations
mongodb.cursors_open_count	open	cursors
mongodb.cursors_open_no_timeout_count	open_no_timeout	cursors
mongodb.cursors_opened_rate	opened	cursors/s
mongodb.cursors_timed_out_rate	timed_out	cursors/s
mongodb.cursors_by_lifespan_count	le_1s, 1s_5s, 5s_15s, 15s_30s, 30s_1m, 1m_10m, ge_10m	cursors
mongodb.transactions_count	active, inactive, open, prepared	transactions
mongodb.transactions_rate	started, aborted, committed, prepared	transactions/s
mongodb.connections_usage	available, used	connections
mongodb.connections_by_state_count	active, threaded, exhaust_is_master, exhaust_hello, awaiting_topology_changes	connections
mongodb.connections_rate	created	connections/s
mongodb.asserts_rate	regular, warning, msg, user, tripwire, rollovers	asserts/s
mongodb.network_traffic_rate	in, out	bytes/s
mongodb.network_requests_rate	requests	requests/s
mongodb.network_slow_dns_resolutions_rate	slow_dns	resolutions/s
mongodb.network_slow_ssl_handshakes_rate	slow_ssl	handshakes/s
mongodb.memory_resident_size	used	bytes
mongodb.memory_virtual_size	used	bytes
mongodb.memory_page_faults_rate	pgfaults	pgfaults/s
mongodb.memory_tcmalloc_stats	allocated, central_cache_freelist, transfer_cache_freelist, thread_cache_freelists, pageheap_freelist, pageheap_unmapped	bytes
mongodb.wiredtiger_concurrent_read_transactions_usage	available, used	transactions
mongodb.wiredtiger_concurrent_write_transactions_usage	available, used	transactions
mongodb.wiredtiger_cache_usage	used	bytes
mongodb.wiredtiger_cache_dirty_space_size	dirty	bytes
mongodb.wiredtiger_cache_io_rate	read, written	pages/s
mongodb.wiredtiger_cache_evictions_rate	unmodified, modified	pages/s
mongodb.sharding_nodes_count	shard_aware, shard_unaware	nodes
mongodb.sharding_sharded_databases_count	partitioned, unpartitioned	databases
mongodb.sharding_sharded_collections_count	partitioned, unpartitioned	collections

#Per lock type

These metrics refer to the lock type.

Labels:

Label	Description
lock_type	lock type (e.g. global, database, collection, mutex)

Metrics:

Metric	Dimensions	Unit
mongodb.lock_acquisitions_rate	shared, exclusive, intent_shared, intent_exclusive	acquisitions/s

#Per commit type

These metrics refer to the commit type.

Labels:

Label	Description
commit_type	commit type (e.g. noShards, singleShard, singleWriteShard)

Metrics:

Metric	Dimensions	Unit
mongodb.transactions_commits_rate	success, fail	commits/s
mongodb.transactions_commits_duration_time	commits	milliseconds

#Per database

These metrics refer to the database.

Labels:

Label	Description
database	database name

Metrics:

Metric	Dimensions	Unit
mongodb.database_collection_count	collections	collections
mongodb.database_indexes_count	indexes	indexes
mongodb.database_views_count	views	views
mongodb.database_documents_count	documents	documents
mongodb.database_data_size	data_size	bytes
mongodb.database_storage_size	storage_size	bytes
mongodb.database_index_size	index_size	bytes

#Per replica set member

These metrics refer to the replica set member.

Labels:

Label	Description
repl_set_member	replica set member name

Metrics:

Metric	Dimensions	Unit
mongodb.repl_set_member_state	primary, startup, secondary, recovering, startup2, unknown, arbiter, down, rollback, removed	state
mongodb.repl_set_member_health_status	up, down	status
mongodb.repl_set_member_replication_lag_time	replication_lag	milliseconds
mongodb.repl_set_member_heartbeat_latency_time	heartbeat_latency	milliseconds
mongodb.repl_set_member_ping_rtt_time	ping_rtt	milliseconds
mongodb.repl_set_member_uptime	uptime	seconds

#Per shard

These metrics refer to the shard.

Labels:

Label	Description
shard_id	shard id

Metrics:

Metric	Dimensions	Unit
mongodb.sharding_shard_chunks_count	chunks	chunks

#Live Data

This collector exposes real-time functions for interactive troubleshooting in the Live tab.

#Top Queries

Retrieves profiled query statistics from MongoDB system.profile collection.

This function queries the system.profile collection across all user databases (excluding admin, local, config) to retrieve slow or sampled queries captured by the MongoDB profiler. It provides detailed execution metrics including timing, document counts, and execution plan information.

Use cases: - Identify slow queries that exceed the profiling threshold - Analyze query patterns by examining docs examined vs docs returned ratios - Detect collection scans (COLLSCAN) that may need index optimization

Query text is truncated at 4096 characters for display purposes.

Aspect	Description
Name	Mongodb:top-queries
Require Cloud	yes
Performance	Reads from system.profile collection across all user databases: • Profiling itself adds overhead to MongoDB operations (typically 1-5%) • Default limit of 500 rows balances usefulness with performance
Security	Query text may contain unmasked literal values including potentially sensitive data: • Document field values in query filters • Personal information in inserted/updated documents • Access should be restricted to authorized personnel only
Availability	Available when: • The collector has successfully connected to MongoDB • Profiling is enabled on at least one user database • Returns HTTP 503 if collector is still initializing or profiling is disabled on all databases • Returns HTTP 500 if the query fails • Returns HTTP 504 if the query times out

#Prerequisites

#Enable MongoDB profiling

Database profiling must be enabled on each database you want to monitor, and the function must be enabled in the collector configuration.

1. Enable profiling on a database (profile slow queries > 100ms):

   use myDatabase
   db.setProfilingLevel(1, { slowms: 100 })

1. Or profile all operations (level 2, use with caution):

   db.setProfilingLevel(2)

1. Verify profiling status:

   db.getProfilingStatus()

1. Enable the function in Netdata collector config:

   jobs:
     - name: local
       uri: mongodb://localhost:27017
       top_queries_function_enabled: true

:::info

• Profiling level 0 = off, 1 = slow operations only, 2 = all operations
• The slowms threshold determines which queries are captured at level 1
• system.profile is a capped collection; old entries are automatically removed
• System databases (admin, local, config) are excluded from profiling queries

:::

#Parameters

Parameter	Type	Description	Required	Default	Options
Filter By	select	Select the primary sort column. Options include execution time, docs examined, keys examined, and more. Defaults to execution time to focus on slowest queries.	yes	execution_time

#Returns

Profiled query statistics from system.profile. Each row represents a single profiled operation with execution metrics and plan details.

Column	Type	Unit	Visibility	Description
Timestamp	timestamp			When the operation was profiled. Useful for correlating slow queries with application events.
Namespace	string			Database and collection name in format database.collection. Identifies which collection the operation targeted.
Operation	string			Type of operation: query, insert, update, remove, command, getmore. Helps categorize workload patterns.
Query	string			The command document as JSON showing the query filter, projection, and options. Truncated to 4096 characters.
Execution Time	duration	seconds		Total execution time of the operation. High values indicate slow queries that may need optimization.
Docs Examined	integer			Number of documents scanned during execution. A high ratio of docs examined to docs returned suggests missing or inefficient indexes.
Keys Examined	integer			Number of index keys scanned. Compare with docs examined to assess index efficiency.
Docs Returned	integer			Number of documents returned to the client. Compare with docs examined to identify inefficient queries.
Plan Summary	string			Execution plan summary (e.g., IXSCAN, COLLSCAN, SORT). COLLSCAN indicates a full collection scan that may need an index.
Client	string			Client IP address or hostname that executed the operation. Useful for identifying query sources.
User	string			Authenticated user who executed the operation. Empty for unauthenticated connections.
Docs Deleted	integer		hidden	Number of documents deleted by the operation. Relevant for remove operations.
Docs Inserted	integer		hidden	Number of documents inserted by the operation. Relevant for insert operations.
Docs Modified	integer		hidden	Number of documents modified by the operation. Relevant for update operations.
Response Length	integer		hidden	Size of the response in bytes. Large responses may indicate queries returning excessive data.
Num Yield	integer		hidden	Number of times the operation yielded to allow other operations to proceed. High yields may indicate lock contention.
App Name	string			Application name from the client connection string. Useful for identifying which application generated the query.
Cursor Exhausted	string		hidden	Whether the cursor was fully exhausted (Yes/No).
Has Sort Stage	string		hidden	Whether the query required an in-memory sort stage (Yes/No). In-memory sorts are slower than index-based sorts.
Uses Disk	string		hidden	Whether the operation used disk for sorting or aggregation (Yes/No). Indicates memory pressure.
From Multi Planner	string		hidden	Whether multiple query plans were evaluated (Yes/No).
Replanned	string		hidden	Whether the query was replanned due to plan cache eviction (Yes/No).
Query Hash	string		hidden	Hash of the query shape for identifying similar queries. Available in MongoDB 4.2+.
Plan Cache Key	string		hidden	Key used for plan cache lookup. Available in MongoDB 4.2+.
Planning Time	duration	seconds	hidden	Time spent planning the query execution. Available in MongoDB 6.2+.
CPU Time	duration	seconds	hidden	CPU time consumed by the operation. Available in MongoDB 6.3+ on Linux only.
Query Framework	string		hidden	Query execution framework used (classic or SBE). Available in MongoDB 7.0+.
Query Shape Hash	string		hidden	Hash representing the query shape for grouping similar queries. Available in MongoDB 8.0+.

#Troubleshooting

#Debug Mode

Important: Debug mode is not supported for data collection jobs created via the UI using the Dyncfg feature.

To troubleshoot issues with the mongodb collector, run the go.d.plugin with the debug option enabled. The output should give you clues as to why the collector isn't working.

• Navigate to the plugins.d directory, usually at /usr/libexec/netdata/plugins.d/. If that's not the case on your system, open netdata.conf and look for the plugins setting under [directories].

  cd /usr/libexec/netdata/plugins.d/

• Switch to the netdata user.

  sudo -u netdata -s

• Run the go.d.plugin to debug the collector:

  ./go.d.plugin -d -m mongodb

To debug a specific job:

  ./go.d.plugin -d -m mongodb -j jobName

#Getting Logs

If you're encountering problems with the mongodb collector, follow these steps to retrieve logs and identify potential issues:

• Run the command specific to your system (systemd, non-systemd, or Docker container).
• Examine the output for any warnings or error messages that might indicate issues. These messages should provide clues about the root cause of the problem.

#System with systemd

Use the following command to view logs generated since the last Netdata service restart:

journalctl _SYSTEMD_INVOCATION_ID="$(systemctl show --value --property=InvocationID netdata)" --namespace=netdata --grep mongodb

#System without systemd

Locate the collector log file, typically at /var/log/netdata/collector.log, and use grep to filter for collector's name:

grep mongodb /var/log/netdata/collector.log

Note: This method shows logs from all restarts. Focus on the latest entries for troubleshooting current issues.

#Docker Container

If your Netdata runs in a Docker container named "netdata" (replace if different), use this command:

docker logs netdata 2>&1 | grep mongodb