Name: dt-obs-network-flows
Rating: 74.4 (1 reviews)
Author: Dynatrace

dt-obs-network-flows

Network flow analysis in Dynatrace across three sources: OneAgent flows (host/process/pod-to-peer connections in the `default_network_flows` Grail bucket), NetFlow/IPFIX/sFlow (via an OpenTelemetry Collector), and cloud flow logs (AWS VPC / Transit Gateway; Azure and GCP planned). Use to analyze traffic between entities, find top talkers by bandwidth, map communication dependencies, investigate connection health (resets, timeouts, retransmissions, RTT), and resolve peers to monitored entities. Routes each question to the right source; source-specific DQL lives in the reference files. Trigger: "network flows", "top talkers", "traffic between hosts", "connection resets", "TCP retransmissions", "RTT", "pod connections", "network dependencies", "NetFlow", "IPFIX", "sFlow", "VPC flow logs", "cloud network traffic". Do NOT use for host NIC throughput or packet drops (use dt-obs-hosts), service request rate or latency (use dt-obs-services), or synthetic/uptime monitoring (use dt-obs-ext-monitors).

Quality

93%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Quality

Content

86%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A well-architected overview skill: concise, table-driven, with a clear routing workflow and verified one-level-deep references holding the detailed DQL. The only gap is that executable query code lives in references rather than inline, which is appropriate for progressive disclosure but leaves the body itself slightly less copy-paste-ready.

Suggestions

Consider including one minimal end-to-end DQL snippet inline (e.g. a top-talkers query against `default_network_flows`) so the body is immediately actionable before diving into references.

Add a one-line note on how to confirm a source has data (e.g. checking bucket existence or a sample count) to give the routing workflow a lightweight validation checkpoint.

Dimension	Reasoning	Score
Conciseness	Lean, table-driven overview that assumes competence — no padding with generic networking concepts Claude already knows; every section (use cases, source comparison, routing, cross-links) earns its tokens. Minor redundancy between the frontmatter description and the opening line is negligible.	5 / 5
Actionability	Routing logic and the source table give concrete, usable details (e.g. `otel.scope.name == "otelcol/netflowreceiver"`, `log.type == "aws.vpc"`, bucket names) and a numbered decision procedure, but the executable DQL queries themselves are deferred to reference files rather than appearing inline.	4 / 5
Workflow Clarity	The three-step routing logic is a clear, ordered decision tree with an overlap-handling note; no destructive/batch operations are present so the validation cap does not apply. It stops short of explicit validation checkpoints, but none are needed for a routing task.	4 / 5
Progressive Disclosure	A clear overview with well-signaled one-level-deep references; all seven linked reference files (oneagent-flows, peer-resolution, netflow, cloud-flows/aws, plus configuration docs) exist on disk and are annotated with their contents, making navigation easy.	5 / 5
	Total	18 / 20 Passed

Description

100%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

An exemplary description: third-person voice, concrete capabilities, comprehensive natural trigger terms, and explicit use/non-use boundaries. Every dimension lands at the top anchor with no verbosity penalty.

Dimension	Reasoning	Score
Specificity	Lists multiple concrete actions — 'analyze traffic between entities', 'find top talkers by bandwidth', 'map communication dependencies', 'investigate connection health (resets, timeouts, retransmissions, RTT)', 'resolve peers to monitored entities' — across three named sources, giving comprehensive coverage.	5 / 5
Completeness	Explicitly answers 'what' (three sources and the actions performed) and 'when' (a dedicated 'Trigger:' clause with concrete phrases), plus a 'Do NOT use for' boundary — matching the top anchor.	5 / 5
Trigger Term Quality	The explicit Trigger list covers natural phrases and synonyms users would say — 'network flows', 'top talkers', 'traffic between hosts', 'connection resets', 'TCP retransmissions', 'RTT', 'pod connections', 'NetFlow', 'IPFIX', 'sFlow', 'VPC flow logs', 'cloud network traffic'.	5 / 5
Distinctiveness Conflict Risk	A clear Dynatrace network-flows niche with distinct triggers and an explicit 'Do NOT use for' clause routing NIC throughput, service latency, and synthetic monitoring to sibling skills, minimizing conflict risk.	5 / 5
	Total	20 / 20 Passed

Validation

87%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 14 / 16 Passed

Validation for skill structure

Criteria	Description	Result
relative_links	Relative link issues: 10 deeper-than-1-level, 5 suspicious	Warning
referenced_paths_exist	Referenced path issues: 2 missing, 20 deeper-than-1-level	Warning

	Total	14 / 16 Passed

Repository: Dynatrace/dynatrace-for-ai
Path: skills/dt-obs-network-flows/SKILL.md
Commit: 47528b0

Reviewed: 6 days ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.