---
title: "Set Up Database Monitoring for MongoDB"
description: "Prepare MongoDB for Middleware Database Monitoring. Create a profiling user and configure the profiling level so slow operations appear in Query Metrics and Samples."
section: "APM"
breadcrumb: "APM > Database Monitoring > Set Up MongoDB"
canonical: "https://docs.middleware.io/get-started/database/mongodb"
---
# Set Up Database Monitoring for MongoDB

MongoDB query data in [Database Monitoring](/features/apm/database-monitoring) comes from the MongoDB database profiler. The Middleware Agent sets the profiler level on your databases, reads new entries from `system.profile` on every collection, and shows them as **Query Metrics** and **Samples**. Instance metrics are collected at the same time.

For the complete integration form, see the [MongoDB Integration](/integrations/mongodb-integration) page.

## Prerequisites

1. **Middleware Agent** (latest version) installed on a host or Kubernetes cluster that can reach MongoDB. See [Installing the Agent](/get-started/agent).
2. **Admin access** to MongoDB, so you can create a user in the `admin` database.

MongoDB Atlas is not supported in Database Monitoring. The [MongoDB Atlas integration](/integrations/mongodb-atlas-integration) sends Atlas metrics to dashboards and alerts.

## Setup

#### 1 Create a Profiling User

Connect with `mongosh` and create a user in the `admin` database:

```text
use admin
db.createUser({
  user: "otelProfiler",
  pwd: "StrongPasswordHere",
  roles: [
    { role: "dbAdminAnyDatabase", db: "admin" },
    { role: "clusterMonitor", db: "admin" }
  ]
})
```

- `clusterMonitor` lets the agent read server status and metrics.
- `dbAdminAnyDatabase` lets the agent set the profiling level and read `system.profile` in each database. Without it, metrics still arrive, but Query Metrics and Samples stay empty.

#### 2 Choose Profiling Settings

Two settings control which operations are recorded:

| Setting | Values | Description |
| --- | --- | --- |
| `profiling_level` | `0`, `1`, `2` | `0` turns profiling off. `1` records operations slower than `slow_ms`. `2` records every operation. |
| `slow_ms` | Milliseconds | The threshold for a slow operation when `profiling_level` is `1`. |

For production, use `profiling_level: 1` with a `slow_ms` value that matches what you consider slow (for example, `10` to `100`). Level `2` records every operation and adds load to busy databases.

> **Warning:** The agent applies the configured profiling level to every database on every collection. If `profiling_level` is missing from your configuration, the agent treats it as `0` and **turns profiling off**, so no queries appear. Always set both `profiling_level` and `slow_ms`.

The agent profiles every database except `admin`, `local`, `config`, and `test`. Use a different database name when you try out Database Monitoring.

#### 3 Configure the MongoDB Integration

#### Host

Create a credentials file on the host where the Middleware Agent runs, for example `/home/ubuntu/mongodb_creds.yaml`:

```yaml
mongodb:
  hosts:
    - endpoint: localhost:27017
  username: otelProfiler
  password: StrongPasswordHere
  profiling_level: 1
  slow_ms: 10
```

Restrict the file so only the agent can read it. Docker users should create the file under `/var/log`.

In Middleware, go to **Installation → All Integrations → MongoDB**, select the host, enter the full file path in **Path**, and click **Save**.

#### Kubernetes

In Middleware, go to **Installation → All Integrations → MongoDB** and select the Kubernetes mode. For each MongoDB service, enter:

- **Endpoints**: one or more service addresses, for example `mongodb.mongo.svc.cluster.local:27017`
- **Username** and **Password**: the profiling user from step 1
- **Profiling Level**: `0`, `1`, or `2` (default `1`)
- **Slow Ms**: the slow operation threshold in milliseconds (default `10`)
- **Collection Interval**: how often to collect, for example `15s`

Click **Save**.

#### 4 Verify

Run some operations that exceed `slow_ms`, then open **APM → Database**:

1. The instance appears on the **Databases** tab under **MongoDB**.
2. Select **MongoDB** in the **Overview** list. **Query Metrics** and **Samples** list your operations.

To confirm the profiler is on, run this in `mongosh` against one of your databases:

```text
db.getProfilingStatus()
```

The output should show `was: 1` (or `2`) and the `slowms` value you configured.

## What You Get

| Data | Source | Used by |
| --- | --- | --- |
| Metrics | `serverStatus`, database and collection statistics, replication status | Instance list, instance **Summary** and **Metrics** tabs, **Collections** table |
| Slow operations | Database profiler (`system.profile`) | **Query Metrics**, **Samples**, Average load by operation |

Explain plans, wait events, blocking analysis, schemas, and APM trace correlation are available for PostgreSQL only.

## Troubleshooting

#### The instance appears, but Query Metrics and Samples are empty

Check that profiling_level is set to 1 or 2 in the credentials file or form. Check that operations actually exceed slow_ms, and that they run in a database other than admin, local, config, or test. Confirm that the user has the dbAdminAnyDatabase role.

#### The profiling level changes back after I set it in mongosh

The agent enforces the configured profiling_level and slow_ms on every collection. Change the values in the credentials file (Host) or the integration form (Kubernetes) instead of in mongosh.

#### The Queries count is lower than my real traffic

Database Monitoring counts only the operations the profiler records. With profiling_level 1, operations faster than slow_ms are not counted.

#### The instance does not appear at all

Check that the MongoDB integration is saved, the credentials file path is correct and readable by the agent, and the agent host can reach the MongoDB endpoint. Confirm that your role has the Database Monitoring permission.

Need assistance or want to learn more about Middleware? Get in touch with us via our Contact Us page or join our Slack channel.