Мониторинг нод криптовалют Ethereum и Bitcoin с помощью Zabbix

Мониторинг нод криптовалют Ethereum и Bitcoin с помощью Zabbix

Мне довольно часто приходится работать с нодами различных криптовалют, о чем я уже писал в отдельной статье. Сегодня хочу рассказать, как я настраиваю мониторинг нод (эфир, биткоин и др.) и конкретно состояние блокчейна с помощью zabbix. Если вам интересна эта тема, приглашаю к дальнейшему ознакомлению.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на . Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Введение

Для тех, кому интересно, как устанавливать и настраивать ноды популярных криптовалют, есть отдельная статья на этот счет — установка и настройка нод. Я расскажу, как мониторить состояние этих нод. Будут показаны 2 разных способа:

  1. Мониторинг нод Ethereum (Эфира).
  2. Мониторинг нод Bitcoin, Litecoin, Dash, Bitcoin Cash и т.д.

Последние ноды очень похожи между собой. Используют одни и те же консольные команды cli, вывод о состоянии блокчейна у них одинаковый. Они все по сути клоны биткоина, поэтому и мониторятся так же, как он. Ноды Эфира работают совсем по-другому, там и мониторинг другой.

Настраивать мониторинг нод криптовалют я будут с помощью системы мониторинга zabbix. Сразу делаю важное замечания. Предложенные в мониторинге скрипты и шаблоны сделаны для внутреннего использования. Я не приводил их к красивому и удобному виду, не оптимизировал код, не искал наиболее оптимальные варианты. Была задача настроить мониторинг и я решал ее сходу, с помощью тех идей, которые приходили в голову. В большей части это были единичные задачи, поэтому тратить время на оптимизацию и улучшения не было смысла. Важно, чтобы все работало так, как надо.

Сам по себе мониторинг криптонод очень примитивный. Надо просто парсить вывод команд о состоянии ноды и блокчейна. Вот и все. Делать это можно разными способами, кто как привык и умеет. Я сделал так, как умею сам, не претендуя ни на какие лавры. Просто делюсь с вами своими наработками. В сети я ничего подобного не видел, поэтому все с нуля делал сам.

Версия zabbix сервера, на котором все это работает — 4.0. Шаблоны и скрипты будут взяты из реальных работающих проектов, так что они 100% рабочие и проверенные.

Если у вас еще нет своего сервера для мониторинга, то рекомендую материалы на эту тему. Для тех, кто предпочитает систему CentOS:

  1. Установка CentOS 8.
  2. Настройка CentOS 8.
  3. Установка и настройка zabbix сервера.

То же самое на Debian 10, если предпочитаете его:

  1. Установка Debian 10.
  2. Базовая настройка Debian.
  3. Установка и настройка zabbix на debian.

Биткоин для начинающих: Полное руководство

Уста но вив его, вы мо же те по лу чать и от прав лять бит ко и ны или дру гие крип то ва лю ты.

Найдены возможные дубликаты (читать далее…)

2. Ано­ним­ность. Ни тран­зак­ции, ни учет­ные за­пи­си не свя­за­ны с ка­ки­ми-ли­бо сущ­но­стя­ми ре­аль­но­го мира. Вы по­лу­ча­е­те бит­ко­и­ны на так на­зы­ва­е­мый адрес, ко­то­рый пред­став­ля­ет собой слу­чай­ную стро­ку при­мер­но из 30 сим­во­лов. Как пра­ви­ло, про­сле­дить поток тран­зак­ций можно, но адрес вовсе не обя­за­тель­но дол­жен быть хоть как-то свя­зан с ре­аль­ной лич­но­стью поль­зо­ва­те­ля.

Мониторинг ноды Ethereum — Эфира

Для начала привожу список параметров, которые я буду мониторить:

  1. eth_blockNumber — число блоков в блокчейне. Если нода выдает 0, то срабатывает триггер.
  2. Наличие запущенного сервиса ноды в системе. В моем случае используется клиент parity, мониторить буду его — запущен или нет процесс.
  3. eth_syncing — состояние синхронизации. С его помощью можно узнать, не отстает ли нода в синхронизации блоков. Если отставание большое, срабатывает триггер.
  4. Открытый tcp порт для rpc запросов. Если порт не отвечает, срабатывает триггер.

Расскажу подробно, как реализована каждая проверка. Пойдем по списку. Для проверки eth_blockNumber есть отдельный метод, который запускается вот так:

Проверку можно делать как локально, так и удаленно. Я в данном случае все проверки буду делать локально, чтобы потом передавать информацию в zabbix-agent. Вывод будет примерно такой:

Нас интересует значение result. К сожалению, оно в 16-ти ричном формате. Я написал небольшой скрипт eth-get.sh, который парсит это значение и преобразует его в 10-ти ричный формат.

#!/bin/bash curl -X POST -H «Content-Type: application/json» —data ‘’ localhost:8545 | cut -f3 -d : | cut -f2 -d'»‘ > /etc/zabbix/scripts/result-hex.txt a=`cat /etc/zabbix/scripts/result-hex.txt` echo $(( $ )) > /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 в системе. Это делается с помощью встроенного функционала заббикса прямо в шаблоне. В агенте ничего настраивать не надо.

Дальше мониторим синхронизацию. Здесь все посложнее. Информация о синхронизации проверяется следующей командой:

Если все ОК, то вывод будет такой:

Нас интересует значение result. В данном случае false это нормальное состояние, когда все в порядке. Если идет процесс синхронизации, то вывод будет примерно такой:

Здесь нас интересуют значения currentBlock и highestBlock. Если разница между последним и первым более 50, считаем, что синхронизация отстает и срабатывает триггер. Здесь мне уже очень хотелось все отправить в zabbix сервер и распарсить там, но я не придумал, как это сделать. Формат json строки меняется. Пришлось опять все делать на клиенте скриптом и отправлять на сервер мониторинга уже подготовленные данные. Вот сам скрипт eth_syncing.sh:

#!/bin/bash curl —data ‘’ -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 $(( $ ))` h=`echo $(( $ ))` 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 ‘’ -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|

📎📎📎📎📎📎📎📎📎📎