/tags/prometheus/ Recent content in prometheus on Hugo -- gohugo.io en Sun, 26 Apr 2026 00:45:00 +0800 /posts/slo-error-budget-multi-burnrate-2026/ Sun, 26 Apr 2026 00:45:00 +0800 /posts/slo-error-budget-multi-burnrate-2026/ 📦 本文基于的完整项目源码：meirongdev/shop 阈值告警（“5xx > 1% 持续 5 分钟”）的两个失败模式工程师都熟悉：阈值定低了一周告警一百条没人看，阈值定高了真出事告警来得太晚。Google SRE Workbook 第 5 章给出的思路是 error budget + multi-window multi-burn-rate——让告警的“敏感度”随事件严重程度变化。本文更像是一次整理：为什么、怎么做、以及落地时绕不开的取舍。 一、SLO 和 error budget 的底层逻辑 Q：SLO 不就是"99.9% 可用"这种数字吗？跟告警有什么关系？ 至少在工程落地里，SLO 一个很重要的用途是把 reliability 变成预算。 SLO 99.9% 意味着每个 30 天窗口允许 0.1% 的请求失败——这就是 error budget。 把整个 30 天窗口的 budget 按时间切片：1 分钟内允许失败的请求量很小（少量异常就把这分钟的 budget 烧光），但 30 天内的累计可以容忍。 如果短窗口内的烧速大于"按比例消耗"的速度，说明这次事件如果不止住，会提前烧完整个月的预算——这就是值得告警的事件。 阈值告警是"超过 X 报警"——只看一个时间点。Burn-rate 告警是"按当前的烧速会在多久烧完月度 budget"——看的是趋势对未来的投影。 Q：burn rate 怎么算？ 定义：burn rate = 观察窗口内的实际错误率 / SLO 允许的错误率。 SLO 99.9% → 允许错误率 0. /posts/homelab-alertmanager-gotify-bridge/ Sat, 25 Apr 2026 01:00:00 +0800 /posts/homelab-alertmanager-gotify-bridge/ 背景 Homelab 跑了一套 LGTM 可观测性栈（Loki + Grafana + Tempo + Prometheus），Prometheus Alertmanager 已经在收集各种告警，但一直没有配出通知渠道——告警只是静静地积在队列里，没有任何推送。 Gotify 是一个轻量的自托管推送通知服务，已经在集群里跑着了，主要用于接收 Redpanda Connect 推送的消息。顺手把 Alertmanager 的告警也接进来，省得再引入第三方服务。 架构 Alertmanager 的 webhook receiver 发送的是自己定义的 JSON 格式；Gotify 的 POST /message API 期望的是另一套字段（title / message / priority）。两者不能直接对接，需要一个中间层做格式转换。 DRuggeri/alertmanager_gotify_bridge 是一个专门做这件事的小服务。它的 README 说明默认监听 /gotify_webhook，并把收到的 Alertmanager webhook 转换后转发到 Gotify。 flowchart LR P[Prometheus] --> A[Alertmanager] A -->|webhook| B[alertmanager-gotify-bridge] B -->|POST /message| G[Gotify] 部署拓扑： 组件 Namespace 说明 Gotify personal-services 消息服务端，已有 alertmanager-gotify-bridge monitoring 格式转换 bridge Alertmanager monitoring kube-prometheus-stack 的一部分 Token 管理走 Vault + External Secrets Operator：在 Gotify 创建一个专用 Application，把 token 存入 Vault，ESO 自动同步到 bridge 所在的 monitoring namespace。 /posts/spring-boot-35-metrics-best-practices/ Mon, 06 Apr 2026 10:00:00 +0800 /posts/spring-boot-35-metrics-best-practices/ 为什么 Metrics 是可观测性的基础信号 在日志、链路追踪（Traces）和 Metrics 三大可观测性信号中，Metrics 往往是最先被告警系统用到的那个。 Metrics 是聚合数据：它告诉你"过去 1 分钟，/api/hello 接口平均延迟 320ms，错误率 0.3%"。日志是个体事件：它记录每一次请求的具体参数。两者不是替代关系，而是分工：Metrics 负责趋势感知和告警触发，日志负责单点定位和细节还原，链路追踪负责调用链拼接。 RED 方法论是 Metrics 最重要的一套设计框架，适合所有面向用户的服务： 指标 英文 含义 请求速率 Rate 每秒处理多少请求 错误率 Error 失败请求占比 请求耗时 Duration P50 / P95 / P99 延迟分布 本文以 springboot3.5-otel 项目（三服务微服务架构）为参考，整理一次 Spring Boot 应用层 Metrics 埋点实践。虽然该项目通过 OTel Collector 导出 Metrics，但本文大部分应用层代码对直接使用 Prometheus 的团队同样适用——因为埋点 API 是 Micrometer 的抽象层，与后端无关。 一、Spring Boot Metrics 技术栈：后端无关的 Micrometer 抽象 Micrometer 的核心价值 Micrometer 是 Spring Boot 的 Metrics 门面（类似 SLF4J 之于日志），它提供统一的埋点 API，在应用层之上屏蔽了不同监控后端的差异：