Мониторинг асиков: какие показатели нужно контролировать на майнинговой площадке

Мониторинг асиков: какие показатели нужно контролировать на майнинговой площадке

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

Открыли устройство, посмотрели хешрейт, температуру, убедились, что оно в сети, — и пошли дальше.

На площадке с сотнями или тысячами устройств такой подход уже не работает.

Если оператор каждое утро видит перед собой список из 5 000 асиков, ему не нужен ещё один список с цифрами. Ему нужно за несколько минут понять:

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

Именно поэтому мониторинг асиков — это не просто экран со статусами онлайн / офлайн.

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

Разберём основные показатели, которые действительно имеют значение на майнинговой площадке.

Хешрейт: первый показатель, на который обычно смотрят

Самый очевидный параметр — хешрейт.

Асик может быть доступен по сети, отображаться как работающий и при этом выдавать заметно меньше ожидаемой производительности.

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

Для оператора это сигнал разобраться в причине.

Но смотреть только на текущее значение недостаточно.

Гораздо полезнее видеть:

• текущий хешрейт;
• среднее значение за период;
• изменение относительно обычного уровня;
• длительность отклонения;
• историю показателя.

Почему это важно?

Кратковременное снижение ещё не обязательно означает неисправность. Показатель может колебаться.

Другая ситуация — когда хешрейт стабильно остаётся ниже нормального уровня 20–30 минут или начинает постепенно снижаться в течение смены. Здесь уже есть смысл проверять устройство.

И ещё важнее смотреть не только на один асик.

Допустим, оператор видит снижение хешрейта сразу у 40 устройств одного ряда.

Это совсем другая ситуация, чем снижение у одного асика.

Проверять 40 устройств по отдельности в таком случае нелогично. Сначала нужно понять, что у них общего: питание, сеть, условия в контейнере или другой участок инфраструктуры.

То есть хешрейт полезен не только как показатель отдельного устройства, но и как способ увидеть масштаб проблемы.

Температура: важна не сама цифра, а отклонение от нормальной работы

Следующий показатель — температура.

Высокая температура может привести к снижению производительности, нестабильной работе или остановке оборудования.

Но здесь есть важный нюанс.

Нельзя сказать, что для всех асиков существует одна универсальная температура, после которой устройство считается перегретым.

Нормальный диапазон зависит от модели, прошивки, режима работы, конструкции охлаждения и условий на самой площадке.

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

Оператору полезно видеть:

текущую температуру → изменение во времени → выход за заданный порог.

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

Это локальная проблема.

Но если температура одновременно растёт у большого количества устройств в одном контейнере, уже стоит смотреть шире.

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

И здесь снова видно преимущество группового мониторинга.

Оператору нужно не просто получить 60 одинаковых предупреждений:

«Высокая температура».

Гораздо полезнее сразу увидеть, что все эти устройства находятся в одном участке площадки.

Статус подключения: офлайн не всегда означает поломку асика

Асик пропал из мониторинга.

Первая реакция — устройство выключилось.

Но причин потери связи может быть несколько.

Сам асик действительно мог остановиться.

Могла пропасть сеть.

Мог отключиться коммутатор.

Мог возникнуть сбой на общем участке.

Могло исчезнуть питание у группы оборудования.

Поэтому статус офлайн нужно рассматривать вместе с местом установки и соседними устройствами.

Представим, что в 14:07 связь потеряли 32 асика.

Все они находятся в одном контейнере и подключены к одному участку сети.

В таком случае начинать обход с первого S/N в списке будет странно.

Сначала имеет смысл проверить общий узел.

Если же из 300 асиков контейнера связь потерял только один, сценарий уже другой.

На большой площадке именно способность быстро увидеть эту разницу экономит время команды.

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

Ещё один показатель, который не стоит игнорировать, — отклонённые шары, или реджекты.

Устройство может показывать нормальный хешрейт и находиться онлайн, но часть отправленной работы отклоняется.

Небольшое количество реджектов само по себе не обязательно означает проблему. Здесь также важно смотреть на динамику и условия работы.

Насторожить должно именно изменение поведения.

Например, у асика долгое время показатель находился примерно на одном уровне, а затем доля реджектов заметно выросла.

Или рост произошёл одновременно у группы устройств.

В первом случае стоит разбираться с конкретным асиком и его настройками.

Во втором — проверять общие причины, включая сеть и внешние условия.

Поэтому реджекты полезнее анализировать не как отдельную цифру, а вместе с хешрейтом, связью и историей работы устройства.

Режим работы: асик может быть онлайн, но работать не так, как должен

Статус онлайн ещё не означает, что всё нормально.

На площадке могут использоваться разные режимы работы оборудования.

Например, для конкретной группы асиков задан определённый режим или расписание.

