13.02.2019 15:42
JustDeveloper 16 3500 Источник
Привет, Хабр!

Я сейчас работаю над проектом мессенджера на блокчейне вместе с командой своих коллег. Кому интересно – смотрите ссылки в профиле или спрашивайте в комментариях.

Блокчейн-разработка – область новая и неизведанная, поэтому порой приходится использовать очень нестандартные инструменты. Куда там микроскопу и гвоздям! Поэтому и решил вести этот блог, чтобы рассказывать разные интересные случаи из практики. Сегодняшний пост – о том, как я настроил моментальные уведомления о состоянии своей ноды, чтобы в случае чего оперативно ее возвращать к жизни.



План, которого я придерживался


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

Я решил, что для осуществления этой задачи я прикручу Zabbix к Slack (он у нас рабочий инструмент проекта). Zabbix, соответственно, будет мониторить ноду и присылать сообщения о неисправностях мне в личку Slack’a.

Реализация: шаг за шагом


Шаг 1: Zabbix


Конечно же, у Zabbix нет стандартных преднастроенных средств мониторинга для нашей ноды. Поэтому первым желанием было определять доступность порта ноды, используя ключ net.tcp.listen[port].

Но есть одно “но”: случается, что нода активна, слушает на порту, но при этом функционирует неправильно. И вот тут-то я столкнулся с тем, что нужно определить основной признак работоспособности ноды.

Нода что должна делать? Правильно, расти. Вот рост и будет главным признаком. Поэтому я решил использовать ключ system.run[command, mode].

Совместно с curl -s http://127.0.0.1:36666/api/blocks/getHeight.

В результате мы получали строку формата JSON вида 

{"success":true,"nodeTimestamp":XXXXXXX,"height":XXXXXXX}

