Привет, Хабр!
Я сейчас работаю над проектом мессенджера на блокчейне вместе с командой своих коллег. Кому интересно – смотрите ссылки в профиле или спрашивайте в комментариях.
Блокчейн-разработка – область новая и неизведанная, поэтому порой приходится использовать очень нестандартные инструменты. Куда там микроскопу и гвоздям! Поэтому и решил вести этот блог, чтобы рассказывать разные интересные случаи из практики. Сегодняшний пост – о том, как я настроил моментальные уведомления о состоянии своей ноды, чтобы в случае чего оперативно ее возвращать к жизни.
Задачу я себе поставил такую: при каждом выходе из строя или прекращении работы ноды мне должны приходить моментальные уведомления об этом. Мы же живем в прогрессивный век и привыкли получать всю важную информацию мгновенно, правда?
Я решил, что для осуществления этой задачи я прикручу Zabbix к Slack (он у нас рабочий инструмент проекта). Zabbix, соответственно, будет мониторить ноду и присылать сообщения о неисправностях мне в личку Slack’a.
Конечно же, у Zabbix нет стандартных преднастроенных средств мониторинга для нашей ноды. Поэтому первым желанием было определять доступность порта ноды, используя ключ
Но есть одно “но”: случается, что нода активна, слушает на порту, но при этом функционирует неправильно. И вот тут-то я столкнулся с тем, что нужно определить основной признак работоспособности ноды.
Нода что должна делать? Правильно, расти. Вот рост и будет главным признаком. Поэтому я решил использовать ключ
Совместно с
В результате мы получали строку формата JSON вида
На помощь в решение задачи парсинга JSON пришел пакет jq (https://stedolan.github.io/jq/). Нехитрая передача результата через пайп
Избыточную информацию необходимо было убирать, и тут пришел помощник – ключ
Для настройки планируемого оповещения потребовался также триггер. План был такой: сравнивать последнее и предыдущее значения, и чтобы триггер срабатывал, если рост меньше единицы.
Следующая задача – оповещать о срабатывание триггера в Slack. За основу я взял материал https://github.com/ericoc/zabbix-slack-alertscript.
Инструкция понятная, но использование смайликов для различения Severity – это не серьезно. Выделение цветовыми полосами намного интереснее. После переработки скрипта осталось это:
В качестве морали – пара слов, почему удобный мониторинг так важен. Чем быстрее узнаешь о ситуации, тем быстрее ее исправишь и тем менее выраженными будут последствия. Как говорится, вовремя поднятое не считается упавшим. А в Slack, помимо всего прочего, есть групповые чаты, поэтому команда может подключиться к устранению проблемы и координировать действия. Кстати, у нашего проекта открытый исходный код, и мы относимся с большим уважением к другим open source проектам. Мой эксперимент в очередной раз показал, что открытый код – это хорошо.
Я сейчас работаю над проектом мессенджера на блокчейне вместе с командой своих коллег. Кому интересно – смотрите ссылки в профиле или спрашивайте в комментариях.
Блокчейн-разработка – область новая и неизведанная, поэтому порой приходится использовать очень нестандартные инструменты. Куда там микроскопу и гвоздям! Поэтому и решил вести этот блог, чтобы рассказывать разные интересные случаи из практики. Сегодняшний пост – о том, как я настроил моментальные уведомления о состоянии своей ноды, чтобы в случае чего оперативно ее возвращать к жизни.
План, которого я придерживался
Задачу я себе поставил такую: при каждом выходе из строя или прекращении работы ноды мне должны приходить моментальные уведомления об этом. Мы же живем в прогрессивный век и привыкли получать всю важную информацию мгновенно, правда?
Я решил, что для осуществления этой задачи я прикручу 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 проектам. Мой эксперимент в очередной раз показал, что открытый код – это хорошо.
