Add otelcol.receiver.mongodbatlas component

[justin-thurston]

Component(s)

New component: otelcol.receiver.mongodbatlas

Request

Add an otelcol.receiver.mongodbatlas component that wraps the upstream
mongodbatlasreceiver
from opentelemetry-collector-contrib. The upstream receiver has been stable for a
while and supports metrics, logs, alerts, and access/audit events pulled from the
MongoDB Atlas Administration API (plus optional log push via a receiver-managed
HTTPS endpoint for Atlas project alerts).

Alloy already wraps many contrib receivers (otelcol.receiver.awscloudwatch,
otelcol.receiver.vcenter, otelcol.receiver.nginx, etc.) but has no first-class
path for MongoDB Atlas today. The closest existing option, prometheus.exporter.mongodb,
targets self-hosted MongoDB via the wire protocol and does not cover Atlas project
metrics, Atlas alerts, or Atlas audit/access logs.

Target UX (River):

otelcol.receiver.mongodbatlas "default" {
  public_key  = sys.env("MONGODB_ATLAS_PUBLIC_KEY")
  private_key = sys.env("MONGODB_ATLAS_PRIVATE_KEY")

  granularity = "PT1M"

  logs {
    enabled = true
    projects = [{
      name               = "my-atlas-project"
      collect_audit_logs = true
    }]
  }

  alerts {
    mode = "poll"     // or "listen" for the HTTPS webhook path
    projects = [{ name = "my-atlas-project" }]
  }

  output {
    metrics = [otelcol.processor.batch.default.input]
    logs    = [otelcol.processor.batch.default.input]
  }
}

Scope of the ask:

• Wrap the upstream receiver, following the same pattern as other
  otelcol.receiver.* components (river block -> config struct -> factory).
• Expose the receiver's public config surface (metrics, logs, alerts, events,
  granularity, projects/organizations filtering, retry/timeout, TLS for the
  listen-mode webhook).
• Add reference docs under docs/sources/reference/components/otelcol/.

Use case

MongoDB Atlas is one of the most common managed database backends we see with
Grafana Cloud customers, and today the recommended ingestion path is either
"stand up a separate contrib-based collector" or "scrape Atlas via a custom
integration." Both are friction that an Alloy-native component removes:

• Observability migrations off vendor tooling (Datadog, New Relic, Splunk
  Observability, etc.) frequently include the vendor's Atlas integration.
  Without an Alloy component, Atlas is the last resource left behind after
  everything else is migrated.
• Grafana Cloud onboarding — customers who already run Alloy for
  Kubernetes / host metrics currently need a second collector process just for
  Atlas, which complicates deployment topology and RBAC.
• Fleet-managed edge deployments — customers using Fleet-managed Alloy
  can't ship Atlas config through the same pipeline as the rest of their
  observability stack.

Having this as a native otelcol.receiver.mongodbatlas component means Atlas
metrics/logs/alerts flow through the same processors, batching, and exporter
config as every other signal in the pipeline.

AI disclosure

• This issue was substantially generated with AI assistance.