Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Use Custom Telemetry Data in an IBA Probe

This topic describes how to configure and use custom telemetry data in an IBA probe.

So far in our walk through, we've created a custom telemetry collector service. This telemetry service specifies the data to gather from your devices. Next, we will ingest this data into IBA probes in your blueprint as described in Create a Probe. Doing this allows Apstra to visualize and analyze the data.

Types of Processors

An IBA probe, functioning as an analytics pipeline, begins with a source processor. This processor creates data and several outputs without requiring any input. The different types of source processors are described in Table 1.

You can add more processors in the probe for extra data analytics. This enhances your network's health insights. These extra processors, known as analytical processors, are described in Table 2.

Analytical processors let you compile, logically process your data, and identify an intended state to detect anomalies. These processors perform calculations such as averages, min/max, and standard deviations. This aggregated data is then compared with expected results to determine if it's within a preset range. Anomalies are only flagged when a specific threshold is surpassed for a certain duration, preventing flags for transient conditions. A Time_In_State processor configuration can achieve this.

Table 1: Source Processors
Built-in

Built-in processors categorize the various processors used to enable services like power monitoring. These processors determine the scope of service activation using a graph query.
Extensible

Data from IBA probes is ingested by extensible collectors. This data is then collected by processors using a graph query provided by a custom service. Service keys are mapped using graph elements, depending on whether the data type is static or dynamic. This process decides the scope of telemetry collection.

  • Extensible Service Data Collector

    The Extensible Service Data collector processes data from custom telemetry services. This processor is ideal for services using custom telemetry collectors. It supports both static series (graph-driven) and dynamic series (collector-driven) telemetry collection.

  • Generic Service Data Collector

    The Generic Service Data collector ingests data from "generic" custom telemetry services. Its telemetry collection is graph-driven and only supports static series.
Graph

Graph processors ingest data from the IBA probes source in the graph database. They do not consume device telemetry data.

  • Generic Graph Collector

    The Generic Graph collector collects data from the active graph. The value field expression provides a value for each item in the graph query response.
Table 2: Analytical Processors
 

Types of Analytical Processors

Analytical Processors

  • Grouping processors

    Grouping processors reduce output size compared to input data.

  • Check processors

    Check processors examine a particular condition, using Boolean output to identify anomalies.

  • Periodic processors

    Periodic processors measure a specific input over a user-determined period.

  • Arithmetic processors

    Arithmetic processors carry out operations like arithmetic (subtraction, division), comparison ('greater than', 'less than'), and logical (AND, OR).

  • Specialized processors

    Specialized processors use distinct analytics functions to support specific probes.

  • Miscellaneous processors
  • Miscellaneous processors, like "Accumulate," store short-term and intermediate data.

For detailed descriptions of all types of processors, see Probe Processor (Analytics) in the Juniper Apstra User Guide.

Create a Probe

Now, we'll create a probe in your deployed blueprint. A probe allows Apstra to gather data from your service. We're using a simple configuration in this scenario to view power information and to create anomaly alerts based on power usage.
Note:

As previously mentioned, an IBA probe, functioning as an analytics pipeline, begins with a source processor. It operates in two modes with the telemetry service: Static and Dynamic series modes. In Static series mode, all keys can be sourced entirely from the graph. Conversely, Dynamic series mode does not require key mapping. In instances where data like power supply isn't modeled in the graph, a probe is created without mapping to the graph. Subsequently, the data ingestion into the IBA pipeline is collector-driven rather than graph-driven.

Note:

Data Center and Freeform blueprints support IBA probes with the Custom Telemetry Collection.

