Coordimap
ConfigurationMongoDB

MongoDB Configuration

Configure MongoDB as a Coordimap data source with the right scope_id, required connection fields, crawl options, and stable identity guidance.

Configuring A MongoDB Data Source In Coordimap

This page explains how to configure the Coordimap agent to crawl a MongoDB deployment. Once configured, Coordimap can discover databases, collections, indexes, and related structure from the target MongoDB environment.

For MongoDB, scope_id should be a replica set or cluster identity when one is available. If the deployment does not expose an immutable identifier, the replica set name is an acceptable but weaker fallback.

Use the MongoDB data source when you want to document database dependencies alongside Kubernetes, cloud, and flow telemetry in the same Coordimap graph.

Prerequisites

Before you begin, make sure you have:

  1. Installed the Coordimap agent in an environment that can reach the MongoDB deployment.
  2. Added the MongoDB data source in the Coordimap UI so you have an id.
  3. Prepared MongoDB credentials for a user with read access to the databases you want to crawl.

Find The Correct scope_id

Useful commands when working with replica sets include:

rs.conf()
rs.status()

Recommended guidance:

  • Prefer a true replica set or cluster identifier if your deployment exposes one.
  • Use the replica set name only as a fallback when no immutable ID is available.
  • For standalone MongoDB deployments, choose an explicitly configured stable scope_id and keep reusing it.

Configuration File

coordimap:
  api_key: ${COORDIMAP_API_KEY}
  data_sources:
    - type: mongodb
      id: <YOUR_DATA_SOURCE_ID_FROM_UI>
      config:
        - name: scope_id
          value: "<MONGODB_REPLICA_SET_OR_CLUSTER_ID>"
        - name: db_name
          value: "*"
        - name: db_host
          value: "hostname"
        - name: db_user
          value: "user"
        - name: db_pass
          value: ${MONGODB_PASSWORD}
        - name: crawl_interval
          value: "10m"

Configuration Options

Attribute NameRequiredDescription
typeYesThe data source type. For MongoDB this must be mongodb.
idYesThe Coordimap data source identifier created in the UI. It identifies the connector record, not the MongoDB deployment identity.
config.name: scope_idYesStable upstream identity for the MongoDB deployment. Prefer a replica set or cluster identity.
config.name: db_nameYesThe MongoDB database name to connect to. Use * to crawl all available databases when supported.
config.name: db_hostYesHostname or IP address of the MongoDB deployment.
config.name: db_userYesMongoDB user used by the agent.
config.name: db_passYesPassword for the MongoDB user. Prefer an environment variable.
config.name: crawl_intervalNoHow often the agent refreshes the MongoDB inventory. See Shared Configuration Options.

Why scope_id Matters For MongoDB

MongoDB deployments are often reconfigured, moved, or reconnected through new crawler instances. Reusing the same stable scope_id ensures Coordimap keeps the discovered MongoDB objects attached to the same logical deployment instead of creating duplicates.

Security Guidance

  • Use a dedicated read-only MongoDB user.
  • Store db_pass in an environment variable or secret manager.
  • Limit network access so only the agent runtime can reach MongoDB.
  • Start with one database before using db_name: "*" in production.

FAQ

What should I use as the MongoDB scope_id?

Use a stable replica set or cluster identity. If your deployment does not expose an immutable ID, use the replica set name or an explicitly configured stable value.

Can Coordimap crawl all MongoDB databases?

Yes. Set db_name to * and make sure the MongoDB user has read-only access to the databases you want Coordimap to inspect.

Should the MongoDB agent user have write permissions?

No. The agent only needs read access for metadata discovery. Use a dedicated read-only user whenever possible.

Does id replace MongoDB scope_id?

No. id identifies the Coordimap connector record. scope_id identifies the MongoDB deployment that owns the discovered database assets.

On this page