Hi. Does anyone know if streaming telemetry is supported?
Hi,
what exactly is that, do you have some documentations/URLs and a more clear description on what you want to achieve with that?
Cheers,
Michael
We’re looking to collect telemetry data from Juniper and Cisco devices. Here are two links that might help explain what we’re hoping to accomplish.
https://www.packetdesign.com/blog/network-basics-by-packet-design-what-is-streaming-telemetry/
Ah, ok, so they are using that as SNMP poll replacement and instead stream the metric data in their own protocol. This seems pretty new.
As the number of objects on the network and the metrics they generate have grown, the traditional models, such as SNMP, used to gather operational statistics for monitoring the health of a network, have imposed limits on network element scale and efficiency. The so-called pull model used by SNMP and the CLI, which requires additional processing to periodically poll the network element, directly limits scaling.
The Junos Telemetry Interface (JTI) overcomes these limits by relying on a so-called push model to deliver data asynchronously, which eliminates polling. A request to send data is sent once by a management station to stream periodic updates. As a result, JTI is highly scalable and can support the monitoring of thousands of objects in a network.
Do they provide example receiver applications? I only see this …
With streaming telemetry, the telemetry data is described using YANG, a structured data modelling language, encoded in JSON, XML or using Google Protocol Buffers and is then streamed over TCP, UDP or gRPC.
Googling a bit further. I can see that the data sent by telemetry senders is somehow free form. So the receiver application you’ll write must specifically search for that data, as done in this example.
Juniper advertises openNTI - and the JTI input with various output plugins - … and it looks like that the collector itself would talk via CLI to Juniper. It may be extended with plugins then to forward the data to known TSDBs.
Another is jtimon which also gives insights into the gRPC interface with Google protocol buffers.
Sounds interesting, but with the lack of examples and specific message formats, I doubt that it already exists somewhere as monitoring plugin or daemon.
At least this entry shows that OpenNTI leverages this all into an interface.
- Native Streaming : This format uses a proprietary data model defined by Juniper, using Google protocol buffers (gpb) as a means of serializing and structuring telemetry data messages. Data is transported via UDP and is exported close to the source, such as directly from a line card or network processing unit (NPU).
- OpenConfig Streaming : This format utilizes OpenConfig data models and key/value pair based Google protocol buffer messages for streaming telemetry data. Unlike native format, data is transported via gRPC over HTTP2 and is exported to the collector centrally from the Routing Engine (RE).
I’d say you can use openNTI and forward metrics to InfluxDB and visualize them with Grafana. If you prefer a deeper integration with Icinga, there’s two possible routes:
- Check InfluxDB with openNTI dumped metrics and write a plugin which does that (or use an existing one, which then raises alerts)
- Write your own gRPC temetry client/collector which creates host/service objects via the Icinga REST API, and sends in check results received from metrics.
Based on this document and this presentation I would imagine that the second part takes quite some days of development, you may ask for development sponsoring via info@icinga.com
Well, a third option: Write an output for openNTI which talks to the Icinga API - that’s likely better than to fully cope with the data model Juniper and also Cisco have implemented.
Again, looks interesting. But one needs access to that hardware during development. And I bet there will be more errors in the processing line than with old school SNMP polling 
Still I am open for discussion, suggestions and design PoCs
Cheers,
Michael
1 Like
Thanks @dnsmichi for the excellent and detailed reply!
I’ve shared it on Twitter, and got some feedback as well. There’s a Prometheus exporter, which you can likely use to forward metrics into Icinga as well.