On-chain алерты: разработка системы мониторинга под ключ

On-chain мониторинг в реальном времени — задача, которая кажется простой до момента, когда вы сталкиваетесь с обрывами WebSocket, дублированием логов и спамом уведомлений. Многие разработчики теряют часы на отладку пайплайнов, а критическое событие может быть пропущено из-за неправильной обработки реконнекта. Мы создаем системы алертов, которые решают эти проблемы на уровне архитектуры: очереди с Redis Streams, дедупликация по (txHash, logIndex), механизмы доставки с гарантией SLA 99.9%. Опыт — более 5 лет в Web3, десятки внедренных решений для DeFi протоколов, NFT маркетплейсов и аналитических платформ. Готовы оценить ваш проект и предложить оптимальную конфигурацию, которая сэкономит вам время и ресурсы.

Типы отслеживаемых событий

• Contract events (logs) — самое распространенное: Transfer, Swap, Deposit, Liquidation, Mint. Декодируются через ABI из raw topics + data.
• Large transactions — трансферы выше порогового значения в USD. Требуют конвертации через price feed (Chainlink, CoinGecko API) на момент события.
• Address activity — любая транзакция с/на отслеживаемый адрес (whale watching, portfolio tracking).
• MEV events — sandwich attacks, arbitrage, flashloans. Детектируются через анализ паттернов в рамках одного блока.
• Protocol health — health factor на Aave/Compound ниже порога, utilization rate выше 90%, падение TVL больше X%.
• NFT события — mint, sale, transfer конкретных коллекций.

Архитектура системы

Ingestion layer

Два варианта получения событий:

WebSocket subscriptions — минимальная latency (< 1 сек от блока). Проблема: при реконнекте пропускаются блоки. Для обработки используется catch-up механизм: при старте обрабатываются пропущенные блоки, затем подписка на новые через watchBlockNumber.

Polling — каждые N секунд делаем eth_getLogs за последние блоки. Менее эффективно, но более надежно. Для систем с SLA — комбинация: WS для скорости, polling как fallback.

Event processing pipeline

[WS / Polling] → [Raw Event Queue] → [Decoder] → [Enricher] → [Rule Engine] → [Alert Queue] → [Delivery] 

Decoder — ABI-декодинг raw logs. Для неизвестных контрактов — попытка найти ABI через Etherscan API или 4byte.directory.

Enricher — обогащение данных: USD-стоимость через price feed, labels (биржа? whale? известный протокол?), entity resolution (несколько адресов одного субъекта).

Rule Engine — проверка условий алертов против обогащенного события.

Rule Engine

Гибкая система правил — ключевой компонент. Правила конфигурируются без деплоя кода:

{ "name": "Large ETH Transfer", "chains": ["ethereum"], "event_signatures": ["0xddf252ad..."], "conditions": [ { "field": "value_usd", "operator": "gt", "value": 1000000 }, { "field": "token_symbol", "operator": "eq", "value": "ETH" } ], "condition_logic": "AND", "channels": ["telegram_main", "webhook_trading_desk"], "cooldown_seconds": 60 } 

Как работает система on-chain алертов

1. Ингестия: события получаются через WebSocket или polling.
2. Декодирование: raw logs преобразуются в понятные структуры.
3. Обогащение: добавляются цена, метки, сущности.
4. Проверка правил: каждое событие сопоставляется с настроенными условиями.
5. Дедупликация: исключаются дубликаты (по txHash + logIndex).
6. Доставка: уведомление отправляется в заданные каналы.

Почему дедупликация критична?

При нескольких нодах или при catch-up одно событие может прийти несколько раз. Дедупликация по (transaction_hash, log_index) в Redis:

async function processEvent(event: DecodedEvent): Promise<boolean> { const key = `processed:${event.txHash}:${event.logIndex}`; const isNew = await redis.set(key, '1', 'EX', 86400, 'NX'); return isNew !== null; } 

Согласно документации Redis, команда SET с опцией NX гарантирует атомарную проверку. Это предотвращает повторную обработку даже при параллельных воркерах.

Как обеспечить надежную доставку?

Telegram — наиболее популярный для крипто-алертов. Доставка реализуется через Bot API с форматированием MarkdownV2 и учетом rate limit (30 сообщений/сек на бота, 1 сообщение/сек в один чат). При высокочастотных событиях нужна батчизация или агрегация.

Webhook — HTTP POST на произвольный endpoint с retry и exponential backoff. Email — для важных событий с низкой частотой через SendGrid/AWS SES.

Discord — через webhook или Bot API. PagerDuty — для критических событий, требующих немедленной реакции.

Анти-spam и агрегация

Проблема: при flash crash или крупном событии генерируются сотни алертов за минуту. Решения:

• Cooldown per rule — не слать повторный алерт по тому же правилу N секунд.
• Digest mode — агрегировать события за 5/60 минут и отправлять сводку.
• Threshold batching — «произошло 47 ликвидаций на Aave за последние 10 минут, общая сумма $2.3M».

Состав deliverables

• Архитектурная документация и схема пайплайна.
• Исходный код с комментариями, конфиги для развертывания.
• Rule Engine с набором предустановленных правил под ваш кейс.
• Доступ к Telegram-боту, webhook-эндпоинтам.
• Мониторинг системы (Prometheus + Grafana), дашборды.
• Обучение команды, документация по добавлению правил.
• Гарантийная поддержка 1 месяц после сдачи.

Мониторинг системы

Система алертов должна мониторить себя:

• Block lag — отставание от head chain. Алерт если > 10 блоков.
• Processing queue depth — рост очереди = узкое место.
• Delivery failures — неудачные попытки отправки в каждый канал.
• Rule match rate — аномальный рост = возможно правило слишком широкое.

# Prometheus метрики alert_system_block_lag_gauge alert_system_queue_depth_gauge alert_system_delivery_total{channel, status} alert_system_rule_matches_total{rule_id} 

Стек и ориентировочные сроки

Базовая система (5–10 типов событий, Telegram + webhook, одна сеть): 2–3 недели. Мультичейн, сложные составные правила, кастомный UI для управления алертами — 4–6 недель.

Пропущенное событие может стоить тысячи долларов, если это ликвидация позиции или мошенническая транзакция. Инвестиции в качественный алерт-мониторинг окупаются за счет предотвращения потерь. Наша система на основе WebSocket + caching обрабатывает события в 10 раз быстрее, чем polling-only решения, при той же надежности. Пропускная способность — до 10000 событий в секунду, latency менее 500 мс, дедупликация снижает количество алертов на 30-50%.

Свяжитесь с нами, чтобы получить оценку вашего проекта и коммерческое предложение. Закажите консультацию по архитектуре on-chain мониторинга — мы поможем выбрать оптимальное решение и обсудим детали внедрения.