mirror of
https://github.com/Dynatrace/dynatrace-for-ai.git
synced 2026-09-19 03:52:19 +08:00
Christian Konnaris
committed by
GitHub
GitHub
parent
6ca0baa0e4
commit
4991356210
@@ -1,7 +1,10 @@
|
||||
---
|
||||
agent: agent
|
||||
description: Generate a daily standup report for one or more services.
|
||||
argument-hint: Optional list of services to include in the report
|
||||
---
|
||||
Generate a daily standup report for my services: [service-1, service-2, service-3].
|
||||
Generate a daily standup report for my services.
|
||||
If no specific services are provided, infer from current workspace and ask user to confirm.
|
||||
|
||||
For each service:
|
||||
1. Health status (healthy/degraded/critical)
|
||||
@@ -12,7 +15,3 @@ For each service:
|
||||
|
||||
Format as concise bullet points I can share with my team.
|
||||
Use Dynatrace to gather all metrics.
|
||||
|
||||
---
|
||||
|
||||
**Related skills:** dt-dql-essentials, dt-obs-services, dt-obs-problems
|
||||
@@ -1,19 +1,16 @@
|
||||
---
|
||||
agent: agent
|
||||
description: Check the health of a service in production.
|
||||
---
|
||||
|
||||
Check the health of [service-name] in production.
|
||||
Check the health of my service in production.
|
||||
Infer service-name from current workspace if not provided. Ask user to confirm if not sure.
|
||||
|
||||
Show me:
|
||||
1. Current performance metrics (response time, errors, throughput)
|
||||
2. Any active problems or alerts
|
||||
2. Any active problems or alerts
|
||||
3. Recent deployments and their impact
|
||||
4. Top 5 slowest endpoints
|
||||
5. Any security vulnerabilities
|
||||
|
||||
Use Dynatrace to gather data. Summarize if everything looks normal or if I need to investigate specific issues.
|
||||
|
||||
---
|
||||
|
||||
**Related skills:** dt-dql-essentials, dt-obs-services, dt-obs-problems
|
||||
@@ -1,4 +1,5 @@
|
||||
---
|
||||
agent: agent
|
||||
description: Respond to an active production incident. Retrieves all active Davis Problems, explains root cause in plain English, surfaces user impact and affected traces, prioritizes by business severity, and generates a shareable incident report.
|
||||
---
|
||||
|
||||
@@ -14,7 +15,3 @@ We have a production incident. Help me investigate:
|
||||
|
||||
Work through this systematically using Dynatrace.
|
||||
Be thorough but concise - this is an active incident.
|
||||
|
||||
---
|
||||
|
||||
**Related skills:** dt-dql-essentials, dt-obs-problems, dt-obs-tracing, dt-obs-logs
|
||||
@@ -1,10 +1,13 @@
|
||||
---
|
||||
agent: agent
|
||||
description: Investigate recent errors in a service using Davis Problems as the starting point (problems → logs → traces).
|
||||
argument-hint: Optional specific service or timeframe for the investigation
|
||||
---
|
||||
Investigate recent errors in [service-name] using Dynatrace Davis Problems as the entry point.
|
||||
|
||||
Investigate recent errors in my service using Dynatrace Davis Problems as the entry point.
|
||||
Infer service-name from the current workspace. Ask user to confirm, or provide a specific timeframe/entity scope if unsure.
|
||||
|
||||
1. Query Dynatrace for active Davis Problems related to the service and obtain their timeframe and affected entities.
|
||||
1. Use root_cause_agent to identify relevant Davis Problems for the service and obtain their timeframe and affected entities.
|
||||
2. For each selected problem, use the problem's timeframe and entities to:
|
||||
- Search for ERROR level logs scoped to that context
|
||||
- Group results by error message/type
|
||||
@@ -16,7 +19,3 @@ Infer service-name from the current workspace. Ask user to confirm, or provide a
|
||||
4. Suggest root cause and remediation steps based on the combined problem, log, and trace analysis.
|
||||
|
||||
Use Dynatrace to gather all data.
|
||||
|
||||
---
|
||||
|
||||
**Related skills:** dt-dql-essentials, dt-obs-services, dt-obs-problems, dt-obs-tracing, dt-obs-logs
|
||||
@@ -0,0 +1,109 @@
|
||||
---
|
||||
agent: agent
|
||||
description: Analyze whether a recent deployment caused a performance regression and recommend rollback or hotfix.
|
||||
---
|
||||
|
||||
# Performance Regression Analysis
|
||||
|
||||
## Rules
|
||||
|
||||
- **ALWAYS confirm the service name with the user before querying.** Infer it from the current workspace if not provided.
|
||||
- **NEVER query without a scoped timeframe and entity.** Broad queries hit scan limits and return no results.
|
||||
- **STOP at Step 2 if no regression threshold is exceeded.** Do not proceed to trace investigation unnecessarily.
|
||||
|
||||
## Step 1 — Establish the investigation window
|
||||
|
||||
Ask the user: "When did the suspected regression start? (e.g. 'about 2 hours ago', 'today at 14:30', or a date range)"
|
||||
Default to the **last 24 hours** if the user has no specific time in mind.
|
||||
|
||||
Then use the **Data Analysis Agent** to find the latest deployment event for the service within the investigation window, filtered to the confirmed service entity.
|
||||
|
||||
**If a deployment event is found:**
|
||||
Use the deployment timestamp as the regression boundary. Split the window into:
|
||||
- **Before:** `[deploymentTime - 35min, deploymentTime - 5min]`
|
||||
- **After:** `[deploymentTime + 5min, deploymentTime + 35min]`
|
||||
|
||||
**If no deployment event is found:**
|
||||
Do not stop. Use the midpoint of the investigation window as the boundary:
|
||||
- **Before:** first half of the window
|
||||
- **After:** second half of the window
|
||||
|
||||
State clearly which boundary was used and why.
|
||||
|
||||
## Step 2 — Compare metrics before and after
|
||||
|
||||
Use the **Data Analysis Agent** to query P95 response time, error rate, and throughput for each window, scoped to the confirmed service entity.
|
||||
|
||||
**A regression is confirmed when any threshold is exceeded:**
|
||||
|
||||
| Signal | Regression threshold |
|
||||
|---|---|
|
||||
| P95 response time | Increased by >20% **or** absolute value >2 s (>2,000,000,000 ns) |
|
||||
| Error rate | Increased by >1 percentage point |
|
||||
| Throughput | Dropped by >20% (without a corresponding drop in traffic) |
|
||||
|
||||
---
|
||||
|
||||
### If NO regression threshold is met — STOP HERE
|
||||
|
||||
Output the following summary and do not proceed to Step 3:
|
||||
|
||||
```
|
||||
## No Regression Detected
|
||||
|
||||
- Service: <service-name>
|
||||
- Investigation window: <before-window> vs <after-window>
|
||||
- Regression boundary: <deployment event or midpoint>
|
||||
- P95 response time: <before> → <after> (<delta>%) — within threshold
|
||||
- Error rate: <before> → <after> — within threshold
|
||||
- Throughput: <before> → <after> — within threshold
|
||||
|
||||
No action required. If you suspect a regression in a different time window, re-run this prompt with a specific timeframe.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Step 3 — Identify regressed endpoints
|
||||
|
||||
Use the **Data Analysis Agent** to query span P95 durations grouped by endpoint for the after window, scoped to the confirmed service entity.
|
||||
|
||||
Flag endpoints exceeding the P95 response time threshold or a >20% increase vs. the before window. List the top 5 sorted by absolute P95 delta (worst first).
|
||||
|
||||
## Step 4 — Fetch distributed traces for slow requests
|
||||
|
||||
For the top 1–3 regressed endpoints, use the **Data Analysis Agent** to fetch slow spans within the after window, scoped to the confirmed service entity and endpoint.
|
||||
|
||||
Pick the trace with the highest duration. Build a timeline sorted by start time. Identify the **first span** whose duration is the dominant contributor — this is the bottleneck span. Record its operation name, service, duration, and any error attributes.
|
||||
|
||||
## Step 5 — Connect slow spans to workspace code changes
|
||||
|
||||
Using the bottleneck span's operation name and service, search the workspace:
|
||||
- Search for the endpoint path or operation name in route definitions, controllers, and handler files.
|
||||
- Look for recently modified files that match the slow code path (check git log or file timestamps).
|
||||
- If a match is found, show the file path and relevant lines. State explicitly which code change is the likely contributor.
|
||||
- If no match is found, state that the slow span could not be correlated to a local file.
|
||||
|
||||
## Step 6 — Check for an active Davis Problem
|
||||
|
||||
Use the **Root Cause Agent** to check for any active or recently closed Davis Problem affecting this service.
|
||||
If found, include: problem ID, title, root cause summary, and affected entities.
|
||||
|
||||
## Step 7 — Recommend: rollback or hotfix
|
||||
|
||||
Based on all findings, give one clear recommendation:
|
||||
|
||||
**Rollback** when:
|
||||
- Multiple endpoints regressed simultaneously
|
||||
- Error rate spiked significantly (>5 pp)
|
||||
- No specific code change in the workspace can be identified as the cause
|
||||
- A Davis Problem is active with no known mitigation
|
||||
|
||||
**Hotfix** when:
|
||||
- Regression is isolated to 1–2 endpoints
|
||||
- A specific code change in the workspace correlates with the slow span
|
||||
- The fix is low-risk (e.g. missing index, inefficient query, removed cache)
|
||||
|
||||
In either case, provide:
|
||||
1. The specific recommendation (rollback or hotfix) with reasoning
|
||||
2. Concrete optimization steps (e.g. which query to optimize, which cache to restore, or the rollback command)
|
||||
3. How to verify the fix: which metric/endpoint to watch and the target value
|
||||
+18
-71
@@ -1,35 +1,33 @@
|
||||
---
|
||||
description: Troubleshoot an existing Dynatrace problem. Starts by listing active problems, scopes log queries to the problem timeframe, classifies actionable errors, and hands off to trace investigation.
|
||||
agent: agent
|
||||
description: Troubleshoot an existing Dynatrace problem. Starts with the Root Cause Agent to list problems, scopes log queries to the problem timeframe, classifies actionable errors, and hands off to trace investigation.
|
||||
---
|
||||
|
||||
# Troubleshoot a Dynatrace Problem
|
||||
|
||||
You are a Dynatrace observability expert helping a developer investigate a production problem.
|
||||
|
||||
## Rules
|
||||
|
||||
- **ALWAYS start with problems.** Never do broad log searches. Query Dynatrace for active problems first, then scope all queries to problem context.
|
||||
- **ALWAYS start with problems.** Never do broad log searches. Use root_cause_agent first, then scope all queries to problem context.
|
||||
- **NEVER query logs without a problem context.** Broad log searches hit the 500GB scan limit and return 0 results.
|
||||
- **NEVER suggest checking other environments.** This prompt is for production troubleshooting only. Only mention dev/staging if the user explicitly asks.
|
||||
- **Follow the drill-down workflow:** problems → logs → traces. Load the `dt-dql-essentials` and `dt-obs-problems` skills for DQL query patterns and best practices.
|
||||
|
||||
## Input
|
||||
|
||||
This prompt accepts two input formats:
|
||||
|
||||
**Format A — Pre-filled:**
|
||||
**Format A — Pre-filled structured input:**
|
||||
> "At [timestamp], service [service-name] has the following problem: [problem message]. Explain the error and suggest how to fix it."
|
||||
|
||||
If this format is detected, extract `timestamp`, `service-name`, and `problem message` directly. Query Dynatrace to find and confirm the matching problem (do not present the full list to the user). Extract `problemId`, affected entity IDs, and the exact timeframe from the problem metadata, then proceed to step 3.
|
||||
If this format is detected, extract `timestamp`, `service-name`, and `problem message` directly. Use the **Root Cause Agent** to find and confirm the matching problem (do not present the full list to the user). Extract `problemId`, affected entity IDs, and the exact timeframe from the problem metadata, then proceed to step 3.
|
||||
|
||||
**Format B — Manual:**
|
||||
If no structured input is provided, proceed from step 1.
|
||||
|
||||
## Steps
|
||||
|
||||
### 1. List active problems *(skip if pre-filled input was provided — query Dynatrace silently to confirm problem context)*
|
||||
### 1. List active problems *(skip if pre-filled input was provided — use root_cause_agent silently to confirm problem context)*
|
||||
|
||||
Retrieve all currently active problems from Dynatrace.
|
||||
Use the **Root Cause Agent** to retrieve all currently active problems on the tenant.
|
||||
|
||||
Present results as a table:
|
||||
|
||||
@@ -56,8 +54,6 @@ From the selected problem's metadata (or from the pre-filled input), extract:
|
||||
- `problemId` (if available)
|
||||
- `startTime` and `endTime` (or "now" if the problem is still active)
|
||||
- affected entity names/IDs or service name
|
||||
|
||||
Compute the query window using a 5-minute buffer around the problem timeframe:
|
||||
```
|
||||
queryFrom = startTime - 5 min
|
||||
queryTo = endTime + 5 min (or now + 5 min if still active)
|
||||
@@ -65,32 +61,14 @@ queryTo = endTime + 5 min (or now + 5 min if still active)
|
||||
|
||||
### 4. Query logs for the problem
|
||||
|
||||
Run the following DQL query scoped to the problem context:
|
||||
Use the **Data Analysis Agent** to run a **problem-scoped** log query for the affected entities and computed timeframe.
|
||||
|
||||
```dql
|
||||
fetch logs
|
||||
| filter dt.entity.service == "<affected-entity>"
|
||||
| filter timestamp >= "<queryFrom>"
|
||||
| filter timestamp <= "<queryTo>"
|
||||
| filter loglevel == "ERROR" or loglevel == "WARN"
|
||||
| sort timestamp desc
|
||||
| limit 100
|
||||
```
|
||||
Do not hardcode DQL in this prompt. Build and validate query details using the platform's agent guardrails and observability best practices.
|
||||
|
||||
Adjust the entity filter based on what the problem metadata provides (service, host, process group, etc.).
|
||||
Adjust entity scope based on problem metadata (service, host, process group, etc.).
|
||||
|
||||
**If the query hits the 500GB data scan limit** (0 records returned, scan warning):
|
||||
1. **STOP** — the query is too broad despite problem scoping
|
||||
2. **Check what's missing:**
|
||||
- Is the entity filter correct?
|
||||
- Is the timeframe still too wide?
|
||||
3. **Narrow further:**
|
||||
- Reduce timeframe: ±5 min → ±2 min
|
||||
- Add specific error pattern if known
|
||||
4. **Ask the user for more context** if you can't narrow further:
|
||||
- "The query scanned 500GB without matches. Can you provide a more specific timeframe or error message?"
|
||||
If the query is too broad (including data-scan-limit warnings), stop and narrow scope using agent guardrails before retrying. If scope cannot be narrowed with available metadata, ask the user for a tighter timeframe or a specific error pattern.
|
||||
|
||||
If the query returns 0 results, verify the entity filter and timeframe before broadening the query scope.
|
||||
|
||||
### 5. Classify errors
|
||||
|
||||
@@ -99,15 +77,10 @@ For each distinct error message found, classify it using the table below:
|
||||
| Error Message | Count | Actionable? | Reason |
|
||||
|---|---|---|---|
|
||||
|
||||
Use this guide:
|
||||
|
||||
| Category | Examples | Actionable? |
|
||||
|---|---|---|
|
||||
| Application logic error | `NullPointerException`, `IndexOutOfBoundsException`, custom `AppError` | ✅ Yes |
|
||||
| Infrastructure / platform | `Connection refused`, `OOMKilled`, `Timeout after 30s` | ✅ Yes (platform team) |
|
||||
| Auth / permission | `403 Forbidden`, `401 Unauthorized`, `Access denied` | ⚠️ Context-dependent |
|
||||
| Expected / benign | `Request canceled by client`, `User not found` (expected 404) | ❌ No |
|
||||
| External dependency | Third-party API rate limit, partner service down | ❌ Not directly actionable |
|
||||
Use this guidance:
|
||||
- Mark errors as actionable when they indicate app logic bugs, infra/platform failures, or clearly misconfigured auth/permissions.
|
||||
- Mark as non-actionable when they represent expected behavior or third-party conditions outside immediate control.
|
||||
- If uncertain, classify as context-dependent and state what additional context is needed.
|
||||
|
||||
### 6. Investigate trace (if trace ID found)
|
||||
|
||||
@@ -115,23 +88,9 @@ Search the returned log entries for `trace_id` or `dt.trace_id` fields. This is
|
||||
|
||||
If no trace IDs appear in log fields, note this explicitly and recommend the user check if trace propagation is configured for the service.
|
||||
|
||||
If trace IDs are found, take the most relevant one and reconstruct the request flow:
|
||||
If trace IDs are found, take the most relevant one and reconstruct the request flow.
|
||||
|
||||
**Fetch spans:**
|
||||
```dql
|
||||
fetch spans
|
||||
| filter trace_id == "<trace-id>"
|
||||
| sort start_time asc
|
||||
| limit 500
|
||||
```
|
||||
|
||||
If no spans are returned, fall back to log-based trace lookup:
|
||||
```dql
|
||||
fetch logs
|
||||
| filter dt.trace_id == "<trace-id>" or trace_id == "<trace-id>"
|
||||
| sort timestamp asc
|
||||
| limit 100
|
||||
```
|
||||
Do not hardcode DQL in this prompt. Generate and validate trace/log queries using the platform's tracing and log-analysis best practices.
|
||||
|
||||
Build a timeline from the spans:
|
||||
|
||||
@@ -140,15 +99,7 @@ Build a timeline from the spans:
|
||||
|
||||
Highlight any span with `status == "ERROR"` or HTTP status ≥ 500. Identify the **first span where an error occurred** — that is the error origin.
|
||||
|
||||
For the erroring service, pull correlated logs:
|
||||
```dql
|
||||
fetch logs
|
||||
| filter dt.entity.service == "<erroring-service-id>"
|
||||
| filter dt.trace_id == "<trace-id>"
|
||||
| filter loglevel == "ERROR" or loglevel == "WARN"
|
||||
| sort timestamp asc
|
||||
| limit 100
|
||||
```
|
||||
For the erroring service, retrieve correlated logs for the same trace and timeframe.
|
||||
|
||||
Summarize the trace findings:
|
||||
- **Trace flow**: Services involved in order.
|
||||
@@ -165,7 +116,3 @@ Provide a concise summary:
|
||||
- **Top actionable errors**: Up to 5, with occurrence counts.
|
||||
- **Trace findings**: Error location, error message, and likely cause (from step 6).
|
||||
- **Recommended next steps**: e.g. check a specific service, escalate, or roll back a deployment.
|
||||
|
||||
---
|
||||
|
||||
**Related skills:** dt-dql-essentials, dt-obs-problems, dt-obs-tracing, dt-obs-logs
|
||||
@@ -1,18 +0,0 @@
|
||||
---
|
||||
description: Analyze whether a recent deployment caused a performance regression.
|
||||
---
|
||||
My recent deployment to [service-name] might have caused a slowdown.
|
||||
Infer service-name from current workspace if not provided. Ask user to confirm if not sure.
|
||||
|
||||
1. Compare metrics before and after latest deployment
|
||||
2. Identify which endpoints got slower
|
||||
3. Get distributed traces for slow requests (>2s)
|
||||
4. Find which code changes correlate with slowdown
|
||||
5. Check if there's a Davis Problem with root cause
|
||||
6. Suggest specific optimization steps
|
||||
|
||||
Use Dynatrace to get production data and provide actionable recommendations.
|
||||
|
||||
---
|
||||
|
||||
**Related skills:** dt-dql-essentials, dt-obs-services, dt-obs-tracing
|
||||
Reference in New Issue
Block a user