Если устройство осталось онлайн, но не перешло в нужный режим, формально оно продолжает работать. Но фактически заданный план не выполняется.

Поэтому мониторинг должен отвечать ещё на один вопрос:

работает ли асик так, как ему сейчас предписано работать?

Это особенно важно, когда режимы меняются массово.

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

Их нужно видеть отдельно.

Иначе оператор смотрит на общую картину, видит тысячи устройств онлайн и считает задачу выполненной, хотя часть парка работает не в том режиме.

График работы: плановая остановка не должна выглядеть как авария

На некоторых площадках оборудование работает по расписанию.

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

В 23:00 асик выключился.

Это проблема?

Если по графику он должен был остановиться в 23:00 — нет.

Если он должен был продолжать работу ещё пять часов — да.

Поэтому статус оборудования нужно сравнивать с заданным графиком.

Иначе оператор получает множество ложных отклонений и перестаёт понимать, какие сигналы действительно требуют реакции.

Особенно заметно это при расчёте uptime.

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

Календарный uptime:

16 / 24 = 66,7%.

Выполнение графика:

16 / 16 = 100%.

Если смотреть только на первое число, создаётся впечатление, что оборудование треть суток простаивало.

На самом деле оно полностью выполнило заданный режим.

Поэтому на площадках с расписаниями полезно разделять календарный uptime и выполнение графика работы.

Uptime: важно понимать, что именно вы считаете

Сам термин uptime кажется простым: сколько времени оборудование было доступно.

Но на практике один и тот же показатель можно посчитать по-разному.

Относительно всего календарного времени?

Только относительно запланированного времени работы?

Учитываются ли плановые остановки?

Как считается подтверждённый технический простой?

Поэтому прежде чем сравнивать uptime между площадками, контейнерами или клиентами, нужно определить правила расчёта.

Для операционной работы особенно полезно отдельно видеть:

фактическое время работы;

выполнение заданного графика;

незапланированный простой.

Так становится понятно, где действительно есть проблема с доступностью оборудования, а где низкий календарный uptime объясняется заданным режимом эксплуатации.

Потребление: отклонение мощности тоже может многое показать

Если площадка получает данные о потреблении оборудования, этот показатель полезно рассматривать вместе с остальными.

Сам по себе асик может оставаться онлайн, но его фактическая работа изменится.

Например, одновременно меняются хешрейт и потребляемая мощность.

Или после перехода в другой режим мощность осталась на прежнем уровне.

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

Особенно полезно сравнивать устройства одной модели и прошивки в одинаковых режимах.

Если большинство асиков группы ведёт себя примерно одинаково, а один заметно выбивается, оператор получает ещё один ориентир для диагностики.

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

Место установки — это тоже часть мониторинга

На первый взгляд контейнер, ряд и ячейка относятся скорее к складскому учёту.

На практике без этих данных мониторинг большого ЦОД быстро становится неудобным.

Представим сигнал:

Высокая температура у 18 асиков.

Хорошо.

А где они находятся?

Если оператору после этого нужно открыть другую таблицу, скопировать S/N и отдельно искать расположение каждого устройства, часть пользы мониторинга теряется.

Гораздо удобнее сразу видеть:

площадка → контейнер → ряд → ячейка.

Тогда из программного сигнала быстро получается физическое место, куда должен подойти сотрудник.

Это особенно важно при массовых проблемах.

Если все 18 асиков находятся рядом, оператор сразу понимает, что стоит искать общую причину.

Клиент и группа оборудования помогают быстрее понять масштаб

На хостинговой площадке один клиент может размещать десятки или сотни асиков.

Поэтому полезно фильтровать мониторинг не только по техническим параметрам, но и по принадлежности оборудования.

Например:

показать все асики конкретного клиента;

показать устройства определённой модели;

открыть один контейнер;

найти группу по списку S/N;

оставить только асики с определённым типом проблемы.

Это кажется мелочью, пока устройств немного.

При нескольких тысячах асиков хороший поиск и фильтрация становятся одним из основных инструментов оператора.

Вместо просмотра всей площадки он работает только с той частью оборудования, которая относится к текущей задаче.

История показателей важнее одного снимка

Мониторинг в конкретную секунду показывает состояние сейчас.

Но многие проблемы невозможно понять без истории.

Допустим, хешрейт асика сейчас ниже нормы.

Когда он начал снижаться?

Падение произошло резко или постепенно?

Это уже случалось вчера?

Повышалась ли одновременно температура?

Переключался ли режим работы?

Был ли перед этим инцидент?

Один текущий показатель на эти вопросы не отвечает.

Поэтому полезно сохранять историю статусов и основных показателей по каждому асику.

Это помогает не только диагностировать текущую проблему, но и находить повторяющиеся отклонения.

