Create your own Telemetry Sensor in Junos

Create your own Telemetry Sensor in Junos

Junos offers a broad range of automation capabilities, starting from a YANG based configuration and state information base, accessible via CLI, NETCONF and REST over gRPC based JET APIs directly into various Junos daemons. Some readers might even be familiar with custom YANG, allowing operators to extend the functionality in Junos in respect to configuration and operational commands and make them available via CLI, NETCONF and REST. An example can be found in my post about L2VPN Custom YANG.

But the ability to customize and extend Junos doesn’t stop here. With the introduction ofJunos telemetry streaming, one can turn any available state information into an OpenConfig Telemetry Sensor via the XML Proxy functionality.

This document walks you thru the steps to stream the output of the CLI command “show system users”. More information can be found in the Juniper TechLibrary about Configurable NETCONF Proxy for Junos Telemetry Interface.

Requirements

  • MX, vMX or PTX Junos device running 17.3R1 or newer
  • Junos Openconfig and na telemetry packages loaded. For Junos 17.4R1, the required packages to install are junos-openconfig-x86–32–0.0.0.8.tgz and network-agent-x86–32–17.4R1.16-C1.tgz. Please check out my blog about jtimon on how to install these.
  • A telemetry data receiver, e.g. jtimon, to verify proper operation of your telemetry sensor.

Where to start?

In this post we want to stream the content of the Junos CLI command ‘show system users’:

root@vmxdockerlight_vmx1_1> show system users
 1:41PM  up 1 day, 38 mins, 2 users, load averages: 0.63, 0.55, 0.54
USER     TTY      FROM                              LOGIN@  IDLE WHAT
root     pts/0    172.21.0.1                       12:40PM     - cli
mwiget   pts/1    66.129.241.10                    1:41PM      - -cl

In addition to the obvious list of currently logged in users, it also provides the average system load per 1, 5 and 15 minutes. How Do I know the meaning of these load averages you might ask? By reading the XML tag of these fields:

root@vmxdockerlight_vmx1_1> 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>-cl</command>
                </user-entry>
            </user-table>
        </uptime-information>
    </system-users-information>
    <cli>
        <banner></banner>
    </cli>
</rpc-reply>

We will need this XML output of the show command when creating the YANG file to match the containers and leafs with the keys and values we want to stream, so keep a copy of its output close.

Create the User-Defined YANG File

The YANG file defines the Junos CLI command to be executed, the Openconfig path the sensors are placed under and the key value pairs taken from the matching XML tags. I find it easier to start from a working example than trying to write one from scratch. If you agree, you can either copy-paste the xmlproxyd_krt.yang from https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/yang-xmlproxy-junos-telemetry-interface-configuring.html (but name the module in the file krt instead of xmlproxyd_krt) or use the example created for this blog post: xmlproxyd_sysusers.yaml. You can also download the krt YANG file I used to write this document at xmlproxyd_krt.yaml.

Allow me to explain a few important elements in this custom YANG file. Where in the Openconfig state tree shall the generated sensor report its values in? Both examples contain an RPC container near the end of the YANG file:

/* shortened example
 */

module sysusers {
  yang-version 1;

  namespace "http://juniper.net/yang/software";

  prefix "sys";

  import drend {
    prefix dr;
  }

  grouping system-users-information-grouping {
    /* actual content removed */
  }

  dr:command-app "xmlproxyd";
  rpc juniper-netconf-get {
    dr:command-top-of-output "/junos";
    dr:command-full-name "drend juniper-netconf-get";
    dr:cli-command "show system users";
    dr:command-help "default <get> rpc";
    output {
      container junos {
        container system-users-information {
          dr:source "/system-users-information";
          uses system-users-information-grouping;
        }
      }
    }
  }
}

The module name should typically match the YANG filename, but loading such a file will fail with an error message about <error: illegal identifier “xmlproxyd_sysusers”, must not start with [xX][mM][lL]> in 17.3R1 and 17.4R1, so keep the xmlproxyd_ prefix of the filename but name the module within to avoid generating this error. I picked ‘sysusers’ (which still generates a warning about naming mismatch with the filename, but works).

With Junos 17.3R2 and newer releases, one can name the module xmlrpoxyd_sysusers without generating any warnings or errors.

The absolute path where the sensors will be reported under is built from the output group: junos + ystem-users-information, concatenated by ‘/’: /junos/system-users-information/. This is the path to query everything from this custom sensor. The example from TechPubs’s path is /junos/krt-state-information/.

