Connect

Collector and shippers

Applications instrumented with an OpenTelemetry SDK send to MonitOps directly. Everything else arrives through the OpenTelemetry Collector or a shipper that speaks OTLP, using the same endpoint, credential and identity rules as a direct sender.

How it works#

Every sender, direct or not, posts OTLP/HTTP to the paths described in OTLP endpoint with the bearer credential of one source. The credential fixes the tenant and the source; the records carry the service name and environment as resource attributes. A Collector or shipper is therefore a sender like any other, and one credential can be shared by many services behind it.

Sender	How it connects
OpenTelemetry SDK	Direct to the endpoint
OpenTelemetry Collector	An OTLP/HTTP exporter that carries the credential header
Fluent Bit	Its native OTLP output
Kubernetes	Through the Collector
Prometheus	Through the Collector
Envoy	Native OTLP traces and access logs
Istio	Through Envoy

Identity comes from the records, not from the transport. Each record group needs service.name and, unless the source's metadata policy fills it, deployment.environment.name. See Identity and environments.

Procedure#

Create a source and copy its credential once, as described in Connect a source. Store it as a secret in the sender's environment.
Choose the sender below and set the endpoint and credential.
Make sure each record group carries its identity attributes. Where the sender cannot set them, set them in a Collector between the sender and MonitOps.
Send traffic and open the source in the console. Its freshness and admission counts show whether MonitOps is receiving it.

OpenTelemetry Collector#

An otlphttp exporter with the credential in a header, and a resource processor that sets identity attributes when the sender has not.

receivers:
  otlp:
    protocols:
      http:

processors:
  resource:
    attributes:
      - key: service.name
        value: order-api
        action: insert
      - key: deployment.environment.name
        value: production
        action: insert
  batch:

exporters:
  otlphttp:
    endpoint: https://<your MonitOps OTLP endpoint>
    headers:
      Authorization: "Bearer ${env:MONITOPS_SOURCE_CREDENTIAL}"
    compression: gzip

service:
  pipelines:
    logs:
      receivers: [otlp]
      processors: [resource, batch]
      exporters: [otlphttp]
    metrics:
      receivers: [otlp]
      processors: [resource, batch]
      exporters: [otlphttp]
    traces:
      receivers: [otlp]
      processors: [resource, batch]
      exporters: [otlphttp]

The exporter appends /v1/logs, /v1/metrics and /v1/traces to the endpoint. insert sets an attribute only when it is absent, so a value set by the application is kept. A single service.name in the processor suits a Collector that serves one service; for many services, let each application set its own.

Log shipper with native OTLP output#

Fluent Bit sends logs with its OpenTelemetry output.

[OUTPUT]
    Name        opentelemetry
    Match       *
    Host        <your MonitOps OTLP host>
    Port        443
    Logs_uri    /v1/logs
    Tls         On
    Header      Authorization Bearer ${MONITOPS_SOURCE_CREDENTIAL}

The records must reach MonitOps with service.name and the environment as resource attributes. If your shipper version cannot set them, send through a Collector with the resource processor above.

Kubernetes and Prometheus metrics#

Both arrive through Collector receivers and leave through the same exporter. Add the receiver to the metrics pipeline.

receivers:
  k8s_cluster:
    auth_type: serviceAccount
  prometheus:
    config:
      scrape_configs:
        - job_name: order-api
          static_configs:
            - targets: ["<host>:<port>"]

service:
  pipelines:
    metrics:
      receivers: [k8s_cluster, prometheus]
      processors: [resource, batch]
      exporters: [otlphttp]

Metrics from these receivers do not carry a MonitOps service name by themselves. Set it with the resource processor, or the records have no identity to resolve.

Service proxy#

Envoy emits OTLP traces and access logs natively. Point its OpenTelemetry tracer and access logger at a Collector in your network, which forwards them with the exporter above.

tracing:
  http:
    name: envoy.tracers.opentelemetry
    typed_config:
      "@type": type.googleapis.com/envoy.config.trace.v3.OpenTelemetryConfig
      grpc_service:
        envoy_grpc:
          cluster_name: otel_collector
      service_name: payments-gw

Istio proxies are Envoy, so the same traces and access logs flow when the mesh is configured to send them to the Collector.

Traces from a proxy add observed edges to the service map only when spans in different services share a trace.

What you see in the console#

On Sources, a source behind a Collector or shipper is listed like any other, with its freshness, admission counts, errors and recent request outcomes. See Source health.

Limits and defaults#

Admission limits, response codes and retry behaviour are those of the OTLP endpoint. A Collector's exporter retry settings decide how it reacts to 429 and 503.
Personal data is masked on admission whatever the sender; see Masking.
A source's metadata policy can fill or enforce the environment and namespace; it cannot supply a service name.

Failure states#

State	What you see
Wrong or revoked credential	`401` from the endpoint; the source goes silent
Missing identity attributes	The records are held as pending with visible diagnostics, not stored under a made-up service
Environment conflict with an enforced policy	The records in that group are rejected with `enforced_metadata_conflict`
Collector stopped	The source goes silent, which MonitOps raises as its own problem rather than reading it as healthy

Last updated October 2026