Observability Export
What this screen is for
Observability Export is where you declare the external observability tools your deployment sends its own telemetry to. It is one of the three cards under Observability & Audit that hold no configuration value: it administers records, each one a destination with a name, a vendor, an endpoint, a credential and an on/off state.
Two independent planes live behind the surface's tabs. Configuration holds the deployment's own backends — the aggregated export, with the tenant identifier stripped. Per tenant holds a plane of its own, where a single tenant receives only its own tenant-tagged telemetry and never another tenant's. They coexist; the second is not a refinement of the first.
Four vendors are offered, in this order: Datadog, Dynatrace, Instana and Generic OTLP.
Three signals can be exported: traces, metrics and logs. A new backend starts with traces and metrics on and logs off. Logs sends the services' log lines with their service, level and host; the message text leaves the platform with UUIDs and e-mail addresses masked, and any other text in it is sent as written.
A tenant's own destination never receives logs.
At most five deployment backends may exist. The console shows the count against that cap, and the sixth create is refused by the platform rather than by the screen.
What must exist first
This is a platform screen, reached in the platform context and served only to the platform tenant. The permissions are this subsystem's own, and holding platform-configuration read does not carry them:
- The permission to read observability backends. It is what makes the card worth reaching and what lists the destinations; without it the surface states that the configuration is not available to you rather than showing an empty list.
- The permission to manage observability backends, for creating, editing, enabling, disabling or deleting one. The platform enforces it on every write.
- For the per-tenant plane, its own read and manage permissions again, plus a SaaS deployment. On a customer-operated install the per-tenant surface is inert and a grant or a declare is refused as not supported for this deployment type.
- Also for the per-tenant plane, an entitlement granted to that tenant by a platform operator. It is a separate flag from any destination, a tenant may be entitled with zero destinations, and without it the tenant may not declare one.
Decisions you make here
Declaring a backend
Add backend is a two-step flow. You choose a vendor tile first, and the vendor is then fixed: editing an existing backend opens the second step directly and shows the vendor as a read-only identity header, never a select. The second step asks for a name, the OTLP/HTTP endpoint, which signals to export, whether the backend starts enabled, and the credential.
The name is unique across the deployment and is not cosmetic — it becomes the exporter identifier in the rendered collector configuration. On the per-tenant plane the name is unique within each tenant, so two tenants may reuse the same one.
The export credential
The credential is write-only. The platform seals it and returns a mask on every read, so the console never holds a copy and there is no reveal control anywhere on this surface. What each vendor calls it differs — an API key, a Dynatrace access or platform token (the platform adds its Api-Token or Bearer scheme), an agent key, or a plain Authorization value — and the field is labelled accordingly.
Editing a backend gives you an empty credential field, not the mask. Leaving it empty means unchanged; typing a real value rotates it. Submitting the mask itself on a create is refused. A deployment credential is sealed under the deployment key; a per-tenant credential is sealed under that tenant's own key, and neither is ever stored in clear.
The endpoint, and what the platform will refuse
The endpoint must be an https URL carrying no inline credentials. Neither the endpoint nor the credential may contain $, because the collector reads ${...} as a reference to a file, a variable or a URL. The credential may not contain a control character, and the endpoint uses only the ASCII characters a URL permits, with no comma and with square brackets only around an IPv6 address; percent-encode any other character of the path, and write an internationalized host in its ASCII form. Such a value is refused and nothing is saved.
Beyond that the rule depends on the deployment: on a SaaS deployment a private or internal address is refused, and elsewhere it is permitted, because an on-premises collector is the normal case there.
Two refusals are deliberately distinguished, and they need different actions from you. Something that is not a URL at all is a request error. A well-formed URL that is not a permitted target is a refusal of the semantics, answered separately. Note also what is not checked: host names are never resolved during validation, so only literal IP addresses are range-checked.
What is never sent
Below the signals the form states, read-only, what the export always strips: secrets, personal data, tenant identifiers and raw payloads. It is deny-by-default and it is not editable — there is no control that turns any of it back on.
When a change reaches the collector
A saved backend is committed first, and the collector configuration is then re-rendered and a reload requested. The collector checks the new configuration, reloads it, and goes back to the previous one if it does not come up healthy.
The platform also re-renders on its own when it starts and checks every minute that the collector still runs the current configuration, so after a restart of the platform your backends come back without being edited. Where the deployment does not provide the shared mount, the render degrades in place: the change is committed, the render is deferred, and the backend reads Not applied. The stack template enables the render seam by default, so on a normally deployed environment it runs.
When the collector reloads, telemetry it was still holding for a backend is lost: the collector keeps a short in-memory queue and retries a failed send for up to five minutes, and it does not replay what it could not deliver.
There is no test action on this surface. Nothing here sends a probe to the endpoint you typed; the first real traffic is the collector's own export, and its outcome is what the status shows.
What a backend's status means
Each backend shows a status measured by the collector itself, refreshed about once a minute — never just whether the backend is switched on. When it is not exporting, the row says what happened and what to do.
- Exporting — the collector is delivering this backend's telemetry.
- Failing — the collector could not deliver to this backend. Either the backend refused the data, usually because the API key or the endpoint is wrong, or the data could not be delivered within five minutes of retries, usually because the endpoint is unreachable from the platform, or the collector's queue for this backend is full and new telemetry is being dropped, because the backend is unreachable or slower than the platform sends.
- Not applied — the collector is not running this backend's current configuration yet; it is normally applied within a minute. If the collector refused the latest export configuration, the previous one keeps running and recent changes are not in effect.
- Switched off — the backend is disabled, so nothing is sent to it.
- Not measured — the platform could not read the collector's state; the platform operator should check the collector.
The card on the Observability & Audit landing reads Active only when every backend is exporting; a switched-off backend, or one in any other state, makes it read Attention.
How it relates to other screens
This surface sits inside the Observability & Audit group, beside the two other subsystems that administer records rather than values:
Where this export ends up is drawn on the integration map, and the state the platform reports about itself is read on the health panel rather than configured here.