Например, устройство может стабильно работать большую часть дня и каждую ночь уходить в одинаковое состояние.

Без истории это выглядит как несколько независимых инцидентов.

С историей становится видно закономерность.

Не все отклонения одинаково важны

Ещё одна ошибка — считать все сигналы равнозначными.

На большой площадке это быстро создаёт информационный шум.

Допустим, одновременно произошло:

один асик ненадолго потерял связь;

у трёх устройств немного выросло количество реджектов;

40 асиков одного контейнера перестали майнить;

у группы оборудования температура вышла за допустимый диапазон.

Если система просто покажет четыре типа уведомлений одинаковым цветом и в порядке поступления, оператору всё равно придётся вручную определять приоритет.

Поэтому мониторинг должен помогать понять не только что произошло, но и насколько это важно.

На приоритет могут влиять:

масштаб проблемы;

тип отклонения;

количество затронутых асиков;

продолжительность;

условия SLA;

клиент;

участок площадки.

Тогда команда в первую очередь занимается тем, что сильнее влияет на работу ЦОД.

Сигнал должен закончиться результатом

Самый красивый мониторинг бесполезен, если после обнаружения проблемы дальнейшая работа снова уходит в Telegram.

Допустим, система обнаружила высокую температуру.

Следующий вопрос:

что произошло после этого?

Кто принял сигнал?

Когда сотрудник начал работу?

Что проверил?

В чём оказалась причина?

Что было сделано?

Проблема устранена?

Если мониторинг никак не связан с задачами и инцидентами, ответ снова придётся искать вручную.

Поэтому на операционной площадке удобно строить цепочку:

сигнал → инцидент → ответственный → диагностика → действие → результат.

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

А следующая смена получает уже не просто сообщение «в контейнере проблема», а историю того, что успели проверить до неё.

Какие показатели действительно стоит вывести оператору

Если свести всё к практическому набору, на основном экране мониторинга не обязательно показывать сотни параметров.

В первую очередь оператору нужны показатели, которые помогают принять решение.

Для каждого асика это обычно:

• статус;
• хешрейт;
• температура;
• связь;
• реджекты;
• текущий режим;
• выполнение графика;
• uptime;
• место установки;
• клиент;
• история отклонений.

Если доступны достоверные данные о потреблении, их также имеет смысл использовать.

Но важнее количества показателей другое:

мониторинг должен выделять отклонения, а не заставлять оператора искать их самостоятельно.

Оператор не должен сидеть перед 10 000 строк и сравнивать цифры глазами.

Ему нужен список того, что изменилось и требует внимания.

Где мониторинг начинает мешать вместо того, чтобы помогать

Это тоже происходит.

Чаще всего проблема появляется, когда система генерирует слишком много уведомлений.

Асик кратковременно изменил показатель — сигнал.

Через минуту вернулся — ещё один сигнал.

Затем снова отклонился.

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

Поэтому пороги и правила мониторинга нужно настраивать под реальную работу площадки.

Например, имеет значение не только сам факт выхода показателя за пределы, но и продолжительность отклонения.

Условно:

одно кратковременное изменение — наблюдаем;

стабильное отклонение несколько минут — проверяем;

массовое отклонение группы — повышаем приоритет.

Конкретные значения здесь нельзя назначить одинаковыми для всех площадок. Они зависят от модели асиков, режима работы, инфраструктуры и требований оператора.

Главное — чтобы система помогала уменьшить шум, а не увеличивать его.

Как понять, что текущего мониторинга уже недостаточно

Проблема не всегда в отсутствии данных.

Иногда данных как раз слишком много.

Мониторинг стоит пересматривать, если оператор регулярно делает следующее:

экспортирует список устройств в Excel, чтобы найти проблемные;

копирует S/N в другую систему, чтобы узнать место установки;

после сигнала пишет задачу вручную в чат;

отдельно ищет, кому принадлежит асик;

не может быстро показать историю показателей;

видит десятки одинаковых сигналов при одной массовой проблеме;

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

В такой ситуации проблема уже не в количестве метрик.

Не хватает связи между данными.

Как мониторинг устроен в ROC

В ROC мониторинг связан с конкретным оборудованием, его размещением и другими процессами площадки.

Оператор может искать асики по S/N, фильтровать оборудование по площадке, клиенту, модели, режиму работы и типу проблемы.

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

Статусы и показатели сохраняются в истории асика.

Также в ROC можно задавать режимы и графики работы оборудования и видеть устройства, которые не выполнили заданный режим.

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

Данные мониторинга дальше используются в связанных процессах ROC — в том числе задачах, биллинге и отчётности.

Базовый мониторинг ROC — 0 ₽ за асик.

Посмотреть, как мониторинг будет работать на конкретной площадке, можно на демо ROC.