Всем привет.




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


В общем и целом, вся эта конструкция работает и является весьма живучей. 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, это не потребовало от меня как от разработчика никаких усилий). А самое главное — получилось получить много удовольствия от процесса и от результата. Ну и маленькая тележка новых знаний добавилась.

Спасибо за чтение!