One Operational View for Splunk and OpenTelemetry
By Roger Lindquist
Published
.png%3F2026-05-28T11%3A42%3A26.887Z&w=3840&q=100)
TL;DR
OpenTelemetry standardizes telemetry collection, but enterprise value depends on much more than deploying collectors. You need to know which data each use case requires, how Splunk and OpenTelemetry should be configured, what is actually running across the estate and whether live telemetry supports the outcome you depend on.
Deslicer AI is the enabling layer for this challenge. It combines thousands of structured use cases with specialised AI agents that understand Splunk, OpenTelemetry Collector configuration and OpAMP-compatible fleet operations.
The result is one governed approach for mixed Splunk and OpenTelemetry environments: start with the required outcome, generate and manage the implementation, observe the effective state and verify the result in Splunk.
OpenTelemetry creates opportunity. Enterprises still need control
OpenTelemetry creates a standardized way to collect, process and export logs, metrics and traces. It gives enterprises a flexible foundation for modern telemetry pipelines across infrastructure, applications and distributed services.
But adopting OpenTelemetry is not the same as achieving a monitoring, security or compliance outcome.
Your organization does not invest in telemetry because it wants more collectors or configuration files. You invest because you need to know when a critical service is failing, whether a security control is working, whether privileged activity can be detected, whether regulatory evidence is reliable and whether operational decisions are supported by trusted data.
Every one of those outcomes depends on implementation.
The required source must be identified. The correct telemetry must be collected. Logs may need to be parsed, filtered and enriched. Metrics and traces must be routed to the correct destination. Collection configurations must be deployed and governed. Finally, the result must be verified in Splunk through the search, detection, dashboard, KPI or compliance control that depends on the data.
This is why your OpenTelemetry strategy cannot begin and end with collector deployment.
It must connect the outcome you need to the telemetry pipeline that delivers it - and to the evidence that proves it is working.
Start with the outcome, not the collector
Technology decisions become clearer when they begin with the result your organization needs.
A platform owner may need telemetry to understand Kubernetes reliability. A security team may need evidence of privileged access attempts or firewall-policy changes. A risk owner may need dependable data supporting NIS2, DORA or ISO 27001 controls. A service owner may need a KPI that explains deteriorating customer experience.
These needs do not begin as configuration files. They begin as use cases.
Deslicer has built its approach around a structured library of thousands of use cases across more than 20 technology domains, including infrastructure, cloud, containers, identity, security, databases, operational technology, compliance and business analytics.
A use case gives purpose to the telemetry implementation. It identifies what needs to be visible, what source data is required, which signals and fields are important, how the data needs to be normalized and what the resulting Splunk outcome should support.
Instead of beginning with a blank configuration file or another manual onboarding project, you can begin with the operational, security, compliance or business outcome you need to deliver.
For a technology decision-maker, this changes the investment case. You are not approving another collection tool in isolation. You are establishing a repeatable method for translating enterprise priorities into measurable and verifiable telemetry coverage.
A operating view across Splunk and OpenTelemetry
For many enterprises, OpenTelemetry will be introduced into an environment where Splunk collection already plays a central role.
Splunk Universal Forwarders and existing Splunk onboarding models may continue to support established log-collection requirements. OpenTelemetry Collectors and gateways may be introduced for modern application telemetry, distributed services, metrics, traces or new processing requirements. Both approaches can be appropriate.
The risk is not that both technologies exist. The risk is operating them without one governing view.
When collection paths are managed separately, it becomes harder to answer basic but critical questions:
- Which telemetry is required for each priority use case?
- Which systems currently provide it?
- Is the required Splunk or OpenTelemetry configuration actually deployed?
- Are logs parsed and normalized correctly?
- Are metrics and traces reaching their intended destination?
- Did a configuration change improve the outcome or silently break it?
- Which dashboards, detections or controls are affected when telemetry coverage changes?
Deslicer is designed to provide the operational view across that mixed reality: required use cases, Splunk collection, OpenTelemetry Collector pipelines, deployment state and verified outcomes in Splunk.
This is end-to-end visibility. It moves the conversation beyond whether a collector is installed or healthy and towards whether your organization has the telemetry it needs to deliver the outcome it committed to support.
Why This Requires Specialised AI Agents
The operational complexity of modern telemetry estates is growing quickly. OpenTelemetry Collectors can receive, process and export logs, metrics and traces through highly configurable pipelines. OpAMP-compatible management can provide controlled remote configuration and collector status at fleet scale. Splunk can turn correctly onboarded telemetry into monitoring, detections, dashboards and operational intelligence.
But the critical work happens between these layers.
Someone must understand which telemetry a use case depends on. Someone must determine whether that requirement should be implemented through Splunk collection, an OpenTelemetry Collector, a gateway or a mixed architecture. Someone must create the correct configuration, understand how the data should be transformed, govern the rollout and verify the resulting Splunk outcome.
Across thousands of systems and thousands of potential use cases, this is not a task that can be handled efficiently through manual configuration or generic AI assistance.
Deslicer AI is being built around specialised agents with deep context in Splunk, OpenTelemetry and telemetry use cases. These agents enable a workflow where your team can begin with an objective and move through implementation and verification with domain-specific guidance at every step.
For example, a security requirement may depend on log sources, field normalization, routing and detection content. A platform reliability requirement may depend on metrics, traces and log correlation from OpenTelemetry pipelines. A compliance requirement may depend on consistent evidence from multiple systems and verified data coverage over time.
Each objective requires more than collection. It requires intelligence that understands both the source technology and the outcome expected in Splunk.
That is what Deslicer AI adds: the specialised operational intelligence required to turn telemetry configuration into verified enterprise value.
Managing OpenTelemetry collector configuration with Deslicer AI
Once you know which outcome you need to support, the next challenge is implementing the telemetry pipeline that delivers it.
OpenTelemetry Collectors use configurable pipelines built from receivers, processors, exporters and connectors. These pipelines determine what telemetry is collected, how it is parsed, filtered or enriched, and where it is delivered. That flexibility is powerful, but at enterprise scale it also creates a significant configuration-management challenge.
Deslicer AI is being extended to manage this challenge as part of the same end-to-end lifecycle used for telemetry onboarding and verification. Starting from a selected use case, specialised Deslicer AI agents will help determine the required telemetry, create the appropriate OpenTelemetry Collector or Splunk configuration, and connect the implementation to the outcome it is intended to support in Splunk.
For your organization, this means that Collector and gateway setup does not need to become another isolated engineering discipline. Deslicer AI will provide a governed way to manage:
- Collector and gateway onboarding.
- Receiver, processor and exporter configuration.
- Parsing, normalization, enrichment and routing rules.
- Splunk destinations and expected data outcomes.
- Configuration validation before rollout.
- Verification after deployment.
Consider an application that produces raw logs which cannot directly support the dashboard, detection or investigation your team requires. The technical task is not simply to forward those logs. The data may need to be collected, parsed, enriched, normalized and delivered in the correct form to Splunk.
Deslicer AI connects that requirement to the implementation. It helps translate the expected outcome into the appropriate telemetry pipeline, governs the change through the Deslicer Automation Platform and verifies whether the resulting data supports the Splunk outcome your team depends on.
This is the difference between deploying telemetry infrastructure and delivering operational value.
Operating collector fleets with OpAMP compatible management
As OpenTelemetry adoption expands beyond pilots, configuration becomes a fleet-management concern.
You need to know which Collectors and gateways are deployed, what configuration they are intended to run, what configuration they are actually running, whether they are healthy and whether a change has improved or disrupted telemetry coverage.
OpAMP provides a standards-based mechanism for remotely managing telemetry agents, including configuration delivery, status reporting and package updates. Deslicer AI is being built to use these capabilities as part of a governed operating model for OpenTelemetry Collector and gateway estates.
The value to you is not simply protocol support. It is accountability across the complete lifecycle.
Deslicer AI will connect:
- the use case your organization needs to support
- the Collector or gateway configuration required to support it
- the approved deployment or configuration change
- the effective state reported from the running estate
- the telemetry outcome verified in Splunk
The Deslicer Automation Platform provides the governed execution and operational control required to apply those decisions safely across the estate. Deslicer AI provides the intelligence required to determine what should be changed, why it matters and whether the result is correct.
Together, this gives you a practical way to scale OpenTelemetry without losing visibility or control: not simply by deploying more Collectors, but by operating telemetry pipelines as a managed capability tied directly to measurable outcomes.
What Deslicer AI solves for your organization
One View Across Splunk and OpenTelemetry
Operate existing Splunk collection, OpenTelemetry Collectors and gateways through one outcome-oriented model rather than separate technology silos.
Faster delivery of priority use cases
Start from thousands of structured monitoring, security, compliance and business use cases, then translate the priorities that matter to you into practical telemetry implementations.
Governed OpenTelemetry adoption
Introduce Collector and gateway capabilities through controlled configuration, deployment and verification workflows rather than disconnected engineering projects.
Fleet-level operational confidence
Use OpAMP-compatible management together with Deslicer AI to understand intended configuration, reported effective state, Collector health and the outcome associated with each rollout.
Verified value in Splunk
Confirm that the logs, metrics and traces required for searches, detections, dashboards, KPIs and compliance controls are present, correctly shaped and useful.
Lower modernization risk
Adopt OpenTelemetry alongside existing Splunk investments without forcing a disruptive migration or creating a fragmented telemetry operating model.
Modernize telemetry without losing control
OpenTelemetry should increase your flexibility. It should not make your operating model harder to govern.
For many enterprises, the right strategy will not be an immediate replacement of existing Splunk collection. Some use cases will continue to be well served through Splunk Universal Forwarders and established onboarding patterns. Others will benefit from OpenTelemetry Collectors and gateways, particularly where modern logs, metrics, traces and flexible processing pipelines are required.
Deslicer AI enables you to make these decisions based on outcomes rather than technology preference.
You can introduce OpenTelemetry where it strengthens your telemetry strategy, retain Splunk collection where it remains appropriate and manage both through one lifecycle built around required use cases, controlled implementation, observed configuration and verified results.
For a technology leader, this creates a stronger basis for investment decisions. Instead of measuring progress through the number of Collectors deployed or the volume of data ingested, you can understand which operational, security, compliance and business outcomes are supported by live telemetry, where coverage is incomplete and how new priorities can be delivered with confidence.
Deslicer AI is the enabling layer
OpenTelemetry standardizes how telemetry is collected, processed and exported. Splunk provides the platform where telemetry becomes monitoring, investigation, detection and operational decision-making.
Deslicer AI connects the two into a managed, outcome-driven lifecycle.
With specialised AI agents that understand Splunk, OpenTelemetry Collector pipelines and OpAMP-compatible fleet operations, Deslicer AI is being built to help you move from required outcome to generated implementation, governed deployment, observed state and verified value in Splunk.
This gives you a practical path to operate Splunk Universal Forwarders, OpenTelemetry Collectors and gateways as one governed telemetry environment—without losing the visibility and accountability required for enterprise adoption.