The actual Junos CLI command that gets executed at the requested sample frequency is defined under dr:cli-command, executed by the xmlproxyd daemon. I would have expected the need to specify the XML RPC equivalent of the CLI command, but using the human readable ‘show system users’ command is actually more user friendly.

Another point I’d like to make is the fact, that one can execute hidden commands too. In fact, the TechPubs example for using ‘show krt’ is such a hidden command, at least in 17.3 and 17.4.

The 1:1 mapping between container, leafs and the XML tag/value from the CLI command output is defined in the grouping referenced by uses within the output container. In my example that is system-users-information-grouping and in the krt case it is krt-state-information-grouping. For readability, the definition of the grouping is shown above the RPC entry in the YANG file.

Every container, list and leaf must be mapped to an output XML tag from the CLI command XML output. I actually forgot to add the source for the nested container ‘user-table’, leaving me without the user table in the streamed telemetry data.

Load the YANG file in Junos

Upload your YANG file to Junos, then load it with

user@junos> request system yang add package sysusers proxy-xml module xmlproxyd_sysusers.yang
XML proxy YANG module validation for sysusers.yang : START
/var/home/mwiget/xmlproxyd_sysusers.yang:38: warning: unexpected modulename "sysusers" in /var/home/mwiget/xmlproxyd_sysusers.yang, should be xmlproxyd_sysusers
XML proxy YANG module validation for sysusers.yang : SUCCESS
JSON generation for sysusers.yang : START
/opt/yang-pkg/sysusers/xmlproxy/yang/xmlproxyd_sysusers.yang:38: warning: unexpected modulename "sysusers" in /opt/yang-pkg/sysusers/xmlproxy/yang/xmlproxyd_sysusers.yang, should be xmlproxyd_sysusers
JSON generation for sysusers.yang : SUCCESS

The warning messages can be ignored. Don’t rename the module name, because that would generate an error when loading. If you remove the ‘xmlproxyd_’ prefix from the filename, the warning messages go away, but it won’t produce any telemetry data.

Verify the module is loaded with

user@junos> show system yang package sysusers
 Package ID            :sysusers
 XML Proxy YANG Module(s) :sysusers.yang

The same for the xmlproxyd_krt.yang file from the Junos documentation (optional):

user@junos> request system yang add package krt proxy-xml module xmlproxyd_krt.yang
XML proxy YANG module validation for xmlproxyd_krt.yang : START
/var/home/mwiget/xmlproxyd_krt.yang:7: warning: unexpected modulename "krtState" in /var/home/mwiget/xmlproxyd_krt.yang, should be xmlproxyd_krt
XML proxy YANG module validation for xmlproxyd_krt.yang : SUCCESS
JSON generation for xmlproxyd_krt.yang : START
/opt/yang-pkg/krt/xmlproxy/yang/xmlproxyd_krt.yang:7: warning: unexpected modulename "krtState" in /opt/yang-pkg/krt/xmlproxy/yang/xmlproxyd_krt.yang, should be xmlproxyd_krt
JSON generation for xmlproxyd_krt.yang : SUCCESS

Verify that now both sensors are loaded:

user@junos> show system yang package krt
Package ID            :krt
XML Proxy YANG Module(s) :xmlproxyd_krt.yang

Enable gRPC (without authentication) in Junos configuration:

 set system services extension-service request-response grpc clear-text port 50051
 set system services extension-service request-response grpc skip-authentication

If you need to update the YANG file in Junos, use a command similar to this:

request system yang update sysusers proxy-xml module xmlproxyd_sysusers.yang

Time to collect

Use your favorite collector, e.g. https://github.com/nileshsimaria/jtimon to pull the newly created telemetry sensor data from the device. The following instructions use jtimon.

Create a simple jtimon config file, adjust the host IP address and port as needed. The “freq” field is defined in ms, streaming a new set of key value pairs every 5 seconds.

 $ cat vmx1.json
 {
   "host": "172.16.122.182",
   "port": 50051,
   "cid": "my-client-id",
   "grpc" : {
     "ws" : 524289
   },
   "paths": [
      {
        "path": "/junos/system-users-information/",
        "freq": 5000
      },
      {
        "path": "/junos/krt-state-information/",
        "freq": 5000
      }
    ]
  }

