API Poller Enhancement Request – Dynamic Array Handling | Example use case - SDWAN metrics custom po

Akeel Taj

Problem Statement (using the SDWAN polling example)

SolarWinds API Poller is a powerful feature for collecting custom metrics from external APIs. However, it currently has two major limitations that make it challenging for dynamic environments like SD-WAN:

1. Static JSONPath Indexing
   API Poller requires selecting individual array elements (e.g., [0], [1]) for monitoring. This means if the API returns a dynamic list of devices, you must manually configure each index. There is no way to monitor all occurrences of a field across an array dynamically.
2. String Handling for Identifiers
   Fields like system-ip (device IP address) are critical for identification but cannot be stored as strings for monitoring without forcing numeric conversion. This makes it impossible to use IP addresses as identifiers in a meaningful way.

Expected Behavior

• Dynamic Array SupportAllow API Poller to monitor all occurrences of a field in an array without hardcoding indexes. For example:

$.data[*].system-ip


$.data[*].number-vsmart-control-connections


$.data[*].expectedControlConnections

The poller should store these as a table or key-value pairs (e.g., IP → metric values).

• Proper String Handling
  Enable storing non-numeric fields (like IP addresses) as strings without forcing numeric conversion, so they can be used for identification and mapping.
• Alerting Across Arrays
  Support alert logic that compares related values within the same object (e.g., number-vsmart-control-connections < expectedControlConnections) across all array items.

Use Case

In SD-WAN environments (Cisco vManage in our case), the /dataservice/device/counters API returns thousands of devices with metrics like:

• system-ip
• number-vsmart-control-connections
• expectedControlConnections

We need to:

• Monitor when actual control connections are less than expected connections for any device.
• Dynamically handle devices joining or leaving the network without manual reconfiguration.
• Map these metrics to SolarWinds nodes for unified visibility.

Currently, this requires external scripting and Orion SDK integration, which defeats the purpose of having a built-in API Poller.

Why This Matters

• Many customers use SD-WAN or other dynamic systems where device lists change frequently.
• Enhancing API Poller to support dynamic arrays and proper string handling would:
  • Reduce manual effort.
  • Improve scalability.
  • Enable richer dashboards and alerting for modern network architectures.