Телеметрия в Junos для рабочих нагрузок AI/ML
Автор: Шалини Мукерджи

Введение

Поскольку трафик кластера ИИ требует сетей без потерь с высокой пропускной способностью и низкой задержкой, критическим элементом сети ИИ является сбор данных мониторинга. Junos Telemetry обеспечивает детальный мониторинг ключевых показателей производительности, включая пороговые значения и счетчики для управления перегрузками и балансировки нагрузки трафика. Сеансы gRPC поддерживают потоковую передачу данных телеметрии. gRPC — это современная высокопроизводительная среда с открытым исходным кодом, построенная на транспорте HTTP/2. Она обеспечивает собственные возможности двунаправленной потоковой передачи и включает гибкие пользовательские метаданные в заголовках запросов. Первым шагом в телеметрии является определение того, какие данные должны быть собраны. Затем мы можем анализировать эти данные в различных форматах. После того как мы соберем данные, важно представить их в формате, который легко отслеживать, принимать решения и улучшать предлагаемую услугу. В этой статье мы используем стек телеметрии, состоящий из Telegraf, InfluxDB и Grafana. Этот стек телеметрии собирает данные с помощью модели push. Традиционные модели pull требуют больших ресурсов, ручного вмешательства и могут включать информационные пробелы в собираемых ими данных. Модели push преодолевают эти ограничения, предоставляя данные асинхронно. Они обогащают данные, используя удобные для пользователя tags и имена. Как только данные будут в более читаемом формате, мы сохраняем их в базе данных и используем в интерактивной визуализации. web приложение для анализа сети. Рисунок 1 показывает нам, как этот стек разработан для эффективного сбора, хранения и визуализации данных, от сетевых устройств, отправляющих данные коллектору, до данных, отображаемых на панелях мониторинга для анализа.

TIG-стек

Мы использовали сервер Ubuntu для установки всего программного обеспечения, включая стек TIG.

Телеграф
Для сбора данных мы используем Telegraf на сервере Ubuntu, работающем под управлением 22.04.2. Версия Telegraf, работающая в этой демонстрации, — 1.28.5.
Telegraf — это серверный агент, управляемый плагином, для сбора и предоставления метрик. Он использует процессор plugins для обогащения и нормализации данных. Выход plugins используются для отправки этих данных в различные хранилища данных. В этом документе мы используем два plugins: один для датчиков openfig, а другой для собственных датчиков Juniper.
InfluxDB
Для хранения данных в базе данных временных рядов мы используем InffluxDB. Выходной плагин в Telegraf отправляет данные в InffluxDB, который сохраняет их очень эффективным образом. Мы используем V1.8, поскольку для V2 и выше CLI отсутствует.
Графана
Grafana используется для визуализации этих данных. Grafana извлекает данные из InfluxDB и позволяет пользователям создавать насыщенные и интерактивные панели мониторинга. Здесь мы используем версию 10.2.2.

Конфигурация на коммутаторе

Для реализации этого стека нам сначала нужно настроить коммутатор, как показано на рисунке 2. Мы использовали порт 50051. Здесь можно использовать любой порт. Войдите в коммутатор QFX и добавьте следующую конфигурацию.

Примечание: Эта конфигурация предназначена для лабораторий/POC, поскольку пароль передается открытым текстом. Используйте SSL, чтобы избежать этого.

Среда

Nginx
Это необходимо, если вы не можете открыть порт, на котором размещена Grafana. Следующий шаг — установить nginx на сервере Ubuntu для работы в качестве обратного прокси-агента. После установки nginx добавьте строки, показанные на рисунке 4, в файл «default» и переместите файл из /etc/nginx в /etc/nginx/sites-enabled.

Убедитесь, что брандмауэр настроен так, чтобы предоставить полный доступ к службе nginx, как показано на рисунке 5.

После установки nginx и внесения необходимых изменений мы сможем получить доступ к Grafana из web браузер, используя IP-адрес сервера Ubuntu, на котором установлено все программное обеспечение.
В Grafana есть небольшой глюк, который не позволяет сбросить пароль по умолчанию. Используйте эти шаги, если вы столкнулись с этой проблемой.
Действия, которые необходимо выполнить на сервере Ubuntu для установки пароля в Grafana:

• Перейдите в /var/lib/grafana/grafana.db
• Установить sqllite3
  или sudo apt install sqlite3
• Запустите эту команду на своем терминале
  о sqlite3 grafana.db
•  Откроется командная строка SQLite; выполните следующий запрос:
  >удалить из пользователя, где логин='admin'
• Перезапустите Grafana и введите admin в качестве имени пользователя и пароля. Он запросит новый пароль.

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

Плагин датчика Openconfig

На сервере Ubuntu отредактируйте файл /etc/telegraf/telegraf.conf, чтобы добавить все необходимые plugins и датчики. Для датчиков openconfig мы используем плагин gNMI, показанный на рисунке 6. Для демонстрационных целей добавьте имя хоста как «spine1», номер порта «50051», который используется для gRPC, имя пользователя и пароль коммутатора, а также количество секунд для повторного набора в случае сбоя.
В строфе подписки добавьте уникальное имя, «cpu» для этого конкретного датчика, путь датчика и временной интервал для захвата этих данных с коммутатора. Добавьте тот же плагин inputs.gnmi и inputs.gnmi.subscription для всех открытых датчиков конфигурации. (Рисунок 6)

