golang如何集成PagerDuty告警_golang PagerDuty告警集成方案-Golang-PHP中文网

go服务应直接调用pagerduty v2 events api（https://events.pagerduty.com/v2/enqueue），禁用已归档的pagerduty-go sdk；需设content-type、authorization: token及routing_key（integration key），通过event_action和payload.severity区分操作与级别，配合超时、重试、secret管理实现可靠告警。

golang如何集成pagerduty告警_golang pagerduty告警集成方案

Go 服务直接调用 PagerDuty API 发送告警是可行的，但必须绕开官方 SDK 的坑——pagerduty-go 已归档、不维护，且默认使用 v1 API（已停用），v2 接口需手动构造请求或换用社区轻量封装。

用 `http.Client` 直接调用 PagerDuty v2 Events API

这是最可控、最轻量的方式，适合告警逻辑简单、不想引入不稳定依赖的场景。PagerDuty 当前只支持 v2 Events API（https://events.pagerduty.com/v2/enqueue）接收告警事件，所有字段必须严格符合 schema。

必须设置 Content-Type: application/json 和 Authorization: Token token=xxx（注意不是 Bearer）
routing_key 是必填项，对应 PagerDuty 中的 Integration Key（不是 API Key），需在 UI 创建「Events API v2」类型的集成获取
告警级别通过 payload.severity 控制：critical、error、warning、info，不填默认 critical
触发（trigger）、解决（resolve）、确认（acknowledge）用同一 endpoint，靠 event_action 字段区分

reqBody := map[string]interface{}{
    "routing_key": "abc123...",
    "event_action": "trigger",
    "payload": map[string]interface{}{
        "summary": "service crashed on host-01",
        "severity": "critical",
        "source": "api-service",
        "custom_details": map[string]string{"trace_id": "tr-789"},
    },
    "links": []map[string]string{{"href": "https://grafana.example.com/d/abc", "text": "Grafana dashboard"}},
}
data, _ := json.Marshal(reqBody)
resp, _ := http.Post("https://events.pagerduty.com/v2/enqueue", "application/json", bytes.NewBuffer(data))

避免用 `github.com/PagerDuty/go-pagerduty`

这个库名义上是 PagerDuty 官方维护，实则长期未更新，其 Incident 相关接口仍指向已下线的 v1 REST API；且没有对 Events API v2 的封装，强行用它发告警会返回 404 Not Found 或 401 Unauthorized（因鉴权方式不匹配）。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

它的 Client.CreateIncident 走的是 /incidents 路径，属于旧管理类 API，不能用于实时告警
即使你只用它发 HTTP 请求，内部也硬编码了过时的 User-Agent 和 Accept 头，部分响应解析逻辑已失效
若项目里已引入，建议立即替换为裸 http.Client 或自建 minimal wrapper

封装一个带重试和上下文控制的告警函数

生产环境不能裸调 http.Post：网络抖动、PagerDuty 短时不可用会导致告警丢失。需加基础容错，但不必上 full-fledged SDK。

用 context.WithTimeout 控制单次请求上限（建议 ≤5s），避免阻塞主流程
失败时最多重试 2 次，间隔用 time.Sleep 指数退避（如 1s → 2s），不要用 backoff.Retry 这类重型库
记录原始响应体（resp.Body）而非仅状态码，PagerDuty 错误详情（如 "invalid routing_key"）全在 body 里
把 routing_key 和 http.Client 抽成 struct 字段，方便测试 mock

type PagerDutyAlert struct {
    client  *http.Client
    key     string
    timeout time.Duration
}

func (p *PagerDutyAlert) Trigger(ctx context.Context, summary string, details map[string]string) error {
    body := map[string]interface{}{
        "routing_key": p.key,
        "event_action": "trigger",
        "payload": map[string]interface{}{
            "summary": summary,
            "severity": "critical",
            "source": "go-service",
            "custom_details": details,
        },
    }
    // ... marshal + request with ctx and retry logic
}

真正容易被忽略的是 routing_key 的来源管理——它不该硬编码在代码里，也不该从环境变量直读（易泄露），最好通过 secret manager 注入，且每个服务/环境应配独立的 Integration，否则告警混杂、无法精准路由。