Telemetry 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 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).