Плагин собственного датчика

Это плагин интерфейса телеметрии Juniper, используемый для собственных датчиков. В том же файле telegraf.conf добавьте собственный плагин датчика inputs.jti_openconfig_telemetry, где поля почти такие же, как в openconfig. Используйте уникальный идентификатор клиента для каждого датчика; здесь мы используем «telegraf3». Уникальное имя, используемое здесь для этого датчика, — «mem» (рисунок 7).

Наконец, добавьте выходной плагин outputs.influxdb для отправки данных этого датчика в InfluxDB. Здесь база данных называется «telegraf» с именем пользователя «influx» и паролем «influxdb» (рисунок 8).

После редактирования файла telegraf.conf перезапустите службу telegraf. Теперь проверьте в CLI InfluxDB, созданы ли измерения для всех уникальных датчиков. Введите «influx», чтобы войти в CLI InfluxDB.

Как показано на рисунке 9, введите приглашение influxDB и используйте базу данных «telegraf». Все уникальные имена, присвоенные датчикам, перечислены как измерения.
Чтобы увидеть выходные данные любого измерения, просто чтобы убедиться, что файл telegraf правильный и датчик работает, используйте команду «select * from cpu limit 1», как показано на рисунке 10.

Каждый раз при внесении изменений в файл telegraf.conf обязательно останавливайте InfluxDB, перезапускайте Telegraf, а затем запускайте InfluxDB.
Войдите в Grafana через браузер и создайте панели мониторинга, убедившись, что данные собираются правильно.
Перейдите в Подключения > InfuxDB > Добавить новый источник данных.

1. Дайте имя этому источнику данных. В этой демонстрации это «test-1».
2.  В разделе HTTP используйте IP-адрес сервера Ubuntu и порт 8086.
   
3. В сведениях об InfluxDB используйте то же имя базы данных, «telegraf», и укажите имя пользователя и пароль сервера Ubuntu.
4. Нажмите Сохранить и проверить. Убедитесь, что вы видите сообщение «успешно».
   
5. После успешного добавления источника данных перейдите в Dashboards и нажмите New. Давайте создадим несколько панелей мониторинга, которые необходимы для рабочих нагрузок AI/ML в режиме редактора.

Exampфайлы сенсорных графиков

Ниже приведены бывшиеampфайлы некоторых основных счетчиков, которые необходимы для мониторинга сети AI/ML.
ПроценtagИспользование входного интерфейса et-0/0/0 на позвоночнике-1

• Выберите источник данных test-1.
• В разделе FROM выберите измерение как «интерфейс». Это уникальное имя, используемое для этого пути датчика.
• В разделе ГДЕ выберите устройство::tag, и в tag значение, выберите имя хоста коммутатора, то есть spin1.
• В разделе SELECT выберите ветвь датчика, которую вы хотите контролировать; в этом случае выберите «field(/interfaces/interface[if_name='et-0/0/0']/state/counters/if_in_1s_octets)». Теперь в том же разделе нажмите «+» и добавьте эту расчетную математику (/50000000000 * 100). Мы в основном вычисляем процентtagиспользование интерфейса 400G.
• Убедитесь, что ФОРМАТ — «временной ряд», и назовите график в разделе ПСЕВДОНИМ.

Пиковая загрузка буфера для любой очереди

• Выберите источник данных test-1.
• В разделе ОТ выберите измерение как «буфер».
• В разделе ГДЕ есть три поля для заполнения. Выберите устройство::tag, и в tag значение выберите имя хоста коммутатора (например, spine-1); И выберите /cos/interfaces/interface/@name::tag и выберите интерфейс (т.е. et- 0/0/0); И также выберите очередь, /cos/interfaces/interface/queues/queue/@queue::tag и выберите очередь номер 4.
• В разделе SELECT выберите ветвь датчика, которую вы хотите отслеживать; в данном случае выберите «field(/cos/interfaces/interface/queues/queue/PeakBufferOccupancy)».
• Убедитесь, что ФОРМАТ — «временной ряд», и назовите график в разделе ПСЕВДОНИМ.

Вы можете объединить данные для нескольких интерфейсов на одном графике, как показано на рисунке 17 для et-0/0/0, et-0/0/1, et-0/0/2 и т. д.

PFC и ECN означают производную

