keptn是事件驱动的编排引擎而非可观测性采集端，go服务需主动发送sh.keptn.event.problem.opened事件、实现/webhook/action接口响应action.triggered事件，并务必上报action.finished事件以闭环流程。
Keptn不是可观测性采集端，而是事件驱动的编排引擎
Keptn 本身不采集日志、指标或追踪数据，它只消费已有的可观测性信号（比如 Prometheus 告警、Lighthouse 评估结果、自定义 CloudEvent）。你在 Go 微服务里要做的，不是“集成 Keptn SDK”，而是让服务能发标准事件、能响应事件、并把自身状态暴露成 Keptn 可理解的格式。
Go 服务需主动发送 sh.keptn.event.problem.opened 类事件
当你的服务检测到异常（如连续 3 次 db.PingContext 失败、httpRequestsTotal 错误率突增），应构造并发送一个符合 Keptn 规范的 CloudEvent：
- 必须设置
type为sh.keptn.event.problem.opened（Keptn 的问题检测入口事件） -
data.project、data.stage、data.service字段需与你的 Keptn shipyard.yaml 中定义一致 -
data.problem中填入可读描述、错误码、影响范围（例如"impact": "readiness_unavailable"） - 用
cloudevents/sdk-go发送，目标地址是 Keptn API 的/v1/event端点（通常为http://keptn-api:8080/v1/event）
Keptn 执行恢复动作时，Go 服务需提供可调用的 webhook 接口
Keptn 自身不直接操作你的服务进程，它通过触发 sh.keptn.event.action.triggered 事件，再由你部署的 Action Handler（即你自己的 Go HTTP handler）来执行具体恢复逻辑：
- 在 Go 服务中新增一个
/webhook/action路由，只接受 POST，校验Content-Type: application/cloudevents+json - 解析
data.action.name，例如值为restart-cache-client或reconnect-db-pool - 执行对应动作：调用
cacheClient.Reset()、重置连接池、触发配置热加载等 - 成功后返回
200 OK并附带{"result": "success"}；失败则返回422 Unprocessable Entity并说明原因
别忽略 Keptn 的事件链闭环验证成本
Keptn 的自愈流程依赖完整事件链：problem.opened → evaluation.triggered → action.triggered → action.finished。你在 Go 服务里最容易漏掉的是最后一步 —— 主动上报 sh.keptn.event.action.finished。
如果没发这个事件，Keptn 会一直等待超时（默认 10 分钟），后续流程卡死，且无法触发告警升级。你得在 webhook handler 执行完恢复动作后，同步调用 Keptn API 发送 finish 事件，其中 data.status 必须是 ok 或 error，data.message 要包含真实执行耗时与结果摘要。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