To create a probe:

  1. From your blueprint, navigate to Analytics > Probes, then click Create Probe > New Probe.
    User interface screenshot of Analytics tab with Probes section active. Create Probe dropdown open with New Probe option highlighted.
  2. Enter a Name and Description (in this example, power monitoring), then click Add Processor.
    User interface for creating a new probe with fields for name and description, buttons for adding processor or importing probe, and tabs for navigation.
  3. Select a processor from the Source Processors list, then enter the collector's name and output information. In this example, we selected the Extensible Service Collector processor to consume the service you just created.
    User interface for configuring a processor, highlighting Extensible Service Collector with Power Management input and output as Power Management per PSU per device.
  4. Click Add to add the processor to the probe.
  5. To the right of the Graph Query field click the Select a predefined graph query button.
    The Graph Query sets the blueprint's scope for the telemetry collection. If a device in the blueprint doesn't match the graph query, the telemetry collection for it won't start.
    User interface for Power Management processor with sections titled Extensible Service Collector and Graph area. A tooltip points to an icon for selecting predefined graph queries. A table on the right summarizes node type system and name system.

    The graph query matches all system nodes in your blueprint graph database. Each managed device, whether a leaf switch or spine switch, is represented as a system node in the graph.

    For example, in the Graph Query, the query matches all system, type nodes. In deploy mode, these nodes have roles such as leaf, access, spine, or superspine.

  6. Select DC – All managed devices (any role) from the Predefined Query drop-down, then click Update.
    User interface for updating graph query with selected predefined query DC - All managed devices any role and Update button.
  7. From the Processor page, specify the following:
    1. In the System ID field, enter system.system_id.
      This entry instructs the probe to match the graph query with your managed devices named system. The attribute system_id on each system node refers to the system ID of each device. This attribute is what Apstra uses to uniquely identify each device.
    2. Select power from the Service name drop-down list.
    3. Select the Data Type.

      • Select Dynamic Value if your telemetry service collects string.

      • Select Static Value (graph-driven) if the service collects integers.

    4. Click Create Probe.
    Configuration interface for custom telemetry collector service setup. Key elements: System ID field for system identifier; Service Name set to Power; Service Interval at 2 Minutes; empty Service Input field; Data Type as Dynamic Value; empty Value Map with Add Column option; collapsed Advanced Section; purple tag Power Management per PSU per device; Create Probe button to finalize setup.
    Well done! You successfully create a probe!

    We created a working probe that collects the power consumption for every device in your network. Now let’s explore a few valuable customization options to refine your probe.

    Service Interval

    The telemetry collection service uses a service interval to fetch and ingest data from devices. This interval is crucial as a too aggressive one can overload your devices. The data type you collect determines the optimal interval.

    Dropdown menu labeled Service interval with 1 Minute selected among options 1 Minute 2 Minutes 5 Minutes 10 Minutes 30 Minutes 1 Hour.

    Query Tag Filter

    Another useful customization option is the Query Tag Filter. Let’s say you tagged some switches in your blueprint as storage for a specific monitoring use case. You can configure this filter to perform telemetry on devices with the matching tag, as shown in the following example:

    Query Tag Filter configuration interface with Tag Filter Operation set to and. Node Name is system, Matcher is Is In, Tags has storage. Add Tag Filter and remove filter buttons available.

    Raw data from your custom telemetry collector might be difficult to interpret. Asptra, however, notifies you proactively if any anomaly is detected in your network.

    In the next section, we'll enrich the power probe we created with additional processors to detect and raise anomalies.

Configure Additional Processors for Anomaly Generation

We'll now set up our power probe to identify any power anomalies. You can do this either individually or cumulatively by adding extra processors. The anomalies are then stored in a historical database for reference. We'll further augment the probe by aggregating power readings from all of the system power supplies.

To get started:

  1. Click the Edit button next to the power monitoring probe you created in Create a Probe.

    System management interface with tabs like Dashboard and Analytics. Rows include Device Traffic and Power Monitoring with status indicators like No anomalies. Action buttons for sharing and editing. Toggle switches for feature activation.

  2. Click the Add Processor button to start adding processors.

    Add Processor button with plus symbol in circle.

    We'll now show you some examples of some different types of processors you can add to your probe. SeeFigure 1.

    Note: Processors fall into two categories: source and analytical. Each category hold various sub-categories. Every probe requires at least one source processor. Although you can use any type of processors, most probes use analytical processors, as shown in the following examples.
    Figure 1: Example of Power Processors Data flow diagram of interconnected metrics for power measurement, capacity, and thermal output analysis in device performance monitoring.

