OpenTelemetry metrics

Send aggregated governance metrics to a collector that supports OTLP/HTTP JSON. These metrics share their definitions with Splunk Observability Cloud, while configuration and delivery remain independent.

The revised metrics integration is undergoing end-to-end validation. Confirm availability before including it in an evaluation.

Before you start

You need VeriProof administrator access and a destination that accepts OTLP metrics as JSON over HTTPS. The endpoint must be approved by the deployment’s outbound destination policy. Use port 443 or 4318 and the signal-specific /v1/metrics path. The endpoint belongs to this tenant’s collector configuration. VeriProof does not substitute a shared collector URL.

This integration does not export synthetic governance spans. It does not create APM service maps or distributed traces. Unrelated runtime instrumentation and inbound OpenTelemetry connections are separate capabilities.

Configure and verify

1. Open Settings → OpenTelemetry metrics.
2. Enter the approved HTTPS metrics endpoint.
3. Enter the required authentication headers as a JSON object, such as {"Authorization":"Bearer your-token"}.
4. Select application groups or All applications, then select environments.
5. Select Save settings, then Send test metric.
6. Find veriproof.export.test in your destination. Match the value and time shown in VeriProof.
7. Select I found the test metric, then Enable delivery.

Credentials are encrypted when saved. Leave the credential field blank to retain the stored value. Pause delivery before changing credentials or scope. Repeat the test after a configuration change. Collection starts when you enable delivery. VeriProof does not export activity recorded before that time.

The supported export protocol is OTLP/HTTP JSON, not gRPC or HTTP/protobuf. Use a compatible collector when your monitoring destination requires a different protocol.

What the metrics mean

• Completed sessions are grouped by their recorded outcome.
• Runtime policy decisions are grouped by action. Technical evaluation failures are separate from policy denials.
• Duration count, sum, and maximum describe recorded session duration, not model latency or policy-evaluation latency.
• Violations, anomalies, and health changes use controlled categories.
• An export heartbeat reports feed freshness independently of application activity.

Calculate weighted average duration by dividing total duration sum by total duration count for the same scope and period. Sessions without a duration measurement do not contribute a zero duration. Policy-decision counts are not session counts; a session can contain several decisions.

The OTLP resource uses service.name=veriproof-governance. Metric attributes include application identity, environment, source deployment, and controlled categories. Session IDs, URLs, rule names, free text, prompts, responses, evidence contents, and subject data are excluded from metrics.

Delivery and status

Additive metrics use cumulative sums built from one-minute source windows. Maximum duration and freshness timestamps remain gauges. Processing runs outside governance request execution. Retries preserve the serialized values and measurement times. The endpoint’s acceptance does not prove that a dashboard shows the expected data.

Check the last accepted delivery and undelivered batch count. An accepted batch is not a completed session. Missing data is not confirmed zero; check the heartbeat before interpreting an empty chart. OTLP partial rejection is treated as a delivery failure rather than full acceptance.

If your collector forwards to Splunk Observability Cloud, review any direct Splunk Observability connection for overlapping application scope. Removing the integration stops future delivery and removes stored credentials. It does not delete data already accepted by your destination.

See the OTLP protocol specification  for HTTP JSON and metric response behavior.