2.9. Data Export to External Systems and Services

NetSpyGlass can be configured to send monitoring data to various external systems and services in addition to Time Series Database. Both data transfers happen at the end of each polling cycle and run in parallel.

Communication with TSDB is bidirectional: NetSpyGlass both sends data to TSDB and reads from it when it receives query for the amount of data that exceeds what it has in memory. Communication with external data export targets is unidirectional: NetSpyGlass only sends data there and can not read it back.

Currently, NetSpyGlass offers integration with DataDog as external data export target.

2.9.1. Data Export to DataDog

This section describes a way to send monitoring data to DataDog. This creates metrics in DataDog that follow corresponding monitoring variables in NetSpyGlass. You can use this to build graphs, dashboards, monitors and other things in DataDog where you use metrics. NetSpyGlass also offers second integration channel with DataDog which can be used to send alerts as DataDog events. See section DataDog in Alert Notifications for more details on how to do that.


Integration with DataDog comes in two parts. First, you can send real-time monitoring data to DataDog. This is accomplished using configuration parameter added to the section integrations. Second, you can use DataDog as notification stream for NetSpyGlass alerts. Every time NetSpyGlass alert activates, it will post an event to DataDog. To set this up, add notification stream to the configuration section alerts.

To configure export to DataDog, add the following section to your nw2.conf file (do not forget to substitute your own API key):

integrations {

    # NetSpyGlass can send monitoring data to DataDog service if this section of the configuration
    # is uncommented and properly configured.
    # Data is submitted to these services at the end of every polling cycle in addition to sending
    # it to the TSDB (see configuration section `monitor.storage` above). NetSpyGlass does not read
    # data from DataDog
    datadogEval1 {

        type = datadog
        apiKey = 12345678901234567890

        # Tags or tag facets that should be send to DataDog.
        # If this list has item "*", then all tags are passed. If this list is empty,
        # no tags are sent. Items in this list can be tag facet names or
        # full tag strings "Facet.Tag".
        acceptTags = [ "Explicit", "Link", "BGP4Peer", "ifAlias", "ifRole" ]

        # Tags and tag facets that should not be sent to DataDog.
        # If this list has item "*", then all tags are suppressed. If the list is
        # empty, all tags listed in `acceptTags` are going to be sent.
        # Filters are applied in order: `acceptTags` is applied first, then `dropTags`.
        # Filter `dropTags` is never going to match anything in the default configuration
        # because `acceptTags` does not pass either of these facets. Filter `dropTags`
        # is defined like this to let user change only `acceptTags` to `[ "*" ]` if
        # they want to, without changing `dropTags`.
        dropTags = [
            "SupportedMIBs", "VariableTags"

        # ===========================================================================
        # This filter can be used to limit set of variables sent to this integration.
        # The filter is defined as a list of variable names. If any entry is "*",
        # all variables are going to be sent (that is, the "*"
        # overrides any other items this list might have). Empty list means no variables
        # will be sent at all.
        # By default we send the same variables we show in the GraphingWorkbench

        variables = ${graphingWorkbench.variables}

        # this filter can used to further restrict the set of monitoring variables to be
        # sent to DataDog. This is a list of device names. If item "*" appears anywhere
        # in the list, monitoring data for all devices is going to be sent.
        devices = [



Each third-party integration target is described by its own configuration block that has the name and the body. Target type is determined by the parameter type (only “datadog” is recognized at this time). You can configure several targets of the same type but with different names and different configuration. For example, you can push different data sets to different DataDog accounts if you wish.

NetSpyGlass creates a new “host” in DataDog with name “netspyglass” and adds custom metrics with names that begin with “netspyglass”. It sends tags along with the metric data but you can control which tags and tag facets are sent using parameters acceptTags and dropTags.

Parameters variables and devices can be used to control the set of monitoring variables to be sent to DataDog. By default, NetSpyGlass sends all variables that appear in its own Graphing Workbench for all devices defined in the system.

In addition to tags associated with monitoring variables in NetSpyGlass, data export adds two additional ones:

  • network_node – this tag has value equal to the device name
  • component – this tag has value equal to the component name


Total number of metrics sent to DataDog this way can be quite big. Check with your DataDog license and possibly use parameter variables to tune this integration.