Launch jtimon, either using your own compiled jtimon or an automatically built image from Docker Hub. The sample query shown below shows two sensor reports per path, then I terminated it with Ctrl-C. Every key is sent in human readable form as an absolute path and in case of lists, contains an index in form of XPATH, ideal to group values from a (time series) database like InfluxDB e.g.

/junos/system-users-information/uptime-information/user-table/user-entry[user='mwiget']/

$ docker run -ti --rm -v ${PWD}:/u marcelwiget/jtimon --config vmx1.json --print
gRPC headers from Junos:
  init-response: [response { subscription_id: 1 } path_list { path: "/junos/system-users-information/" sample_frequency: 5000 } path_list { path: "/junos/krt-state-information/" sample_frequency: 5000 } ]
  content-type: [application/grpc]
  grpc-accept-encoding: [identity,deflate,gzip]
2018/03/04 17:13:19 system_id: vmxdockerlight_vmx1_1
2018/03/04 17:13:19 component_id: 65535
2018/03/04 17:13:19 sub_component_id: 0
2018/03/04 17:13:19 path: sensor_1000:/junos/system-users-information/:/junos/system-users-information/:xmlproxyd
2018/03/04 17:13:19 sequence_number: 16689
2018/03/04 17:13:19 timestamp: 1520183589391
2018/03/04 17:13:19 sync_response: %!d(bool=false)
2018/03/04 17:13:19   key: __timestamp__
2018/03/04 17:13:19   uint_value: 1520183589391
2018/03/04 17:13:19   key: __junos_re_stream_creation_timestamp__
2018/03/04 17:13:19   uint_value: 1520183589372
2018/03/04 17:13:19   key: __junos_re_payload_get_timestamp__
2018/03/04 17:13:19   uint_value: 1520183589390
2018/03/04 17:13:19   key: /junos/system-users-information/uptime-information/date-time
2018/03/04 17:13:19   str_value: 5:13PM
2018/03/04 17:13:19   key: /junos/system-users-information/uptime-information/up-time
2018/03/04 17:13:19   str_value: 1 day,  4:10
2018/03/04 17:13:19   key: /junos/system-users-information/uptime-information/active-user-count
2018/03/04 17:13:19   int_value: 2
2018/03/04 17:13:19   key: /junos/system-users-information/uptime-information/load-average-1
2018/03/04 17:13:19   str_value: 0.62
2018/03/04 17:13:19   key: /junos/system-users-information/uptime-information/load-average-5
2018/03/04 17:13:19   str_value: 0.56
2018/03/04 17:13:19   key: /junos/system-users-information/uptime-information/load-average-15
2018/03/04 17:13:19   str_value: 0.53
2018/03/04 17:13:19   key: __prefix__
2018/03/04 17:13:19   str_value: /junos/system-users-information/uptime-information/user-table/user-entry[user='root']/
2018/03/04 17:13:19   key: tty
2018/03/04 17:13:19   str_value: pts/0
2018/03/04 17:13:19   key: from
2018/03/04 17:13:19   str_value: 172.21.0.1
2018/03/04 17:13:19   key: login-time
2018/03/04 17:13:19   str_value: 12:40PM
2018/03/04 17:13:19   key: idle-time
2018/03/04 17:13:19   str_value: -
2018/03/04 17:13:19   key: command
2018/03/04 17:13:19   str_value: cli
2018/03/04 17:13:19   key: __prefix__
2018/03/04 17:13:19   str_value: /junos/system-users-information/uptime-information/user-table/user-entry[user='mwiget']/
2018/03/04 17:13:19   key: tty
2018/03/04 17:13:19   str_value: pts/1
2018/03/04 17:13:19   key: from
2018/03/04 17:13:19   str_value: 66.129.241.10
2018/03/04 17:13:19   key: login-time
2018/03/04 17:13:19   str_value: 5:12PM
2018/03/04 17:13:19   key: idle-time
2018/03/04 17:13:19   str_value: -
2018/03/04 17:13:19   key: command
2018/03/04 17:13:19   str_value: -cl
2018/03/04 17:13:21 system_id: vmxdockerlight_vmx1_1
2018/03/04 17:13:21 component_id: 65535
2018/03/04 17:13:21 sub_component_id: 0
2018/03/04 17:13:21 path: sensor_1001:/junos/krt-state-information/:/junos/krt-state-information/:xmlproxyd
2018/03/04 17:13:21 sequence_number: 450
2018/03/04 17:13:21 timestamp: 1520183591382
2018/03/04 17:13:21 sync_response: %!d(bool=false)
2018/03/04 17:13:21   key: __timestamp__
2018/03/04 17:13:21   uint_value: 1520183591383
2018/03/04 17:13:21   key: __junos_re_stream_creation_timestamp__
2018/03/04 17:13:21   uint_value: 1520183591375
2018/03/04 17:13:21   key: __junos_re_payload_get_timestamp__
2018/03/04 17:13:21   uint_value: 1520183591379
2018/03/04 17:13:21   key: __prefix__
2018/03/04 17:13:21   str_value: /junos/krt-state-information/krt-queue-state[operations-queued='0']/
2018/03/04 17:13:21   key: rt-table-adds
2018/03/04 17:13:21   uint_value: 0
2018/03/04 17:13:21   key: interface-routes
2018/03/04 17:13:21   uint_value: 0
2018/03/04 17:13:21   key: high-multicast-adds-changes
2018/03/04 17:13:21   uint_value: 0
2018/03/04 17:13:21   key: top-indirect-adds-changes
2018/03/04 17:13:21   uint_value: 0
2018/03/04 17:13:21   key: indirect-adds-changes
2018/03/04 17:13:21   uint_value: 0
2018/03/04 17:13:21   key: indirect-deletes
2018/03/04 17:13:21   uint_value: 0
2018/03/04 17:13:21   key: high-mpls-adds
2018/03/04 17:13:21   uint_value: 0
2018/03/04 17:13:21   key: high-mpls-changes
2018/03/04 17:13:21   uint_value: 0
2018/03/04 17:13:21   key: top-priority-adds
2018/03/04 17:13:21   uint_value: 0
2018/03/04 17:13:21   key: top-priority-changes
2018/03/04 17:13:21   uint_value: 0
2018/03/04 17:13:21   key: top-priority-deletes
2018/03/04 17:13:21   uint_value: 0
2018/03/04 17:13:21   key: high-priority-adds
2018/03/04 17:13:21   uint_value: 0
2018/03/04 17:13:21   key: high-priority-changes
2018/03/04 17:13:21   uint_value: 0
2018/03/04 17:13:21   key: high-priority-deletes
2018/03/04 17:13:21   uint_value: 0
2018/03/04 17:13:21   key: normal-priority-indirects
2018/03/04 17:13:21   uint_value: 0
2018/03/04 17:13:21   key: normal-priority-adds
2018/03/04 17:13:21   uint_value: 0
2018/03/04 17:13:21   key: normal-priority-changes
2018/03/04 17:13:21   uint_value: 0
2018/03/04 17:13:21   key: normal-priority-deletes
2018/03/04 17:13:21   uint_value: 0
2018/03/04 17:13:21   key: least-priority-adds
2018/03/04 17:13:21   uint_value: 0
2018/03/04 17:13:21   key: least-priority-changes
2018/03/04 17:13:21   uint_value: 0
2018/03/04 17:13:21   key: least-priority-deletes
2018/03/04 17:13:21   uint_value: 0
2018/03/04 17:13:21   key: normal-priority-cnh-deletes
2018/03/04 17:13:21   uint_value: 0
2018/03/04 17:13:21   key: normal-priority-gmp
2018/03/04 17:13:21   uint_value: 0
2018/03/04 17:13:21   key: rt-table-deletes
2018/03/04 17:13:21   uint_value: 0
2018/03/04 17:13:21   key: operations-deferred
2018/03/04 17:13:21   uint_value: 0
2018/03/04 17:13:21   key: operations-canceled
2018/03/04 17:13:21   uint_value: 0
2018/03/04 17:13:21   key: async-count
2018/03/04 17:13:21   uint_value: 0
2018/03/04 17:13:21   key: async-non-q-count
2018/03/04 17:13:21   uint_value: 0
2018/03/04 17:13:21   key: time-until-next-run
2018/03/04 17:13:21   uint_value: 0
2018/03/04 17:13:21   key: kernel-rt-learnt
2018/03/04 17:13:21   uint_value: 34
2018/03/04 17:13:25 system_id: vmxdockerlight_vmx1_1
2018/03/04 17:13:25 component_id: 65535
2018/03/04 17:13:25 sub_component_id: 0
2018/03/04 17:13:25 path: sensor_1000:/junos/system-users-information/:/junos/system-users-information/:xmlproxyd
2018/03/04 17:13:25 sequence_number: 16690
2018/03/04 17:13:25 timestamp: 1520183595425
2018/03/04 17:13:25 sync_response: %!d(bool=false)
2018/03/04 17:13:25   key: __timestamp__
2018/03/04 17:13:25   uint_value: 1520183595425
2018/03/04 17:13:25   key: __junos_re_stream_creation_timestamp__
2018/03/04 17:13:25   uint_value: 1520183595385
2018/03/04 17:13:25   key: __junos_re_payload_get_timestamp__
2018/03/04 17:13:25   uint_value: 1520183595425
2018/03/04 17:13:25   key: /junos/system-users-information/uptime-information/date-time
2018/03/04 17:13:25   str_value: 5:13PM
2018/03/04 17:13:25   key: /junos/system-users-information/uptime-information/up-time
2018/03/04 17:13:25   str_value: 1 day,  4:10
2018/03/04 17:13:25   key: /junos/system-users-information/uptime-information/active-user-count
2018/03/04 17:13:25   int_value: 2
2018/03/04 17:13:25   key: /junos/system-users-information/uptime-information/load-average-1
2018/03/04 17:13:25   str_value: 0.57
2018/03/04 17:13:25   key: /junos/system-users-information/uptime-information/load-average-5
2018/03/04 17:13:25   str_value: 0.55
2018/03/04 17:13:25   key: /junos/system-users-information/uptime-information/load-average-15
2018/03/04 17:13:25   str_value: 0.52
2018/03/04 17:13:25   key: __prefix__
2018/03/04 17:13:25   str_value: /junos/system-users-information/uptime-information/user-table/user-entry[user='root']/
2018/03/04 17:13:25   key: tty
2018/03/04 17:13:25   str_value: pts/0
2018/03/04 17:13:25   key: from
2018/03/04 17:13:25   str_value: 172.21.0.1
2018/03/04 17:13:25   key: login-time
2018/03/04 17:13:25   str_value: 12:40PM
2018/03/04 17:13:25   key: idle-time
2018/03/04 17:13:25   str_value: -
2018/03/04 17:13:25   key: command
2018/03/04 17:13:25   str_value: cli
2018/03/04 17:13:25   key: __prefix__
2018/03/04 17:13:25   str_value: /junos/system-users-information/uptime-information/user-table/user-entry[user='mwiget']/
2018/03/04 17:13:25   key: tty
2018/03/04 17:13:25   str_value: pts/1
2018/03/04 17:13:25   key: from
2018/03/04 17:13:25   str_value: 66.129.241.10
2018/03/04 17:13:25   key: login-time
2018/03/04 17:13:25   str_value: 5:12PM
2018/03/04 17:13:25   key: idle-time
2018/03/04 17:13:25   str_value: -
2018/03/04 17:13:25   key: command
2018/03/04 17:13:25   str_value: -cl
2018/03/04 17:13:27 system_id: vmxdockerlight_vmx1_1
2018/03/04 17:13:27 component_id: 65535
2018/03/04 17:13:27 sub_component_id: 0
2018/03/04 17:13:27 path: sensor_1001:/junos/krt-state-information/:/junos/krt-state-information/:xmlproxyd
2018/03/04 17:13:27 sequence_number: 451
2018/03/04 17:13:27 timestamp: 1520183597402
2018/03/04 17:13:27 sync_response: %!d(bool=false)
2018/03/04 17:13:27   key: __timestamp__
2018/03/04 17:13:27   uint_value: 1520183597403
2018/03/04 17:13:27   key: __junos_re_stream_creation_timestamp__
2018/03/04 17:13:27   uint_value: 1520183597392
2018/03/04 17:13:27   key: __junos_re_payload_get_timestamp__
2018/03/04 17:13:27   uint_value: 1520183597400
2018/03/04 17:13:27   key: __prefix__
2018/03/04 17:13:27   str_value: /junos/krt-state-information/krt-queue-state[operations-queued='0']/
2018/03/04 17:13:27   key: rt-table-adds
2018/03/04 17:13:27   uint_value: 0
2018/03/04 17:13:27   key: interface-routes
2018/03/04 17:13:27   uint_value: 0
2018/03/04 17:13:27   key: high-multicast-adds-changes
2018/03/04 17:13:27   uint_value: 0
2018/03/04 17:13:27   key: top-indirect-adds-changes
2018/03/04 17:13:27   uint_value: 0
2018/03/04 17:13:27   key: indirect-adds-changes
2018/03/04 17:13:27   uint_value: 0
2018/03/04 17:13:27   key: indirect-deletes
2018/03/04 17:13:27   uint_value: 0
2018/03/04 17:13:27   key: high-mpls-adds
2018/03/04 17:13:27   uint_value: 0
2018/03/04 17:13:27   key: high-mpls-changes
2018/03/04 17:13:27   uint_value: 0
2018/03/04 17:13:27   key: top-priority-adds
2018/03/04 17:13:27   uint_value: 0
2018/03/04 17:13:27   key: top-priority-changes
2018/03/04 17:13:27   uint_value: 0
2018/03/04 17:13:27   key: top-priority-deletes
2018/03/04 17:13:27   uint_value: 0
2018/03/04 17:13:27   key: high-priority-adds
2018/03/04 17:13:27   uint_value: 0
2018/03/04 17:13:27   key: high-priority-changes
2018/03/04 17:13:27   uint_value: 0
2018/03/04 17:13:27   key: high-priority-deletes
2018/03/04 17:13:27   uint_value: 0
2018/03/04 17:13:27   key: normal-priority-indirects
2018/03/04 17:13:27   uint_value: 0
2018/03/04 17:13:27   key: normal-priority-adds
2018/03/04 17:13:27   uint_value: 0
2018/03/04 17:13:27   key: normal-priority-changes
2018/03/04 17:13:27   uint_value: 0
2018/03/04 17:13:27   key: normal-priority-deletes
2018/03/04 17:13:27   uint_value: 0
2018/03/04 17:13:27   key: least-priority-adds
2018/03/04 17:13:27   uint_value: 0
2018/03/04 17:13:27   key: least-priority-changes
2018/03/04 17:13:27   uint_value: 0
2018/03/04 17:13:27   key: least-priority-deletes
2018/03/04 17:13:27   uint_value: 0
2018/03/04 17:13:27   key: normal-priority-cnh-deletes
2018/03/04 17:13:27   uint_value: 0
2018/03/04 17:13:27   key: normal-priority-gmp
2018/03/04 17:13:27   uint_value: 0
2018/03/04 17:13:27   key: rt-table-deletes
2018/03/04 17:13:27   uint_value: 0
2018/03/04 17:13:27   key: operations-deferred
2018/03/04 17:13:27   uint_value: 0
2018/03/04 17:13:27   key: operations-canceled
2018/03/04 17:13:27   uint_value: 0
2018/03/04 17:13:27   key: async-count
2018/03/04 17:13:27   uint_value: 0
2018/03/04 17:13:27   key: async-non-q-count
2018/03/04 17:13:27   uint_value: 0
2018/03/04 17:13:27   key: time-until-next-run
2018/03/04 17:13:27   uint_value: 0
2018/03/04 17:13:27   key: kernel-rt-learnt
2018/03/04 17:13:27   uint_value: 34
^C

