Best practices for optimizing network monitoring cost

• Latest Dynatrace
• Best practices
• 8-min read
• Published Apr 28, 2026

Network monitoring costs can grow quickly as you expand device coverage, add interfaces, and select additional feature sets. This guide helps you identify the key cost drivers and take targeted action to reduce them without sacrificing visibility.

The primary cost driver is metrics ingestion. Because retention is included at no cost for the first 15 months and queries are included at no cost, your bill is determined by what you collect—not how long you keep it or how often you query it.

The recommended approach is to start lean by enabling the default feature set first, then expand only for specific, well-defined use cases. This keeps your ingestion footprint minimal by default and ensures every additional metric collected has a clear purpose.

To put this approach into practice, this guide walks you through:

Core concepts

You should understand these core concepts before onboarding and optimizing your network monitoring in Dynatrace.

Before continuing, review the core metrics concepts in Best practices for optimizing metrics cost.

Understand cost

Understand how Dynatrace bills for network monitoring

Metrics ingestion is billed based on the number of stored metric data points. An increase in metric data points directly leads to higher consumption.

The number of ingested metric data points depends on three factors:

Any increase in these factors leads to higher consumption. The more feature sets are selected, the more metrics are collected. The more devices and interfaces are monitored, the more timeseries each metric produces.

For example, a metric split by dimensions (such as device and interface) creates one timeseries for each distinct combination. The more combinations, the higher the cardinality, and the more data points generated per collection cycle.

Select only the feature sets you need

Network monitoring metrics are organized into feature sets that cover basic and advanced network observability needs. In addition to the always-on default feature set, select only the feature sets you currently need. This reduces initial cost and alerting noise.

Add feature sets only where they support specific use cases (alerts, troubleshooting data, dashboards).

To manage feature sets

Configure or edit a feature sets configuration in the Extensions app.

The sections below describe each feature set and help you select the appropriate ones based on your monitoring objectives.

Basic device and interface monitoring

Basic device and interface monitoring for all interfaces in the network.

The default feature set is always on and can't be deselected.

Metrics collected: 4 metrics per device + 2 metrics per collected interface.

Traffic volume and basic health

Per-interface traffic volume and well-known health indicators for the most important interfaces.

Select the Interfaces feature set. This feature set enriches the generic interface entities collected by the default feature set with new metrics; it doesn't create new entities.

Metrics collected: 7 metrics per collected interface.

Packet metrics

Packet metrics and per-packet error ratio calculation.

Select the Advanced Interfaces feature set. This feature set enriches the metrics collected by the default and Interfaces feature sets with new metrics; it doesn't create new entities.

Metrics collected: 7 metrics per collected interface.

Legacy or limited-resource devices

Monitor old or limited-resource devices.

Select the Interfaces 32-bit feature set. For devices where 64-bit interface counters don't respond, this feature set provides equivalent metrics to the Interfaces feature set.

Metrics collected: 2 metrics per collected interface.

Routing protocols: OSPF and EIGRP

Route protocol visibility.

Select the OSPF and/or EIGRP feature sets, depending on your needs. Each feature set covers one routing protocol to offer granularity and account for device configurations. They use device-specific entities and create one entity per device.

Metrics collected: 1 metric per neighbor.

BGP monitoring

Two BGP feature sets are available:

Option 1: BGP (standard)

Select the BGP feature set for maximum compatibility.

Metrics collected: 3 metrics per BGP peer.

Option 2: Cisco BGP

Select the Cisco BGP feature set to cover Cisco devices that don't support generic BGP MIBs.

Metrics collected: 5 metrics per BGP peer.

Understand your network metrics ingest

Before optimizing metrics ingest, identify which network metrics are ingested and stored in Dynatrace and how they are distributed across your organization.

The DQL queries below can be run in Dynatrace using Notebooks, Dashboards, or Workflows.

1. Find high-cardinality network metric sources

Identify which network metric sources contribute the most to your metric cardinality. This helps pinpoint which metric sources ingest the most metrics so you can target optimization efforts where they have the greatest impact.

The metrics command scans a maximum of 100,000 series. For large environments, results may be truncated. If you hit this limit, use the queries in the next step to narrow the query scope.

For details, see DQL metric commands.

metrics
| filter contains(dt.metrics.source, "f5")
    or contains(dt.metrics.source, "snmp")
    or contains(dt.metrics.source, "cisco")
    or contains(dt.metrics.source, "palo-alto")
    or contains(dt.metrics.source, "netscaler")
    or contains(dt.metrics.source, "meraki")
    or contains(dt.metrics.source, "forti")
    or contains(dt.metrics.source, "firewall")
    or contains(dt.metrics.source, "switch")
    or contains(dt.metrics.source, "alteon")
| summarize count = count(), by: { dt.metrics.source }
| sort count desc

Run in Playground

The following example shows the query executed in Notebooks:

Query in Notebooks to find high cardinality network metric sources.

2. Drill down into metric keys

Once you identify high-cardinality sources, filter by those attributes and examine individual metric keys to see which specific metrics contribute the most to cardinality.

metrics
| filter dt.metrics.source == "metric_source_name"
| summarize count = count(), by: {metric.key}
| sort count desc

The following example shows the query executed in Notebooks:

Query in Notebooks to drill down into metric keys.

3. Analyze a specific metric key

Use the timeseries command to get the cardinality for a specific metric key.

timeseries count(metric.key, scalar: true)

For more details, see DQL timeseries examples.

The following example shows the query executed in Notebooks:

Query in Notebooks to analyze a specific metric key.

Optimize cost

Reduce your network monitoring cost by decreasing the number of ingested metric data points.

Optimization can be applied at two levels:

The following best practice explains how to optimize at the source.

Drop metrics and reduce metric cardinality

Select interfaces based on your use cases. For most enterprise switches or remote office routers, this means uplink interfaces and, optionally, critical interfaces such as video conferencing or wireless access points. Less important interfaces can be monitored through Syslog for availability only.

Add pattern fields configuration in the Extensions app to collect a targeted set of interfaces.

Manage cost

Continuously validate network metrics

Continuously validate cardinality and ingest intervals as part of your CI/CD processes. Changes in instrumentation or configuration can unintentionally introduce excessive cardinality, overly frequent metric collection, or shifts in data behavior, all of which increase ingestion costs.

Use Dynatrace to automate these checks. Validate DQL queries through a Site Reliability Guardian (SRG) integrated into configuration workflows to detect data anomalies early. SRG evaluations can alert you when new code or configuration changes modify cardinality, scraping intervals, or other telemetry profile aspects.

Continuous validation lets teams correct instrumentation or adjust their network monitoring configuration before changes reach production.

Ensure costs are allocated

Allocate network monitoring costs to specific cost centers or products. Go to monitoring configurations and add cost allocation attributes (dt.cost.costcenter or dt.cost.product) as metadata.

For details, see Allocate your DPS costs.

Validate the business value of feature sets

To minimize data point volume and reduce cost, keep only feature sets that support defined use cases.