Skip to main content
Это руководство описывает настройку как простых, так и сложных правил оповещений с помощью API Tenderly. Мы рассмотрим каждый тип выражения, а затем объединим их в комплексные решения для мониторинга.

Справочник Alerting API

Введение

Tenderly Alert API позволяет создавать как простые, так и сложные оповещения (Alerts). Простое оповещение состоит из одного правила, например, method_call будет срабатывать, когда транзакция вызывает ваш публичный или внешний метод. Сложное оповещение может содержать несколько условий и сработает только когда все они выполняются. Например, оповещение с method_call и state_change сработает, когда транзакция вызовет указанный метод и изменит указанный слот хранилища. При определении оповещения через API вам необходимо указать следующее:
  • каналы доставки (delivery channels), которые получат уведомление при срабатывании правила. Подробнее о каналах доставки (Delivery Channels).
  • массив выражений (expressions), которые вызовут срабатывание оповещения, если все условия, представленные отдельными выражениями, будут выполнены.
Каналы доставки email, Discord и Sentry можно создавать через API (POST /api/v1/account/{accountId}/delivery-channel). Каналы Slack, Telegram и PagerDuty требуют OAuth/бот-подключения и создаются только через Dashboard. Получить все каналы можно через API.

Аутентификация

Прежде чем создавать оповещения, вам нужно настроить аутентификацию и идентифицировать ваш проект:

Типы выражений

Для задания правил срабатывания оповещений можно использовать различные типы выражений.

Примечания

  • Это все типы выражений, которые принимает API. Полезная нагрузка с любым другим значением type отклоняется с ошибкой 400 (“Expressions are not in the right format”).
  • Все выражения внутри оповещения объединяются логикой AND: оповещение срабатывает только тогда, когда каждое выражение совпадает с одной и той же транзакцией. Для мониторинга независимых условий создавайте отдельное оповещение для каждого.
  • Для операторов сравнения (operator) допустимые значения: >, >=, <, <=, ==, !=, contains, notContains
  • Типы параметров (parameter_type) включают: uint, int, bool, address, string, slice, array, tuple, fixed_bytes, bytes, hash, function
  • Типы выражений emitted_log, erc20_transfer_matcher, eth_balance, tx_value, method_call, state_change, tx_status и view_function поддерживают необязательное поле not: true, инвертирующее совпадение
  • eth_balance срабатывает только тогда, когда транзакция переводит баланс через порог (из несоответствия в соответствие), а не на каждой транзакции, пока условие выполняется
  • Все адреса должны быть валидными Ethereum-адресами (с префиксом 0x, 40 hex-символов)
  • Значения в wei следует передавать в виде строк для работы с большими числами
  • ID сети должны соответствовать целевому блокчейну (например, “1” для Ethereum mainnet)
Подробнее см. в справочнике Alerting API.

Примеры простых выражений

Рассмотрим примеры настройки простых правил-выражений.

1. Мониторинг вызовов методов

Сценарий: отслеживание вызовов определённых функций в вашем смарт-контракте.

2. Мониторинг изменений состояния

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

3. Мониторинг событий

Сценарий: мониторинг определённых событий, генерируемых вашими контрактами, с фильтрацией по параметрам.

4. Мониторинг баланса нативного ETH

Сценарий: оповещение о снижении баланса нативного ETH некоторого адреса ниже порогового значения, например, для релеера или операционного кошелька, который должен оставаться пополненным. Ограничьте оповещение сетью и адресом, затем сравните нативный баланс с пороговым значением (в wei).

Примеры сложных оповещений

Далее приведены примеры сложных правил-выражений. Оповещение сработает, когда каждое выражение в массиве expressions выполнено.

1. Система мониторинга безопасности

Сценарий: комплексный мониторинг безопасности, объединяющий несколько условий:
  • Мониторинг вызовов административных функций
  • Отслеживание крупных переводов
  • Отслеживание адресов из чёрного списка
  • Оповещения об изменениях критичных параметров состояния

2. Мониторинг DeFi-протокола

Сценарий: мониторинг DeFi-пула для:
  • Крупных сделок/свопов
  • Изменений ликвидности
  • Неудачных транзакций
Поскольку выражения внутри оповещения объединяются логикой AND, каждое условие оформляется отдельным оповещением. Примеры ниже создают три оповещения за один прогон.

3. Мониторинг ERC20-токена

Сценарий: мониторинг токена, включающий:
  • Проверки согласованности Transfer
  • Мониторинг крупных переводов
  • Изменения totalSupply
Как и в предыдущем примере, каждое условие представляет собой отдельное оповещение.