MakeStack
Back to Feed

MongoDB observability with Grafana, Mimir, Loki, Tempo, and Alloy

A Docker Compose observability stack with Grafana, Loki, Mimir, Tempo, Alloy, and a standalone MongoDB instance, with MongoDB metrics available in Grafana through Mimir.

Service versions and responsibilities
ServiceImageRole
grafanagrafana/grafana:13.1.0web UI and data source provisioning
mongomongo:8.3.4standalone database and metrics target
lokigrafana/loki:3.7.3log storage
mimirgrafana/mimir:3.1.2metrics storage
alloygrafana/alloy:v1.17.0collector, embedded exporter, and OTLP receiver
tempografana/tempo:3.0.2application trace storage

The main metrics path is MongoDB -> Alloy -> Mimir -> Grafana.

This stack runs one MongoDB container without replica-set configuration. Grafana reads MongoDB and node metrics from Mimir, so database health, workload, storage-engine pressure, and host resources can be investigated from the same UI as logs and application traces.

MongoDB metrics flow#

Alloy runs one embedded MongoDB exporter component, connects it to the mongo container, labels the target as mongo, and remote-writes the samples to Mimir. In the same process, Alloy collects node metrics, forwards Docker logs to Loki, accepts OTLP telemetry, and sends application traces to Tempo.

Examplepromql
count by(__name__) ({job="integrations/mongodb"})

MongoDB dashboard coverage#

The MongoDB dashboard is organized around operational questions: whether the instance is reachable, how much traffic it handles, how WiredTiger uses its cache, which queries are expensive, where locks appear, how quickly storage grows, what MongoDB logs report, and how the container uses system resources.

Server Health and Availability

Covers instance status, uptime, restart detection, server assertions, exporter availability, and container health.

Traffic, Operations, and Connections

Covers operation rates, inserts, queries, updates, deletes, commands, active and available connections, connection saturation, network traffic, active clients, and queued reads and writes.

Replica Set Monitoring

Shows an explicit standalone-topology note. Member state, heartbeat, oplog, elections, and replication-lag panels are omitted because no replica set is configured.

WiredTiger and Cache

Covers cache usage, dirty cache bytes, pages read and written, eviction activity, checkpoint duration, and available or active concurrent transaction tickets.

Query Performance

Covers operation latency, documents and index keys examined, scan-and-order activity, document operations, and per-collection execution count and total execution time.

Slow Query Analytics

Covers slow-query logs, expensive collections, operation counts, time spent by collection, collection scans, unindexed work, and profiler-backed query activity.

Storage and Document Operations

Covers database data, storage, total, and index sizes together with document counts, collection counts, and per-collection storage usage.

Concurrency and Lock Troubleshooting

Covers lock acquisition counts, lock wait time, concurrent transaction tickets, active clients, and queued read or write operations.

MongoDB Log Analytics

Covers all MongoDB logs plus filtered views for errors and warnings, connections, authentication, and slow queries.

System and Container Resource Usage

Covers CPU, memory, network I/O, disk I/O, filesystem availability, host resources, and database storage usage.

The dashboard uses stat, gauge, table, bar chart, pie chart, heatmap, logs, and time-series visualizations instead of forcing every metric into a line chart. Its standalone rendering replaces replica-only panels with a clear topology note rather than empty or fabricated replication data.

Logs and traces#

Alloy reads Docker container logs, adds project, service, container, and container_id labels, and forwards the streams to Loki. The dashboard uses those labels for MongoDB log views covering slow queries, connections, authentication, errors, and warnings.

For OTLP traffic, Alloy exposes gRPC on 4317 and HTTP on 4318. OTLP logs are converted for Loki, OTLP metrics are converted to Prometheus remote write for Mimir, and OTLP traces are batched and sent to Tempo. Tempo is reserved for application traces; the MongoDB dashboard does not depend on traces.

Alloy telemetry routing
SourceDestination
Docker container logsLoki
OTLP logs on 4317/4318Loki
OTLP metrics on 4317/4318Mimir
OTLP traces on 4317/4318Tempo
Node exporter metricsMimir
MongoDB exporter metricsMimir