Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Create an IBA Probe and Processor

We've created a custom telemetry service for BFD. Next, we'll create a probe and add a processor to enable Apstra to collect data from the telemetry service. Before continuing, we first need to understand IBA and the role of processors.

Introduction to IBA

IBA, or Intent-Based Analytics, is a real-time analytics pipeline composed of processors in two categories: source processors and analytical processors. Source processors, the pipeline's initial stage, ingest telemetry data from built-in and custom telemetry services. These processors use graph queries to define data collection scope, skip an input stage, and produce data for downstream analytical processors.

Types of Processors

Source processors start the IBA pipeline by ingesting telemetry data from both built-in and custom telemetry services. These processors do not require an input stage and produces initial data for downstream analytical processors. The three types of source processors are described in Table 1.

You can also add analytical processors to the probe for extra data analytics. See Add an Analytical Processor for details.

Table 1: Source Processors
Built-in Processors Built-in processors ingest data from service collectors as a source for IBA Probes. These processors are designed for use cases involving one or more predefined IBA Probes but can also be used in custom probes. Some examples of built-in processors include the following types:
  • BGP Sessions: Collects metrics and statistics on BGP sessions across VRFs and address-families. Reports session state (such as "Established," "Connect") and flap counts.

  • EVPN Type-3 Routes: Generates configurations with expectations for EVPN type 3 routes.

  • EVPN Type-5 Routes: Generates configurations with expectations for EVPN type 5 routes.

  • Interface Counters: Selects interfaces based on configuration and outputs counter stats (such as tx_bytes). Requires no input.

Extensible Processors

Extensible processors ingest data from extensible collectors as a source of IBA probes. This category includes processors for custom service collectors. You can use a graph query to determine which systems to activate the service on depending on the service’s data type: Static or Dynamic.

For static or dynamic data types, use graph elements to map the service keys to determine the scope of the telemetry collection, including which telemetry series to extract from each system.

Graph Processors Graph processors ingest data from the graph database as a source of IBA Probes. These processors do not consume device telemetry data. The only processor in this category, Generic Graph Collector, ingests data from the active graph. The value field expression generates a value for each item in the graph query response.

Create a Probe

Now, we'll create a probe in your deployed blueprint. The probe enables Apstra to collect telemetry data, aggregate and calculate the collected data, and optionally set conditions that trigger anomaly detection.

To create a probe:

  1. From the left pane, select your blueprint, and navigate to Analytics > Probes > Create Probe > New Probe.
  2. Enter a label for the new probe. Optionally, you can enter a description.
  3. Click Add Processor. The processor ingests the raw telemetry into the probe to start the data-processing pipeline. Alternatively, you can import a probe from JSON.
  4. Select Extensible Service Collector under the Extensible category from the left pane.
  5. Rename the collector. For our example, we renamed the collector and output fields to BFD-state.

    You can use this processor for any service you create with custom telemetry collectors. This collector supports both static series (graph-driven) and dynamic series (collector-driven) telemetry collections.

  6. Click Add.
Next, we'll add a graph query. In IBA, source processors derive context from the Apstra blueprint graph. The graph iserves as the single source of truth for systems, interfaces, and their relationships, and is used to select exactly where and what to collect. Understanding the graph model and how processors scope collection and derive identities (keys) is essential.

Continue to Graph Database Overview for an overview of the graph database. Or, skip to Add Graph Queries to the Probe.