Collector Stats (Run time : 14.8724842s)
4            : in-packets
110          : data points (KV pairs)
314          : in-header wirelength (bytes)
4328         : in-payload length (bytes)
4328         : in-payload wirelength (bytes)
309          : throughput (bytes per seconds)

Troubleshooting

I used two methods to troubelshoot user defined telemetry sensors:

  • tcpdump on Junos for the interface my gRPC requests came from (fxp0 in my case):
    monitor traffic interface fxp0 no-resolve matching "tcp port 50051"
  • Traceoptions for xmlproxyd via Junos configuration (requires manual daemon restart:
    set services analytics traceoptions flag xmlproxy

In case you wonder how to find the correct configuration syntax for traceoptions, try ’help apropos;:

root@junos> configure
Entering configuration mode

[edit]
root@junos# help apropos xmlproxy
set services analytics traceoptions flag xmlproxy
    Trace xmlproxy events

Example traceoptions session:

root@junos> clear log messages
 
root@junos> restart xmlproxyd
XMLPROXY Daemon started, pid 53038
 
root@junos> 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
---(more)---

Summary

I hope this post triggered your interest to explore your own telemetry sensors. Feedback most welcome.

Check https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/yang-xmlproxy-junos-telemetry-interface-configuring.html for the official Junos documentation of the NETCONF XML proxy function.

Advertisements

One thought on “Create your own Telemetry Sensor in Junos

Add yours

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Create a free website or blog at WordPress.com.

Up ↑

%d bloggers like this: