dynatrace/dynatrace-for-ai

dt-obs-network-flows

Network flow analysis in Dynatrace across three sources: OneAgent flows (host/process/pod-to-peer connections in the defaultnetworkflows Grail bucket), NetFlow/IPFIX/sFlow (via an OpenTelemetry Collector), and cloud flow logs (AWS VPC / Transit Gateway; Azu…

View source

How to use

  1. Copy the installation command and review the source package before installing it in your own agent environment.
  2. Check the source document for required tools, credentials and supported hosts.
  3. Describe your input and desired deliverable; review the output against the source material.
npx skills add https://github.com/dynatrace/dynatrace-for-ai --skill dt-obs-network-flows

Before you start

  • Installation does not include a model subscription, API allowance or permission to access your files.
  • Repository stars and installation counts describe activity, not an independent quality or security test.
Original skill document

Rendered from the source repository. Headings, examples, code, tables, links, and referenced images are preserved.

Network Flows Skill

Analyze network traffic in Dynatrace across three flow data sources. This skill covers the use cases network flows enable and routes each question to the right source and reference file. The detailed, source-specific DQL lives in the reference files.

What Network Flows Tell You

Network flow data answers questions that metrics and traces cannot:

  • Who talks to whom — communication dependencies between hosts, processes, pods, services, and external endpoints
  • Top talkers — which entities generate the most traffic, by bytes or connection count
  • Connection health — resets, timeouts, retransmissions, and round-trip time (RTT) per conversation
  • Traffic composition — protocol (TCP/UDP), destination ports, direction (client vs server)
  • Peer resolution — mapping raw IP:port peers back to monitored entities (host, process, pod, service) or flagging them as external

The Three Flow Sources

Choose the source based on where the traffic is and what is capturing it. When more than one applies, prefer the source with the richest entity context (usually OneAgent).

SourceCaptured byData locationEntity contextUse when
OneAgent flowsOneAgent network agent on the hostevents in the default_network_flows Grail bucketRich — the capturing entity (client or server) resolved to host / process / pod smartscape IDs; the remote peer as IP:portTraffic to/from OneAgent-monitored hosts, processes, or Kubernetes pods. The default and most detailed source.
NetFlow / IPFIX / sFlowNetwork devices (switches, routers), ingested via an OpenTelemetry Collectorlogs (otel.scope.name == "otelcol/netflowreceiver"; recommend routing to a dedicated bucket)Device/interface level — raw IPs, exporter, interfaces; no smartscape entitiesTraffic seen by network hardware. Covers east-west and north-south flows at the network layer.
Cloud flow logsCloud provider (AWS VPC / TGW; Azure, GCP not yet documented)logs (log.type == "aws.vpc" / "aws.tgw"; recommend routing to a dedicated bucket)Cloud resource level — VPC / subnet / AZ / ENI, TGW attachment; raw IPs, no smartscape entitiesTraffic within/across cloud networks, including managed services and resources without an agent.

Routing logic

  1. Is the traffic to/from a OneAgent-monitored host, process, or pod? → OneAgent flows. See references/oneagent-flows/oneagent-flows.md.
  2. Is it device-level or from unmonitored hosts? → NetFlow. See references/netflow/netflow.md.
  3. Is it cloud-network / managed-service traffic? → Cloud flow logs (per provider). AWS: references/cloud-flows/aws/aws.md.
The three sources overlap. A pod-to-pod flow may appear in both OneAgent flows (with full pod context) and cloud flow logs (as ENI-to-ENI). Lead with the source that carries the entity context the user needs, and mention the alternative only if the primary source has no data.

Related Network Data in Dynatrace

Network flows are one part of Dynatrace's network observability. Route to these when the question is not about flows:

The user wants…Use
Host NIC throughput, link utilization, packet drops/errorsdt-obs-hosts → references/host-metrics.md (Network Monitoring section)
Process-level network I/O and TCP connection quality metricsdt-obs-hosts → references/process-monitoring.md
Kubernetes pod connections and cluster network topologydt-obs-kubernetes
Service request rate, latency, error ratedt-obs-services
External / synthetic uptime and network-availability monitorsdt-obs-ext-monitors
Network devices — switches, routers, firewalls (SNMP/monitoring)dt-obs-network-devices (planned — not yet available)
A future macro `dt-obs-network` skill may connect all network concepts (devices, hosts/process/pod metrics, flows, availability monitors, cloud network monitoring). Until it exists, this skill carries the flow-specific cross-links above.

Reference Files

  • references/oneagent-flows/oneagent-flows.md — Validated. Data model, field reference, and DQL for the default_network_flows bucket: top talkers, traffic maps, protocol/port breakdowns, connection health (resets/timeouts/retransmissions/RTT), bandwidth in bps, and which side of a flow is the peer.
  • references/peer-resolution/peer-resolution.md — Validated. Shared Smartscape lookups that resolve a raw flow IP (and optional port) to a monitored host, process, Kubernetes pod, or service (host → pod → service → external). Used by both OneAgent flows and NetFlow.
  • references/oneagent-flows/configuration.md — Enabling and tuning builtin:network-connection-monitoring (the setting that produces OneAgent flow data).
  • references/netflow/netflow.md — Validated. NetFlow/IPFIX/sFlow ingested via an OpenTelemetry Collector into logs: data model, direction semantics (unidirectional, no client/server role), and DQL for top conversations/talkers/ports, protocol breakdowns, traffic-over-time, and per-exporter/per-interface views.
  • references/netflow/configuration.md — OTel Collector netflow-receiver ingestion path and the dedicated-bucket routing recommendation for netflow logs.
  • references/cloud-flows/aws/aws.md — Validated (AWS). AWS VPC Flow Logs and Transit Gateway flow logs ingested into logs: aws.vpc/aws.tgw field model (incl. pkt_srcaddr vs srcaddr, log_status filtering), and DQL for top conversations/talkers/ports, rejected-traffic (security), egress traffic_path, per-VPC/subnet/AZ, inter-VPC, traffic-over-time, and TGW packet-loss. Also AWS entity resolution — ENI/instance by id or IP-in-aws.object — for agentless resources the shared peer lookups miss.
  • references/cloud-flows/aws/configuration.md — Amazon Data Firehose ingestion path for AWS flow logs and the dedicated-bucket routing recommendation.

(Azure NSG/VNet and GCP VPC flow logs are not yet documented; add them as sibling `cloud-flows/<provider>/` folders when tenant data is available.)

Related by task

from this repository

More skills

All skills
dynatrace
Community

dt-alerting

End-to-end Dynatrace alerting lifecycle — anomaly detector setup and model selection (static threshold, adaptive baseline, seasonal baseline), alert event storage in Grail, problem grouping and denoising by root cause analysis, and workflow-based notification routing (email, Slack, ServiceNow, webhook). Use when configuring alerting, choosing between detector types, querying alert event history, understanding why alerts merged into a problem, or setting up problem-triggered notifications.

installs
3
GitHub stars
166
Updated
Oct 1
dynatrace
Community

dt-app-dashboards

Work with Dynatrace dashboards - create, modify, query, and analyze dashboard JSON including tiles, layouts, DQL queries, variables, and visualizations.

installs
3
GitHub stars
166
Updated
Oct 1
dynatrace
Community

dt-app-notebooks

Work with Dynatrace notebooks - create, modify, query, and analyze notebook JSON including sections, DQL queries, and visualizations.

installs
3
GitHub stars
166
Updated
Oct 1
dynatrace
Community

dt-dql-essentials

Core DQL syntax, pitfalls, query patterns, and query optimization. Load to write, build, fix, or OPTIMIZE a DQL query — prevents syntax errors and makes queries faster, more efficient, and cheaper (less data scanned = lower query consumption/cost per run). Covers fetch commands, data models, field namespaces, time alignment, entity/smartscape patterns, metric discovery, and performance/cost optimization (filter early, bucket filters, short time ranges, field selection, sampling, cardinality). Tr

installs
3
GitHub stars
166
Updated
Oct 1