agentleFS
HugoSandoHugoSando/beacon-ops-framework/.agents/skills/dtctl/SKILL.md

dtctl

Skill0 starsChanged 6 months agoMITView on GitHub

Investigate incidents, debug performance issues, analyze logs, and manage observability resources in Dynatrace using the dtctl CLI. Use this skill whenever the user asks about error rates, latency spikes, service health, crash-looping pods, web vitals, SLO status, open problems, root cause analysis, log patterns, trace analysis, or building dashboards — even if they don't mention Dynatrace by name. Also covers DQL queries, workflow management, notebook and dashboard creation, settings configuration, and any operations against a Dynatrace environment.

2 other projects use a version of this, 1 of them edited.

Adopted by

Most recently taken up by

  • Other versions2 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 1

    1. dynatrace-oss/dtctl★ 20112% same

    Wrote their own version · 1

    1. virtualrussel/dynatrace-ai-dtctl-workspace★ 2same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repository2 other files it gives its agents.

The file

Show its rules and text

We split this skill into the rules it gives an agent

14 rules. About 0 are common, 4 are distinctive, and 10 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 10

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Before writing, modifying, or executing any DQL that fetches Dynatrace data (for example via dtctl query, dtctl wait query, or query …

    line 35
  2. Distinctive:

    If there is any conflict between memory/assumptions and the reference, prefer the reference.

    line 37
  3. Distinctive:

    If dtctl is not installed or not working, see references/troubleshooting.md for installation and setup.

    line 41
  4. Distinctive:

    Use IDs whenever possible instead of names to avoid ambiguity.

    line 75
  5. Very specific:

    Prefer get ... -o json --plain first, then describe/exec with explicit IDs.

    line 178
  6. Very specific:

    Use can-i to verify permissions before attempting operations.

    line 189
  7. Very specific:

    Create/update: dtctl apply -f dashboard.yaml --plain.

    line 218
  8. Very specific:

    Always set davis.enabled: false on data tiles.

    line 258
  9. Very specific:

    Use makeTimeseries for log/span time series.

    line 259
  10. Distinctive:

    If a name matches multiple resources, dtctl will fail

    line 266
  11. Very specific:

    Check token scopes: https://github.com/dynatrace-oss/dtctl/blob/main/docs/TOKEN_SCOPES.md

    line 271
  12. Very specific:

    Check safety level: dtctl config describe-context $(dtctl config current-context) --plain

    line 273
  13. Very specific:

    Use --plain for machine/AI consumption

    line 291
  14. Very specific:

    Use --mine flag to filter resources you own

    line 293

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Dynatrace Control with dtctl

Operate dtctl, the kubectl-style CLI for Dynatrace. This skill teaches core dtctl command patterns and operations.

Recommended Initialization

At the start of a task, run these checks to establish context and permissions:

# Discover all available commands, flags, and resources
dtctl commands --brief -o json

# Show current context
dtctl config current-context

# Show context details
dtctl config describe-context $(dtctl config current-context) --plain

# Show authenticated user
dtctl auth whoami --plain

This displays:

  • Current context name and environment URL
  • Safety level (readonly, readwrite-mine, readwrite-all, dangerously-unrestricted)
  • Authenticated user identity (name, email, UUID)

DQL Reference Usage

Before writing, modifying, or executing any DQL that fetches Dynatrace data (for example via dtctl query, dtctl wait query, or query files), you MUST consult references/DQL-reference.md and follow its documented syntax and templates.

If there is any conflict between memory/assumptions and the reference, prefer the reference.

Prerequisites

If dtctl is not installed or not working, see references/troubleshooting.md for installation and setup.

Resources & Commands

Available Resources

dtctl uses a uniform pattern for all resource types. Discover schema from actual output with dtctl describe <resource> <id> -o json --plain.

ResourceAliases
analyzeranalyzers
appapps
bucketbkt
copilot-skillcopilot-skills
dashboarddash
edgeconnectec
extensionext, extensions
extension-configextcfg, extension-configs
functionfn, func
groupgroups
intentintents
lookuplookups, lkup
notebooknb
notificationnotifications
sdk-versionsdk-versions
settingssetting
settings-schemaschema
slo-
slo-templateslo-templates
trashdeleted
userusers
workflowwf
workflow-executionwfe

Use IDs whenever possible instead of names to avoid ambiguity.

Command Verbs

VerbDescriptionExample
getList resourcesdtctl get workflows --mine
describeShow resource detailsdtctl describe workflow <id>
editEdit resource interactivelydtctl edit dashboard <id>
applyCreate/update from filedtctl apply -f workflow.yaml --set env=prod
deleteDelete resourcedtctl delete workflow <id>
execExecute workflow/function/analyzer/copilotdtctl exec workflow <id>
queryRun DQL querydtctl query "fetch logs | limit 10"
logsPrint resource logsdtctl logs workflow-execution <id>
waitWait for conditionsdtctl wait query "fetch logs" --for=any
historyShow document historydtctl history dashboard <id>
restoreRestore document versiondtctl restore dashboard <id> --version 3
shareShare documentdtctl share dashboard <id> --user email@example.com
unshareRemove sharingdtctl unshare dashboard <id> --user email@example.com
findDiscover resourcesdtctl find intents --data trace.id=abc
openOpen in browserdtctl open intent <app/intent> --data key=value
diffCompare resourcesdtctl diff -f workflow.yaml
verifyValidate without executingdtctl verify query 'fetch logs' --fail-on-warn
commandsList all commands (machine-readable)dtctl commands --brief -o json

Key Concepts for AI Agents

Output Modes

# Agent envelope mode (auto-detected in AI environments)
-A, --agent      # Structured JSON envelope with ok/result/error/context
--no-agent       # Opt out of auto-detected agent mode

# Machine-readable formats (use these for AI agents)
-o json          # JSON output
-o yaml          # YAML output
-o csv           # CSV output
-o chart         # ASCII chart (for time series)
-o sparkline     # ASCII sparkline (for time series)
-o barchart      # ASCII bar chart (for time series)

# Human-readable formats
-o table         # Table format (default)
-o wide          # Wide table with more columns

# Always use --plain flag for AI consumption (implied by --agent)
--plain          # Strips colors and prompts, best for parsing

For AI agents, prefer: dtctl <command> --agent (auto-detected) or dtctl <command> -o json --plain

The --agent envelope provides structured metadata alongside results:

{
  "ok": true,
  "result": [ ... ],
  "context": {
    "verb": "get", "resource": "workflow",
    "total": 5, "has_more": false,
    "suggestions": ["Run 'dtctl describe workflow <id>' for details"]
  }
}

Template Variables

In YAML/DQL files, use Go template syntax:

# workflow.yaml
title: "{{.environment}} Deployment"
owner: "{{.team}}"
trigger:
  schedule:
    cron: "{{.schedule | default "0 0 * * *"}}"
# query.dql
fetch logs
| filter host.name == "{{.host}}"
| filter timestamp > now() - {{.timerange | default "1h"}}

Execute with: dtctl apply -f file.yaml --set environment=prod --set team=platform

Copilot, Functions, Analyzers

# Copilot skills
dtctl get copilot-skills -o json --plain

# Functions
dtctl get functions -o json --plain
dtctl exec function <id-or-name> --payload '{"key":"value"}' --plain

# Analyzers
dtctl get analyzers -o json --plain
dtctl exec analyzer <id-or-name> --input '{"timeframe":"now-2h"}' --plain

Prefer get ... -o json --plain first, then describe/exec with explicit IDs.

Authentication & Permissions

# Check current user and permissions
dtctl auth whoami --plain
dtctl auth can-i create workflows
dtctl auth can-i delete dashboards

Use can-i to verify permissions before attempting operations.

Quick Reference: DQL Queries

Required workflow for DQL data fetching:

  1. First consult references/DQL-reference.md
  2. Build/validate the query using the documented patterns
  3. Execute with dtctl query ... -o json --plain (or dtctl wait query ... when waiting for results)
# Inline query
dtctl query "fetch logs | filter status='ERROR' | limit 100" -o json --plain

# Query from file with variables
dtctl query -f query.dql --set host=h-123 --set timerange=2h -o json --plain

# Wait for query results
dtctl wait query "fetch spans | filter test_id='test-123'" --for=count=1 --timeout 5m

# Query with chart output
dtctl query "timeseries avg(dt.host.cpu.usage)" -o chart --plain

Dashboards

For full examples and field-level gotchas, see references/resources/dashboards.md.

Create/update: dtctl apply -f dashboard.yaml --plain. Export for reference: dtctl get dashboard <id> -o yaml --plain.

YAML skeleton

name: "Dashboard Name"
type: dashboard
content:
  annotations: []
  importedWithCode: false
  settings:
    defaultTimeframe:
      enabled: true
      value: { from: now()-2h, to: now() }
  layouts:
    "1":                    # string key, must match a tile key
      x: 0                 # 24-column grid (full=24, half=12, third=8)
      "y": 0               # MUST quote "y" to avoid YAML boolean parse
      w: 12
      h: 6
  tiles:
    "1":
      title: "Tile Title"
      type: data            # data | markdown
      query: |
        fetch logs | limit 10
      visualization: lineChart
      visualizationSettings:
        autoSelectVisualization: false
      davis: { enabled: false, davisVisualization: { isAvailable: true } }

Tile types & visualizations

  • type: data — DQL tile with query + visualization: singleValue, lineChart, areaChart, barChart, pieChart, table, honeycomb, scatterplot
  • type: markdown — static text via content field (supports markdown)

For detailed visualizationSettings (singleValue, charts, tables, thresholds, unit overrides), see references/resources/dashboards.md.

Gotchas

  • Always set davis.enabled: false on data tiles.
  • Use makeTimeseries for log/span time series; timeseries for metrics.
  • version field warning on create is benign.
  • No id field → creates new; with id field → updates existing.

Common Issues

Name resolution ambiguity:

  • If a name matches multiple resources, dtctl will fail
  • Solution: Use IDs instead of names
  • Find ID: dtctl get <resource> -o json --plain | jq -r '.[] | "\(.id) | \(.name)"'

Permission denied:

Context/safety blocks:

  • Destructive operations may be blocked by safety level
  • Switch context: dtctl config use-context <name>
  • Adjust safety level when creating context

Additional Resources

  • Troubleshooting: references/troubleshooting.md
  • Multi-tenant setup: references/config-management.md
  • DQL syntax and templates: references/DQL-reference.md
  • Notebooks: references/resources/notebooks.md
  • Extensions: references/resources/extensions.md
  • CLI help: dtctl --help, dtctl <command> --help

Safety Reminders

  • Use --plain for machine/AI consumption
  • Confirm context + safety level before destructive ops; prefer get/describe first
  • Use --mine flag to filter resources you own
  • For multi-tenant work, see references/config-management.md

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.