Skip to main content

MongoDB Atlas

Telemetry Provided
  • Infrastructure Entities - Complete infrastructure topology including compute, storage, and networking resources
  • Metrics - Performance metrics from applications and infrastructure
  • Signals - Automatic Signal detection from metrics, traces, and external monitoring systems

Overview​

Causely provides native integration with MongoDB Atlas to help you identify and resolve database performance issues before they impact your users.

Instead of just monitoring signals, Causely analyzes them in real time from the Atlas Monitoring API to surface the actual diagnosis behind database problems.

This integration helps you identify the following causes for reliability issues, among others:

The integration supports MongoDB Atlas clusters and automatically maps Atlas shard processes to the Causely service topology, enabling end-to-end tracing from your application to the Atlas cluster.

Step 1: Create an Atlas API Key​

Create a programmatic API key for your MongoDB Atlas project with the necessary permissions:

  1. Log in to the MongoDB Atlas Console
  2. Navigate to your Organization → Access Manager → API Keys
  3. Click Create API Key
  4. Set a description and assign the Project Read Only role (minimum required)
  5. Copy and securely store the Public Key and Private Key
  6. Add your Causely mediator's IP address to the API key access list
note

You will also need the Project ID (also called Group ID) from your Atlas project. Navigate to your project → Settings to find it.

Step 2: Configure the Integration​

Add data source from the UI​

You can add MongoDB Atlas as a data source from the Causely UI. Go to Integrations, add the MongoDB Atlas integration, enter your Public Key, Private Key, and Project ID, and select the cluster to which the configuration will be pushed.

Basic setup (ops as code)​

If you prefer to manage configuration as code, create a Kubernetes Secret containing your Atlas API credentials and label it for autodiscovery:

kubectl create secret generic atlas-credentials \
  --namespace causely \
  --from-literal=publicKey="<your-public-key>" \
  --from-literal=privateKey="<your-private-key>" \
  --from-literal=groupId="<your-project-id>"

kubectl label secret atlas-credentials \
  --namespace causely \
  causely.ai/scraper=MongoAtlas

Alternatively, create the secret using a YAML manifest:

apiVersion: v1
kind: Secret
metadata:
  name: atlas-credentials
  namespace: causely
  labels:
    causely.ai/scraper: MongoAtlas
type: Opaque
stringData:
  publicKey: '<your-public-key>'
  privateKey: '<your-private-key>'
  groupId: '<your-project-id>'

Secret keys:

  • publicKey (required): MongoDB Atlas programmatic API public key. Also accepted as public_key.
  • privateKey (required): MongoDB Atlas programmatic API private key. Also accepted as private_key.
  • groupId (required): MongoDB Atlas project ID (Group ID). Also accepted as group_id, projectId, or project_id.

To monitor multiple Atlas projects, create one secret per project and label each with causely.ai/scraper=MongoAtlas.

What Data is Collected​

The MongoDB Atlas scraper collects comprehensive metadata and performance information from your Atlas deployment, including:

  • Cluster entities with display names and labels (causely.ai/service-type=MongoDB Atlas Cluster)
  • Shard process entities (Workloads) for each mongod/mongos instance, linked to their parent cluster
  • Network endpoints for all client-facing hostnames (both the SRV parent and the individual shard seed hosts), enabling automatic topology stitching from application services to the Atlas cluster
  • Connection metrics per shard: current connections and available connections (derived from the cluster tier's connection limit)
  • Replication lag per shard (OPLOG_REPLICATION_LAG_TIME)
  • Open cursors per shard (CURSORS_TOTAL_OPEN)