Dt Obs Tracing logo

Dt Obs Tracing

Organization
Dynatrace
dt-obs-tracing

Distributed traces, spans, service dependencies, and request flow analysis. Use when investigating span-level details, failures, performance bottlenecks, or trace correlation. Trigger: "trace analysis", "slow requests", "failed spans", "service dependencies", "distributed trace", "span details", "HTTP status codes in traces", "database query spans", "messaging spans", "gRPC calls", "Lambda cold starts", "trace ID lookup", "exception analysis", "correlate logs and traces", "request attributes". Do NOT use for explaining existing queries, product documentation or configuration questions, service-level RED metrics (use dt-obs-services), log searching (use dt-obs-logs), or problem analysis (use dt-obs-problems).

Overview

PublisherDynatrace
Repositorydynatrace-for-ai
Skill namedt-obs-tracing
Stars
156
Forks
30
Bundled files
12
LicenseApache-2.0
Links
  • Markdown instructions

    A SKILL.md file the model loads on demand, so it only costs tokens when a request actually matches.

  • Works with any LLM

    AI skills are plain Markdown, not provider-specific code, so this works with GPT, Claude, Gemini, Grok, or a local model.

  • 12 bundled files

    Scripts, templates, and references the model can read while it works. Files are read-only and never executed.

  • Open source

    Published by Dynatrace on GitHub. Read the source before you install it.

Installation

Install the Dt Obs Tracing AI skill in TypingMind to use it with any LLM, or drop it into another agent that reads SKILL.md.

1

Install in TypingMind

TypingMind installs a skill straight from its GitHub folder — it reads SKILL.md, bundles the resource files, and stores the result locally.

  1. Open the app and go to Plugins → Skills.
  2. Choose "Install from GitHub".
  3. Paste the skill folder URL below and confirm.
  4. Enable the skill in any chat where you want it available.
Plugins → Skills → Add skill → From GitHub URL, then paste the folder URL and press Continue.
2

Install in another agent

Any agent that reads the Agent Skills format can use this skill — copy the folder into that agent's skills directory.

Claude Code — .claude/skills
git clone --depth 1 https://github.com/Dynatrace/dynatrace-for-ai.git /tmp/dynatrace-for-ai
mkdir -p .claude/skills
cp -r /tmp/dynatrace-for-ai/skills/dt-obs-tracing .claude/skills/dt-obs-tracing
Restart Claude Code after copying so it picks up the new skill.

Use it in TypingMind

Enable Dt Obs Tracing in any TypingMind chat and the model takes it from there. Its name and description sit in the system prompt, and the moment a request matches, the model loads the full instructions itself — you never invoke it by hand, and it costs no tokens until it is actually used.

The model loads Dt Obs Tracing on its own as soon as a request matches it.

Works with any AI model

AI skills are plain Markdown instructions rather than provider-specific code, so Dt Obs Tracing is not tied to the model it was written for. Install it once in TypingMind and use it with GPT-5, Claude, Gemini, Grok, DeepSeek, Mistral, Llama, or a local model you run yourself — all on your own API keys.

  • Loaded only when it is needed

    The system prompt carries just the name and description. The instructions are fetched on the first matching request, so an idle skill costs nothing.

  • Switch models mid-chat

    Because the skill is instructions rather than code, changing model does not break it — the next model reads the same SKILL.md.

Skill instructions

This is the SKILL.md content the model loads. Read it before installing — a skill is instructions your model will follow.

Application Tracing Skill

Overview

Distributed traces in Dynatrace consist of spans - building blocks representing units of work. With Traces in Grail, every span is accessible via DQL with full-text searchability on all attributes. This skill covers trace fundamentals, common analysis patterns, and span-type specific queries.


Use Cases

1. Investigate Slow Requests

  • Goal: Find and diagnose requests exceeding a latency threshold
  • Trigger: "slow requests", "high latency", "p99 response time", "find traces over 5 seconds"
  • Done: List of slow traces with duration, endpoint, service, and trace IDs for drilldown

