Telemetry export
PolicyArc can ship its OpenTelemetry (OTLP) telemetry straight to your collector. You don't log into our Grafana — your traces, metrics, and decision logs land in your own observability backend, scoped to your tenant automatically.
Managed telemetry export is an enterprise-plan feature. It isn't available on free/pro hosted plans — talk to your account team to enable it. Self-hosting is unaffected/unrestricted; the plan gate only applies to the hosted managed-collector path described below.
What it is
Every PolicyArc instance runs an OpenTelemetry exporter. When you turn it on, the authorization server pushes telemetry over OTLP. Self-hosting, that goes straight to a collector you operate. On the hosted SaaS platform, PolicyArc runs a small managed collector alongside your instance and forwards it to your Splunk on your behalf — see How to enable it (hosted) below. Either way, nothing about your traffic transits a shared dashboard: the data ends up in your backend, not ours.
Tenant isolation is automatic. A hosted instance only ever exports its own telemetry, and every record is tagged with resource attributes (service.name, service.instance.id, deployment.environment, service.version) so you can tell instances apart in your backend.
This is an operational / SIEM feed — for dashboards, latency tracking, alerting, and security monitoring. It is not the legal audit trail. The append-only DB audit log remains the system of record for "who accessed what, when, and under what authority." See Audit.
The three signals
OTLP carries three independent signals, and each is opt-in — enable only the ones your backend ingests.
| Signal | What you get |
|---|---|
| Traces | Per-request spans with latency, including child spans for the OPA policy decision and database calls. |
| Metrics | Rates and counts — request throughput, decision outcomes, error rates. |
| Logs | The structured decision stream as OTLP log records: token_decision, introspect_decision, callback_result, register_decision. Ideal for a SIEM. |
Journey correlation with flow_id
A single product journey is many separate requests — /authorize → callback → /token → /gateway → /introspect. PolicyArc tags every request in one journey with a shared, opaque pbac.flow.id attribute (and a matching flow_id field on logs and on the introspection response).
Filter your backend on pbac.flow.id to pull up one whole journey at once. The same id on the introspection response lets a resource server correlate its own logs back to the PolicyArc journey.
flow_id is an attribute shared across records — not a single stitched distributed trace. And it is opaque: it correlates requests without leaking any subject identity. No user, no sub, no email is encoded in it.
What is exported — and what is redacted
PolicyArc is deliberately conservative about what leaves your instance. Spans and logs carry only safe operational fields:
client_id,grant_type,outcome,reason,request_id,flow_id- resource attributes:
service.name,service.instance.id,deployment.environment,service.version
They do not carry:
id_tokenoraccess_tokentool_argumentsresource_id- any subject identifier (
sub, email, name)
Authorization/cookie headers and URL query strings are stripped from telemetry before it leaves the process. Logs additionally use an allowlist — only request_id, client_id, and flow_id are forwarded, never arbitrary log context.
Redaction is on by default. On a production profile, a startup guard refuses to boot if export is enabled while redaction is turned off — so a misconfiguration can never silently ship sensitive fields.
Remember: OTLP is an operational feed, not the audit trail. The DB audit log keeps the full, immutable record for compliance.
How to enable it (hosted)
On hosted tenants (*.policyarc.com) you enable export from the dashboard's Observability
page — not per environment. It's one Splunk connection for your whole account,
applied automatically to every environment (dev/staging/prod, etc.) you own:
- Open Observability in the dashboard sidebar.
- Click Enable export.
- Pick a vendor — Splunk is the only one supported today; more are on the roadmap.
- Fill in your Splunk details: HEC endpoint, HEC token, HEC index (for logs/decision events), and your Observability realm + access token (for traces/metrics). Both token fields are stored encrypted and never shown again once set.
- Pick which signals to send (traces / metrics / logs).
- Save.
Unlike self-host, you never hand PolicyArc a collector URL — you don't run a collector at all. PolicyArc provisions and operates a small collector per environment that speaks OTLP to your instance on one side and translates to Splunk (HEC for logs, SignalFx for traces/metrics) on the other.
Because this is one account-wide connection, saving a change briefly restarts every environment you own so each one's exporter picks up the new configuration — not just the one you happen to be looking at. If a particular environment fails to pick up the change, the Observability page flags it so you can investigate rather than assuming everything applied.
Supported backends
- Self-hosting: PolicyArc speaks OTLP and nothing more — your own collector does the rest. Point any OpenTelemetry Collector at your instance and have it front-end the backend of your choice: Datadog, Splunk, Dynatrace, Grafana Cloud, or anything else your collector can export to. There is no vendor-specific code in the authorization server itself — it emits standard OTLP; your collector translates it to whatever your backend wants.
- Hosted, managed Splunk export: this is the one exception to "no vendor-specific code" — since hosted tenants don't run any infrastructure of their own, PolicyArc runs a Splunk-configured collector on your behalf (see above). Other vendors aren't available on the hosted path yet.
Endpoint format and auth (self-host)
This section applies to self-hosting only — hosted tenants configure Splunk fields directly in the dashboard (see above), not a collector base URL.
- Endpoint: supply the collector base URL only (host + port, e.g.
https://otel.acme.com:4318). PolicyArc appends/v1/traces,/v1/metrics, and/v1/logsfor the signals you enabled. - Auth: a single auth header (for example
Authorization: Bearer <token>) is applied to all enabled signals. It is stored encrypted.
Next steps
- Audit — the immutable, DB-backed system of record (distinct from this operational feed)
- Architecture — where telemetry fits in the overall system