Configure a NETCONF Proxy Telemetry Sensor in Junos
Using Junos telemetry streaming, you can turn any available state information into a telemetry sensor by means of the XML Proxy functionality. The NETCONF XML management protocol and Junos XML API fully document all options for every supported Junos OS operational request. After you configure XML proxy sensors, you can access data over NETCONF “get” remote procedure calls (RPCs).
This task shows you how to stream the output of a Junos OS operational mode command.
We recommend not to use YANG files that map to a Junos OS operational command with extensive or
verbose output. The output from some operational mode commands is dynamic and the level of
their verbosity depends on factors such as the configuration and hardware. Examples of such
commands include any variation of show interfaces
, show
route
, show arp
, show bfd
, show
bgp
, and show ddos-protection
. To check the verbosity level of a
command, issue the command-name|
display xml | count command. If the line
count exceeds a value of 4000 lines, then the command is not recommended for XML proxy
streaming. This value is more of an approximation based on internal base-lining. It can be
less depending upon various factors such as device type, processing power of the device, and
the existing CPU load. Consequently, this feature needs to be used judiciously based on how
the device is performing.
Using a YANG file that maps to a verbose command results in one or more of following::
The xmlproxyd process CPU utilization remains high. If xmlproxyd has tracing enabled, the CPU utilization is even higher.
An increase in the xmlproxyd process memory utilization.
The xmlproxyd process state may show
sbwait
, indicating that the command output is verbose and that xmlproxyd is spending significant time reading the command's remote procedure call’s (RPC’s) output.The xmlproxyd sensor data does not complete the wrap.
The xmlproxyd streams partial or no data for the sensors.
The xmlproxyd misses reporting-interval cycles. The intervals start to overlap because of a command’s verbose output, resulting in the xmlproxyd's sensor streaming data that is slow or delayed.
The process or application that serves the verbose command's RPC may show high CPU numbers or delays in performing main tasks. This behavior is caused when the process or application is busy serving the RPC that has verbose output.
This task requires the following:
An MX Series, vMX Series, or PTX Series router operating Junos OS Release 17.3R2 or later.
Installation of the required Network Agent package ( network-agent-x86–32–17.4R1.16-C1.tgz or later).
A telemetry data receiver, such as OpenNTI, to verify proper operation of your telemetry sensor.
In this task, you will stream the contents of the Junos OS command show system users
.
show system users (vMX Series)
user@switch> show system users USER TTY FROM LOGIN@ IDLE WHAT user1 pts/0 172.31.12.36 12:40PM 39 -cli (cli) user2 pts/1 172,16.03.25 3:01AM - -cli (cli)
In addition to the expected list of currently logged-in users,
the show system users
output also provides the average
system load as 1, 5 and 15 minutes. You can find the load averages
by using the show system users | display xml
command to
view the XML tagging for the output fields. See <load-average-1>
, <load-average-5>
, and <load-average-15>
in the XML tagging output below.
user@switch> show system users | display xml <rpc-reply xmlns:junos="http://xml.juniper.net/junos/17.4R1/junos"> <system-users-information xmlns="http://xml.juniper.net/junos/17.4R1/junos"> <uptime-information> <date-time junos:seconds="1520170982">1:43PM</date-time> <up-time junos:seconds="86460">1 day, 40 mins</up-time> <active-user-count junos:format="2 users">2</active-user-count> <load-average-1>0.70</load-average-1> <load-average-5>0.58</load-average-5> <load-average-15>0.55</load-average-15> <user-table> <user-entry> <user>root</user> <tty>pts/0</tty> <from>172.21.0.1</from> <login-time junos:seconds="1520167202">12:40PM</login-time> <idle-time junos:seconds="0">-</idle-time> <command>cli</command> </user-entry> <user-entry> <user>mwiget</user> <tty>pts/1</tty> <from>66.129.241.10</from> <login-time junos:seconds="1520170862">1:41PM</login-time> <idle-time junos:seconds="60">1</idle-time> <command>cli</command> </user-entry> </user-table> </uptime-information> </system-users-information> <cli> <banner></banner> </cli> </rpc-reply>
The uptime-information
tag shown
in the preceding output is a container that contains leafs, such as date-time
, up-time
, active-user-count
. and load-average-1
. Below is a sample YANG file for this container:
container uptime-information { dr:source "uptime-information"; // Exact name of the XML tag leaf date-time { // YANG model leaf type string; // Type of value dr:source date-time; // Exact name of the XML tag } leaf up-time { // YANG model leaf type string; // Type of value dr:source up-time; // Exact name of the XML tag } leaf active-user-count { // YANG model leaf type int32; // Type of value dr:source active-user-count; // Exact name of the XML tag } leaf load-average-1 { // YANG model leaf type string; // Type of value dr:source load-average-1; // Exact name of the XML tag } ...
The uptime-information
tag also
has another container named user-table
that
contains a list of user entries.
Below is a sample YANG file for this container:
container user-table { // "user-table" container which contains list of user-entry dr:source "user-table"; // Exact name of the XML tag list user-entry { // "user-entry" list which contains the users' details in form of leafs key "user"; // Key for the list "user-entry" which is a leaf in the list "user-entry" dr:source "user-entry"; // Source of the list "user-entry" which is the exact name of the XML tag leaf user { // YANG model leaf dr:source user; // A leaf in the list "user-entry", exact name of the XML tag type string; // Type of value } leaf tty { // YANG model leaf dr:source tty; // A leaf in the list "user-entry", exact name of the XML tag type string; // Type of value } leaf from { // YANG model leaf dr:source from; // A leaf in the list "user-entry", exact name of the XML tag type string; // Type of value } leaf login-time { // YANG model leaf dr:source login-time; // A leaf in the list "user-entry", exact name of the XML tag type string; // Type of value } leaf idle-time { // YANG model leaf dr:source idle-time; // A leaf in the list "user-entry", exact name of the XML tag type string; // Type of value } leaf command { // YANG model leaf dr:source command; // A leaf in the list "user-entry", exact name of the XML tag type string; // Type of value } } }
Create a User-Defined YANG File
The YANG file defines the Junos CLI command to be executed, the resource path the sensors are placed under, and the key value pairs taken from the matching XML tags.
Custom YANG files for Junos OS conform to the YANG language syntax defined in RFC 6020 YANG 1.0 YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) and RFC 7950 The YANG 1.1 Data Modeling Language. Certain directives need to be present in the file that configure XML proxy.
To use the xmlproxyd
(daemon) process to translate
telemetry data, create a render.yang
file. In this file, the dr:command-app
is set to xmlproxyd
.
The XML proxy YANG filename and module name must start with xmlproxyd_
:
For the XML proxy YANG filename, add the extension
.yang
, for example,xmlproxyd_sysusers.yang
For the module name, use the filename without the extension
.yang
, for example,xmlproxyd_sysusers
To simplify creating a YANG file, it’s easiest to start by modifying a working example.
Load the Yang File in Junos
After the YANG file is complete, upload the YANG file and verify that the module is created.
Collect Sensor Data
Use your favorite collector to pull the newly created telemetry sensor data from the device.
Consider resource constraints before initiating sensors:
- Avoid specifying the same reporting interval for multiple XML proxy sensors.
- Because xmlproxyd performs XML and text processing, a device should only contain XML proxy sensors that execute within the CPU utilization range.
The following instructions use the collector jtimon. For information about jtimon setup, see Junos Telemetry Interface client.
Installing a User-Defined YANG File
To add, validate, modify, or delete a user-defined YANG
file for XML proxy for the Junos telemetry interface, use the request system yang
set of commands from the operational mode:
See Also
Troubleshoot Telemetry Sensors
Problem
Description
Use the following methods to troubleshoot user-define telemetry sensors:
Execute a tcpdump for the interface your gRPC requests came from (for this task, interface
fxp0
was used).user@switch>monitor traffic interface fxp0 no-resolve matching "tcp port 32767"
Enable traceoptions using the set services analytics traceoptions flag xmlproxy command. Check the
xmlproxyd
log file for confirmation of whether the CLI command’s RPC was sent and if a response was received:
Issue the show log xmlproxyd command to show the xmlproxyd log. The value for the field
xmlproxy_execute_cli_command:
indicates if the RPC was sent or not. The value for the fieldxmlproxy_build_context
indicates the command.
user@switch>show log xmlproxyd Mar 4 18:52:46 vmxdockerlight_vmx1_1 clear-log[52495]: logfile cleared Mar 4 18:52:51 xmlproxy_telemetry_start_streaming: sensor /junos/system-users-information/ Mar 4 18:52:51 xmlproxy_build_context: command show system users merge-tag: Mar 4 18:52:51 <command format="xml">show system users</command> Mar 4 18:52:51 xmlproxy_execute_cli_command: Sent RPC.. Mar 4 18:52:51 <system-users-information xmlns="http://xml.juniper.net/junos/17.4R1/junos" xmlns:junos="http://xml.juniper.net/junos/*/junos"> <uptime-information> <date-time junos:seconds="1520189571"> 6:52PM </date-time> <up-time junos:seconds="107400"> 1 day, 5:50 </up-time> <active-user-count junos:format="1 users"> 1 </active-user-count> <load-average-1> 0.94 </load-average-1> <load-average-5> 0.73 </load-average-5> <load-average-15> 0.65