Эта статья о проблемах, с которыми сталкивается инженер при попытке объединить зоопарк старого оборудования с современным подходом к его мониторингу. Современный мониторинг строится вокруг динамических сущностей: микросервисы, контейнеры, оркестрация в Kubernetes, сбор метрик через Prometheus и визуализация в Grafana. В этой парадигме всё динамично меняется и обычно разговаривает на языке /metrics и OpenTelemetry. Для инженера это привычная и удобная экосистема, где работают автообнаружение и pull-модель которые позволяют забыть о ручном конфигурировании целей сбора.
Однако реальная инфраструктура довольно часто включает в себя физические сервера, сетевое оборудование, системы бесперебойного питания, коммутаторы, маршрутизаторы и прочие железки. Все они живут по своим законам и общается исключительно на протоколах, разработанных в 80-90-х годах: SNMP и IPMI. Поддержка отдельного тяжелого стека мониторинга вроде Zabbix или Centreon только ради контроля пары десятков свитчей противоречит идеологии унификации инструментов и вызывает дополнительную нагрузку на инженеров.
Возникает задача: вписать железное оборудование в современную экосистему мониторинга.
SNMP и IPMI: краткий обзор для работающих с /metrics
Прежде чем говорить об интеграции, полезно вспомнить особенности этих протоколов.
SNMP (Simple Network Management Protocol) - универсальный язык сетевого оборудования. Любое устройство - от управляемого коммутатора до IP-камеры - поддерживает SNMP. Информация организована в виде древовидной структуры, а конкретные параметры, такие как температура устройства, загрузка порта, количество ошибок на интерфейсе идентифицируются числовыми последовательностями и выглядят как .1.3.6.1.2.1.2.2.1.10 - это счетчик входящих октетов на сетевом интерфейсе. Протокол предполагает два основных режима работы:
-
SNMP Polling - система периодически отправляет запросы на устройство и получает значения запрошенных OID. Это основной способ сбора метрик. Главная проблема SNMP - это трансляция. Просто взять OID и засунуть его в Prometheus не получится. Нужно:
Понимать, что за типом данных (счетчик, gauge, строка).
Уметь ходить в дерево SNMP, чтобы динамически находить все интерфейсы или диски.
Добавлять лейблы, к примеру имена интерфейсов, которые мы можем найти в соседних OIDах.
SNMP Traps - устройство самостоятельно отправляет асинхронные уведомления о важных событиях, например, обрыв линка или превышение порога температуры, как правило, отправляются по UDP и требуют наличия на стороне мониторинга приемника.
IPMI (Intelligent Platform Management Interface) - стандарт для управления аппаратным обеспечением серверов, предоставляет доступ к физическим сенсорам: температура CPU и памяти, обороты вентиляторов, напряжение питания, состояние дисковой подсистемы. Доступ осуществляется по отдельному сетевому интерфейсу.
Почему Zabbix не всегда ответ
Зачем что-то делать, если для SNMP и IPMI есть Zabbix? Он имеет много готовых шаблонов, он ловит трапы и умеет считать триггеры. Для чисто «железного» мониторинга это действительно хороший инструмент. Но как только твоя инфраструктура перестает быть просто набором серверов в стойке и начинает обрастать облаками, Kubernetes и прочими динамическими сущностями, Zabbix начинает ощущаться чужеродным организмом.
Поддерживать два разных стека мониторинга это не просто двойная работа - это двойная головная боль. Нужно держать в голове две разные логики алертинга, два способа управления конфигурацией, два разных источника данных для дашбордов. Команда разработчиков, привыкшая смотреть на свои поды в Grafana, вынуждена переключаться на другой интерфейс, чтобы узнать, не перегрелся ли сетевой порт, который этот трафик передает. Zabbix сложно масштабировать и интегрировать в современные процессы. Его конфигурация - это, по сути, база данных и веб-интерфейс и весь современный iac подход с декларативным описанием конфигураций в Git-репозитории работает с ним только через дополнительные прослойки. Автообнаружение в Zabbix работает, но оно заточено под свою, замкнутую экосистему. Проще построить единую систему, где и метрики приложений, и метрики железа стекаются в одну и ту же базу данных, а алерты идут через один менеджер оповещений.
SNMP-Exporter и IPMI-Exporter на практике
В мире Prometheus есть два основных инструмента: snmp_exporter и ipmi_exporter. Prometheus посылает запрос к метрикам через экспортёр, а он уже ходит на целевое устройство по SNMP или IPMI, парсит ответ и отдает метрики в понятном для Prometheus виде.
Настройка snmp_exporter
Сам snmp_exporter без конфига - совершенно бесполезен, ему нужно объяснить, какие данные получать и как их интерпретировать. Конфиг для него не пишут руками - его генерируют из MIB-файлов специальной утилитой - generator. В репозитории snmp_exporter уже есть готовый snmp.yml, собранный из самых популярных MIB Cisco, APC, HP и т.д. Если ваше оборудование достаточно типовое, можно просто скачать этот файл и пользоваться - скорее всего, нужные модули там уже есть.
Если вам нужно мониторить что-то экзотическое и импортозамещённое - придётся запустить генератор самому. Процесс простой: generator берёт набор MIB-файлов и инструкцию в формате YAML generator.yml, где описано, какие модули нас интересуют. На выходе получается готовый snmp.yml для экспортёра. Достаточно положить свои .mib файлы в папку с MIB и указать их в generator.yml.
Пример части конфига для простого мониторинга загрузки интерфейсов на коммутаторе:
Запускаем экспортер с конфигурацией, и указываем цель для Prometheus.
При обращении за метриками к экспортеру, необходимо передать параметр target с адресом железки и module , например, ifs. Настройки Prometheus для сбора данных с экспортёра:
Экспортер сам сходит на target, получит данные и выдаст метрики вроде:
Настройка ipmi_exporter
Тут история проще. В конфигурационном файле ipmi_remote.yml мы просто описываем модули сбора - какие сенсоры нас интересуют. Для большинства случаев хватает дефолта:
Prometheus в конфиге таргетов просто шлет запросы на ipmi_exporter: http://ipmi-exporter:9290/ipmi?target=10.0.0.10. Экспортер идёт на 10.0.0.10 (BMC сервера), используя заданные в переменных окружения или файле секреты и отдает метрики температуры, напряжения и оборотов вентиляторов.
С чем придётся работать
SNMP-запросы к железу могут быть медленными, особенно если устройство старое или нагруженное. Экспортеру нужно уложиться в период опроса: сходить на устройство, обойти все OIDы, дождаться ответов. Если у вас коммутатор с большим количеством портов, это легко вылетает за таймаут. Исправить можно увеличением scrape_timeout в конфиге Prometheus и уменьшением walk_timeout в экспортере, но тут нужно искать баланс, чтобы мониторинг не тормозил сбор всей остальной инфраструктуры.
2.Написание правил может потребовать некоторой экспертизы, так как статусы портов или сенсоров часто приходят не как число,а как всякие 1.3.6.1.4.1.318.1.1.1.2.2.3.0 - это enum, где 1 может означать normal, 2 - warning, 3 - critical. Приходится писать выражения, которые транслируют эти цифры в понятные состояния.
3.Когда у вас действительно много оборудования, поддерживать в snmp.yml модуль для каждого - ад. Обычно на помощь приходит Ansible, один эталонный snmp.yml, который генерируется из MIB-ок, и он просто копируется на все инстансы snmp_exporter. А discovery целей для Prometheus делается через file_sd_configs, где Ansible периодически генерирует список JSON-файлов со всеми целями и указанием, какой модуль SNMP или параметр target IPMI для каждой использовать. Это превращает ручное конфигурирование в нормальный CI/CD процесс.
Обработка SNMP Traps
До сих пор мы говорили про метрики: экспортёры обращаются к железу, получают данные, и Prometheus сохраняет их, это покрывает большую часть потребностей. Оборудование, когда с ним случается беда, само может инициировать отправку сообщения - SNMP Trap, это быстрее и может сильно ускорить разбор инцидентов. По своей природе это очень похоже на логи и обращаться с ними нужно аналогично.
Как организовать приём трапов
Для получения данных ставим snmptrapd - стандартный демон-приёмник из пакета net-snmp, он слушает UDP-порт 162 и принимает входящие сообщения. Изначально трап приходит в виде набора OID-значений, если у вас нет загруженных MIB-баз на стороне приёмника, вы увидите что-то вроде:
Глазами такое читать невозможно, чтобы превратить это в структурированное сообщение, нужно загрузить MIB файлы в snmptrapd для трансляции OIDов в символьные имена. Мы получаем набор сообщений в файле, который мы читаем инструментами для сбора логов, такими как Loki, Promtail и Fluent Bit. Пример конфигурации для vector:
В результате каждое событие становится красивой записью с лейблами.
А что с безопасностью?
Теперь остаётся один вопрос - аутентификация. SNMP и IPMI были придуманы во времена, когда сети были маленькими и доверенными. SNMPv2 использует community string - это по сути пароль, который передаётся в открытом виде и даже в SNMPv3 с шифрованием всё равно нужны ключи. IPMI тоже требует логин и пароль для доступа к BMC.
Если snmp_exporter и ipmi_exporter живут в Kubernetes как часть вашего мониторингового стека, логично хранить креды в секретах. Для ipmi_exporter, например, можно создать Secret с файлом ipmi_passwords.yml, который монтируется в под. Для snmp_exporter community strings обычно задаются в параметрах таргета - например, через лейблы в file_sd_configs. В этом случае сами файлы с таргетами генерируются так, чтобы содержать поле community. Сами данные для авторизации будут храниться в файле:
Если ваша инфраструктура описывается Ansible, вы можете хранить зашифрованные пароли в ansible-vault, а при прогоне плейбука генерировать конфиги экспортёров, подставляя уже расшифрованные значения. Это красиво с точки зрения GitOps: всё в репозитории, секреты зашифрованы. Однако на целевых хостах конфиги окажутся лежать в открытом виде.
Заключение: Стратегия гибридного мониторинга
Несмотря на кажущуюся архаичность SNMP и IPMI, задача их интеграции в современный стек мониторинга давно перестала быть сложной. Сложности, которые пугают новичков - MIB файлы и зоопарк из конфигов легко автоматизируется. Интеграция старых протоколов это не костыль и не временная мера - это полноценная инженерная задача по построению надежного конвейера из прошлого в настоящее. В результате вместо двух разных стеков и двух дежурных инженеров вы получаете единую систему, где на одном дашборде соседствуют графики из разных источников.
Автор: Андрей Никифоров, инжинер Департамента разработки средств мониторинга в "Группе Астра"