Splunk Observability Cloud

Monitor governance activity and application health alongside your operational metrics. This integration is separate from the Splunk event integration.

This integration is undergoing validation. Cross-organization dashboard import and end-to-end acceptance are not yet complete.

Choose the integration for your task

Governance metrics do not create distributed traces or APM service-map relationships. Session duration measures the recorded session, not model latency or policy-evaluation latency.

Configure delivery

You need VeriProof administrator access, a Splunk Observability organization, and permission to view its metrics.

1. Create an organization token with INGEST scope. Routine delivery does not need API or RUM access.
2. Open Settings → Splunk Observability Cloud in VeriProof.
3. Select the realm shown by your Splunk organization and enter the ingest token.
4. Select application groups or All applications, then choose the environments to include.
5. Select Save settings, then Send test metric.
6. Find veriproof.export.test in Splunk. Match the value and time displayed by VeriProof.
7. Select I found the test metric, then Enable delivery.

One destination is supported per tenant. Application scope applies independently of your Splunk event integration and OpenTelemetry configuration. VeriProof selects the metric and event endpoints from your realm; no endpoint URL is required. Saved credentials are encrypted. Pause delivery before changing credentials or scope, then repeat verification. Collection starts when you enable delivery. VeriProof does not export activity recorded before that time.

Understand delivery states

An accepted request does not prove that a chart contains the expected data. The export heartbeat distinguishes a working, idle feed from delayed delivery. It does not measure application health.

Data and calculations

Use the metrics to compare session outcomes, policy decisions, violations, anomalies, and application health changes. Duration measurements include a count, sum, and maximum. Policy-decision counts are separate from session counts. A session can contain several decisions. Values are grouped into one-minute windows, with a processing allowance for incoming activity. Additive measurements use cumulative counters, while maximum duration remains a gauge. Weighted average duration uses total recorded duration divided by the number of sessions with a duration measurement.

Dimensions include application identity, environment, source deployment, and controlled outcome or severity categories. Metrics exclude session identifiers, URLs, free text, and rule names. Prompts, responses, evidence contents, borrower details, and subject data are not exported. Selected health events may include an authorized application link; they are not copies of the Splunk session feed.

Do not interpret missing measurements as zero. A session without a duration measurement does not contribute zero seconds to the average. Runtime policy denials and technical evaluation failures remain separate categories. A cancelled session alone does not establish a policy denial.

Dashboard and alerts

The versioned VeriProof application governance v1 dashboard includes application, environment, and source-deployment filters. It shows policy decisions, session outcomes, weighted and maximum recorded duration, violations, anomalies, and health changes.

Open Dashboards → New dashboards, then search for the dashboard name. Save its URL in VeriProof to add an Open dashboard link to the integration settings. Review the last accepted delivery and backlog in VeriProof before treating an empty chart as confirmed zero.

To add application drilldowns, create a Splunk global data link for any value of veriproof.application.id:

https://my.veriproof.app/applications/{{value}}/sessions

Name the link Open application in VeriProof. Splunk replaces {{value}} with the selected application ID. VeriProof applies the signed-in user’s access when the link opens.

Download the VeriProof application governance v1 dashboard JSON. Import it into a dashboard group with Create → Import → Dashboard. The sandbox dashboard has passed native rendering and weighted-calculation checks. Import acceptance in a second organization remains part of release validation. Detector thresholds and notification recipients are customer choices; enabling this integration does not enable paging.

Delivery limits and troubleshooting

Delivery runs outside governance request execution. Batches and retries are bounded; retries preserve the serialized payload and measurement times. Activity that arrives more than 24 hours late is excluded from delivery. Cumulative counter prefixes preserve accepted corrections within that window, with at most eight delivery attempts per batch. Review rejected or expired delivery separately from accepted batch counts. Accepted batch counts are not session totals.

If a test is rejected, check the realm, token scope, token expiration, and organization limits. If the test is accepted but absent, inspect the test metric’s exact time and application dimensions in Splunk. If both OpenTelemetry and this integration forward to the same Splunk organization, review their application scopes to avoid overlapping metrics.

Restore delivery after an interruption

Administrators receive a delivery alert in Inbox → Admin tasks. Open it to review the integration settings and rejected or expired counts.

1. Restore token access or correct the limit reported by the destination.
2. If you change credentials or scope, pause delivery, save the changes, and repeat test verification.
3. If the same verified connection works again but rejected batches keep Needs attention visible, select Pause delivery, then Enable delivery.
4. Check the new accepted-delivery time and dashboard freshness. The recovery message appears in Inbox → Updates.

Resuming starts a new collection period. It does not resend rejected or expired batches, and those counts remain in history. Record any resulting monitoring gap in your team’s incident record. A recovery message confirms renewed delivery, not recovery of missing measurements.

See Splunk organization access tokens .