Как я читал показания датчиков через SNMP (Python+AgentX+systemd+Raspberry Pi) и соорудил ещё одну мониторилку

    Всем привет.

    image

    Лирическое отступление
    Статья лежит в черновиках уже пару недель, потому как не было времени таки допилить описываемый объект. Но под натиском товарищей, которые своими статьями уже покрыли половину того, что я сказать хотел, решил последовать принципу «release fast, release early, release crap» и опубликовать то, что есть. Тем более, что разработка на 80% закончена.

    С момента публикации статьи про «В меру Универсальное Устройство Управления» прошло немало времени (а если быть точным, больше года). Немало, но недостаточно много, чтобы я таки написал нормальную программную начинку для этого устройства. Ведь не для красоты ж оно есть — оно должно собирать данные с датчиков и делать так, чтобы эти данные оказывались в системе мониторинга (в моём случае Zabbix)

    Часть первая — software


    За прошедшее время из программной начинки было реализовано следующее:

    • Тестовый скрипт для демонстрации, что всё подключенное работает
    • Скрипт для заббикса, чтобы собирать показания с термодатчиков

    Были попытки написать отдельные мониторилки для ntpd и для gpsd. Много времени было потрачено на супер-мониторилку, которая должна была уметь читать конфиг, запускать процессы сбора данных из различных источников согласно конфигу, собирать данные из этих процессов и выводить на экранчик показания, одновременно давая возможность заббиксу читать эти данные. По факту получилось реализовать диспетчер процессов, который читал конфиг и плодил нужные процессы, и рисовалку на экране, которая получилась весьма крутой — даже умеет читать layout из конфига и менять содержимое экрана по таймеру, при этом собирая данные от процессов в тот момент, когда они нужны. Нет в этой супер-мониторилке только одного — собственно процессов, которые бы собирали данные. Ну и плюс были идеи сделать систему сигналов, чтобы функции кнопкам назначать, учитывать приоритеты разных источников данных, ну и так далее, но всё упёрлось в свободное время и в то, что эта супер-мониторилка получалась уж очень раздутой и монструозной.

    На какое-то время я забил на разработку полноценной программной начинки. Ненуачо, скрипт же работает, а правило «работает — не трожь», как говорят, святое правило администратора. Но вот ведь незадача — чем больше хочется мониторить, тем больше надо скриптов писать и тем больше надо добавлять исключений в SELinux для заббикса (я ж не только raspi мониторю) — в дефолтной политике заббиксу (как и rsyslog, например) запрещено вызывать произвольные программы, и это понятно. Отключать SELinux для заббикса совсем или писать свою политику под каждый бинарник, который будет дёргаться, очень не хотелось. Поэтому пришлось думать.

    А давайте вообще разберёмся, как можно собирать данные в систему мониторинга:

    • По тому, кто инициатор:

      • Активный мониторинг — наблюдаемый узел инициирует передачу данных (push)
      • Пассивный мониторинг — наблюдающий узел инициирует передачу данных (pull)

    • По методу сбора данных:

      • Через агента на наблюдаемом узле, используя только поддерживаемые агентом метрики
      • Через агента на наблюдаемом узле, расширяя агент скриптами
      • По SNMP
      • Примитивный ping
      • По telnet
      • … и так далее

    Я использую pull-мониторинг, не по религиозным причинам, а просто так сложилось. На самом деле разницы между push и pull немного, особенно на малых нагрузках (на одной из предыдущих работ делал Nagios+NSCA, большой разницы не заметил, элементы всё равно руками создавать). Можно было бы использовать zabbix_sender, если бы у меня уже был push-мониторинг, но его нет, а на нет и суда нет, а мешать одно с другим как-то неаккуратненько. А вот в вопросе, по какому протоколу мониторить, вроде бы выбор большой, да не очень — discovery поддерживается только через агента или через SNMP, что оставляет нас уже только с двумя вариантами. Агент отпадает из-за описанной проблемы с SELinux. Вуаля, у нас остаётся pull-мониторинг через SNMP.

    Урраа! А чего ура-то? В линуксе вроде как есть snmpd, но как заставить его отдавать то, что нам нужно, но о чём snmpd не имеет ни малейшего понятия? Оказывается, у snmpd есть целых 3 (принципиально различных) способа отдавать произвольные данные по произвольным OIDам:

    • Запустить внешний скрипт (директивы exec/sh/execfix/extend/extendfix/pass/pass_persist) — плохо из-за потенциальных проблем с SELinux и из-за того, что неконтролируемая куча скриптов в конечном итоге превратится в свалку. Да и говорят, у pass_persist всё плохо с передачей бинарных данных. Не знаю, может, бессовестно врут, но мне идея плодить миллион скриптов в любом случае не нравилась;

    • Написать что-то на встроенном perl или загрузить .so — не знаю и не хочу знать перл, не хочу писать so-шки, я ж не программист, чтобы на С писать;

    • Получить данные у внешнего агента (proxy, SMUX, AgentX) — а вот это звучит хорошо, loose coupling же, от языка не зависит. Давайте разбираться:

      • proxy — запросить OID у SNMP-агента на указанном узле. Надо реализовывать целиком протокол SNMP, что мне совершенно ни к чему, да и зачем запрашивать что-то у другого узла, задействовать сеть, когда я хочу данные локально получить. Я знаю про существование 127.0.0.1, но в любом случае, реализовывать SNMP не улыбается совершенно;

      • SMUX — нужна поддержка протокола smux в вызывающем агенте в том числе, а man говорит, что по умолчанию net-snmp собирается без поддержки smux (и так уже ntpd пересобирать для поддержки pps, ещё и пересобирать net-snmp на raspi не улыбается). Да и smux этот — всего лишь обёртка для пакетов SNMP, просто добавлена возможность для субагента зарегистрироваться на агенте;

      • AgentX — по сути то же, что и SMUX, только протокол проще, а пакет легче. Ну и вкомпилен по умолчанию в net-snmp, что тоже приятно. Звучит как наш выбор.

    Я пишу на питоне, поэтому пошёл искать, а не реализовал ли кто уже протокол agentx. И ведь нашлись такие хорошие люди — https://github.com/rayed/pyagentx и https://github.com/pief/python-netsnmpagent. Второй проект вроде поживее, но первый показался проще. Я начал с первого (pyagentx), он работает и делает всё, что надо. Но вот когда я стал думать, а как в эту библиотеку передавать данные, захотелось таки разобраться со вторым пакетом (python-netsnmpagent). Проблема с pyagentx заключается в том, что так, как оно написано, оно не может получать данные от вызывающих функций, а следовательно, запрос свежих данных должен происходить прямо в функции, которая посылает обновления в snmpd, что не всегда удобно и не всегда возможно. Можно было, конечно, отпочковать что-то своё и переопределить функции, но по сути пришлось бы переписать класс почти целиком, чего делать также не хотелось — на коленке ж разрабатываем, всё должно быть просто и быстро. Однако нежелание разбираться с python-netsnmpagent таки победило и я нашёл способ передать данные в updater из pyagentx, но об этом ниже.

    Следующий вопрос был такой — а как должна выглядеть архитетура? Попытка написать диспетчер, форкающий источники данных и читающий данные из них, уже была и закончилась не очень хорошо (см. выше), так что было решено отказаться от реализации диспетчера. И так удачно сложилось, что то ли я где-то увидел статью про systemd, то ли просто в очередной раз пощекотало давнее желание разобраться с ним поближе, и я решил, что диспетчером в моём случае будет systemd. Haters gonna hate, а мы будем разбираться, коли оно уже даже на raspi из коробки есть.

    Какие полезные возможности systemd для себя я обнаружил:

    • Бесплатная демонизация — пишем юнит службы с типом simple (или notify) и получаем демона, не написав ни строчки кода для этого. Прощайте python-daemon и/или daemonize
    • Автоматический перезапуск упавших юнитов — ну тут комментарии излишни, спасает от непостоянных ошибок
    • Сокет-активация и вообще управление сокетами — очень приятно, когда некто, кто хочет записать в сокет, может это сделать, даже если тот, кто будет читать из сокета, ещё не готов это сделать. Более того, читателя можно активировать по факту записи в сокет, что может сэкономить сколько-то оперативной памяти (впрочем, не то, чтобы её не хватало...)
    • Template-юниты — если у меня много одинаковых датчиков, можно наплодить много процессов из одного юнита, передать всем разные параметры и радоваться
    • (обнаружено слишком поздно, пока не реализовано) юниты-таймеры — позволяют периодически запускать некий юнит. Почему не cron — потому что у cron минимальный период 1 минута, а я хочу чаще опрашивать датчики. Почему не sleep() — потому что активное ожидание и потому что период начинает дрейфовать — да, датчик мы дёргаем каждые N секунд, но с учётом чтения и обработки данных период обновления данных будет не N секунд, а N+x, то есть при каждом чтении период обновления данных будет съезжать на x

    С учётом этих находок в голове нарисовалась архитектура:

    • systemd открывает сокет для связи между процессами-датчиками и процессом-коллектором, все процессы-датчики пишут в один и тот же сокет
    • systemd запускает юниты для процессов-датчиков
    • процесс-датчик читает данные с датчика, пишет их в сокет и засыпает (systemd timer unit я на тот момент ещё не нашёл)
    • как только данные с какого-то датчика записаны в сокет, systemd запускает процесс-коллектор, который принимает обновление от датчика, волшебным образом его обрабатывает и сохраняет во внутреннем состоянии. Процесс-коллектор не умирает
    • процесс-коллектор порождает отдельный поток (именно поток, не процесс, чтобы избежать IPC между процессами, которое в питоне для данной задачи несколько печальное, ниже напишу, почему я так думаю), в котором происходит передача внутреннего состояния в snmpd по протоколу agentx

    Одно очень нехорошее место — это разделяемое внутреннее состояние между потоком-коллектором и потоком-agentx. Но я себе это простил, потому что в питоне есть волшебный GIL, который решает вопрос синхронизации между двумя потоками. Хотя это, конечно, очень плохо и не по книге. Была мысль вынести разделяемое состояние в отдельный процесс и заставить процесс-agentx и процесс-коллектор работать с процессом-состоянием через сокет, но заломало меня делать ещё один сокет, писать ещё один юнит и так далее.

    Почему мне не понравилось IPC в питоне применительно к данной задаче:

    • Queue работает нормально, но эти очереди неименованные, инстанс Queue надо передавать в форкаемый процесс. В моём случае это означает полностью переписать pyagentx
    • Manager, возможно, решил бы мою проблему, но опять же, это означает полностью переписать pyagentx
    • posix/sysv ipc великолепно, там есть именованные очереди, но эти очереди ограничены в размере, на некоторых системах — совершенно убого ограничены (пишут [листать до «Usage tips»], что на macos, например, не больше 2КБ на очередь и даже настроить нельзя). Не то, чтобы мне надо было запускаться на куче разных систем с разной степени убогости реализацией sysv ipc, но заниматься тюнингом тоже не хотелось. Хочу, чтобы сразу и хорошо
    • снова posix/sysv ipc — очереди блокирующие, то есть какой-то минимальный таймаут должен быть, прежде чем чтение из очереди вернёт «пусто». В случае с pyagentx блокировка на чтении из очереди в update() очень нежелательна, да и вообще убого это
    • и снова posix/sysv ipc — проблема с именованием очередей. Несмотря на то, что очереди сообщений именованные, именованные они не именем, а ключом. Так как ключ не является иерархическим или семантически очевидным, легко выбрать неуникальный ключ. В реализации posix/sysv ipc для питона есть возможность сгенерировать ключ очереди автоматически, но вот незадача — если бы я мог что-то передать в pyagentx, я бы передал туда Queue и не мучился. Можно генерировать ключ с помощью ftok, но пишут [листать до «Usage tips»], что ftok даёт не больше уверенности в уникальности ключа, чем int random() {return 4;}
    • (больше ничего на ум не пришло, что не вовлекало бы внешний брокер очередей, а задача не такая уж, чтобы ещё и брокер очередей держать — лишний сервис, лишняя головная боль)

    dbus выглядел решением всех бед, да и есть он везде, где есть systemd, но вот беда — pydbus требует GLib >=2.46, чтобы публиковать API, а в raspbian только 2.42. dbus-python объявлен устаревшим и неподдерживаемым. Короче, пока петух жареный в попу не клюнет, буду разделять состояние небезопасным образом.

    При использовании SNMP в своих грязных целях есть ещё одна загвоздка — а как выбрать OIDы для своих наборов данных? Для этого есть специальная ветка в private, которая называется enterprises — .1.3.6.1.4.1.<enterprise_id>. Получить уникальный enterprise ID можно у IANA. Когда схема OIDов определена, неплохо было бы написать MIB, чтобы самому не забыть, где что, ну и чтобы системам мониторинга было легче. Введение в написание MIBов есть тут.

    В какой-то момент я обнаружил ntpsnmpd с соответствующим MIBом и возрадовался было до плеши, но когда скомпилил это чудо, обнаружил, что автор удосужился только реализовать несколько констант верхнего уровня и на этом выдохся. Я немного поковырялся в коде и так до конца и не понял, каким же хитрым образом автор взаимодействовал с ntpd (или ntpq), чтобы вытащить те константы, не парся вывод. Одно я понял точно — готового python API нет, а значит, ловить нечего, придётся этот MIB самому реализовывать.

    Пятиминутка ненависти
    Нет, ну вот правда, неужели за все эти годы никто так и не написал аналогов ntpd, smartctl, lm_sensors и прочих утилит без API? Никто не прикрутил к ним snmp-агентов? Таких аналогов, чтобы не надо было парсить текстовый вывод? Нет, я понимаю, юниксвей и всё такое, но это не тот случай. Ладно бы её была возможность вывести данные в машиночитаемом формате, но нет, всё только для людей. Причём судя по плачам в интернете (русском и забугорном), я не один такой несчастный. Ну, допустим, lm_sensors можно простить, потому что те же данные можно в машиночитаемом формате вычитать из sysfs, но остальные-то?

    В общем и целом, вся эта конструкция работает и является весьма живучей. Discovery в заббиксе работает, итемы создаются, графики рисуются, триггеры шлют алёрты — чего ещё для счастья надо? Код ещё не финализирован, так что не публикую.

    Часть вторая — hardware


    Не везде можно вкрячить юнитовый корпус, но и вешать сопли по стенам тоже не хочется. Есть очень изящное решение — DIN-рейка. Кучи конструктивов с рейкой продаются на рынке, в которые можно и блок питания реечный поставить (я использую MeanWell DR-15-5), и всякие автоматы-узо-что_угодно. Соответственно, захотелось корпус на DIN-рейку для raspi. В качестве кандидатов рассматривались вот эти два товарища — модель от Italtronic и RasPiBox. Преимущество RasPiBox в том, что там уже есть плата для прототипирования и ввод питания осуществляется через винтовые контакты (через стабилизатор на GPIO), что удобно, но может быть небезопасно. Но стоит он больше, чем в 3 раза дороже, занимает больше места на рейке и не имеет прозрачного окошка. Модель от Italtronic также не идеальна — ширина её такова, что все готовые LCD-экраны 16х2 туда не влазят по ширине, то есть ценность прозрачного окошка резко падает, но за низкую цену я был готов этот недостаток простить.

    Корпус оказался достаточно удобен, имеет места под крепления (а точнее, под установку) двух печатных плат или листа чего угодно. Я подложки делаю из акрила, завёрнутого в токонепроводящую ESD-защитную плёнку, пилю дремелем:



    Платы внутри держатся только на силе трения и на небольших уступах с двух сторон, то есть никакого жёсткого крепления внутри не предусмотрено. Несмотря на кажущуюся величину, корпус маленький и места над самой raspi остаётся не так уж много, особенно если вставлять плату на нижний уровень. А плата мне нужна, так как нужно разместить несколько светодиодов и плату с RTC.

    Фотографии корпуса







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



    Оказалось, что мои экземпляры ds18b20 вполне себе не врут. А вот следующий датчик как раз-таки врёт, причём аж на 0,6 градуса. Впрочем, опять же, зависит от экземпляра — один врал, другой почти не врал.

    С влажностью оказалось всё не так просто. Дешёвое или не работает с raspi совсем (потому что аналоговое), или нет библиотек (хочу, чтобы сразу и хорошо), или дорогое как авиационные кабели. Компромисс между удобством и жабой был найден в датчике Adafruit BME280, который бонусом ещё и температуру с давлением показывает (но может врать, как я выше отметил).

    Если ds18b20 можно просто завернуть в термоусадку и радоваться, с ВМЕ280 такой фокус не пройдёт. Идей про корпус было немало — и оставить как есть, припаяв провода и залив их клеевыми соплями (ушки для крепления уже есть, получается), и сделать мини-корпус из того же акрила, что и подложки под компоненты, и вычудить что-нибудь с 3D-принтером, благо есть один в зоне досягаемости… Но потом я вспомнил про яйца:



    Это же идеальный корпус. Для датчика места хватает, разъём поставить можно, удобный доступ для обслуживания, подвесить можно везде или просто забросить куда-нибудь.

    Подключать датчики к raspi решил через DB9. В USB линий мало, розетка RJ45 не влезла по габаритам. Датчик-яйцо решил подключить по USB, потому что в шкафу обнаружились остатки резаных USB-кабелей — не пропадать же добру:



    Для защиты GPIO-гребёнки на raspi и для удобства разборки корпуса взял ещё одну гребёнку и припаялся к ней. Гребёнка угловая, что дало чуть больше места по вертикали, но я немного не подрассчитал и эта гребёнка уткнулась в резисторы для светодиодов. Всё, конечно, намертво завёрнуто в термоусадку, но момент, который в будущем стоит помнить. В итоге половинки корпуса всё ещё можно разнять, чтобы, допустим, поменять батарейку в rtc или саму raspi. Всё остальное (точнее, флешка) доступно для замены без открывания корпуса.

    Фотографии полуготовности и готовности






    Одна рекомендация — не экономьте на кнопках. Я вот сэкономил, так кнопка не только дребезжит (с этим можно бороться, в библиотеке RPi.GPIO защита от дребезга предусмотрена), но ещё и срабатывает только в очень конкретном положении. Кнопку я предусматривал для программного отключения устройства на случай, если надо отключить питание (уже несколько раз убил ФС на флешке неаккуратным выключением), но оказалось, что мало что-то предусмотреть — надо ещё и документацию читать. Если вы, как и я, не читаете документацию, то знайте — overlay gpio_shutdown делает вовсе не то, что можно было бы предположить, а всего лишь выставляет на некотором пине высокий/низкий уровень при отключении, чтобы, например, внешний блок питания мог погаснуть. Для того, чтобы отключать raspi по кнопке, есть ядрёный модуль rpi_power_switch (но его компилять надо, а для этого kernel-headers нужны) или пользовательский демон Adafruit-GPIO-Halt. У меня будет свой hostd, который будет мигать светодиодами, вот заодно и на кнопку реагировать будет.

    Заключение


    Получился программно-аппаратный комплекс для мониторинга, расширяемый, использующий актуальные технологии, устойчивый к сбоям. Части ПО можно обновлять и перезапускать независимо то других частей (спасибо systemd, это не потребовало от меня как от разработчика никаких усилий). А самое главное — получилось получить много удовольствия от процесса и от результата. Ну и маленькая тележка новых знаний добавилась.

    Спасибо за чтение!
    Поделиться публикацией

    Комментарии 10

      0
      В качестве экрана можно использовать не 1602, а 0802. Если устройство считывает только данные о температуре и влажности, а потом передать их в сеть, то почему не применить микроконтроллер типа AVR или STM, зачем стрелять из пушки по воробьям?
        +2
        Тут целая стая воробьёв:
        • на raspi сеть уже есть, к контроллерам сеть надо прикручивать сбоку
        • для контроллеров надо делать плату и знать электронику; полагаю, что если опытный электронщик посмотрит на мои схемы, он заплачет кровавыми слезами и повесит меня
        • контроллеры надо программировать на ассемблере/Си, а raspi даёт мне питон, который я знаю относительно неплохо, который мне нравится и который не даёт пальцу, который держит спусковой крючок винтовки, направленной в ногу, этот крючок нажать до конца
        • на raspi работает линукс, из которого я могу выжать так много, как я хочу; на контроллерах фишки типа snmp, lldp, zabbix agent и прочего мне придётся писать самому

        И самый убер-воробей, просто вожак стаи — с raspi у меня опыт есть, с контроллерами у меня опыта нет и нет времени учиться

        По такой стае воробьёв имеет смысл стрелять, как по мне
        0

        Можно расширить: добавить радиомодуль, чтобы ловить по воздуху показания с других датчиков (газа, утечки воды, движения, света и т.п.). И все показания выводить в веб-интерфейс.

          0
          Расширять можно бесконечно :) Нужды не было

          Что до веб-интерфейса — основная задача была в том, чтобы показания с датчиков доставить в заббикс. Проверять 10 разных веб-интерфейсов скучно, надёжнее, когда заббикс смотрит на показание и шлёт алёрты в случае чего
          0
          Очень понравилась идея с яйцом от Киндер-сюрприза в качестве контейнера для модуля. Обязательно использую!
            0
            Единственное, надо подумать, насколько это яйцо электростатично. Я акриловые подложки заворачиваю в изолятор, потому что акрил электризуется как бешеный. С яйцами такого не наблюдал, но это пища для подумать
          • НЛО прилетело и опубликовало эту надпись здесь
              0
              Абсолютно согласен. В шкафах всё равно всё за UPSом, так что и raspi будет за ним. Вот даже кнопку присобачил, чтобы выключать аккуратно
              0
              А чем не устроил AM2302 как датчик температуры-влажности? Он у меня на мониторинге полтора года отработал в помещении, я не заметил проблем или вранья. Температура, правда, ниже +10 не падала.

              Для часов я взял модулек на ds3231, они вроде поточнее, прям готовый китайский модуль на разъеме со впаянным аккумулятором, меньше возни с подключением.

              p.s. Упс, пардон, открыл по ссылке, не заметил дату :) Но удалять не буду.
                0
                Честно говоря, даже и не знаю, чем АМ2302 не устроил. Я его видел, вроде, но дело было давно, так что сейчас уже не скажу. Может, доступность запчастей, может, цена, а может, наличие/отсутствие библиотек, уже не помню

                Ну а RTC взял тот, который всегда использовал, вроде проблем с ним никогда не было, микросекундной точности всё равно не надо :)

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое