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#
-
Sign in as an administrator and open Sources.
-
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. -
Set the metadata policy. For
service.namespaceanddeployment.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.nameso 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. -
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.
-
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=productionThe SDK appends the signal paths
/v1/logs,/v1/metricsand/v1/tracesto the endpoint. OTLP endpoint lists them with the response codes. -
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.
-
Open the service map. After the identity of each service is resolved,
order-apiappears 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#
| Symptom | Likely cause and check |
|---|---|
Sender receives 401 | The 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 400 | Content 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-After | The 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 count | An 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 appears | Identity 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 edges | The sender is not sending traces, or the spans do not cross a service boundary |
| Freshness is stale | The sender stopped, or a firewall is blocking it. A silent source is raised as its own alert; see Source health |
Related#
Last updated October 2026