Go微服务监控告警系统核心在于指标采集、传输、存储、查询、触发逻辑五层可控且低侵入；需用独立Registry避免冲突，规范命名、基线定阈值、用分位数而非均值、告警含service/instance标签、Webhook显式引用labels、repeat_interval防刷屏，并确保每项指标对应明确业务语义。
Go 微服务监控与告警系统不能靠堆库实现，核心在于指标采集、传输、存储、查询、触发逻辑这五层是否可控且低侵入。
用 prometheus.ClientGolang 暴露指标时，别直接注册全局 DefaultRegistry
全局注册器在多模块或测试场景下容易冲突，尤其当你引入了第三方 SDK（比如某些云厂商的 trace 包）也偷偷注册了同名指标时，panic: duplicate metrics collector registration attempted 就会突然出现。
- 始终用独立 registry：
reg := prometheus.NewRegistry()，再传给promhttp.HandlerFor(reg, ...) - HTTP handler 路由别写成
/metrics硬编码，微服务可能有多个 endpoint（如/admin/metrics、/v1/metrics），需和团队约定前缀 - 自定义指标命名严格遵循
namespace_subsystem_name，例如payment_service_http_request_duration_seconds，避免 Prometheus 的label_replace规则失效
告警规则写在 alert.rules.yml 里，但触发条件必须结合服务真实 SLI
Prometheus 的 ALERTS{alertstate="firing"} 只是“规则命中”，不代表业务出问题。比如一个 HTTP 5xx 告警，如果服务本身 5xx 占比常年 0.2%，那阈值设成 rate(http_requests_total{code=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.01 就会误报。
- 先用
rate(http_requests_total{code=~"5.."}[1h])查过去一小时基线，再定百分比或绝对值阈值 - 对延迟类指标（如
http_request_duration_seconds_bucket），优先用histogram_quantile(0.95, ...)而非平均值，避免被长尾拖偏 - 告警分组 label 必须含
service和instance，否则 Alertmanager 收不到有效路由信息
用 Alertmanager 转发告警到钉钉/企业微信时，模板里别硬编码 summary 字段
Alertmanager 的 text/template 默认只渲染 summary 和 description，但很多 Go 微服务的日志上下文（如 traceID、用户 ID、订单号）存在 labels 里，不显式取出来就丢了。