Для нахождения средней производной (разницы значений в пределах временного диапазона) используйте режим необработанного запроса.
Это запрос на приток, который мы использовали для нахождения средней производной между двумя значениями PFC на et-0/0/0 Spine-1 за секунду.
ВЫБРАТЬ производную(среднее(“/интерфейсы/интерфейс[if_name='et-0/0/0′]/состояние/pfc-счетчик/tx_pkts”), 1с) ИЗ “интерфейс” ГДЕ (“устройство”::tag = 'Spine-1') И $timeFilter GROUP BY time($interval)

ВЫБРАТЬ производную(среднее(“/интерфейсы/интерфейс[if_name='et-0/0/8′]/состояние/счетчики-ошибок/ecn_ce_marked_pkts”), 1с) ИЗ “интерфейс” ГДЕ (“устройство”::tag = 'Spine-1') И $timeFilter GROUP BY time($interval)

Ошибки входных ресурсов означают производную

Исходный запрос для производной среднего значения ошибок ресурсов выглядит следующим образом:
SELECT производная(среднее(“/интерфейсы/интерфейс[if_name='et-0/0/0′]/состояние/счетчики-ошибок/if_in_resource_errors”), 1с) ОТ “интерфейс” ГДЕ (“устройство”::tag = 'Spine-1') И $timeFilter GROUP BY time($interval)

Отбрасывание хвоста означает производную

Необработанный запрос для производной среднего значения отбрасывания хвоста:
SELECT derived(mean(“/cos/interfaces/interface/queues/queue/tailDropBytes”), 1s) FROM “buffer” WHERE (“device”::tag = 'Leaf-1' И «/cos/interfaces/interface/@name»::tag = 'et-0/0/0' И «/cos/interfaces/interface/queues/queue/@queue»::tag = '4') И $timeFilter ГРУППИРОВКА ПО времени ($__interval) fill(null)
 Загрузка ЦП

• Выберите источник данных test-1.
• В разделе FROM выберите измерение как «newcpu»
• В WHERE есть три поля для заполнения. Выберите устройство::tag и в tag значение выберите имя хоста коммутатора (например, spine-1). И в /components/component/properties/property/name:tagи выберите cpuutilization-total И в имени::tag выберите RE0.
• В разделе SELECT выберите ветвь датчика, которую вы хотите контролировать. В этом случае выберите «field(state/value)».

Необработанный запрос для нахождения неотрицательной производной отбрасывания хвоста для нескольких коммутаторов на нескольких интерфейсах в битах/сек.
SELECT non_negative_derivative(mean(“/cos/interfaces/interface/queues/queue/tailDropBytes”), 1s)*8 FROM “buffer” WHERE (device::tag =~ /^Spine-[1-2]$/) и («/cos/interfaces/interface/@name»::tag =~ /et-0\/0\/[0-9]/ или «/cos/interfaces/interface/@name»::tag=~/et-0\/0\/1[0-5]/) И $timeFilter ГРУППИРОВКА ПО времени($__interval),устройство::tag fill(null)

Это были некоторые из бывшихampфайлы графиков, которые можно создать для мониторинга сети AI/ML.

Краткое содержание

В этой статье описывается метод извлечения данных телеметрии и их визуализации путем создания графиков. В этой статье конкретно говорится о датчиках AI/ML, как собственных, так и с открытой конфигурацией, но настройка может использоваться для всех типов датчиков. Мы также включили решения для множества проблем, с которыми вы можете столкнуться при создании настройки. Шаги и результаты, описанные в этой статье, относятся к версиям стека TIG, упомянутым ранее. Они могут меняться в зависимости от версии программного обеспечения, датчиков и версии Junos.

Ссылки

Juniper Yang Data Model Explorer для всех вариантов датчиков
https://apps.juniper.net/ydm-explorer/
Форум Openfig для датчиков Openfig
https://www.openconfig.net/projects/models/

Штаб-квартира корпорации и продаж
Juniper Networks, Inc.
1133 инноваций
Саннивейл, Калифорния 94089 США
Телефон: 888. ДЖУНИПЕР (888.586.4737)
или +1.408.745.2000
Факс: +1.408.745.2100
www.juniper.net
Штаб-квартира в странах Азиатско-Тихоокеанского региона и Европы, Ближнего Востока и Африки
Juniper Networks International BV
Боинг Авеню 240
1119 ПЗ Схипхол-Рейк
Амстердам, Нидерланды
Телефон: +31.207.125.700
Факс: +31.207.125.701
Авторские права 2023 Juniper Networks. Inc. Все права защищены. Juniper Networks, логотип Juniper Networks, Juniper, Junos и другие товарные знаки являются зарегистрированными товарными знаками Juniper Networks. inc. и/или ее филиалов в США и других странах. Другие названия могут быть товарными знаками их соответствующих владельцев. Juniper Networks не несет ответственности за любые неточности в этом документе. Juniper Networks оставляет за собой право изменять, модифицировать, передавать или иным образом пересматривать эту публикацию без предварительного уведомления.
Отправьте отзыв по адресу: design-center-comments@juniper.net V1.0/240807/ejm5-телеметрия-junos-ai-ml

Документы/Ресурсы

Телеметрия Juniper NETWORKS в Junos для программного обеспечения рабочих нагрузок AI ML [pdf] Руководство пользователя Телеметрия в Junos для программного обеспечения для рабочих нагрузок AI ML, Junos для программного обеспечения для рабочих нагрузок AI ML, Программного обеспечения для рабочих нагрузок AI ML, Программного обеспечения для рабочих нагрузок, Программного обеспечения

Ссылки

• Руководство пользователя