Мне довольно часто приходится работать с нодами различных криптовалют, о чем я уже писал в отдельной статье. Сегодня хочу рассказать, как я настраиваю мониторинг нод (эфир, биткоин и др.) и конкретно состояние блокчейна с помощью zabbix. Если вам интересна эта тема, приглашаю к дальнейшему ознакомлению.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном онлайн-курcе по администрированию MikroTik. Автор курcа – сертифицированный тренер MikroTik Дмитрий Скоромнов. Более 40 лабораторных работ по которым дается обратная связь. В три раза больше информации, чем в MTCNA.
Введение
Для тех, кому интересно, как устанавливать и настраивать ноды популярных криптовалют, есть отдельная статья на этот счет - установка и настройка нод. Я расскажу, как мониторить состояние этих нод. Будут показаны 2 разных способа:
- Мониторинг нод Ethereum (Эфира).
- Мониторинг нод Bitcoin, Litecoin, Dash, Bitcoin Cash и т.д.
Последние ноды очень похожи между собой. Используют одни и те же консольные команды cli, вывод о состоянии блокчейна у них одинаковый. Они все по сути клоны биткоина, поэтому и мониторятся так же, как он. Ноды Эфира работают совсем по-другому, там и мониторинг другой.
Настраивать мониторинг нод криптовалют я будут с помощью системы мониторинга zabbix. Сразу делаю важное замечания. Предложенные в мониторинге скрипты и шаблоны сделаны для внутреннего использования. Я не приводил их к красивому и удобному виду, не оптимизировал код, не искал наиболее оптимальные варианты. Была задача настроить мониторинг и я решал ее сходу, с помощью тех идей, которые приходили в голову. В большей части это были единичные задачи, поэтому тратить время на оптимизацию и улучшения не было смысла. Важно, чтобы все работало так, как надо.
Сам по себе мониторинг криптонод очень примитивный. Надо просто парсить вывод команд о состоянии ноды и блокчейна. Вот и все. Делать это можно разными способами, кто как привык и умеет. Я сделал так, как умею сам, не претендуя ни на какие лавры. Просто делюсь с вами своими наработками. В сети я ничего подобного не видел, поэтому все с нуля делал сам.
Версия zabbix сервера, на котором все это работает - 4.0. Шаблоны и скрипты будут взяты из реальных работающих проектов, так что они 100% рабочие и проверенные.
Если у вас еще нет своего сервера для мониторинга, то рекомендую материалы на эту тему. Для тех, кто предпочитает систему CentOS:
То же самое на Debian 10, если предпочитаете его:
Мониторинг ноды Ethereum - Эфира
Для начала привожу список параметров, которые я буду мониторить:
- eth_blockNumber - число блоков в блокчейне. Если нода выдает 0, то срабатывает триггер.
- Наличие запущенного сервиса ноды в системе. В моем случае используется клиент parity, мониторить буду его - запущен или нет процесс.
- eth_syncing - состояние синхронизации. С его помощью можно узнать, не отстает ли нода в синхронизации блоков. Если отставание большое, срабатывает триггер.
- Открытый tcp порт для rpc запросов. Если порт не отвечает, срабатывает триггер.
Расскажу подробно, как реализована каждая проверка. Пойдем по списку. Для проверки eth_blockNumber есть отдельный метод, который запускается вот так:
# curl -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":83}' localhost:8545
Проверку можно делать как локально, так и удаленно. Я в данном случае все проверки буду делать локально, чтобы потом передавать информацию в zabbix-agent. Вывод будет примерно такой:
{"jsonrpc":"2.0","result":"0x65a0d9","id":83}
Нас интересует значение result. К сожалению, оно в 16-ти ричном формате. Я написал небольшой скрипт eth-get.sh, который парсит это значение и преобразует его в 10-ти ричный формат.
#!/bin/bash curl -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":83}' localhost:8545 | cut -f3 -d : | cut -f2 -d'"' > /etc/zabbix/scripts/result-hex.txt a=`cat /etc/zabbix/scripts/result-hex.txt` echo $(( ${a} )) > /etc/zabbix/scripts/result-dex.txt
Результат записывается в текстовый файл, а не выводится сразу из-за того, что в вывод попадает какая-то информация от curl. Уже не помню подробностей, но по-моему не получалось избавиться от ее прогресс бара, даже явно запрещая его ключами. В итоге пришлось записать значение в файл, а потом вторым скриптом выводить это значение и передавать в zabbix сервер. Второй скрипт eth-chek.sh
#!/bin/bash a=`cat /etc/zabbix/scripts/result-dex.txt 2>/dev/null` echo $a
После работы этого скрипта, в консоль должно выводиться только число с номером блока. Сразу скажу, что сделано очень костыльно. Мне, когда я делал, просто не пришло в голову, что zabbix умеет принимать сразу готовый json. Далее есть возможность сделать зависимый элемент и в нем же перевести 16-ти ричный формат в 10-ти ричный. Когда я делал данную проверку, не знал об этом. Сейчас по работе с json в zabbix у меня есть отдельная статья, где рассказано, как сделать то, что я описал быстро и красиво. Мониторинг bitcoin, который описан ниже, тоже сделан весь через парсинг json полностью на стороне zabbix server.
Следующим этапом я проверяю наличие службы parity в системе. Это делается с помощью встроенного функционала заббикса прямо в шаблоне. В агенте ничего настраивать не надо.
Дальше мониторим синхронизацию. Здесь все посложнее. Информация о синхронизации проверяется следующей командой:
curl --data '{"method":"eth_syncing","params":[],"id":1,"jsonrpc":"2.0"}' -H "Content-Type: application/json" -X POST localhost:8545
Если все ОК, то вывод будет такой:
{"jsonrpc":"2.0","result":false,"id":1}
Нас интересует значение result. В данном случае false это нормальное состояние, когда все в порядке. Если идет процесс синхронизации, то вывод будет примерно такой:
{"id": 1,"jsonrpc": "2.0","result": {"startingBlock": "0x384","currentBlock": "0x386","highestBlock": "0x454"}}
Здесь нас интересуют значения currentBlock и highestBlock. Если разница между последним и первым более 50, считаем, что синхронизация отстает и срабатывает триггер. Здесь мне уже очень хотелось все отправить в zabbix сервер и распарсить там, но я не придумал, как это сделать. Формат json строки меняется. Пришлось опять все делать на клиенте скриптом и отправлять на сервер мониторинга уже подготовленные данные. Вот сам скрипт eth_syncing.sh:
#!/bin/bash curl --data '{"method":"eth_syncing","params":[],"id":1,"jsonrpc":"2.0"}' -H "Content-Type: application/json" -X POST localhost:8545 -o /etc/zabbix/scripts/eth_syncing.txt 2>/dev/null if grep -q "false" /etc/zabbix/scripts/eth_syncing.txt; then echo "1" else currentblock=`cat /etc/zabbix/scripts/eth_syncing.txt | cut -f4 -d : | cut -f1 -d , | cut -f2 -d'"'` highestblock=`cat /etc/zabbix/scripts/eth_syncing.txt | cut -f5 -d : | cut -f1 -d , | cut -f2 -d'"'` c=`echo $(( ${currentblock} ))` h=`echo $(( ${highestblock} ))` a=$(($h-$c)) if [ $a -gt 50 ] then echo 0 else echo 1 fi
Скрипт парсит вывод. Если в выводе есть false, выводит в консоль 1, что в шаблоне будет означать ОК. Дальше считает разницу между highestblock и currentblock. Если больше 50, то выводит 0. В шаблоне на это настроен триггер. Если разница меньше 50, то выводит 1, что означает ОК.
Это что касается скриптов. Теперь создаем конфиг для заббикса с UserParameter. Для этого создаем файл /etc/zabbix/zabbix_agentd.d/eth.conf следующего содержания.
UserParameter=eth_blockNumber,/etc/zabbix/scripts/eth-check.sh UserParameter=eth_syncing.json,curl --data '{"method":"eth_syncing","params":[],"id":1,"jsonrpc":"2.0"}' -H "Content-Type: application/json" -X POST localhost:8545 2>/dev/null UserParameter=eth_syncing.status,/etc/zabbix/scripts/eth_syncing.sh
Первый и третий параметры передают вывод описанных скриптов. Второй передает полный json синхронизации на сервер. Это просто для информации, чтобы было проще продебажить момент работы последнего скрипта. Значение 0 или 1 не очень информативно, рядом будет полный json вывода.
После добавления параметров в zabbix-agent перезапустите его и проверьте в консоли, что ключи выводят правильные значения.
# zabbix_agentd -t eth_blockNumber eth_blockNumber [t|4972806]
# zabbix_agentd -t eth_syncing.json eth_syncing.json [t|{"jsonrpc":"2.0","result":false,"id":1}]
# zabbix_agentd -t eth_syncing.status eth_syncing.status [t|1]
Если все в порядке и цифры реальные, то можно перемещаться на сервер и продолжать настройку там. Я подготовил шаблон для мониторинга Ethereum на основе описанных настроек - Cryptonode ETH check
Список итемов из шаблона.
Список триггеров.
После подключения шаблона для мониторинга ноды Эфира, в Latest Data будет следующая информация.
Проверка доступности tcp порта для rpc запросов настраивается отдельно на том хосте, откуда вы хотите вести наблюдение. Я обычно с самого zabbix server настраиваю. Сделать это можно, создав вот такой элемент данных.
Используется Simple check. В поле key указывается ip адрес и порт для проверки. Подробнее об этом рассказывал в мониторинге служб linux. Не забудьте открыть на фаерволе доступ к порту со стороны zabbix сервера.
На этом про мониторинг Ethereum node все. Переходим к ноде bitcoin и производным от него.
Мониторинг bitcoin node
С мониторингом биткоин ноды все немного проще, так как для получения всей необходимой информации достаточно распарсить json, который не меняет свой формат в зависимости от ответа. Поэтому достаточно будет просто необходимую json строку передавать на сервер и там парсить с помощью зависимых элементов. Наблюдать будем за следующими параметрами:
- Разница значений headers и blocks. Она не должна превышать определенного значения. Если превышает - срабатывает триггер.
- Параметр networkactive должен возвращать значение true. Если это не так, срабатывает триггер.
- Наличие процесса bitciond в системе.
- Ответ на внешний запрос через rpc порт.
3 и 4 пункты сделаны точно так же, как и для ноды эфира. Не буду на этом останавливаться. Первый пункт настраивается через парсинг вывода следующей команды:
/usr/bin/bitcoin-cli -rpcuser=user -rpcpassword=password getblockchaininfo
Ответ должен быть примерно такой:
Нас интересует разница указанных значений. Они уже в десятиричном формате, так что проблем с их распознаванием нет. Все будет сделано в шаблоне, в том числе и настроен триггер на контроль разницы этих значений.
Второй пункт из списка на тему мониторинга сети настраивается парсингом вывода следующей команды:
/usr/bin/bitcoin-cli -rpcuser=user -rpcpassword=password getnetworkinfo
Вывод:
Весь этот json тоже отправляем на сервер и там парсим и проверяем параметр networkactive. Он должен быть true.
Таким образом в zabbix-agent на нужно добавить следующие параметры:
UserParameter=blockchaininfo,/usr/bin/bitcoin-cli -rpcuser=user -rpcpassword=password getblockchaininfo UserParameter=networkinfo,/usr/bin/bitcoin-cli -rpcuser=user -rpcpassword=password getnetworkinfo
Я их добавил в отдельный конфиг - /etc/zabbix/zabbix_agentd.d/btc.conf Перезапускаем агент и проверяем:
# zabbix_agentd -t blockchaininfo # zabbix_agentd -t networkinfo
В выводе должны увидеть полные json строки. Если все в порядке, переходим к zabbix серверу для настройки ноды биткоина там.
Для этого импортируем мой готовый шаблон для bitcoin node - Cryptonode BTC check
Там присутствуют следующие итемы:
Вот пример зависимого итема, который получает значение blocks из json строки.
Более подробно о парсинге json строк читайте в отдельной статье, ссылку на которую я приводил в начале.
Список триггеров в шаблоне:
Тут все понятно из описания триггеров. Комментировать нечего. После применения шаблона к хосту с биткоин нодой, получите следующие данные.
При открытии History к json элементам, можно посмотреть полностью всю строку.
Все остальные клоны биткоина мониторятся похожим образом. Отличаться может консольная команда, например, litecoin-cli, dash-cli и т.д. Так же названия системных служб будут отличаться. Для настройки мониторинга этих нод достаточно скопировать шаблон и конфиги bitcoin и отредактировать.
Мониторинг внешнего порта для rpc команд настраивается точно так же, как для ethereum, не буду повторяться. Достаточно только поменять ip адрес и номер порта.
Заключение
Очередной наглядный пример простоты и удобства работы с мониторингом zabbix. С его помощью можно настроить мониторинг чего угодно. Главное, данные подать в удобочитаемом виде.
Очень нравится реализованная в нем работа с json. Не помню точно, с какой версии она появилась, но я стал пользоваться только недавно, когда появилась необходимость. Сейчас формат json очень популярен.
У меня накопился неплохой опыт работы с нодами различных криптовалют. Если кому-то нужна помощь или советы по работе с ними, задавайте в комментариях к статье про настройку криптонод или в темах на форуме.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном онлайн-курcе по администрированию MikroTik. Автор курcа – сертифицированный тренер MikroTik Дмитрий Скоромнов. Более 40 лабораторных работ по которым дается обратная связь. В три раза больше информации, чем в MTCNA.
Добрый день
Почему в параметрах curl укзан id=83 для блоков и id=1 для синхронизации?
Добрый день! Давно читаю ваши статьи, спасибо большое! У меня вопрос: пробовали ли вы разворачивать zabbix в docker? Было бы интересно почитать (у меня ничего не получилось)
Не пробовал, но не вижу проблем, чтобы развернуть. Будет работать. Я просто не вижу практического смысла запуска zabbix в docker.