Web3 Actions
这种类型的告警目标意味着您的 action 将被用作 告警的 destination。example.yaml
Webhooks
此告警目标允许在触发告警时执行您的 webhook。您的 webhook 将收到一个已签名的负载,其中包含触发该告警的事务对象。在将 Webhook 添加为告警目标之后,您可以将其用作其他告警的 destination。
如何使用 Webhook 进行告警
Webhook 的要求:
- 它 必须 可通过 webhook URL 访问:添加 webhook 时,Tenderly 会发送一个 GET 请求来验证可达性。任何 HTTP 响应都能通过验证;只有传输层错误(DNS、TCP、TLS 或 2 秒内无响应)才会导致验证失败。
- 它 必须 在同一 webhook URI 上公开一个 POST 方法。webhook 将收到下文描述的负载。
- 除非 webhook 在 10 秒 内以
2xx状态响应,否则该次投递视为失败。 - 强烈建议 webhook URL 使用 HTTPS。
- Success: 表示 webhook 已成功执行,并将事件投递到指定的 URL
- Failed: 表示由于错误(例如连接问题、URL 问题或其他原因)导致 webhook 无法执行(请检查响应内容以了解错误原因,或联系我们的支持)
- Pending: 表示 webhook 正在执行中,尚未完成
- Retry: 表示 webhook 执行失败并将被重试;每个事件总共最多尝试 5 次 投递,之后状态定格为 Success 或 Failed
- Skipped: 表示 webhook 未被执行,因为它已被禁用
Webhook 负载
webhook 将收到表示告警事件的负载。负载包含四个字段:- id:
String, 所有已投递告警事件中唯一的 ID(UUID)。 - event_type:
TEST|ALERT, webhook 事件类型。 - alert_id:
String, 其规则触发了此事件的告警 ID。TEST事件时为空。 - transaction:
Object, 表示触发告警和 webhook 执行的未解码事务对象。
TEST 告警事件类型被调用一次。
使用
id 字段并跟踪已处理的 ID,可以确保您的 webhook 对每个告警事件都仅处理一次。保护 Webhook
您可以使用签名验证方法增强 webhook 的安全性。这样,您可以在执行之前验证 webhook 请求是否来自 Tenderly。x-tenderly-signature 头部包含一个加密签名:以签名密钥作为 密钥,对请求负载后接时间戳计算得到的 HMAC-SHA256 摘要。时间戳通过请求的 Date HTTP 头部传递。
步骤 1. 获取 Secret Signing Secret。

复制签名密钥
- 完整的 webhook 请求负载;
- 时间戳(来自请求的
Date头部)。
x-tenderly-signature 头部的值进行比较。
- example.go
- example.js
- example.py
example.go
调试 Webhook 执行
为支持排查 webhook 故障,您可以基于任意网络上现有的事务手动发送TEST 事件。
步骤 1. 在 webhooks 页面的导航栏中点击 “Test Webhook”。

Webhook 概览

测试 webhook:粘贴事务哈希
TEST。系统将展示该次执行的概览。

手动(测试)执行 webhook 的结果