2. Analyze Request Failures

  • Goal: Identify failed requests, failure reasons, and exception patterns
  • Trigger: "failed spans", "HTTP 500 errors", "exception analysis", "failure rate by service"
  • Done: Failure breakdown by reason (HTTP code, exception, gRPC status) with exemplar traces

3. Map Service Dependencies

  • Goal: Understand service-to-service communication patterns and external API calls
  • Trigger: "service dependencies", "what services does X call", "outgoing HTTP calls"
  • Done: Dependency map showing call counts, latency, and error rates between services

Core Concepts

Understanding Traces and Spans

Spans represent logical units of work in distributed traces:

  • HTTP requests, RPC calls, database operations
  • Messaging system interactions
  • Internal function invocations
  • Custom instrumentation points

Span kinds:

  • span.kind: server - Incoming call to a service
  • span.kind: client - Outgoing call from a service
  • span.kind: consumer - Incoming message consumption call to a service
  • span.kind: producer - Outgoing message production call from a service
  • span.kind: internal - Internal operation within a service

Root spans: A request root span (request.is_root_span == true) represents an incoming call to a service. Use this to analyze end-to-end request performance.

Key Trace Attributes

Essential attributes for trace analysis:

AttributeDescription
trace.idUnique trace identifier
span.idUnique span identifier
span.parent_idParent span ID (null for root spans)
request.is_root_spanBoolean, true for request entry points
request.is_failedBoolean, true if request failed
durationSpan duration in nanoseconds
span.timing.cpuOverall CPU time of the span (stable)
span.timing.cpu_selfCPU time excluding child spans (stable)
dt.smartscape.serviceService Smartscape node ID
dt.service.nameDynatrace service name derived from service detection rules. It is equal to the Smartscape service node name.
endpoint.nameEndpoint/route name

Service Context

Spans reference services via Smartscape node IDs and the detected service name dt.service.name which is also present on every span.

dql
fetch spans
| summarize spans=count(), by: { dt.smartscape.service, dt.service.name }

Node functions:

  • getNodeName(dt.smartscape.service) - Adds dt.smartscape.service.name field with the human-readable service name
  • getNodeField(dt.smartscape.service, "attribute_name") - Access specific node attributes

📖 Learn more: See Entity Lookups for advanced entity selectors, infrastructure correlation, and hardware analysis.

Sampling and Extrapolation

One span can represent multiple real operations due to:

  • Aggregation: Multiple operations in one span (aggregation.count)
  • ATM (Adaptive Traffic Management): Head-based sampling by agent
  • ALR (Adaptive Load Reduction): Server-side sampling
  • Read Sampling: Query-time sampling via samplingRatio parameter

When to extrapolate: Always extrapolate when counting actual operations (not just spans). Use the multiplicity factor:

dql
fetch spans
| fieldsAdd sampling.probability = (power(2, 56) - coalesce(sampling.threshold, 0)) * power(2, -56)
| fieldsAdd sampling.multiplicity = 1 / sampling.probability
| fieldsAdd multiplicity = coalesce(sampling.multiplicity, 1)
                         * coalesce(aggregation.count, 1)
                         * dt.system.sampling_ratio
| summarize operation_count = sum(multiplicity)

📖 Learn more: See Sampling and Extrapolation for detailed formulas and examples.

Common Query Patterns

Basic Span Access

Fetch spans and explore by type:

dql
fetch spans | limit 1

Explore spans by function and type:

dql
fetch spans
| summarize count(), by: { span.kind, code.namespace, code.function }

Request Root Filtering

List request root spans (incoming service calls):

dql
fetch spans
| filter request.is_root_span == true
| fields trace.id, span.id, start_time, response_time = duration, endpoint.name
| limit 100

Service Performance Summary

Analyze service performance with error rates:

dql
fetch spans
| filter request.is_root_span == true
| summarize
    total_requests = count(),
    failed_requests = countIf(request.is_failed == true),
    avg_duration = avg(duration),
    p95_duration = percentile(duration, 95),
    by: {dt.service.name}
| fieldsAdd error_rate = (failed_requests * 100.0) / total_requests
| sort error_rate desc

