Configuring Dial-Out Telemetry

A server profile defines the parameters of the server that collects exported telemetry data. You can define more than one server profile. You can also associate the same server profile with more than one sensor profile. Starting in Junos OS Release 15.1F6, you can associate more than one server with a specific sensor.

To define the profile of a streaming server to collect exported telemetry data:

An export profile defines the parameters of the export process of data generated through the Junos telemetry interface. You must configure at least one export profile, but you can configure multiple export profiles. Each export profile can be associated with multiple sensor profiles. However, you can associate only one export profile with a specific sensor profile.

To enable export of statistics, include the export-profile and sensor statements at the [edit services analytics] hierarchy level. The export profile must include the reporting rate, the transport service (for example, gRPC), and the format (for example, gbp-gnmi). The sensor configuration should include the name of the collector (the server’s name), the name of the export profile, and the resource path. An example of a resource path is /interfaces/interface[name='fxp0'.

To configure an export profile:

A sensor profile defines the parameters of the system resource to monitor and stream data. You can enable only one system resource to monitor for each sensor profile. Configure a different sensor profile for each system resource you want to monitor. You can, however, configure more than one sensor to monitor the same system resource. For example, you might want to configure different parameters for exporting data for the same system resource.

To configure a sensor profile:

From configuration mode, confirm your configuration by entering the show services analytics command. If your output does not display the intended configuration, repeat the instructions in this configuration procedure to correct the configuration.

After you commit the configuration, verify that the sensor is enabled by issuing the show agent sensors operational command.

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.

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.

• 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 2: 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).