beego原生监控能力不足，需集成prometheus+grafana或zabbix才能满足生产级告警需求；其admin模块仅提供临时基础指标，不兼容openmetrics标准，须手动挂载/metrics端点并注册自定义指标。
Beego 自带的监控能力有限，直接开箱即用无法满足生产级报警需求；必须集成 Prometheus + Grafana 或对接 Zabbix 才能实现指标采集、可视化与告警闭环。
Beego 内置监控模块只能看基础运行时指标
Beego 的 admin 模块（启用后访问 /beego/admin）可暴露 goroutine 数、memory、cpu、request count 等基础指标，但：
- 数据不持久，刷新即丢失，无法做趋势分析
- 无报警能力，不能配置阈值触发通知
- 端点路径固定为
/metrics，且格式是 Beego 自定义文本，不兼容 Prometheus 的 OpenMetrics 标准 - 默认关闭，需在
app.conf中显式开启：EnableAdmin = true，并确保ListenAddr和ListenPort配置正确
要接入 Prometheus，必须手动注册 client_golang 的指标端点
Beego 不提供原生 Prometheus 支持，得自己在路由中挂载标准 /metrics 接口：
- 引入
github.com/prometheus/client_golang/prometheus和promhttp - 在
main.go初始化后，用beego.Router("/metrics", &controllers.MetricsController{}, "get:Get")绑定控制器 - 控制器中直接返回
promhttp.Handler().ServeHTTP()，而非自行拼接文本 - 避免使用
prometheus.NewRegistry()多次初始化，否则会导致指标重复注册 panic - 自定义指标（如请求耗时直方图）需在应用启动时注册一次，不能每次请求都
NewHistogram
示例片段：
func (c *MetricsController) Get() {
promhttp.Handler().ServeHTTP(c.Ctx.ResponseWriter, c.Ctx.Request)
}
ZbxTable 是更省事的 Beego 报警方案，但依赖 Zabbix 生态
如果你已有 Zabbix，ZbxTable 是专为 Beego 设计的报警聚合前端：
- 后端基于 Beego，前端用 Vue，报警数据由部署在 Zabbix 服务器上的
MS-Agent转发过来 - 无需改 Beego 代码，只要确保 Beego 服务能被 MS-Agent 访问（通常走 HTTP POST）
- 支持报警 Top 10、时间段筛选、XLSX 导出，比纯 Prometheus + Alertmanager 更贴近运维习惯
- 注意
MS-Agent配置中的zbxtable_url必须指向你的 Beego 部署地址，否则报警会丢失
Grafana 告警规则必须配在 Prometheus 侧，Beego 不参与决策
很多人误以为在 Beego 里写个 if 判断就能触发邮件——不是这样：
- Prometheus 负责定时拉取
/metrics，执行alert_rules.yml中的 PromQL 表达式 - 触发后，由 Prometheus 将报警推给
Alertmanager，再由它完成去重、静默、分组和通知（邮件/钉钉/Webhook） - Beego 只是被动暴露指标，不处理任何告警逻辑；若想在 Beego 中响应报警（如自动降级），需另起一个 Webhook 接收端，监听 Alertmanager 的回调
- 常见坑：
scrape_configs中的targets写成127.0.0.1:8080导致容器内 Prometheus 拉不到宿主机 Beego，应改用服务名或 host.docker.internal
真正难的不是加几个 Counter，而是让指标有意义：比如 HTTP 错误率不该只看 status != 200，还得排除健康检查探针；耗时 P95 要按 path 分组，否则 /health 和 /api/order 混在一起完全失真。