Trace ID Lookup

Find all spans in a specific trace:

dql
fetch spans
| filter trace.id == toUid("abc123def456")
| fields span.name, duration, dt.service.name

Performance Analysis

Response Time Percentiles

Calculate percentiles by endpoint:

dql
fetch spans
| filter request.is_root_span == true
| summarize {
    requests=count(),
    avg_duration=avg(duration),
    p95=percentile(duration, 95),
    p99=percentile(duration, 99)
  }, by: { endpoint.name }
| sort p99 desc

💡 Best practice: Use percentiles (p95, p99) over averages for performance insights.

Slow Trace Detection

Find requests exceeding a threshold:

dql
fetch spans, from:now() - 2h
| filter request.is_root_span == true
| filter duration > 5s
| fields trace.id, span.name, dt.service.name, duration
| sort duration desc
| limit 50

Duration Buckets with Exemplars

dql
fetch spans, from:now() - 24h
| filter http.route == "/api/v1/storage/findByISBN"
| summarize {
    spans=count(),
    trace=takeAny(record(start_time, trace.id))
  }, by: { bin(duration, 10ms) }
| fields `bin(duration, 10ms)`, spans, trace.id=trace[trace.id], start_time=trace[start_time]

Performance Timeseries

Extract response time as timeseries:

dql
fetch spans, from:now() - 24h
| filter request.is_root_span == true
| makeTimeseries {
    requests=count(),
    avg_duration=avg(duration),
    p95=percentile(duration, 95),
    p99=percentile(duration, 99)
  }, by: { endpoint.name }

📖 Learn more: See Performance Analysis for advanced patterns and timeseries techniques.

Failure Investigation

Failed Request Summary

Summarize failures by service:

dql
fetch spans
| filter request.is_root_span == true
| summarize
    total = count(),
    failed = countIf(request.is_failed == true),
  by: { dt.service.name }
| fieldsAdd failure_rate = (failed * 100.0) / total
| sort failure_rate desc

Failure Reason Analysis

Breakdown by failure detection reason:

dql
fetch spans
| filter request.is_failed == true and isNotNull(dt.failure_detection.results)
| expand dt.failure_detection.results
| summarize count(), by: { dt.failure_detection.results[reason] }

Failure reasons:

  • http_code - HTTP response code triggered failure
  • grpc_code - gRPC status code triggered failure
  • exception - Exception caused failure
  • span_status - Span status indicated failure
  • custom_rule - Custom failure detection rule matched

HTTP Code Failures

Find failures by HTTP status code:

dql
fetch spans
| filter request.is_failed == true
| filter iAny(dt.failure_detection.results[][reason] == "http_code")
| summarize count(), by: { http.response.status_code, endpoint.name }
| sort `count()` desc

Recent Failed Requests

List recent failures with details:

dql
fetch spans
| filter request.is_root_span == true and request.is_failed == true
| fields
    start_time,
    trace.id,
    endpoint.name,
    http.response.status_code,
    duration
| sort start_time desc
| limit 100

📖 Learn more: See Failure Detection for exception analysis and custom rule investigation.

Service Dependencies

Service-to-Service Analysis

Analyze service communication patterns:

dql
fetch spans, from:now() - 1h
| filter isNotNull(server.address)
| fieldsAdd
    remote_side = server.address
| summarize
    call_count = count(),
    avg_duration = avg(duration),
    by: {dt.service.name, remote_side}
| sort call_count desc

Outgoing HTTP Calls

Identify external API dependencies:

dql
fetch spans
| filter span.kind == "client" and isNotNull(http.request.method)
| summarize
    calls = count(),
    avg_latency = avg(duration),
    p99_latency = percentile(duration, 99),
  by: { dt.service.name, server.address, server.port }
| sort calls desc

Trace Aggregation

Complete Trace Analysis

Aggregate all spans in a trace to understand full request flow:

