Telemetry Sensor Paths
A telemetry sensor path is a specific route within a data model, often defined using YANG, that specifies the exact data to be collected and streamed from a network device. It 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, identify the relevant sensor path.
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.
To search and view other telemetry sensors and specific information about some legacy sensors, see Legacy Sensor Paths.
Configuring 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 Configuring 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 leavesparent_ae_name
andinit_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 leavesparent-ae-name
andinit\u0002time
(with hyphens in the leaf name).
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.
/network-instances/network-instance/afts
.