DAVIS problem analysis including root cause identification, impact assessment, and correlation with other telemetry. Use when querying or investigating detected problems. Trigger: "active problems", "root cause analysis", "problem impact", "affected users", "list problems", "P-12345 details", "recurring problems", "problem history", "problem trending", "blast radius", "which entity caused the problem", "problems affecting Kubernetes", "problems by service". Do NOT use for explaining existing queries, product documentation questions, generic log searching, distributed tracing, or host-level resource monitoring.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
Instruções da origem · Visualização somente leitura
name
dt-obs-problems
description
DAVIS problem analysis including root cause identification, impact assessment, and correlation with other telemetry. Use when querying or investigating detected problems. Trigger: "active problems", "root cause analysis", "problem impact", "affected users", "list problems", "P-12345 details", "recurring problems", "problem history", "problem trending", "blast radius", "which entity caused the problem", "problems affecting Kubernetes", "problems by service". Do NOT use for explaining existing queries, product documentation questions, generic log searching, distributed tracing, or host-level resource monitoring.
license
Apache-2.0
Problem Analysis Skill
Analyze Dynatrace AI-detected problems including root cause identification, impact assessment, and correlation with logs and metrics.
Use Cases
1. Active Problem Triage
Goal: List and prioritize currently active problems
Done: Prioritized list of active problems with category, user impact, and display IDs
2. Root Cause Investigation
Goal: Identify the root cause entity for a specific problem
Trigger: "root cause of P-12345", "what caused this problem", "which entity is the root cause"
Done: Root cause entity identified with affected entity list and blast radius
3. Problem Trending
Goal: Analyze problem patterns over time to identify recurring issues
Trigger: "recurring problems", "problem history", "problem trends last 30 days"
Done: Trend data showing problem frequency, recurring root causes, and resolution times
Overview
Dynatrace automatically detects anomalies, performance degradations, and failures across your environment, creating problems that aggregate related alert, warning and info-level events and provide root cause and impact insights.
What are Problems?
Problems are automatically detected, software and infrastructure health and resilience issues that:
Automatically correlate related alert, warning, and info-level events across services, infrastructure, frontend applications, and user sessions
Identify root causes using causal analysis of Smartscape dependencies
Assess business impact by tracking affected users and services
Reduce alert noise by grouping related symptoms into single problems that share the same root cause and impact
Track problem lifecycle from early detection through resolution
Event Kinds
The event.kind field (stable, permission) identifies the high-level event type:
event.kind value
Description
DAVIS_EVENT
Davis-detected infrastructure/application events
BIZ_EVENT
Business events (ingested via API or captured from spans)
RUM_EVENT
Real User Monitoring events
AUDIT_EVENT
Administrative/security audit events
event.provider (stable, permission) identifies the event source.
Problem Categories
Common event.category values:
Category
Description
Example
AVAILABILITY
Infrastructure or service unavailable
Web service returns no data, synthetic test actively fails, database connection lost
ERROR
Increased error rates beyond baseline
API error rate jumped from 0.1% to 15%
SLOWDOWN
Performance degradation
Response time increased from 200ms to 5000ms
RESOURCE
Resource saturation
Container memory at 95%, causing OOM kills
CUSTOM
Custom anomaly detections
Business KPI (orders/minute) dropped below threshold
Problem Lifecycle
Detection → ACTIVE → Under Investigation → CLOSED
ACTIVE: Currently occurring issues requiring attention
CLOSED: Resolved issues used for historical analysis
Essential Fields
Common Field Name Mistakes
❌ WRONG
✅ CORRECT
Description
title
event.name
Problem title/description
status
event.status
Problem lifecycle status
severity
event.category
Problem type/category
start
event.start
Problem start time
Correct Status Values
// ✅ CORRECT: Use these status values
fetch dt.davis.problems
| filter event.status == "ACTIVE" // Currently occurring problems
// or event.status == "CLOSED" // Resolved problems
// ❌ INCORRECT: event.status == "OPEN" does not exist!
| limit 1
Key Fields Reference
fetch dt.davis.problems, from:now() - 1h
| filter not(dt.davis.is_duplicate)
| fields
event.start, // Problem start timestamp
event.end, // Problem end timestamp (if closed)
display_id, // Human-readable problem ID (P-XXXXX)
event.name, // Problem title
event.description, // Detailed description
event.category, // Problem type
event.status, // ACTIVE or CLOSED
dt.smartscape_source.id, // The smartscape ID for the affected resource
dt.davis.affected_users_count, // Number of affected users
affected_entity_ids = smartscape.affected_entities[][id], // Array of affected entity IDs
dt.smartscape.service, // Affected services (may be array)
dt.davis.root_cause_entity, // Entity identified as root cause
root_cause_entity_id, // Root cause entity ID
root_cause_entity_name, // Human-readable root cause name
dt.davis.is_duplicate, // Whether duplicate detection
dt.davis.is_rootcause // Root cause vs. symptom
| limit 10
Standard Query Pattern
Always start problem queries with this foundation:
When summarizing problem causes, categories, or patterns, provide a comprehensive
breakdown across all standard categories present in the data: AVAILABILITY, ERROR,
SLOWDOWN, RESOURCE, and CUSTOM. For each category found:
Category name and count of problems
What triggers it — brief explanation (e.g., RESOURCE = CPU/memory/disk threshold
exceeded; AVAILABILITY = service or entity became unreachable)
Specific examples from the tenant's data (affected entity names, problem IDs)
Do not stop after the first two categories — users expect the full picture. Reference
the Problem Categories table above for trigger descriptions.
Analysis Results
When presenting query results:
Include entity names (not just IDs) — but choose the efficient method:
Few entities (< 5):get-entity-name calls are fine
Many entities: Use query-problems tool which returns names directly, or
include root_cause_entity_name / entityName() in the DQL query to resolve
names inline. Avoid calling get-entity-name in a loop for 10+ entities —
this can exhaust the tool call limit and return no answer at all.
Provide actionable recommendations aligned to the identified causes
Organize by frequency or impact for easy prioritization
Best Practices
Essential Rules
Always filter duplicates: Use not(dt.davis.is_duplicate) to avoid counting the same problem multiple times
Use correct status values: "ACTIVE" or "CLOSED", never "OPEN"
Specify time ranges: Always include time bounds to optimize performance
Include display_id: Essential for problem identification and linking
Test incrementally: Add one filter or field at a time when building queries
Filter early: Apply not(dt.davis.is_duplicate) immediately after fetch
Query Development
Start simple: Begin with basic filtering, then add complexity
Test fields first: Run with | limit 1 to verify field names exist
Use meaningful time ranges: Too broad wastes resources, too narrow misses data
Document problem IDs: Always capture and store display_id for reference
Root Cause Verification
Always filter isNotNull(root_cause_entity_id) when required
Cross-reference events using dt.davis.event_ids
Consider time delays: root cause may appear in logs minutes before problem
Time Range Guidelines
// ✅ GOOD - Specific time range
fetch dt.davis.problems, from:now() - 4h
// ❌ BAD - Scans all historical data
fetch dt.davis.problems
Absolute Timeframes Require Double Quotes
When using absolute ISO 8601 timestamps for from and to in DQL queries, always wrap them in double quotes. Unquoted timestamps are a syntax error.
