告警与通知
Pier 监视主机和容器指标，以及部署、备份等生命周期事件，并在某项越过阈值或失败时发送通知。
一条规则将一个指标与一个阈值、一种比较方式和一个严重级别配对。数值型规则按周期性的 tick 进行评估（默认每 30 秒一次）；事件型规则则由产生该事件的代码路径触发。
可用指标：
| 分组 | 指标 |
|---|---|
| 主机 | cpu、ram、disk |
| 容器 | container_cpu、container_ram、container_status、container_restarts |
| 生命周期 | deploy_status、deploy_success、backup_status、backup_success |
| 基础设施 | agent_offline、server_reachable、ssl_expiry、docker_cleanup_success、docker_cleanup_failure |
每条规则还携带：
- comparison（比较）——
gt、lt或eq。 - severity（严重级别）——
info、warning或critical。 - scope（范围）——
global或某个特定服务。 - duration（持续时间）——触发前违规状态必须保持多长时间（默认 60 秒）。
- cooldown（冷却时间）——在仍处于违规状态时，两次重复触发之间的最小间隔（默认 30 分钟）。
一条规则在其违规状态保持了所配置的持续时间后触发，仅在冷却时间结束后才再次触发，并在数值回落到阈值以下时自动解除。
Pier 提供四种渠道。每种渠道有一份全局配置，加密存储：
| 渠道 | 配置 |
|---|---|
| Telegram | Bot token + chat ID |
驱动（smtp、brevo 或 resend）+ 发件/收件地址 | |
| Discord | Webhook URL + 可选的 @here 提醒 |
| Slack | Webhook URL |
对于 SMTP 邮件，加密模式（starttls、tls、none）、主机、端口（默认 587）和凭据按渠道分别配置。Brevo 和 Resend 改为通过其 HTTP API 配合 API 密钥发送。
Telegram 投递直接访问
api.telegram.org。如果你服务器的网络封锁了该主机，即使配置有效，Telegram 通知也会发送失败。
每种渠道都有一个 Test 操作，它会通过实时配置发送一条示例消息，以便你在依赖该渠道之前确认凭据和连通性。单条规则也可以发送一条带 [TEST] 标记的测试消息。
每一次触发和解除都会作为一个事件记录下来，并附带其投递状态。提供两种视图：
- 跨所有规则的最新事件的全局事件流。
- 某条规则近期事件的逐规则历史。
投递失败的记录会保留并附上错误消息，因此配置错误的 webhook 或错误的 SMTP 主机会在事件流中可见，而不是被悄无声息地丢弃。
Pier 预置了一组现成的预设规则，让你无需从空白开始。预设是直接开启或关闭，而不是逐字段构建，并且它们通过上述全局渠道配置进行投递，而不携带各自的凭据。