Data Models and Sensor Paths

Data Models

Juniper Telemetry Interface data models define the structure of telemetry data collected from network devices, using YANG (Yet Another Next Generation). YANG is a standards-based, extensible data modeling language used in the Juniper Telemetry Interface (JTI) to define configuration, operational state data, and remote procedure calls (RPCs) for network devices. In JTI, YANG modules enable the provisioning of sensors to collect and export telemetry data, such as interface statistics, using native or OpenConfig data models. The YANG standard is defined in RFC 6020 and RFC 7950.

Juniper Networks publishes YANG modules for Junos devices, which can be downloaded from the Juniper GitHub repository or generated on-device.

The OpenConfig working group defines the OpenConfig data model. It is a vendor-neutral data model to configure and manage the network. OpenConfig data model generates data as Google Protocol Buffers (GPB) messages in a universal key/value format. JTI allows you to leverage OpenConfig models for a broader, vendor-agnostic view of your network. Openconfig sensor paths are used to retrive sensor information from sensors based on the Openconfig data model. For detailed Openconfig resource path exploration, see Junos YANG Data Model Explorer.

The Juniper native data model is an open and extensible framework developed by Juniper. This model is used to stream telemetry data about the unique features found on Juniper devices. These include interface statistics, routing information, security metrics, and so on. Additionally, the native model allows for the definition of enterprise-specific sensors. To access information from Juniper or enterprise-specific sensors, subscribe to Juniper native sensors. Native sensor paths are used to retrive sensor information from sensors based on the native data model. Juniper’s YANG modules for native sensors are available at Juniper's Telemetry GitHub repository.

Sensor Paths

A telemetry sensor path describes the hierarchical path to the data points or metrics that need to be monitored. To stream the required sensor data and activate the sensor and identify the relevant sensor path. JTI supports both Openconfig sensor paths and native sensor paths:

• Openconfig Sensor Paths

  To configure data collection from Openconfig sensors, define the subscriptions and sensor paths (for example, /interfaces/interface/state/counters), set up the data collector, and download the Junos Telemetry Interface protocol buffers files from the Juniper Networks support page. Capture and decode the captured data on the collector.

• Native Sensor Paths

  Native sensor paths are specific to Junos OS (for example, /junos/system/line card/interface/) and offer granular, Juniper-optimized access to device-specific metrics.

  To configure data collection from native sensors, use the Junos CLI to provision native sensors for collecting specific data. Configure the telemetry interface to stream data using gRPC or UDP. Use the protocol buffer's files to decode the streamed data on the collector.

Both path types enable the structured output of data in formats such as JSON or XML, ensuring compatibility with external collectors for efficient monitoring and analytics.

Sensor Path Explorer

The Juniper Networks Junos YANG Data Model Explorer is an online tool for viewing all the supported resource paths, their corresponding leaves, and the device platforms that support them. It enables you to explore or compare various OpenConfig and Native data model attributes. Use the filter option based on the software release number or product to view the list of resource paths and sensors on each platform.

Selecting Telemetry Sensor Paths

In a model-driven telemetry system, the sensor path can be configured to end at any level within the data model's container hierarchy. Based on the required telemetry information, you can configure the sensor path to retrieve a broad data set or be very specific and retrieve targetted information for a particular sensor. For example, a sensor path might point to a container that includes all interface statistics on a router, or it could be more granular, focusing on a single metric like packet loss on a specific interface. 

For example, to receive telemetry data about alarms generated on the device (using the OpenConfig data model), you can configure either of the following resource paths based on the granularity of sensor data required:

• /system/alarms/alarm/id: This path retrieves only the alarm ID.
• /system/alarms/alarm/config: This path retrieves the detailed alarm information.

Configuring the correct sensor paths ensures an efficient telemetry system. Each resource path enables data streaming for the system resource globally, that is, systemwide. You can modify each resource path to specify a logical or physical interface. The resource path "/interfaces/interface/config" retrieves the list of configurable items at the global, physical interface level, whereas the path "/interfaces/interface/config/name" specifies the name of the interface, and the device may restrict the allowed values for this leaf depending on the type of the interface.

Important Guidelines for Selecting Sensor Paths

• Users should always provide the complete and direct resource path when configuring sensors. Providing partial resource paths, such as "/components/component/", results in incomplete configurations and potential errors. Such resource paths overwhelm the device, as it needs to display all the available options at that hierarchy. To prevent this, always verify and use the full resource path to ensure precise and efficient sensor configuration.

  Note: Creating subscription and sensor configuration at the "/" (root) and "/junos/" is not allowed.

  Table 1: Sensor Path Example

  Good example of a Resource Path	Poor example of a Resource Path
  /interfaces/interface/subinterfaces/subinterface/state/counters/out-pkts	/interfaces/interface

• The logical and physical Packet Forwarding Engine interface sensors report some leaves inconsistently to the collector. For example, the subscribed path /interfaces/ 115 interface/ producing the streamed path /junos/system/linecard/interface/logical/ usage/ reports key name leaves parent_ae_name and init_time (with underscores in the leaf name). The subscribed path /interfaces/interface/state/ producing the streamed path / junos/system/linecard/interface/queue/ reports key name leaves parent-ae-name and init\u0002time (with hyphens in the leaf name).