На помощь в решение задачи парсинга JSON пришел пакет jq (https://stedolan.github.io/jq/). Нехитрая передача результата через пайп curl http://127.0.0.1:36666/api/blocks/getHeight | jq .height, и вместо долгожданной высоты мы получили ответ содержащий информацию о выполнении команды curl.



Избыточную информацию необходимо было убирать, и тут пришел помощник – ключ -s, он же --silent. В итоге с помощью Zabbix-ключа system.run[curl -s http://127.0.0.1:36666/api/blocks/getHeight | jq .height] мы получаем высоту ноды желаемого и удобного для мониторинга вида ХХХХХХХХ.



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

{ADAMANT Node Monitoring:system.run[curl -s http://127.0.0.1:36666/api/blocks/getHeight | jq .height].change()}<1

Шаг 2. Zabbix to Slack




Следующая задача – оповещать о срабатывание триггера в Slack. За основу я взял материал https://github.com/ericoc/zabbix-slack-alertscript.

Инструкция понятная, но использование смайликов для различения Severity – это не серьезно. Выделение цветовыми полосами намного интереснее. После переработки скрипта осталось это:

 url='********************************'
username='Server'

to="$1"
subject="$2"

recoversub='^RECOVER(Y|ED)?$'
if [[ "$subject" == 'Warning' ]]; then
	color='#EBFF00'
elif [ "$subject" == 'Not classified' ]; then
	color='#D8E3FF'
elif [ "$subject" == 'Information' ]; then
	color='#0049FF'
elif [ "$subject" == 'Average' ]; then
	color='#FFC200'
elif [ "$subject" == 'High' ]; then
	color='#FF5500'
elif [ "$subject" == 'Disaster' ]; then
	color='#FF0000'
else
	color='#00FF06'
fi

message="${subject} \n $3"

payload="payload={\"attachments\": [{\"color\": \"${color}\", \"text\": \"${message}\"}]}"
curl -m 5 --data-urlencode "${payload}" $url

Выводы


В качестве морали – пара слов, почему удобный мониторинг так важен. Чем быстрее узнаешь о ситуации, тем быстрее ее исправишь и тем менее выраженными будут последствия. Как говорится, вовремя поднятое не считается упавшим. А в Slack, помимо всего прочего, есть групповые чаты, поэтому команда может подключиться к устранению проблемы и координировать действия. Кстати, у нашего проекта открытый исходный код, и мы относимся с большим уважением к другим open source проектам. Мой эксперимент в очередной раз показал, что открытый код – это хорошо.

Комментарии (16)


  1. usego
    13.02.2019 19:42
    #19753034
    +1

    В 4ом заббиксе есть http agent, избавляет от парсинга jsonа


    1. AlexGluck
      13.02.2019 21:16
      #19753304
      -1

      А в 2.0 появился ключ web.get и в 3.4 появился препроцессинг, так что до 3.4 можно было регуляркой в триггере проверять, а в 3.4 из json доставать данные. И никаких rce незащищённых не надо открывать, вы наверное не шифруете связь между сервером и агентом, а мне хватит и телнета чтобы получить remote shell на таких реализациях как у вас.


    1. kyookineko
      14.02.2019 11:52
      #19755150

      Всё ещё проще — даже в самых древних версиях в агенте есть web.page.get, с помощью него вытаскиваем весь JSON и засовываем в короткоживущий айтем типа Text. Дальше делаем все необходимые айтемы, как зависимые и с JSON Path препроцессором.
      При этом на клиенте вообще ничего, кроме заббикс агента ставить не надо!
      Посмотрите темплейт для nginx от AlexGluck — там как раз такой подход применяется.


  1. SiliconValleyHobo
    13.02.2019 21:15
    #19753300

    >Я сейчас работаю над проектом мессенджера на блокчейне
    Лiл


    1. JustDeveloper Автор
      13.02.2019 22:28
      #19753516

      Да, мы часто сталкиваемся со скепсисом в адрес проекта и с высказываниями вроде «Блокчейн не для этого». Но мессенджер уже есть, он работает, люди пользуются. Кто хочет — может сам протестировать на сайте.


      1. Maxlinus
        14.02.2019 14:49
        #19756230

        хотим! в статье не увидел сайта. Ткните носом где можно глянуть.


  1. MicroNovaX
    13.02.2019 21:16
    #19753302
    -1

    Стартап, блокчейн, иии… Zabbix. Почему именно он?
    Та же Grafana с Prometheus в качестве хранилища лучше по всем параметрам (Имхо).
    А подобная задача решается банальным вебхуком из панельки.


    1. JustDeveloper Автор
      13.02.2019 22:27
      #19753514

      Zabbix — потому что надежное и удобное решение «из коробки». Prometeus, судя по описанию — это решение для очень крупных сетей. А Графана — это ещё дополнительный софт, чтобы рисовать графики. Которые и так есть в Заббиксе, но мы их не используем.
      В общем, отвечая именно на вопрос «Почему» — потому, что это первое удобное решение, которое нашлось, при том, что я не проводил масштабного исследования всех доступных продуктов. Рассудил, что лучшее — враг хорошего.


      1. gecube
        14.02.2019 01:15
        #19753872

        Что Вы подразумеваете под мониторингом ноды?
        Как я понял — не саму доступность самого узла (сервера), а сервиса на нем?
        Вообще MicroNovaX правильно пишет: если у Вас самописный HTTP-сервис (второе точно верно, первое — не уверен, но скорее всего), то проще всего сделать отдельный эндпойнт вида 127.0.0.1:36666/metrics и в нем выдать метрики в прометеусовском формате. Можно считать, что это уже стандарт де-факто на нынешнем этапе. А далее все достаточно легко делается. Интересно, что alertmanager легко умеет слать оповещения сразу в слак и не нужно городить костыли.

        Prometeus, судя по описанию — это решение для очень крупных сетей.

        на самом деле нет. Это просто альтернативный подход к мониторингу. Не мониторинг узлов или еще чего-то, а сервис-ориентированный мониторинг. У этого принципа есть недостатки, но в целом годно.
        А Графана — это ещё дополнительный софт, чтобы рисовать графики

        если графики не нужны, то графану можно не ставить. Просто из средств визуализации данных (в том числе и метрик) Графана сейчас — лучшее, что есть на рынке.


    1. gecube
      14.02.2019 01:12
      #19753862

      Графана — ок.
      Prometheus — для оперативного хранения метрик ок, для долговременного — не ок.
      Алертинг — вообще отдельная история, т.к. через графану он гипер-костыльный. Через prometheus (точнее — alertmanager) — ок, но нужно его еще умудриться настроить. Это не сложно, но нужно день мозг понасиловать )

      Если для коллег заббикс — приемлемый инструмент, то пускай используют.


  1. baxxter
    14.02.2019 00:18
    #19753792

    Можно ещё из самого нодовского приложения zabbix-sender'ом(есть реализация под js) посылать нужные статусы при ошибках например или метрики какие нибудь (количество активных пользователей… ) — думали об этом?


    1. AlexGluck
      14.02.2019 16:05
      #19756634

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


  1. ilyakruchinin
    15.02.2019 16:24
    #19761298

    Какой ужас!
    Велосипедостроение в худшем его проявлении.
    Читайте документацию к Заббиксу и используйте нативные методы получения и обработки данных.
    Любые скрипты на агенте — ЗЛО, и должны быть последней крайней мерой.
    Почти всё можно получить средствами встроенных в Заббикс-агент нативных средств.

    web.page.regexp[127.0.0.1,api/blocks/getHeigh,36666,regexp,,]


    1. JustDeveloper Автор
      15.02.2019 16:26
      #19761308

      Так я и предупреждал, что буду рассказывать о нестандартных методах решения проблем! Мы обсуждали другие пути, но этот способ мониторинга был признан самым удобным для команды. Иногда приходится идти и на крайние меры.


  1. Nick_Neck
    15.02.2019 16:26
    #19761310

    Заббикс уже давно прикручен к телеграмм ботам, есть много готовых, удобных и быстрых решений, у Вас, скорее, частный случай для слак


    1. JustDeveloper Автор
      15.02.2019 16:27
      #19761318

      Да, так и есть. Слак у нас рабочий мессенджер, поэтому его и выбрали для уведомлений. Телеграм неплох, но не для всех участников команды удобен.