Alertmanager客户端怎么连不上？查http.Client超时和TLS配置
Go服务调用Alertmanager API失败，十有八九卡在HTTP层——不是地址写错，而是默认http.Client没设超时，或对方启用了双向TLS但你没配tls.Config。Alertmanager的/api/v2/alerts接口对连接稳定性敏感，尤其在K8s集群内跨namespace调用时。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 显式初始化
http.Client，设置Timeout: 5 * time.Second，避免阻塞goroutine - 若Alertmanager启用了
tls.crt和tls.key（如通过prometheus-operator部署），需用http.DefaultTransport.(*http.Transport).TLSClientConfig加载CA证书，否则报x509: certificate signed by unknown authority - K8s Service DNS名（如
alertmanager-main.monitoring.svc）必须带完整域名，省略.svc后缀会导致解析失败
发告警时status字段总被忽略？注意Alertmanager v0.24+的status语义变更
v0.24起Alertmanager把status从“告警当前状态”改为“是否已解决”，只接受firing或resolved两个值。老代码里传status: "warning"或"critical"会被静默丢弃，告警进不来。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 告警级别（warning/error）应放在
labels.severity里，这是Prometheus生态约定，Alertmanager路由规则也依赖它 -
status只控制生命周期：新发告警设firing，恢复事件设resolved，且resolved必须带原fingerprint或完全匹配的labels - 用
curl -XPOST -H "Content-Type: application/json" --data-binary @alert.json http://am/api/v2/alerts手动测时，先确认alert.json结构符合v2 schema
Go struct怎么映射Alertmanager的Alert JSON？别手写，用官方model.Alert
自己定义struct解析/api/v2/alerts返回体，容易漏掉generatorURL、receivers等字段，更糟的是startsAt/endsAt是RFC3339字符串，不加time.Time自定义Unmarshal会panic。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 直接go get
github.com/prometheus/alertmanager/pkg/labels和github.com/prometheus/alertmanager/pkg/model - 发送告警用
model.Alert，它内置了MarshalJSON/UnmarshalJSON，自动处理时间字段和空值 - 接收Alertmanager回调（如webhook receiver）时，同样用
model.Alert反序列化，别用map[string]interface{}——后者无法校验必填字段，上线后才发现labels为空
为什么告警发出去没触发通知？检查group_by和group_wait的Go client行为
Alertmanager的分组逻辑在服务端，但Go客户端如果批量发告警却不控制节奏，可能被group_wait: 30s拦住——头一条告警进来，后面30秒内的同group_by标签告警全塞进同一组，直到超时才发通知。你看到“发了10条”，实际只触发1次邮件。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 调试时临时把Alertmanager配置里的
group_wait调成5s，确认是否分组导致延迟 - 确保
labels中参与group_by的键值一致（比如都带cluster="prod"），否则每条告警单独成组，又可能触发频率限制 - Go服务里不要循环高频调用
http.Post发单条告警；聚合后一次性提交[]*model.Alert，减少连接开销，也更贴合Alertmanager设计意图
Alertmanager的路由匹配、抑制规则、静默都是服务端行为，Go代码唯一要管牢的，就是发过去的labels和annotations字段是否拼写准确、类型合法——少一个冒号，多一个空格，整条链路就断在第一步。
