Cloudprober 告警配置完整指南Slack、PagerDuty、邮件与 Webhook 通知实战【免费下载链接】cloudproberAn active monitoring software to detect failures before your customers do.项目地址: https://gitcode.com/gh_mirrors/clo/cloudproberCloudprober 是一款开源的主动监控active monitoring软件能在真实用户发现故障之前主动检测到网站、API、内部服务与第三方依赖的异常。这份 Cloudprober 告警配置完整指南将带你从零开始掌握 Slack、PagerDuty、邮件SMTP与 Webhook 等主流渠道的告警通知实战配置让每一次探测失败都能第一时间送达值班团队。一、Cloudprober 告警机制先搞懂两个核心概念Cloudprober 的告警是按探针probe配置的每个探针可以挂多个独立的告警每个告警由两部分组成告警条件Alert Condition和通知配置NotifyConfig完整字段定义可参考 internal/alerting/proto/config.proto。1. 告警条件failures 与 total告警条件用「最近 total 次探测中失败 failures 次」来定义例如condition { failures: 3, total: 5 }表示「最近 5 次探测中失败 3 次」就触发告警。场景配置说明立即告警默认不写 condition等效于 failures:1、total:1第一次失败就告警连续失败failures: 3, total: 3连续 3 次失败才触发避免偶发抖动偶发失败failures: 3, total: 5探测间隔 30s 时约 2 分钟内连续失败或 5 分钟内失败 4 次都会触发灵活使用 total可以同时覆盖「持续故障」和「间歇性故障」两种场景这是 Cloudprober 告警配置中最实用的技巧。2. 通知配置把告警发出去在notify块中Cloudprober 支持以下通知渠道EmailSMTPPagerDutySlackOpsgenieMicrosoft TeamsHTTP Webhook任意 REST API⚙️Command执行任意 shell 命令二、最快配置方法一个完整的告警配置示例把下面这段配置保存为cloudprober.cfgtextproto 格式也支持 YAML同时接入 Slack、PagerDuty 和邮件三种渠道probe { name: homepage type: HTTP targets { host_names: example.com } http_probe { protocol: HTTPS } interval: 30s timeout: 5s alert { name: homepage_down condition { failures: 3 total: 5 } notify { slack { webhook_url_env_var: SLACK_WEBHOOK_URL } pager_duty { routing_key_env_var: PAGERDUTY_ROUTING_KEY } email { to: oncallexample.com smtp_server: smtp.example.com:587 smtp_username: alertexample.com smtp_password_env... # 推荐使用环境变量 SMTP_PASSWORD } } } }启动方式export SLACK_WEBHOOK_URLhttps://hooks.slack.com/services/xxx export PAGERDUTY_ROUTING_KEY你的-routing-key export SMTP_PASSWORD你的密码 cloudprober --config_file /cloudprober.cfgCloudprober 非常贴心地支持密钥环境变量注入Webhook URL、Routing Key、SMTP 密码等敏感信息都可以不写进配置文件而是通过环境变量读取避免密钥泄露风险。三、Slack 告警通知配置步骤第一步在 Slack 控制台的「Incoming Webhooks」中为你的频道创建一个 Webhook URL。第二步在notify块中加入 Slack 配置URL 可以直接写在webhook_url字段也可以写在环境变量SLACK_WEBHOOK_URL默认读取该变量notify { slack { webhook_url: https://hooks.slack.com/services/T000000/B000000/XXXX } }Slack 通知的具体实现可参考 internal/alerting/notifier/slack/slack.go它会自动把告警标题、失败详情组装成 Slack 消息卡片发送到指定频道。四、PagerDuty 告警通知配置步骤PagerDuty 适合接入值班与升级机制on-call 轮班、电话/短信通知。第一步在 PagerDuty 服务的 Integrations 标签页获取 Routing Key。第二步在notify块中加入 PagerDuty 配置默认读取环境变量PAGERDUTY_ROUTING_KEYnotify { pager_duty { routing_key: 你的-routing-key } }PagerDuty 通知基于 Events API v2 实现见 internal/alerting/notifier/pagerduty/pagerduty.go告警触发与恢复都会同步到 PagerDuty 事件流方便与值班排班联动。五、邮件SMTP告警通知配置步骤邮件适合作为兜底通知渠道。在notify块中配置收件人与 SMTP 信息notify { email { to: oncallexample.com from: cloudprober-alertexample.com smtp_server: smtp.example.com:587 smtp_username: alertexample.com smtp_password: 密码或使用SMTP_PASSWORD环境变量 } }各字段默认值如下不配置时从环境变量读取SMTP_SERVER、SMTP_USERNAME、SMTP_PASSWORDfrom缺省时取 SMTP 用户名或cloudprober-alert主机名。六、Webhook 与 Command 通用通知当现有渠道不够用Cloudprober 还提供两个「万能出口」HTTP Webhook把告警以 HTTP 请求形式发给任意 REST API支持 Header、Method 与 Bodynotify { http_notify { url: http://localhost:8080/alert method: POST header { key: Authorization value: Bearer {{env AUTH_TOKEN}} } data: {\message\: \alert fired for target\} } }Command执行任意 shell 命令适合自建通知或联动自愈脚本如重启 Pod、清缓存notify { command: /usr/bin/mail -s Alert alert fired for target oncallexample.com }七、自定义告警通知内容模板占位符告警内容支持模板化在summary_template、details_template、dashboard_url_template、playbook_url_template中可以使用以下占位符告警触发时自动替换字段解析逻辑见 internal/alerting/alertinfo/alertinfo.go占位符含义alert告警名称未指定时等于探针名probe探针名称target目标名称failures触发告警的失败次数total窗口内总探测次数since告警开始时间target_ip目标 IP自动发现的目标可用target.label.label目标标签值如target.label.envdashboard_url/playbook_url面板 / 处置预案链接例如把 Playbook 地址设为playbook_url_template: https://ops.example.com/playbook/alert告警通知里就会带上对应的处置文档链接大幅提升排障效率。八、告警高级配置Severity 与重复通知severity 严重级别支持CRITICAL、ERROR、WARNING、INFO其中 PagerDuty 通知未指定时默认ERROR。repeat_interval_sec 重复通知间隔同一个告警默认每 1 小时重复提醒一次设为 0 可关闭节流适合高频敏感场景。多告警同一个探针可配置多个alert每个 alert 需指定不同的name实现「不同条件、不同渠道、不同优先级」的组合告警策略。九、告警面板与告警恢复通知Cloudprober 内置告警面板访问http://localhost:9313/alerts可查看当前触发中的告警与最近 20 条历史告警方便快速定位。更贴心的是告警恢复resolved时也会自动发送通知PagerDuty、Slack 等渠道默认开启可通过disable_send_resolved关闭让你知道故障已经过去、一切恢复正常。十、常见问题Q1如何快速验证告警配置是否生效把 condition 设为failures: 1, total: 1然后探测一个不存在的域名或关闭本地服务观察/alerts面板与通知渠道是否收到消息。Q2告警为什么没触发检查 condition 的 failures/total 是否合理确认探针 interval 与超时时间再看日志中 notifier 是否有报错密钥、网络、Webhook URL 是三大常见坑。Q3告警信息里能带上更多业务标签吗可以给目标添加 label 后用target.label.xxx引用即可。结语至此你已经掌握了 Cloudprober 告警配置的完整链路从告警条件设计到 Slack、PagerDuty、邮件、Webhook 的实战接入再到通知内容模板化与高级参数调优。更详细的配置字段说明可查阅官方文档 docs/content/docs/how-to/alerting/index.md 与 docs/content/docs/faq/alerting.md告警整体调度逻辑见 internal/alerting/alerting.go。配置好告警就是给线上服务装上了「提前报警器」——让故障在用户抱怨之前就被发现和处理。【免费下载链接】cloudproberAn active monitoring software to detect failures before your customers do.项目地址: https://gitcode.com/gh_mirrors/clo/cloudprober创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Cloudprober 告警配置完整指南Slack、PagerDuty、邮件与 Webhook 通知实战【免费下载链接】cloudproberAn active monitoring software to detect failures before your customers do.项目地址: https://gitcode.com/gh_mirrors/clo/cloudproberCloudprober 是一款开源的主动监控active monitoring软件能在真实用户发现故障之前主动检测到网站、API、内部服务与第三方依赖的异常。这份 Cloudprober 告警配置完整指南将带你从零开始掌握 Slack、PagerDuty、邮件SMTP与 Webhook 等主流渠道的告警通知实战配置让每一次探测失败都能第一时间送达值班团队。一、Cloudprober 告警机制先搞懂两个核心概念Cloudprober 的告警是按探针probe配置的每个探针可以挂多个独立的告警每个告警由两部分组成告警条件Alert Condition和通知配置NotifyConfig完整字段定义可参考 internal/alerting/proto/config.proto。1. 告警条件failures 与 total告警条件用「最近 total 次探测中失败 failures 次」来定义例如condition { failures: 3, total: 5 }表示「最近 5 次探测中失败 3 次」就触发告警。场景配置说明立即告警默认不写 condition等效于 failures:1、total:1第一次失败就告警连续失败failures: 3, total: 3连续 3 次失败才触发避免偶发抖动偶发失败failures: 3, total: 5探测间隔 30s 时约 2 分钟内连续失败或 5 分钟内失败 4 次都会触发灵活使用 total可以同时覆盖「持续故障」和「间歇性故障」两种场景这是 Cloudprober 告警配置中最实用的技巧。2. 通知配置把告警发出去在notify块中Cloudprober 支持以下通知渠道EmailSMTPPagerDutySlackOpsgenieMicrosoft TeamsHTTP Webhook任意 REST API⚙️Command执行任意 shell 命令二、最快配置方法一个完整的告警配置示例把下面这段配置保存为cloudprober.cfgtextproto 格式也支持 YAML同时接入 Slack、PagerDuty 和邮件三种渠道probe { name: homepage type: HTTP targets { host_names: example.com } http_probe { protocol: HTTPS } interval: 30s timeout: 5s alert { name: homepage_down condition { failures: 3 total: 5 } notify { slack { webhook_url_env_var: SLACK_WEBHOOK_URL } pager_duty { routing_key_env_var: PAGERDUTY_ROUTING_KEY } email { to: oncallexample.com smtp_server: smtp.example.com:587 smtp_username: alertexample.com smtp_password_env... # 推荐使用环境变量 SMTP_PASSWORD } } } }启动方式export SLACK_WEBHOOK_URLhttps://hooks.slack.com/services/xxx export PAGERDUTY_ROUTING_KEY你的-routing-key export SMTP_PASSWORD你的密码 cloudprober --config_file /cloudprober.cfgCloudprober 非常贴心地支持密钥环境变量注入Webhook URL、Routing Key、SMTP 密码等敏感信息都可以不写进配置文件而是通过环境变量读取避免密钥泄露风险。三、Slack 告警通知配置步骤第一步在 Slack 控制台的「Incoming Webhooks」中为你的频道创建一个 Webhook URL。第二步在notify块中加入 Slack 配置URL 可以直接写在webhook_url字段也可以写在环境变量SLACK_WEBHOOK_URL默认读取该变量notify { slack { webhook_url: https://hooks.slack.com/services/T000000/B000000/XXXX } }Slack 通知的具体实现可参考 internal/alerting/notifier/slack/slack.go它会自动把告警标题、失败详情组装成 Slack 消息卡片发送到指定频道。四、PagerDuty 告警通知配置步骤PagerDuty 适合接入值班与升级机制on-call 轮班、电话/短信通知。第一步在 PagerDuty 服务的 Integrations 标签页获取 Routing Key。第二步在notify块中加入 PagerDuty 配置默认读取环境变量PAGERDUTY_ROUTING_KEYnotify { pager_duty { routing_key: 你的-routing-key } }PagerDuty 通知基于 Events API v2 实现见 internal/alerting/notifier/pagerduty/pagerduty.go告警触发与恢复都会同步到 PagerDuty 事件流方便与值班排班联动。五、邮件SMTP告警通知配置步骤邮件适合作为兜底通知渠道。在notify块中配置收件人与 SMTP 信息notify { email { to: oncallexample.com from: cloudprober-alertexample.com smtp_server: smtp.example.com:587 smtp_username: alertexample.com smtp_password: 密码或使用SMTP_PASSWORD环境变量 } }各字段默认值如下不配置时从环境变量读取SMTP_SERVER、SMTP_USERNAME、SMTP_PASSWORDfrom缺省时取 SMTP 用户名或cloudprober-alert主机名。六、Webhook 与 Command 通用通知当现有渠道不够用Cloudprober 还提供两个「万能出口」HTTP Webhook把告警以 HTTP 请求形式发给任意 REST API支持 Header、Method 与 Bodynotify { http_notify { url: http://localhost:8080/alert method: POST header { key: Authorization value: Bearer {{env AUTH_TOKEN}} } data: {\message\: \alert fired for target\} } }Command执行任意 shell 命令适合自建通知或联动自愈脚本如重启 Pod、清缓存notify { command: /usr/bin/mail -s Alert alert fired for target oncallexample.com }七、自定义告警通知内容模板占位符告警内容支持模板化在summary_template、details_template、dashboard_url_template、playbook_url_template中可以使用以下占位符告警触发时自动替换字段解析逻辑见 internal/alerting/alertinfo/alertinfo.go占位符含义alert告警名称未指定时等于探针名probe探针名称target目标名称failures触发告警的失败次数total窗口内总探测次数since告警开始时间target_ip目标 IP自动发现的目标可用target.label.label目标标签值如target.label.envdashboard_url/playbook_url面板 / 处置预案链接例如把 Playbook 地址设为playbook_url_template: https://ops.example.com/playbook/alert告警通知里就会带上对应的处置文档链接大幅提升排障效率。八、告警高级配置Severity 与重复通知severity 严重级别支持CRITICAL、ERROR、WARNING、INFO其中 PagerDuty 通知未指定时默认ERROR。repeat_interval_sec 重复通知间隔同一个告警默认每 1 小时重复提醒一次设为 0 可关闭节流适合高频敏感场景。多告警同一个探针可配置多个alert每个 alert 需指定不同的name实现「不同条件、不同渠道、不同优先级」的组合告警策略。九、告警面板与告警恢复通知Cloudprober 内置告警面板访问http://localhost:9313/alerts可查看当前触发中的告警与最近 20 条历史告警方便快速定位。更贴心的是告警恢复resolved时也会自动发送通知PagerDuty、Slack 等渠道默认开启可通过disable_send_resolved关闭让你知道故障已经过去、一切恢复正常。十、常见问题Q1如何快速验证告警配置是否生效把 condition 设为failures: 1, total: 1然后探测一个不存在的域名或关闭本地服务观察/alerts面板与通知渠道是否收到消息。Q2告警为什么没触发检查 condition 的 failures/total 是否合理确认探针 interval 与超时时间再看日志中 notifier 是否有报错密钥、网络、Webhook URL 是三大常见坑。Q3告警信息里能带上更多业务标签吗可以给目标添加 label 后用target.label.xxx引用即可。结语至此你已经掌握了 Cloudprober 告警配置的完整链路从告警条件设计到 Slack、PagerDuty、邮件、Webhook 的实战接入再到通知内容模板化与高级参数调优。更详细的配置字段说明可查阅官方文档 docs/content/docs/how-to/alerting/index.md 与 docs/content/docs/faq/alerting.md告警整体调度逻辑见 internal/alerting/alerting.go。配置好告警就是给线上服务装上了「提前报警器」——让故障在用户抱怨之前就被发现和处理。【免费下载链接】cloudproberAn active monitoring software to detect failures before your customers do.项目地址: https://gitcode.com/gh_mirrors/clo/cloudprober创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
