Connect

Sources

A source is any system that sends telemetry to MonitOps. Applications, integration services, synthetic checks and provider status feeds are all sources, and each has its own configuration, credential and health.

How it works#

Sources send logs, metrics and traces over OpenTelemetry. Each source sends with its own credential and sets its service name and environment as resource attributes. MonitOps derives services, and the edges between them, from this data; no manual registration is needed for a service to appear.

Provider health, API quota usage and synthetic check results arrive on the same path, as metrics and events, so detection, correlation and explanation treat them like any other signal.

The credential is the source of authority. It fixes the tenant, the source, the system the source belongs to, whether its services take part in correlation, and whether its logs are forwarded. The telemetry itself is not trusted for any of these. Within that boundary the telemetry identifies the services it describes, and the source's metadata policy can fill or enforce some of its attributes.

Source kinds#

Kind	How data arrives	Created and edited
OTLP push	An application, collector or shipper pushes OpenTelemetry to MonitOps with the source's credential	Created in the console by an administrator
Provider plugin	A plugin that knows one provider's API acquires its status, limits and events and emits them as telemetry. The provider credentials are held by MonitOps	Configured by the deployment owner; settings are not edited in the console
Synthetic checks	Scheduled probes against journeys and management endpoints emit `success` and `latency` signals. See Synthetic checks	Configured with the deployment
Provider status feed	A feed of a provider's own status, polled or received as events	Configured with the deployment
Collector scrape	A collector scrapes a target and delivers the result through the same path	Configured with the deployment

All kinds enter through the same admission path with the source's own credential. Configured sources are listed alongside OTLP push sources, with the same health fields. A new plugin is added without changing the core product.

Configuration#

A source has a display name, an enabled flag and a metadata policy. Updating any of them records a new immutable version of the source configuration. Rotating or revoking a credential does not change the configuration version.

Metadata policy#

Two keys can carry a rule: service.namespace and deployment.environment.name. Each rule is either a default or an enforced value.

Mode	Absent in the record	Sender sends a different value
default	The value is filled in	The sender's value is kept
enforced	The value is filled in	The record is rejected with `enforced_metadata_conflict`

Policy is applied per resource group in a request, and rechecked after any transformation. A conflict never overwrites the sender's value to make it match. A key with no rule means no configured value: MonitOps does not infer a healthy, production or default identity. service.name, service.version and service.instance.id have no source-level defaults, because one source can carry many services; the producer supplies them.

Environment handling#

The canonical attribute is deployment.environment.name. If a sender uses the older alias deployment.environment and the canonical attribute is absent, MonitOps normalises the alias. If both are present with conflicting values, the records in that group are rejected with environment_alias_conflict. The environment scopes health, signals and correlation, and it is not part of a service's logical identity, so production and staging state are never merged. See Identity and environments.

Allowed services#

Source policy includes the services the source is allowed to send for. Like the rest of the policy, it survives credential rotation.

Allowances and metering#

MonitOps meters each source per day, counting the uncompressed bytes and the records received, including traffic that is later filtered. A daily allowance in bytes can be set per source.

Event	Result
Usage reaches 80 % of the allowance	An alert is raised through the normal alert path
Usage reaches 100 % of the allowance	An alert is raised through the normal alert path
Allowance used up with a soft cap	Requests are still accepted and the usage is flagged as overage. This is the default
Allowance used up with a hard cap	Requests receive `429` with `Retry-After`

The console shows usage against the allowance for the current day and for the last 30 days.

What a source cannot change#

A sender and the source's own metadata policy cannot change the tenant, the system a source belongs to, whether its services take part in correlation, or its forwarding policy. These come from trusted configuration set by the deployment owner. Several sources may observe the same service without gaining authority over its membership.

A source that belongs outside your own estate, for example an external collector, is metered and stored, but its services do not appear on the service map and do not enter correlation or cause assessment unless an administrator maps them in. Its data is not forwarded to your log destinations.

What you see in the console#

Sources lists every source with its kind, enabled state, admission counts, errors and backlog, usage against the allowance and its acquisition freshness. Acquisition freshness is shown separately from event time and ingestion lag, and a source that stops sending is raised as its own problem. Source health describes the fields.

Limits and defaults#

Item	Value
Allowance cap mode	Soft by default
Allowance alerts	At 80 % and 100 %
Usage history in the console	Today and the last 30 days
Active credentials per source	Two, to allow rotation

Failure states#

A disabled source denies all of its credentials after a short, bounded delay. A record that fails validation or conflicts with an enforced value is quarantined with masked diagnostics. See OTLP endpoint and Masking.

Last updated October 2026