A hands-on guide to using Observability Studio to audit instrumentation, inspect traces and logs, and validate dashboards.
If you have added OpenTelemetry (OTel) to an application, the next question is practical: are the signals complete, connected, and useful when something breaks? This walkthrough shows how Observability Studio, a new open source project from Splunk, can help you inspect an OTel project, find instrumentation gaps, and move from a trace to its related logs and dashboards. The goal is a repeatable validation loop you can use before a change reaches production.
Start with an audit
Observability Studio provides an AI-assisted workspace for exploring an application’s telemetry setup and generating relevant configuration or analysis. Begin by opening your project in the Studio and running an audit. Review the report as a set of actionable findings: confirm which services and signals are detected, identify missing instrumentation or configuration, and prioritize the gaps that block useful troubleshooting.
Treat generated guidance as a proposal. Check it against your repository, deployment environment, and team conventions before applying changes.
Add instrumentation and verify the result
Use the audit findings to guide the next change. From the Observability Studio repository, run the installer for the coding-agent environment:
./obstudio install --target=codex
Then use the relevant OpenTelemetry skills in your coding agent to review or update instrumentation. Follow the current installation guide for prerequisites and supported targets.
After applying a change, run the application and generate representative traffic. Confirm that telemetry reaches the expected local or configured backend, that service and environment attributes are present, and that resource names match the conventions your dashboards and detectors expect. Keep secrets out of source control and avoid forwarding telemetry to a shared or cloud destination unless your organization has approved that data flow.
Follow a request through its trace
A trace is most useful when its spans tell a coherent story across service boundaries. Open a representative request and inspect the waterfall: check parent-child relationships, service names, timing, errors, and important span attributes. A broken or fragmented trace can reveal missing context propagation, inconsistent resource attributes, or a service that is not exporting spans.
Connect logs to trace context
When the trace points to a slow or failing operation, follow the trace and span context into the related logs. Verify that logs carry the identifiers needed to correlate them with the request. This makes it easier to move from “this request failed” to the specific service event that explains why.
Turn findings into dashboards and detectors
Once the signal path is working, build the views that help a team notice regressions. Use the Studio’s supported Splunk skills, such as $splunk-dashboard and detector workflows, to draft a dashboard or alert from the telemetry and questions you care about. Review every generated query, threshold, and dimension; validate it against real traffic and expected behavior before relying on it for response.
A repeatable pre-ship check
Before shipping an instrumentation change, verify that services and resources are named consistently, traces remain connected across boundaries, errors and latency are visible, and logs include the context needed to pivot from an affected request. Then confirm your dashboards and detectors still reflect the behavior you intend to monitor. Capture unresolved gaps in the pull request so they are visible to reviewers.
Observability Studio can shorten the distance between “we installed the SDK” and “we can use the telemetry.” Start with one service, follow a real request end to end, and expand the workflow as the instrumentation becomes more complete.
Try it and share what you find
Explore the project and setup instructions:
What is the first gap you would check in your own telemetry setup? Leave a question or tell us where you got stuck in the comments. I’m especially interested in which step—instrumentation, trace context, log correlation, or alert design—takes the most effort in your environment.
Top comments (0)