Cisco SD-WAN extension

No, not all feature sets are required.

The vManage API returns health status for sites, devices, tunnels, and applications as textual values.

The extension reports health as numeric metric values representing the status returned by the vManage API, using the following mappings.

Site, Site Devices, Site Tunnels, and Applications Health

Applied to:

Device Health

Applied to:

Device Reachability

Applied to:

The extension reports TLOC metrics by aggregating data retrieved from the vManage API. It calculates average latency, loss, and jitter values using the vManage API query language and aggregates them by the following TLOC attributes:

The extension queries the metrics from Application-Aware Routing (App-Route) statistics and aggregates them across all tunnels associated with the same local TLOC.

The extension determines the number of tunnels for a TLOC by evaluating the cardinality of remote system IPs associated with the aggregated App-Route statistics.

Some metrics have two keys: one in Grail and one in Dynatrace classic.

This affects the gauge metrics whose key ends in _count:

It also affects the count metrics that are reported without a .count suffix, for example, cisco.sdwan.tloc.rx_octets and cisco.sdwan.tloc.tx_octets. In Dynatrace classic, they're cisco.sdwan.tloc.rx_octets.count and cisco.sdwan.tloc.tx_octets.count.

The reason is that a classic metric key can refer to only one payload type, so classic metrics automatically receive the .count or .gauge suffix, while Grail metrics don't. For details, see:

Cisco SD-WAN Manager reports two kinds of signals, and the extension handles them separately.

Alarms describe a condition, but they aren't a reliable record of its state. Cisco SD-WAN Manager raises an alarm when it detects a condition, and for many alarm types it never clears the alarm. Its own Alarm Reference says "No clearing procedure" for whole alarm families, and a lasting condition, such as an expired certificate, is re-raised as a new alarm every day. An alarm that's still marked active might therefore describe something that ended long ago.

The extension builds the state itself. It groups alarms by the condition they describe and opens one Dynatrace problem for each group. It keeps the problem open while the condition is still reported. It closes the problem when the alarm clears or when the condition is no longer reported. Each closing log record says which of the two happened.

SD-WAN events are single points in time. An event says that something happened at one moment, for example, a DHCP address was rejected, a tracker changed state, or an IPsec key was renewed. An event is never active and never cleared.

For that reason, SD-WAN events become Dynatrace log records only—they never become Dynatrace problems. To open problems, use alarms. A busy fabric produces hundreds of events per day, which would bury the alarms that matter.

Each event becomes a log record with its severity, component, name, details, device, and site. The extension also keeps the complete original record from Cisco SD-WAN Manager.

To find your event records, run the following DQL query:

fetch logs
| filter cisco_sdwan_event_type == "cisco_sdwan_event_log_event"
| sort timestamp desc

Two settings on the SD-WAN Events tab of the monitoring configuration control the volume:

You can also enable the optional events feature set. It adds an event count metric per device and severity, and an SD-WAN Events by Severity chart. Log records don't need this feature set.

You can see events on the SD-WAN Events card on the SD-WAN infrastructure, site, and device screens.

With Report Alarms as Events enabled, use List of conditions to override Default Event Type in the monitoring configuration.

Enter the Alarm Type as the Cisco SD-WAN Manager alarms table shows it in the Alarm Type column, with _ instead of spaces, for example, Tracker_State_Change or CERT_EXPIRED.

Cisco SD-WAN Manager names a site only by its number, for example, SITE_4000. Many organizations include the real location in their device hostnames instead, for example, BRN-rtr01, BRN-rtr02, and BRN-sw01 for the Brno site.

With Friendly Site Name Pattern, you can take that part of the hostname and use it as the site name.

The extension always fills in the property, so screens and dashboards always have a value to show.

Friendly Site Name Pattern is a regular expression, and it must contain a capture group. The text inside the group becomes the friendly site name.

For example, ^(.{3}) takes the first three characters of the hostname. Without the brackets, ^.{3} is still a valid expression, but it captures nothing, so the extension produces no friendly name.

If the pattern is invalid, the extension reports a warning and ignores the pattern. It uses the plain site name instead, and metric collection continues.

Three feature sets cover the same fabric from three different angles. They complement each other—they aren't alternatives, and their numbers aren't meant to match.

When something is wrong, the usual order is:

Controllers only appear in the device totals. vSmart, vBond, and vManage carry control connections but have no WAN transports, so they're absent from every per-transport series. A vBond can report a dozen control connections at the device level and nothing per transport. Before device_control_plane, controller control-plane health wasn't visible as a metric at all. This is the main gap that the feature set closes.

A missing metric value doesn't mean zero. Cisco SD-WAN Manager leaves a counter out of its response instead of sending a zero, and the extension then reports no value for it.

This happens most often with BFD sessions, because controllers have none. Controllers also have no Transport Locators, so the TLOC counters are missing for them too.

Note this when you create an alert. A missing counter isn't a failure, and a counter can be missing while its up counter is present, so an alert that compares the two must allow for one of them being absent.

alarm_component carries the component category that Cisco SD-WAN Manager (vManage) assigns to an alarm, for example, VPN, OMP, or BFD.

Some alarm types, such as security-certificate-expiring, have no component category. For those, the vManage API returns the literal text None, and the extension reports that value unchanged.

This is the value returned by the API, not a collection error. The extension deliberately doesn't rewrite it, so that dashboards, alerts, and DQL queries always match what vManage reports.

The extension primarily uses Cisco SD-WAN Statistics / Monitoring APIs (non-bulk) to collect operational data. According to Cisco SD-WAN documentation, these APIs are subject to a general rate limit of 100 requests per second.

To ensure stable and predictable operation, the extension applies its own internal API rate limiting, which you can configure by setting API rate limit per minute per one SD-WAN Manager Connection in the extension settings. The default rate limit is 16 requests per minute, with a maximum supported value of 48 requests per minute.

The extension periodically collects data from the Cisco SD-WAN Manager at a configurable Metrics Collection Frequency, which is 5 minutes by default. During each collection cycle, it evenly distributes API requests over time to stay within the configured rate limit.

For a single Cisco SD-WAN deployment, API rate limits apply to the SD-WAN fabric as a whole, not to individual vManage nodes. As a result, you should treat them as fabric-wide limits.

You can configure the extension to use the vManage virtual IP (VIP) or load-balanced endpoint, which is the recommended access method for high-availability deployments. This approach relies on vManage's internal load-balancing and failover mechanisms.

Alternatively, you can configure multiple vManage node endpoints, provided they belong to the same vManage cluster and manage the same SD-WAN fabric. In this configuration, all endpoints return identical fabric-wide data, and the extension automatically distributes API requests evenly across the configured nodes.

The internal API rate limit configured in the extension applies globally across all configured vManage endpoints. For example, if you configure three vManage node endpoints and set the rate limit to 16 requests per minute, the extension distributes API calls across the nodes, resulting in approximately 5 requests per minute per node while maintaining the overall fabric-wide rate limit.

If the extension detects that one of the configured vManage nodes is not reachable, it automatically stops using that endpoint and continues data collection using the remaining nodes without increasing the per-node request rate. Once the unavailable node becomes reachable again, the extension automatically resumes using all configured nodes for data collection.

The extension collects statistics in pages. Each page requests data from Cisco SD-WAN Manager for one group of devices. A smaller page needs less memory.

Three expert settings define the page size, one for each type of statistics:

You can set each one to a value from 1 to 1000.

How low you can go depends on:

Change one setting at a time, and check the result before you change the next one.