Тестируем Junos Telemetry Interface (JTI) в связке с OpenNTI

В сети на данный момент достаточно публикаций на английском языке с описанием и анализом обеих технологий.
Эта статья не является переводом какой-либо из них и основана на собственном опыте тестирования OpenNTI и JTI. Оба продукта представлены компанией Juniper и являются частью SDN-решений в плане визуализации различных метрик, получаемых с сетевых устройств.

Начнем с описания OpenNTI, поддерживаемого Juniper проекта с открытым исходным кодом.
OpenNTI — упакованный в docker (единый контейнер) набор инструментов для сбора, хранения и визуализации данных, полученных от устройств сети. В его состав входят популярный графический интерфейс Grafana, предназначенный для работы со streaming data, база данных InfluxDB, коллектор данных FluentD и агент PyEZ — библиотека для Python от Juniper, разработанный для удаленного управления и автоматизации сетевых устройств. Для сбора данных по SNMP имеется SNMP агент.

Структура контейнера и взаимодействие с сетевыми устройствами отражены ниже.

 Для OpenNTI характерны push и pull методы сбора данных телеметрии с устройств сети. Push — данные о телеметрии отправляются настраиваемыми сенсорами устройств в виде потока данных по предустановленным таймерам, pull — данные с устройств запрашиваются, а затем обрабатываются агентом. В отношении push применимы два формата передачи данных: Native Streaming и OpenConfig Streaming. Оба используют формат данных gpb (Google protocol buffers) и отличаются тем, что Native Streaming использует в качестве транспорта UDP и отправляет данные с line card, а OpenConfig Streaming передает данные от Routing Engine через gPRC over HTTP2.

    С проектом более подробно можно ознакомиться по ссылкам:

• Juniper/open-nti,
• OpenNTI Documentation,
• Continuous Integration for OpenNTI Collector without any Junos Device.

В последнее время популярной моделью сбора, хранения и обработки метрик сетевых устройств становится асинхронная push модель, имеющая в отличие от традиционной pull модели, используемой в SNMP и CLI, более высокую масштабируемость и эффективность.
 Одним из вендорских решений является Junos Telemetry Interface (JTI), представленный в JunOS начиная с 15.1F3 для МХ-серии, и в более поздних релизах для других продуктовых линеек. Технология, по сути, довольно проста и предполагает сбор и передачу данных о системных ресурсах (физические интерфейсы, firewall-фильтры, etc.) с предварительно сконфигурированных сенсоров. Поддерживаются Native Streaming и OpenConfig Streaming.

Более подробно описано по ссылкам ниже:

• Overview of the Junos Telemetry Interface,
• Junos Telemetry Interface Feature Guide,
• Configuring a Junos Telemetry Interface Sensor (CLI Procedure),

Все описанное выше можно считать небольшим введением в обе технологии, практические аспекты применения которых будут рассмотрены ниже в примерах.
Итак, прежде чем внедрять данные решения в "живую" сетевую инфраструктуру, было принято решение развернуть и протестировать их на лабораторном стенде.
В качестве стенда использовался сетевой эмулятор EVE-NG (старое название Unetlab, http://www.eve-ng.net/) с установленными Juniper vMX и виртуальным хостом Ubuntu Server 16.04.3, предназначенным для OpenNTI. Описание развертывания эммулятора и установка хостов выходит за рамки данной статьи. Единственное, с чем пришлось столкнуться, это с правами для виртуальных сетевых адаптеров VMware Player, без которых для хоста с Ubuntu отсутствовал доступ в Internet. Проблема решилась следующим образом, на физической машине изменены права для трех адаптеров VMware:

chmod q+rw /dev/vmnet0
chmod q+rw /dev/vmnet1
​chmod q+rw /dev/vmnet8

  Установка и запуск OpenNTI на виртуальный хост из docker довольно проста и выполняется в несколько кликов.
    git clone https://github.com/Juniper/open-nti.gitcd open-nti/
    make start

В процессе запуска могут возникнуть ошибки со ссылкой на отсутствующие пакеты make и docker-compose, установить которые можно с помощью:
apt-get install make
apt-get install docker-compose
 

Существует возможность изменения дефолтных параметров контейнера.

root@ubuntu-noc2:~/open-nti# nano open-nti.params

  После установки можно сразу же проверить доступ в Grafana и InfluxDB.

Для сбора данных методом Pull с сетевых устройств необходимо в каталоге /open-nti/data/ отредактировать три файла:

commands.yaml
credentials.yaml
​hosts.yaml

  1)