dql
fetch spans, from:now() - 30m
| summarize {
    spans = count(),
    client_spans = countIf(span.kind == "client"),

    // Endpoints involved in the trace
    endpoints = toString(arrayRemoveNulls(collectDistinct(endpoint.name))),

    // Extract the first request root in the trace
    trace_root = takeMin(record(
        root_detection_helper = coalesce(
            if(request.is_root_span, 1),
            if(isNull(span.parent_id), 2),
            3),
        start_time, endpoint.name, duration
      ))
}, by: { trace.id }

| fieldsFlatten trace_root
| fieldsRemove trace_root.root_detection_helper, trace_root

| fields
    start_time = trace_root.start_time,
    endpoint = trace_root.endpoint.name,
    response_time = trace_root.duration,
    spans,
    client_spans,
    endpoints,
    trace.id
| sort start_time
| limit 100

Root detection strategy: Use takeMin(record(...)) with a detection helper to reliably find the root request:

  1. Priority 1: Spans with request.is_root_span == true
  2. Priority 2: Spans without parent (root spans)
  3. Priority 3: All other spans

Multi-Service Traces

Find traces spanning multiple services:

dql
fetch spans, from:now() - 1h
| summarize {
    services = collectDistinct(dt.service.name),
    trace_root = takeMin(record(root_detection_helper = coalesce(if(request.is_root_span, 1), 2), endpoint.name))
}, by: { trace.id }
| fieldsAdd service_count = arraySize(services)
| filter service_count > 1
| fields endpoint = trace_root[endpoint.name], service_count, services = toString(services), trace.id
| sort service_count desc
| limit 50

Request-Level Analysis

Request Attributes

Access custom request attributes captured by OneAgent on request root spans:

dql
fetch spans
| filter request.is_root_span == true
| filter isNotNull(request_attribute.PaidAmount)
| makeTimeseries sum(request_attribute.PaidAmount)

Field patterns: request_attribute.<name>, captured_attribute.<name> (always arrays)

Request Attributes — full patterns for request attributes, captured attributes, and request ID aggregation

Span Types

Span TypeDetectionKey FieldsReference
HTTP server (incoming)span.kind == "server" and isNotNull(http.request.method)http.route, http.request.method, http.response.status_codehttp-spans.md
HTTP client (outgoing)span.kind == "client" and isNotNull(http.request.method)server.address, server.porthttp-spans.md
Databasespan.kind == "client" and isNotNull(db.system)db.system, db.namespace, db.statementdatabase-spans.md
MessagingisNotNull(messaging.system)messaging.system, messaging.destination.name, messaging.operation.typemessaging-spans.md
RPC / gRPCisNotNull(rpc.system)rpc.system, rpc.service, rpc.method, rpc.grpc.status_coderpc-spans.md
Serverless / FaaSisNotNull(faas.name) and span.kind == "server"faas.name, faas.trigger.type, cloud.providerserverless-spans.md

⚠️ Database spans: Can be aggregated (one span = multiple calls). Always use aggregation.count extrapolation for accurate operation counts.

📖 Detailed patterns per span type: See the reference files above.

Advanced Topics

Exception Analysis

Exceptions are stored as span.events within spans:

dql
fetch spans
| filter iAny(span.events[][span_event.name] == "exception")
| expand span.events
| fieldsFlatten span.events, fields: { exception.type }
| summarize {
    count(),
    trace=takeAny(record(start_time, trace.id))
  }, by: { exception.type }
| fields exception.type, `count()`, trace.id=trace[trace.id], start_time=trace[start_time]

💡 Tip: Use iAny() to check conditions within span event arrays.

Logs Correlation — joining logs and traces, filtering traces by log content → Network Analysis — client IPs, DNS resolution, subnet analysis

Best Practices

AreaRule
FilteringApply request.is_root_span == true and endpoint filters first
SamplingUse samplingRatio (e.g., 100 = read 1%) for performance
PercentilesUse p95/p99 over averages for performance analysis
Root spansUse request.is_root_span == true for end-to-end analysis
Trace groupingGroup by trace.id for complete trace metrics
Request groupingGroup by request.id for OneAgent-only request metrics
ExtrapolationAlways apply multiplicity for accurate operation counts
ExemplarsUse takeAny(record(start_time, trace.id)) to enable UI drilldown

