Привет, я Борис Хасанов, и это заключительная часть цикла статей про сетевую телеметрию. В первой и второй частях рассказал про основы и базовые протоколы. Сегодня расскажу, как мы подошли к работе с телеметрией в облаке MWS и рассмотрю тренды развития сетевой телеметрии на ближайшее время.
Тренды развития сетевой телеметрии
Как читатель мог видеть, основные протоколы и механизмы для получения сетевой телеметрии плоскостей управления и передачи данных придуманы и воплощены несколько лет тому назад. Значит ли это, что всё уже придумано и развитие остановилось? Конечно, нет. Поэтому я хочу остановиться на новых предложениях, которые задают векторы или тренды дальнейшего развития сетевой телеметрии.
На мой взгляд, правильный маркер этих трендов — работа Инженерного совета Интернета (IETF), потому что именно там вносятся предложения, в виде черновиков стандартов, по дальнейшему развитию протоколов сетевой телеметрии. В них же содержится мотивация того, зачем это нужно, и в рабочих группах проходит обсуждение этих предложений (с позитивными или негативными комментариями, которые авторы должны учесть, чтобы достичь консенсуса). Поэтому далее я сделаю короткий обзор того, что обсуждается сейчас в части сетевой телеметрии, в IETF.
Hint: коллегам, которые не захотят пробираться через списки стандартов и их описание, рекомендую сразу переходить к части TLDR и ознакомиться с выводами.
Развитие сетевой телеметрии плоскости управления
Протокол ВМР
Наименование документа | Краткое описание |
RFC 8671 | Добавление Adj-RIB-Out в ВМР |
RFC 9069 | Добавление Local RIB в ВМР |
draft-ietf-grow-bmp-tlv | Новые TLV для BMP Route Monitoring and Peer Down Messages: дополняет TLV соотв. сообщений, дает возможность передавать характеристики NLRI и вендорскую информацию (имплементации в FRR и pmacct, Wireshark) |
draft-ietf-grow-bmp-path-marking-tlv | BMP Extension for Path Status TLV: передача статуса пути в BMP (Invalid, Best, Primary, Backup...) |
draft-ietf-grow-bmp-tlv-ebit | Поддержка Enterprise-specific TLVs in the BGP Monitoring Protocol: возможность передачи вендорской информации |
draft-ietf-grow-bmp-rel | Логирование routing events в BMP: передача event-driven информации (Policy discard, Validation Fail, Mailformed packet...) и данных |
draft-ietf-grow-bmp-yang | BMP Yang модель: конфигурация ВМР через Netconf или gNMI, телеметрия ВМР (конфиг и телеметрия телеметрии…) |
draft-ietf-grow-bmp-bgp-rib-stats | Расширение диапазонов счетчиков статистики с 32-бит до 64 |
draft-lucente-grow-bmp-offline | Периодическая рассылка сообщения Peer Summary |
draft-liu-grow-bmp-over-quic | Реализация ВМР поверх QUIC |
Обзор развития стандартизации ВМР
Развитие сетевой телеметрии плоскости передачи данных
Протокол IPFIX
Наименование документа | Краткое описание |
RFC 9487 | Export SRv6 information in IPFIX |
RFC 9160 | Export of MPLS Segment Routing Label Type Information in IPFIX |
draft-ietf-opsawg-ipfix-on-path-telemetry | Export of Delay Performance Metrics in IP Flow Information eXport (IPFIX) |
draft-spiegel-ippm-ioam-rawexport | In-situ OAM raw data export with IPFIX |
Обзор развития стандартизации IPFIX
Развитие Netconf/Yang в IETF
Наименование документа | Краткое описание |
RFC 8639 | Subscription to YANG Notifications – описывает механизмы динамических подписок клиента на стрим событий от сервера
|
RFC 8640 | Dynamic Subscription to YANG Events and Datastores over NETCONF – возможность использования клиента Netconf для запроса и получения данных из хранилища Yang-модели через динамическую подписку |
RFC 8641 | Subscription to YANG Notifications for Datastore Updates – расширение возможностей RPC (establish-subscription, modify-subscription, delete-subscription, resync-subscription), нотификации апдейтов, введение термина Yang-push подписок |
draft-ietf-netconf-https-notif | предлагается использование HTTPS-транспорта для сконфигурированных на клиенте подписок |
draft-ietf-netconf-udp-notif | предлагается использование UDP-транспорта для сконфигурированных на клиенте подписок |
draft-ietf-netconf-distributed-notif | возможность экспорта данных с нескольких процессов, н-р, на Routing Engine |
draft-ietf-netconf-yang-notifications-versioning | возможность информировать получателя об изменении версии Yang-модуля |
draft-tgraf-netconf-notif-sequencing | для корреляции данных от различных Yang-push источников добавляется sysName + connection ID |
draft-tgraf-netconf-yang-push-observation-time | измерение времени задержки между экспортом данных и их получением |
draft-ietf-nmop-yang-message-broker-integration | Архитектура по интеграции Yang-push телеметрии с брокером сообщений Kafka |
Обзор развития стандартизации Yang-push-телеметрии
Какие тенденции для развития сетевой телеметрии или TLDR
Если попытаться оценить текущие предложения по развитию ВМР, то мы увидим:
Стандартизовано добавление в ВМР статистики Adj-RIB-out и Local RIB (требуйте у вашего вендора!).
Предложено сделать все сообщения ВМР использующими TLV (полагаю, нет нужды объяснять, почему это так важно для развития протокола в целом).
Ведётся большая работа по дополнению ВМР различного рода нужной информацией (статус пути, routing events).
Прозорливые коллеги уже думают про стандартизацию ВМР поверх QUIC (хочу напомнить, что такая же работа ведётся для BGP over QUIC, уже описана его FSM — ждём имплементаций).
Имеется большое количество имплементаций (с нюансами, конечно, но разве бывает иначе).
Поэтому можно с уверенностью сказать, что ВМР продолжает активно развиваться и остаётся удобным и практичным инструментом получения телеметрии о состоянии BGP и плоскости управления в целом для мультивендорных сетей.
Телеметрия плоскости передачи данных
IPFIX
Известно, что IPFIX является единственным стандартным вендоро-независимым вариантом экспорта информации о потоках трафика с оборудования c очень широким списком поддерживаемых для экспорта информационных элементов. После добавления в этот список таких новых технологий, как SR-MPLS50, SRv6, экспорта метрик (таблица: «Обзор развития стандартизации IPFIX»), он «играет новыми красками», например, для SRv6 с его помощью мы можем понять:
Сколько пакетов, попавших в SR Policy, было доставлено или «пролито»?
По какой причине они не были доставлены?
Активный SID и информацию, каким протоколом он был распространён?
Список сегментов (SL)
Кто будет следующим SRv6-узлом и сколько ещё сегментов (SID) остаётся до узла назначения?
Какая задержка между конечными узлами?
Netconf/Yang
Пожалуй, это наиболее сложная для оценки часть эволюции сетевой телеметрии в силу большого многообразия Yang-моделей (модулей) от разных источников, деления их по различным признакам, которые я описывал в предыдущей статье, разной мотивации у разработчиков моделей и RPC из разных организаций и альянсов. Тем не менее, я попытаюсь.
Несомненным является наличие нескольких различных подходов и реализаций, развивающихся достаточно параллельно друг другу:
gRPC/gNMI c OpenConfig (и/или вендорскими) моделями
Netconf+Yang-push (IETF-модели)
Как я говорил выше, достаточно много вендоров поддерживают (в том или ином объёме) OpenConfig-модели (наряду, конечно, с собственными), и, на мой субъективный взгляд, их распространённость на текущий день выше. Однако в IETF в последнее время активно развивается второй вариант с Yang-push.
Кратко расскажу суть Yang-push: в ней возможны динамические и предварительно сконфигурированные подписки на определённые пути в Yang-хранилище. У динамических подписок есть ещё важное отличие: Yang-push-данные отправляются через другое транспортное подключение (HTTPS, UDP), т. е. такой своеобразный Control + Data Plane.
Оба типа этих подписок могут быть как периодическими, так и активироваться в случае каких-то изменений состояния. Если нотификации отправляются для динамических подписок, то будет использоваться предварительно установленная Netconf-сессия, а если для статических подписок, то может использоваться либо HTTPS-транспорт, либо UDP. Для стриминга апдейтов (извиняюсь за англицизмы) используются два типа нотификаций: push-update и push-change-update:
Кроме того, есть отдельный набор нотификаций о состоянии самой подписки:
subscription-started
subscription-modified
subscription-terminated
subscription-suspended
subscription-resumed
subscription-completed
replay-completed
Закончить часть, посвящённую развитию архитектуры Yang-push, я хотел бы кратким описанием предлагаемой целевой архитектуры интеграции сетевой телеметрии с брокером сообщений, например, Apache Kafka. Это крайне важно, т. к. нам необходимо куда-то отправлять собранные данные для хранения и последующего отображения и желательно с сохранением семантики объектов Yang. Как же видится такая интеграционная архитектура? Она приведена на схеме ниже и может показаться на первый взгляд весьма запутанной, хотя я и не являюсь автором черновика этого стандарта, но всё-таки попробую кое-что разъяснить.
Итак, на схеме мы видим несколько компонентов:
Маршрутизатор — Yang-push-publisher
Коллектор телеметрии – Yang-push-receiver
Брокер сообщений — Kafka, Rabbit MQ
Реестр для Yang-схем
Потребитель данных — клиентское приложение, подписывающееся на данные из Kafka и записывающее их в хранилище
Хранилище данных — TSDB, например
На шаге 1 — происходит обнаружение (discovery) транспортных параметров (capabilities — выбираются: протокол — HTTPS или UDP, тип кодирования — JSON/XML/ CBOR, параметры нотификаций — поддержка 'notification-envelope’ модели, параметры подписок на нотификации).
На шаге 2 — на маршрутизаторе конфигурируется Yang-push-подписка (статически — через конфигурацию или динамически* — через Netconf RPC).
На шаге 3 — посылаются нотификации об изменении состояния подписки от маршрутизатора (Yang-push-publisher) коллектору (Yang-push-receiver). Он добавляет возможность подписываться на определённую версию модуля Yang и, соответственно, добавляет в нотификации состояния подписки: имя модуля, его версию (revision) и метку (revision-label).
На шаге 4 — маршрутизатор отправляет коллектору либо Push-update-сообщение, либо Push-change-update, либо периодически (стриминг телеметрии начался, ура!) или в случае происшедших изменений. Для варианта стриминга в случае изменений черновик стандарта предлагает использовать специальный заголовок с указанием времени события, имени хоста и номера идентификационной последовательности, чтобы потребитель (консьюмер) данных мог понять, от кого они и когда.
Кроме того, не забываем про свежий черновик стандарта, позволяющий прямую публикацию Yang-push-метрик (стриминг телеметрии) непосредственно с линейных карт, параметр message-publisher-id позволяет потребителю данных понять, от какого именно процесса (источника) они. Коллеги позаботились и о ещё большей точности для поступающих данных — они предложили добавить в сообщения push-update/push-change-update т. н. обсервационный таймстамп (observation timestamp) и точку-во-времени (point-in-time).
На 5-м шаге — все Yang-зависимости должны быть определены через Yang-библиотеку, содержащую все модули Yang, хранилища данных и их схемы, а затем через Netconf RPC <get-schema> все соответствующие модули Yang должны быть запрошены с устройства.
Итак, мы добрались до 6-го шага, и пока все, на мой взгляд, было более-менее понятно и логично. Но на этом шаге начинается основная магия и, на мой личный взгляд, уровень сложности возрастает, т. к. в игру вступают компоненты, которых мы ранее не наблюдали, а именно Реестр Yang-схем (Yang Schema Registry). Как видно из названия обязательное требование к нему: поддержка Yang для определения схем. Каждая схема регистрируется в Реестре, в ответ Реестр выдает Schema ID (шаг 7), которая будет использована брокером сообщений. Авторы рекомендуют использовать для этого Confluent Schema Registry, основная задача которой — обеспечить понимание того, как «разбирать» присылаемые данные телеметрии.
На шаге 8 — сериализованные коллектором (receiver) данные вместе со Schema ID отправляются брокеру сообщений. Он анализирует заголовок схемы и пишет данные в тот или иной топик.
Для того чтобы проверить схему на корректность, на шаге 9 брокер сообщений использует ID-подписки, чтобы запросить нужную схему у потребителя данных. На шагах 10 и 11 потребитель данных запрашивает схему у Реестра и получает её. После этого данные, вместе с обсервационным таймстампом, отправляются в хранилище.
Дело с Yang-push не ограничивается только теоретизированием, в IETF за последние пару лет проведено несколько хакатонов с тестированием с конфигурированных Yang-push-подписок (в т. ч. и interoperability), изменением их состояния, получением push-нотификаций на MVP в мультивендорном варианте и с Open Source имплементациями. Последний из этой серии проводился во время последнего IETF-121. Его результаты внушают оптимизм по развитию этой технологии, растёт число имплементаций, что не может не радовать. Не могу не отметить, что коллегам предстоит ещё много работы, т. к. пока они проверили работу целевой архитектуры только на соответствие шагам 1–5.
Ниже я привожу выдержки из результатов последнего хакатона.
Результаты проверок имплементация Yang-push в IETF
Где MVP-1 — посвящён базовым требованиям реализации Yang-push, MVP-2 — масштабированию и безопасности Yang-push, MVP-3 — оптимизации.
Участники:
YANG-Push Publisher — Cisco IOS XR
YANG-Push Publisher — 6WIND VSR
YANG-Push Publisher — Huawei VRP
YANG-Push Receiver — Pmacct
YANG-Push Receiver — Netgauze 2
udp-notifdissector — Wireshark
Подводя резюме сказанному про Yang-push, приведу мнение признанного эксперта в этой области, широко известного (легендарного) в индустрии человека Benoit Claise в моём вольном переводе: «Yang-push-архитектура и её расширения — наиболее перспективные, потому что они позволяют решить задачу сохранения семантики данных после прохождения данными всей цепочки от коллектора Yang-push до места хранения данных в хранилище, например, Time Series Database — TSDB. А семантика данных крайне важна для их последующей обработки системами ML».
Наша работа с сетевой телеметрией в облаке MWS
На nexthop 2023 мой коллега Дмитрий Дементьев выступил с докладом об адаптации SRv6 в МТС. В докладе описывается наш подход к созданию сетевой инфраструктуры нового облака в MTS Web Services (MWS). Было очевидно, что нам будет необходимо получать данные о сетевом состоянии фабрики для обеспечения работоспособности сети и облачных сервисов.
Мы попытались сначала сформулировать основные требования к системе получения сетевой телеметрии:
Использование только Open Source компонентов в решении
Сбор данных с сетевого оборудования (коммутаторы фабрики в первую очередь) в квазиреальном времени, используя PUSH-модель
Телеметрия как плоскости передачи данных, так и плоскости управления
Сбор телеметрии на основе открытых Yang-моделей (Open Config/IETF)
Использование ВМР для телеметрии плоскости управления
Масштабируемость коллектора и других компонентов решения
СУБД, используемая в решении, должна отвечать требованиям также масштабируемости, быстроты записи-чтения и отказоустойчивости
Возможность динамического добавления новых устройств для сбора с них телеметрии
Гибкие возможности по созданию дашбордов
Развёртывание в K8s-кластере
Интеграция с имеющейся общей платформой observability
Было понятно, что хотя в качестве временного решения мы можем использовать традиционную poll-модель c SNMP, но в целевой архитектуре мы должны иметь именно push-модель сетевой телеметрии с подпиской на определённые данные с устройств.
Итак, в задаче построения архитектуры сбора сетевой телеметрии с самого начала нам были заданы достаточно строгие ограничения, например, интеграция с observability-платформой сразу задала жёсткие требования о том, как и в каком формате мы должны отдавать им собранные данные. Другими примерами, например, были временные и ресурсные ограничения на создание прототипа (MVP).
Суровая реальность
Первый момент, который стал менять наш подход, — это поддержка телеметрии нашим вендором коммутаторов. Выяснилось, что поддерживается только gNMI (что было в целом ожидаемо), но только в варианте со своими (вендорскими) Yang-моделями, про OpenConfig в среднесрочной перспективе можно было забыть. Это не заставило отказаться нас от сути решения, кроме того, мы смогли получить доступ к вендорским моделям и разобраться, стриминг каких данных мы сможем получить с устройства. Мы сосредоточились на базовой информации: состоянии интерфейсов (входящий и исходящий трафик, ошибки и т. д.) плюс системных данных: утилизации ЦПУ, оперативной памяти, состоянии БП. Были и другие ограничения у вендора, из-за которых пришлось корректировать архитектуру нашего решения.
Сразу стало понятно, что одним из ключевых вопросов будет выбор коллектора или клиента для сбора сетевой телеметрии. Перед нами встала дилемма: искать какой-то существующий Open Source продукт и попытаться его использовать или создавать свой «с нуля», как говорится. После анализа наших текущих возможностей и тех ограничений, про которые я сказал выше, было принято решение использовать готовый Open Source продукт.
Как выбирали компоненты
Для Open Source вариантов работы с gNMI есть два наиболее известных варианта клиентов (коллекторов или агентов):
gnmic
Telegtaf
gnmic — прост в запуске и гибок, имеет интуитивно понятный CLI, поддерживает возможность экспорта данных в разных форматах. Telegraf — в свою очередь, намного более универсальный продукт, имеющий более 300 вариантов (plugins) импорта и экспорта информации, структурированный конфиг, возможность дополнительного препроцессинга данных при помощи скриптов, агрегации данных и т. д. Кроме того, разработчики Telegraf также делают TSDB — InfluxDB и широко известную многим Grafana. По совокупности этих характеристик мы решили использовать Telegraf для MVP, а gnmic использовали в процессе отладки. Таким образом, первоначально решили использовать все три компонента в связке: Telegraf + InfluxDB + Grafana.
Естественно, у обоих вариантов есть и свои ограничения, например, Telegraf требует рестарта после изменений конфигурационного файла (например, после добавления в него нового коммутатора).
К сожалению, Telegraf на текущий момент не поддерживает ВМР. Поэтому встал вопрос об использовании дополнительного коллектора для сбора телеметрии плоскости управления. Посмотрев на имеющиеся Open Source имплементации ВМР, решили взять goBMP-коллектор на эту роль.
Платформа Observability (OBS)
Не могу в этой статье описать архитектуру нашей платформы observability, надеюсь, коллеги сделают подробный доклад по ней или напишут отдельную статью. Скажу лишь, что она создавалась для мониторинга разнообразных (инфраструктурных и других) сервисов, работающих в K8s. Сейчас более важно понять — как нам было необходимо интегрироваться с нею, поэтому я нарисовал следующую схему:
То есть практически для нас было принципиально понять, что мы должны подключаться в Kafka c определёнными IPv6-адресами и топиком (topic). В теории всё выглядело достаточно просто: Telegraf должен выступить продюсером для Кафки — и вуаля.
Прорисовка архитектуры MVP по сбору телеметрии
Итак, на первый взгляд, для сбора телеметрии всё выглядело понятно и прозрачно:
Сетевые устройства отдают по gNMI стрим данных (метрики) по состоянию системы и интерфейсов, а также состояние BGP-таблиц, коллекторы их принимают и сохраняют в СУБД, система визуализации отображеют их на дашбордах. Просто, не правда ли? И тут вспоминается стишок: «Гладко было на бумаге…»
Во-первых, приведённая выше схема была бы полностью актуальной только в случае создания нашего отдельного контура системы сбора сетевой телеметрии, нам же необходимо было интегрироваться в уже существующую платформу OBS.
Во-вторых, уже на старте выяснилось, что наш вендор коммутаторов не поддерживает протокол ВМР, соответственно, получать его с устройств мы не можем, а значит, надо искать альтернативное решение, в частности, попытаться получить ВМР с другой стороны: с агента маршрутизации на хостах (FRR).
В-третьих, надо решить задачу масштабирования и отказоустойчивости с прицелом на то, что вся эта архитектура будет развёртываться в K8s.
Поэтому на свет появился второй вариант архитектуры:
Во втором варианте мы попытались решить проблемы, озвученные выше. Отказоустойчивость решалась разбиением коллекторов на K8s-кластеры и дублированием стриминга от устройств, такой Active-Active-вариант. Также на этом этапе, для упрощения, мы решили не дублировать OBS ещё одним контуром визуализации и не стали устанавливать свои InfluxDB+Grafana в качестве параллельного контура, поэтому они не нарисованы на схеме. Именно с таким вариантом мы пошли на реализацию прототипа.
С какими проблемами столкнулись
gNMI-телеметрия (плоскость передачи данных)
Как уже писал выше, нам удалось разобраться с приватными вендорскими Yang-моделями. Далее нам встретились еще несколько неожиданных ограничений:
невозможность получения данных с элемента более низкого уровня без возможности предварительно подписаться на элемент более верхнего уровня (например, стрим телеметрии path ="/interfaces/interface[name=e0]/state/counters/in-octets" не отправлялся без предварительной подписки на path ="/interfaces/interface[name=e0]/state/counters")
ограничения на количество gNMI-подписок на коммутаторе в моменте
используемые таймстампы не распознавались корректно в Telegraf
Пришлось искать «обходные пути» (workarounds), чтобы как-то запустить это. Но про это дальше.
[[inputs.gnmi]]
addresses = ["192.168.1.1:11111"]
username = "user"
password = "password"
encoding = "json_ietf"
redial = "10s"
max_msg_size = "10MB"
[[inputs.gnmi.subscription]]
name = "in-octets_e0"
origin = "XXXX"
path = "/interfaces/interface[name=e0]/state/counters/in-octets"
subscription_mode = "sample"
sample_interval = "10s"Пример конфигурации gNMI-телеметрии для Telegraf
ВМР — телеметрия плоскости управления
Выше я уже говорил, что ВМР не поддерживается вендором наших коммутаторов на текущий момент. Именно поэтому мы решили получать информацию о состоянии таблиц BGP с агента маршрутизации на хосте — FRR. Для минимизации количества ВМР-сессий мы решили собирать ВМР со Route Servers, имеющих пиринг со всеми FRR на хостах.
router bgp 4207710099
bgp router-id 192.168.11.11
[SNIP]
bmp targets test-BMP
bmp connect 192.168.1.101 port 5050 min-retry 30000 max-retry 3000 source-interface eth2
exit
exitПример конфигурации BMP для FRR 10.0
Кроме того, для проведения теста goBMP мы также подали на него стриминг ВМР-телеметрии с маршрутизатора одного известного вендора, поддерживающего ВМР в достаточно широком объёме.
И тут goBMP показал себя не с лучшей стороны, он стал работать нестабильно, и пошли следующие сообщения об ошибках:
W0607 18:17:23.730701 10632 bmpstats.go:61] unprocessed stats type:0
W0607 18:17:23.731595 10632 bmpstats.go:61] unprocessed stats type:14
W0607 18:17:23.731858 10632 bmpstats.go:61] unprocessed stats type:15
W0607 18:17:23.731865 10632 bmpstats.go:61] unprocessed stats type:16
W0607 18:17:23.732117 10632 bmpstats.go:61] unprocessed stats type:17Ошибки, выдаваемые goBMP по неподдерживаемым статистическим отчётам
Как ясно из описания ошибок, речь идёт о том, что goBMP не поддерживает некоторые типы статистических отчётов.
В MVP мы минимально хотели видеть хотя бы статистические отчёты за номерами 7 и 8 (# routes in Adj-RIB-In, #routes in Loc-RIB) и индикации падения/поднятия сессий.
Однако выяснилось, что FRR на текущий момент (10.0) не поддерживает выдачу таких Peer Up / Peer Down нотификаций. Надеемся, что они появятся в каком-то из следующих релизов. Поэтому мониторинг маршрутной информации в FRR пришлось пока решать альтернативным способом.
Интеграция с OBS (Kafka)
Видимо, для того чтобы нам жизнь не казалась мёдом, выяснилось, что в силу специфики настройки Kafka в нашей платформе OBS ей нужен на входе формат данных OTLP, а этот формат, в свою очередь, не поддерживается в текущей версии Telegraf и, соответственно, первоначальный вариант с Telegraf в роли Kafka producer не заработал. Казалось, что всё пропало: «Гипс снимают, клиент уезжает…»
Как мы решали проблемы
gNMI-телеметрия — плоскость передачи данных
Проблему некорректных таймпстампов в gNMI мы с помощью вендора победили путём их модификации процессинговым скриптом Startlark (некий диалект Python). Проблему невозможности подписаться на данные нижнего уровня без подписки на данные верхнего быстро пофиксить не удалось, пришлось добавлять эти высокоуровневые подписки в конфигурацию Telegraf. Также ограничение на количество gNMI-подписок вендор пообещал устранить в ближайшем релизе софта. Нам сильно помогло плотное взаимодействие с вендором, его помощь и готовность оперативно решать выявленные проблемы.
ВМР — телеметрия плоскости управления
Проблему нестабильной работы goBMP в случае получения неподдерживаемых типов статистических отчётов мы преодолели, сделав собственный fork goBMP с некоторыми модификациями кода.
А для того чтобы всё-таки получать информацию о состоянии BGP-сессий со свитчей в фабрике (не поддерживающих ВМР), мы также нашли альтернативный вариант: посылаем Netconf-запрос на считывание BGP-сессий на свитче Python-скриптом, парсим его и далее отправляем в OBS для генерации соответствующих алертов:
NetMonBot, [03.12.2024 01:10]
BGP_OPR_NEIGH_STATE_CHANGE
xxx-xxx01 BGP[3487]: 2024 Dec 03 00:06:43 : xxx-xxx01 : BGP : CRITI : [BGP_OPR_NEIGH_STATE_DOWN_2]: Neighbour [XXXX:XXXX:XX:9::6] Session down due to config deletion
NetMonBot, [03.12.2024 01:15]
BGP_OPR_NEIGH_STATE_CHANGE
xxx-xxx01 BGP[3487]: 2024 Dec 03 00:06:39 : xxx-xxx01 : BGP : NOTIF : [BGP_OPR_NEIGH_STATE_CHANGE_4]: Neighbour [XXXX:XXXX:XX:9::7] Status change established -> idle
BGP_OPR_NEIGH_STATE_CHANGE
xxx-xxx01 BGP[3480]: 2024 Dec 03 00:06:59 : xxx-xxx01 : BGP : NOTIF : [BGP_OPR_NEIGH_STATE_CHANGE_4]: Neighbour [XXXX:XXXX:XX:9::7] Status change down -> upПримеры алертов о состоянии BGP-сессий
В результате даже в отсутствие поддержки в FRR BMP Peer Up / Down Notifications мы организовали им соответствующую замену и даже более того — мы нашли вариант экспорта BGP-метрик с FRR без использования BMP как альтернативный вариант.
Интеграция с OBS (Kafka)
Мы не смирились с ситуацией неработоспособности, в нашем варианте, связки Telegraf — Kafka и, углубившись в чтение документации, выяснили, что Telegraf имеет outputs.plugin, умеющий отдавать метрики в формате Prometheus, а уже этот формат мы можем перекодировать в OTLP при помощи OpenTelemetry Collector (OTC). Хотя мы теперь приобрели новую сущность в нашей архитектуре в лице ОТС, но тем не менее нашли вариант решения нашей задачи, и архитектура MVP стала выглядеть так:
Это решение было подсказано коллегами из OBS, без их всесторонней помощи и содействия оперативный запуск и проверка MVP сетевой телеметрии не был бы возможен, за это им огромное спасибо!
Для небольшой справки, Telegraf также используется как коллектор телеметрии с определённых сетевых функций, работающих на хостах. Ну и самое главное, что мы добились попадания собранных метрик в платформу OBS и работоспособности MVP cетевой телеметрии в целом.
Развёртывание в K8s
Тут пришлось повозиться и прибегнуть к помощи опытных коллег из инфраструктурной команды, много работающих с K8s, и хотя тот же Telegraf имеет свой базовый helm chart, но пришлось его адаптировать к нашим реалиям, а промежуточные тесты и проверки решать через Config Map.
Целевая архитектура нашей сетевой телеметрии и планы
На схеме выше я показал общее высокоуровневое видение того, как мы на текущий момент видим развитие РМ в сети и применение сетевой телеметрии. Использование TWAMP-Light и Alternate marking требует дополнительных исследований и проработок. Вполне вероятно, что в итоге останется какой-то один из них. Также планируем протестировать другие варианты коллекторов ВМР. Еще ожидаем фиксации вендором имеющихся ограничений на gNMI, чтобы развернуть его уже at scale. Поэтому в текущем рассказе рано ставить точку.
На этом всё, спасибо читателям, которые прочли статью до конца.