root@ubuntu-noc2:~/open-nti/data# nano hosts.yaml
#test: test
192.168.5.1: lab

192.168.5.1 — IP-адрес интерфейса lo0 нашего маршрутизатора;
lab — тэг

Очень удобная раскраска по тэгам позволяет группировать устройства по классам, географическому положению, функционалу и собирать с них данные, обозначенные конкретными тэгами. Тэгов может быть несколько на одно устройство, так же, как и одинаковые тэги могут применяться к различным устройствам.

 2)

root@ubuntu-noc2:~/open-nti/data# nano credentials.yaml
lab_credentials:
 username: lab
 password: lab123
 method: password
 key_file:
 tags: lab

username=lab и tags=lab — не что иное как совпадение.

3)

root@ubuntu-noc2:~/open-nti/data# nano commands.yaml
# GENERIC COMMANDS
#NOTE: Commands will be executed & parsed as text/regex ONLY if there isn"t any valid xml output for that command
#    (so please check the output of the command with "| display xml" before building the parser or adding it in this file)
generic_commands:
 commands: |
  show isis statistics | display xml
  show chassis routing-engine | display xml
  show pfe statistics traffic | display xml
  show system processes extensive
  show system buffers
  show system statistics icmp | display xml
  show route summary | display xml
 tags: lab
lab_commands:
 commands: |
  show route summary | display xml
 tags: lab
# Commands to query vmx-docker-lwaftr Container running vMX for lightweight 4 over 6.
# Note: The space in "statisti s" is required until PR-1236994 is fixed in Junos.
lwaftr_commands:
 commands: |
  show lwaftr statisti s | display xml
  show lwaftr state | display xml
 tags: lab
# Do not remove this three dashes ("---") they are used to separate documents
​---

 После редактирования запускаем работу агента по крону:

make cron-add TAG=lab TIME=1m

Самое важное, на маршрутизаторе обязательно необходимо включить ssh и netconf:

root@JTI# show system services
ssh;
netconf {
 ssh;
}
[edit]

Т.к. в Grafana templates предустановлены, можно сразу же увидеть в графике поступающие данные:

Обратите внимание на соответствующее название дашборда.

 Для приема и обработки данных JTI каких-либо дополнительных конфигураций OpenNTI не требуется. Соответствующий плагин интегрирован в OpenNTI.
Конфигурация выполняется исключительно на стороне маршрутизатора и выглядит вот так:

 Первый блок traceoptions является отладочным, оставляем его без внимания. Блок streaming-server указывает параметры сервера, куда будут экспортироваться данные. Таких серверов может быть несколько. 50000 — порт, на котором OpenNTI слушает JTI. Блок export-profile определяет такие параметры как IP-адрес и порт, с которых данные будут отправляться на коллектор, параметры CoS для этих данных, формат данных и транспорт о которых говорилось выше, частота отправки данных, в примере 1 сек, и payload-size. О последнем несколько слов в отдельности, так как при дефолтных настройках возникла проблема с размером пакетов, которая решилась подбором данного параметра, о чем показано ниже:

16:25:09.855373 IP 192.168.5.1.21111 > 192.168.210.1.3000: UDP, bad length 3240 > 1472
16:25:31.839582 IP 192.168.5.1.21111 > 192.168.210.1.3000: UDP, bad length 3239 > 1472
16:25:53.628087 IP 192.168.5.1.21111 > 192.168.210.1.3000: UDP, bad length 3240 > 1472
16:25:55.653492 IP 192.168.5.1.21111 > 192.168.210.1.3000: UDP, length 450
16:25:55.653575 IP 192.168.5.1.21111 > 192.168.210.1.3000: UDP, length 436
16:25:55.653587 IP 192.168.5.1.21111 > 192.168.210.1.3000: UDP, length 436

Крайние три блока — настраиваемые сенсоры, в конфигурации которых указываются серверы для отправки данных, export-profile и какие ресурсы подлежат мониторингу. При необходимости, с помощью resource-filter и regexp можно фильтровать необходимые к отправке данные. Перечень ресурсов отражен ниже.

Наблюдаем данные JTI (дашборд Data Streaming Collector) в Grafana OpenNTI. Всплеск небольшого трафика — запущенный UDP-флуд с помощью iperf. 

Резюмируя, можно сказать, что OpenNTI — очень гибкое и масштабируемое решение для сбора и визуализации метрик с устройств сети, способное работать по старой и новой моделям, с возможностью применения в мультивендорных сетях.