Sum processor to aggregate allocated capacity

  1. From the Analytical Processors list, under the Grouping category, select Sum. In the Sum and Output fields, enter Aggregated Allocated Capacity and Allocated Capacity Per Device.

    User interface for adding a processor in a data tool. Sum processor highlighted, calculates aggregated allocated capacity from input to output as allocated capacity per device.

  2. Edit the processor.

    Enter Power Measurement per PSU per Device for the Stage Name and Allocated_Capacity for the Column Name. We'll then group this data by system id to provide a consolidated view of the allocated capacity for each device's power supplies.

    Configuration interface for sum calculation task with Inputs Processing and Advanced sections. Inputs include Input Name in Stage Name Power Measurement per PSU per Device and Column Name Allocated_Capacity. Processing groups by system_id. Advanced section is not expanded.

  3. Check Enable Metric Logging to enable logging, then enter the value such as Watt, to measure the Allocated Capacity Per Device. This action allows tracking of aggregate usage history for the past 30 days.

    Configuration interface for Allocated Capacity Per Device feature showing enabled metric logging, 30-day data retention, empty description field, no graph annotations, and units section with Total Count and Watts.

Sum processor to aggregate thermal output

The thermal output of devices is an important metric to monitor. It plays a key role in data center capacity planning and power usage. Having knowledge of the actual power utilization and thermal output for devices and your EVPN fabric helps the DC Manager plan for power and cooling capacity expansion. The thermal output data from our custom telemetry collector provides a comprehensive fabric total.

  1. From the Analytical Processors list, under the Grouping category, select Sum. In the Sum and Output fields, enter Aggregated Thermal Output and Thermal Output Per Device.

    User interface for adding a processor in a workflow tool; Sum processor selected; flow diagram shows data pipeline from Input to Aggregated Thermal Output to Output.

  2. Edit the processor.

    Enter Power Measurement per PSU per Device for the Stage Name and Thermal_Output for the Column Name. We'll then group this data by system id to provide a consolidated view of the thermal output for each device.

    Configuration interface for Aggregated Thermal Output processor performing Sum operation. Inputs from Power Measurement per PSU per Device, processing column Thermal_Output, grouped by system_id. Advanced options collapsed. Toolbar with move, edit, duplicate, delete actions.

  3. Check Enable Metric Logging to enable logging Then specify the power consumption value, such as BTUs, to measure the thermal output.

    Metric logging UI with options to enable logging, set retention for 30 days, add description, and specify units as BTUs per H.

Sum processor to aggregate used capacity

  1. From the Analytical Processors list, under the Grouping category, select Sum. In the Sum and Output fields, enter Aggregated Used Capacity and Allocated Used Capacity per Device.

    User interface for adding a processor in a data tool, featuring highlighted Sum option in Analytical Processors list and a flow diagram showing data from Input to Sum and Output.

  2. Edit the processor.

    Enter Power Measurement per PSU per Device for the Stage Name and Used_Capacity for the Column Name. We'll then group this data by system id to provide a consolidated view of the actual power usage for each device.

    Configuration interface for data processing tool showing processor 'Aggregated Used Capacity' with inputs from 'Power Measurement per PSU per Device' and grouped by 'system_id'. Toolbar includes move, edit, duplicate, delete options.

  3. Check Enable Metric Logging to enable logging. Then specify the power consumption value, such as Watt, to measure the used capacity.

    Configuration interface for tracking device capacity usage. Title: Used Capacity Per Device. Metric logging enabled; data retained for 30 days. Add annotation button available. Watt specified as unit for Value row.

Ratio processor to calculate the proportion of used capacity to allocated capacity