Troubleshooting

ProblemCauseSolution
Duration values seem wrong (too large)duration is in nanoseconds, not millisecondsDivide by 1000000 or compare with 5s (DQL duration literal)
Span counts don't match expected request volumeSampling or aggregation not accounted forUse multiplicity extrapolation — see Sampling and Extrapolation reference
getNodeName(dt.smartscape.service) returns nullService not yet resolved or OneAgent not monitoringVerify OneAgent monitors the service; entity resolution may have a short delay
request.is_root_span filter returns nothingQuerying OpenTelemetry-only traces without OneAgentUse isNull(span.parent_id) as fallback for root span detection
trace.id filter returns no resultsTrace ID not converted to UID formatUse filter trace.id == toUid("abc123...") for string-based trace IDs
Database span counts are too lowDatabase spans are aggregated (one span = N calls)Always use aggregation.count extrapolation for database operation counts

Related Skills

  • dt-dql-essentials — Core DQL syntax for querying trace data
  • dt-app-dashboards — Embed trace queries in dashboards
  • dt-migration — Smartscape entity model and relationship navigation

References

Detailed documentation for specific topics:

Bundled files

The model reads these on demand while the skill is loaded. They are exposed as readable files and are never executed.

Frequently asked questions

What does the Dt Obs Tracing AI skill do?

Distributed traces, spans, service dependencies, and request flow analysis. Use when investigating span-level details, failures, performance bottlenecks, or trace correlation. Trigger: "trace analysis", "slow requests", "failed spans", "service dependencies", "distributed trace", "span details", "HTTP status codes in traces", "database query spans", "messaging spans", "gRPC calls", "Lambda cold starts", "trace ID lookup", "exception analysis", "correlate logs and traces", "request attributes". Do NOT use for explaining existing queries, product documentation or configuration questions, serv...

Why use Dt Obs Tracing on TypingMind?

Because you install it once and use it with any model. Dt Obs Tracing is plain Markdown rather than provider-specific code, so the same skill runs on GPT-5, Claude, Gemini, Grok, or a local model — and you can switch model mid-chat without it breaking. TypingMind runs on your own API keys, so you pay providers directly instead of a per-seat subscription, and your skills and chats stay in your own storage.

How do I install Dt Obs Tracing in TypingMind?

Open Plugins → Skills → Install from GitHub in TypingMind and paste https://github.com/Dynatrace/dynatrace-for-ai/tree/main/skills/dt-obs-tracing. TypingMind reads its SKILL.md and bundles its files and installs it as a skill you can enable per chat.

Which AI models can use Dt Obs Tracing?

Any model you connect in TypingMind. AI skills are plain Markdown instructions rather than provider-specific code, so GPT, Claude, Gemini, Grok, and local models can all load this skill when a request matches it.

How many AI models can I use with Dt Obs Tracing?

As many as you like. As long as a model supports skills, you can use Dt Obs Tracing with it — GPT, Claude, Gemini, Grok, DeepSeek, Mistral, Llama and more — all on TypingMind with your own API keys.

Is the Dt Obs Tracing AI skill free?

Yes. It is published on GitHub by Dynatrace under the Apache-2.0 license. You only pay your own AI provider for the tokens you use.

What are AI skills?

An AI skill is a reusable instruction bundle that teaches an AI model how to do one specific task. It follows the open Agent Skills format: a SKILL.md file with a name and description, plus any scripts, templates or reference files the model may need. The model reads the instructions only when your request matches the skill, so an installed skill costs nothing until it is used.

How are AI skills different from plugins or MCP servers?

A plugin or MCP server gives a model new tools to call — code that runs somewhere and returns a result. An AI skill gives the model knowledge and process instead: how to approach a task, which steps to follow, what good output looks like. Skills are plain Markdown, so they need no server, no API key and no runtime, and they work with any model.

View all

Set up your own AI workspace now

Get notified about new features and future giveaways by subscribing to our newsletter 👇