Skip to content

Getting started

Connect a source

A source is any system that sends telemetry to MonitOps, and connecting one takes five things: a source record, a metadata policy, a credential, a sender configured with that credential, and a check on the Sources page that data is arriving. This article walks through the procedure with the sample service order-api and lists what to check when nothing appears.

Before you start#

You need the administrator role, because creating a source and issuing credentials are administrator operations. Operators and viewers can read source configuration but not change it. You also need an application or a collector that speaks OpenTelemetry, and the OTLP endpoint address agreed for your environment.

A credential belongs to one source, and one source can carry many services. Plan sources by who operates the sender, not by service: all services sent through one collector can share one source and one credential.

Procedure#

  1. Sign in as an administrator and open Sources.

  2. Create the source. Give it a display name, for example order-api production. The console creates sources that receive OpenTelemetry pushes. Sources that acquire data from a provider are configured by the deployment owner and appear in the same list, but their acquisition settings are not edited in the console.

  3. Set the metadata policy. For service.namespace and deployment.environment.name, choose a rule for each:

    • A default fills the value only when the sender leaves it out.
    • An enforced value fills it when absent and rejects records whose sender-supplied value conflicts.

    For a production sender, enforce deployment.environment.name so that a misconfigured sender cannot report its data as another environment. Leave a key unset if the source should not supply a value. An unset key does not infer a healthy, production or default identity.

  4. Issue a credential. The console shows the secret once, at issue time. Copy it into the sender's secret store immediately. MonitOps keeps only a digest of it and cannot show it again.

  5. Configure the sender. Use the standard OpenTelemetry SDK settings. Replace the endpoint with your environment's address and the bearer value with the credential.

    OTEL_EXPORTER_OTLP_ENDPOINT=https://<your-otlp-endpoint>
    OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
    OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer <credential>"
    OTEL_SERVICE_NAME=order-api
    OTEL_RESOURCE_ATTRIBUTES=service.namespace=checkout,deployment.environment.name=production

    The SDK appends the signal paths /v1/logs, /v1/metrics and /v1/traces to the endpoint. OTLP endpoint lists them with the response codes.

  6. Send telemetry and open Sources. The source shows admission counts and errors for the day, and its acquisition freshness. Freshness is shown separately from event time and ingestion lag.

  7. Open the service map. After the identity of each service is resolved, order-api appears as a service, with edges where traces show it calling other services.

Sending more than one service#

One credential can carry several services. If a collector sends telemetry for order-api and payments-gw, both appear on the service map as distinct services, each with its own identity, and you do not issue a credential per service. Each service identifies itself by its service name in the telemetry, and the source's metadata policy applies to all of them. When you rotate the credential later, the services and the configuration survive; see Credentials.

What you see in the console#

On Sources, each source shows its admission counts, errors, backlog and freshness, and its usage against the daily allowance when one is set. Admission counts record what was received and handed on. They do not by themselves mean that records are searchable or that every service identity has been resolved.

On the service map, a service appears once it has sent telemetry. Edges appear when traces contain a span whose parent is in another service; logs and service names alone never create an edge. Open a service to reach its logs and metrics with source, environment and time already applied. Trace inspection is available only for services that send traces.

If nothing appears#

SymptomLikely cause and check
Sender receives 401The credential is unknown, revoked or its source is disabled. Issue a new credential, or enable the source. A re-enabled source does not restore a revoked credential
Sender receives 415 or 400Content type or encoding is not supported, or the payload is malformed. Use OTLP over HTTP with protobuf or JSON, and gzip if you compress
Sender receives 429 or 503 with Retry-AfterThe source is over a hard allowance or a request limit, or MonitOps could not accept the request. Retry with backoff after the interval given
Sender receives 200 but a rejected countAn enforced metadata value conflicts with what the sender reports, or the environment attribute is given under conflicting names. The affected records are quarantined with a reason; see Masking
Counts rise, but no service appearsIdentity is unresolved for the records. Ambiguous records stay masked and pending, with a diagnostic on Sources, and are not guessed into a service
Service appears, no edgesThe sender is not sending traces, or the spans do not cross a service boundary
Freshness is staleThe sender stopped, or a firewall is blocking it. A silent source is raised as its own alert; see Source health

Last updated October 2026