The Arithmetic processor, an Analytical processor type, calculates power usage ratios for each device. This offers a clear view of power distribution.

  1. From the Analytical Processor list, under the Arithmetic category, select Ratio. In the Sum and Output fields, enter Ratio of Used vs. Allocated Power.

    Configuration interface for a Ratio processor in a data processing tool. Highlights include inputs for numerator and denominator, and output labeled as Ratio of Used vs. Allocated Power.

  2. Enter Used Capacity Per Device as the numerator and Allocated Capacity Per Device as the denominator. Use 100 as the Multiplier value so that the result shows as a percentage.

  3. Set the Result type based on input and type.

    Workflow interface showing data processing steps for calculating the Ratio of Used vs Allocated Power, highlighting stages like Power Measurement and Aggregated Used Capacity.

  4. Check Enable Metric Logging to enable logging. Then specify the power consumption value in percentages (%) to measure the Ratio of Used vs. Allocated Power for each device.

    Configuration interface for tracking Ratio of Used vs. Allocated Power with metric logging enabled, data retained for Last 30 Days, and unit set to percent.

    Dashboard showing real-time power usage ratio for systems GM215, GM228, GM612. Usage ranges 24.4% to 27.6%. Categories: Spine, Superspine, Leaf.

Sum processor to calculate total thermal output and user power

For capacity planning purposes, it’s useful to know the total power usage and thermal output for your entire fabric. For this information, we'll create two more Sum processors for Total Blueprint Thermal Output and Total Blueprint Used Power.

Note:

In both processors, the Group by field remains empty. This approach allows for an aggregate across the blueprint.

To add a processor for total thermal output:

  1. From the Analytical Processor list, under the Grouping category, select Sum. In the Sum and Output fields, enter Total Blueprint Thermal Output.

    UI for adding a processor in a data app. Menu with search and options like Average and Sum. Flow diagram shows Input to Sum to Output labeled Total Blueprint Thermal Output.

  2. Edit the processor.

    Enter Thermal Output per Device for the Stage Name and value for the Column Name.

    Configuration interface for Sum operation in a data tool, summing the value column from Thermal Output per Device without grouping.

  3. Check Enable Metric Logging to enable logging.

    Configuration interface for Total Blueprint Thermal Output with options for metric logging, data retention Last 30 Days, description field, and BTU/H unit.

  4. View your result.

    Dashboard showing Total Blueprint Thermal Output with real-time data updates. Data source is real-time. Dynamic and Persisted data options available, storage 3.01 MB over 30 days. Table shows Total Count 7, Value 13769, updating in a few seconds. Pagination controls indicate 1 of 1 page. Includes search and settings icons.

  5. Next, we'll create a processor for Total Blueprint Used Power.

    From the Analytical Processor list, under Grouping, select Sum. In the Sum and Output fields, enter Total Blueprint Used Power.

    User interface for adding a processor in a data tool: Left panel lists Analytical Processors, Sum processor selected. Right panel shows configuration flow: Input, Sum, Output blocks.

  6. Edit the processor.

    Enter Used Capacity Per Device for the Stage Name and value for the Column Name.

    Configuration interface for a data processing tool showing setup for a Sum operation with inputs from Used Capacity Per Device and summing column value.

  7. View your result.

    Dashboard interface displaying Total Blueprint Used Power metrics with real-time data source. Includes options for dynamic and persisted data, 30-day retention, 2.82 MB size. Table shows total count 7, value 4034, updated in a minute. Pagination controls present.

Range processor to set threshold based anomaly

You can create a range processor to generate an alert when a device uses more than 80 percent of its allocated capacity. A range processor checks the value against a defined range.

To create a range processor:

  1. From the Analytical Processor list, under the Check category, select Range. In the Range and Output fields, enter Device with power usage > 80 % capacity.

    User interface for configuring a data processing workflow with a highlighted Range processor filtering devices with power usage over 80 percent capacity.

  2. Set the range processor to the ratio of used versus allocated power and specify an anomalous range of 80 percent or more. Check Raise Anomaly to receive alerts in the Apstra GUI when this range is exceeded. This allows for efficient power management and early detection of potential issues.

    Configuration interface for anomaly detection rule setup. Input stage is Ratio of Used vs. Allocated Power. Anomalous range flags values more than or equal to 80. Advanced section collapsed.

Verify Your Configuration

You can view your configuration by selecting your probe from the table under Analytics > Probes. The following example shows the processor we created for Aggregated Used Capacity that details the capacity used for each device.

Dashboard interface monitoring system metrics for power and capacity usage across devices. Highlighted: Aggregated Used Capacity, live data monitoring. Columns: System ID, Device Type, Total Count, Value, Updated.