beego服务必须手动暴露/metrics端点才能被grafana采集；其admin模块不兼容openmetrics，需用promhttp.handler()显式挂载并注册自定义指标，经prometheus抓取后供grafana可视化。
Beego 服务必须手动暴露 /metrics 端点才能被 Grafana 采集
Beego 自带的 admin 模块（如 /admin/monitor）只提供基础运行时信息，不输出 OpenMetrics 格式，Prometheus 抓取会失败。Grafana 本身不直接拉取指标，它依赖 Prometheus 或其他数据源；所以第一步不是连 Grafana，而是让 Beego 输出 Prometheus 能识别的指标。
你需要在启动时显式挂载一个符合规范的 /metrics 路由，并注册自定义指标（如请求计数、响应延迟）。官方未内置 Prometheus 中间件，得自己用 promhttp.Handler() 或轻量库（如 github.com/prometheus/client_golang/prometheus/promhttp）接入。
- 不要依赖
beego.BConfig.Listen.EnableAdmin，它和 Prometheus 无关 - 避免把指标逻辑写在控制器里——应统一在中间件或初始化阶段注册
- 若用 Beego v2.x，
app.Use()可插入 Prometheus 中间件；v1.x 需改写Router或用InsertFilter
Beego + Prometheus + Grafana 的最小可行链路
这不是三者直连，而是一条明确的数据流向：Beego → /metrics → Prometheus scrape → Grafana dashboard。中间缺一不可。
常见错误是跳过 Prometheus，试图让 Grafana 直接调 Beego 的某个接口——这行不通，因为 Grafana 不解析 Beego 的 admin JSON，也不支持 pull-based 自定义 HTTP 接口（除非你写插件）。
- Prometheus 配置中
scrape_configs的targets必须指向 Beego 实例的/metrics地址（如http://beego-svc:8080/metrics） - Grafana 数据源必须选
Prometheus类型，并填对 Prometheus 的 API 地址（通常是http://prometheus-svc:9090） - Beego 进程需监听在 Prometheus 可达的网络（K8s 中注意 Service 和 NetworkPolicy）
Beego 中注册 HTTP 请求指标的典型写法
用 prometheus/client_golang 注册 counter 和 histogram 是最常用做法。别直接用 promhttp.Handler() 暴露全部 Go 运行时指标——那会包含大量无业务意义的内存/协程数据，干扰排查。
import (
"github.com/prometheus/client_golang/prometheus"
"github.com/prometheus/client_golang/prometheus/promhttp"
)
var (
httpRequestCounter = prometheus.NewCounterVec(
prometheus.CounterOpts{
Name: "http_requests_total",
Help: "Total HTTP Requests",
},
[]string{"method", "path", "status"},
)
httpLatencyHistogram = prometheus.NewHistogramVec(
prometheus.HistogramOpts{
Name: "http_request_duration_seconds",
Help: "HTTP request duration in seconds",
Buckets: prometheus.DefBuckets,
},
[]string{"method", "path"},
)
)
func init() {
prometheus.MustRegister(httpRequestCounter)
prometheus.MustRegister(httpLatencyHistogram)
}
然后在 Beego 的全局 filter（如 BeforeRouter）中记录请求开始时间，在 FinishRouter 中打点并观察延迟。路径要 normalize（如 /user/:id 统一为 /user/{id}），否则 label 爆炸。
Beego 指标在 Grafana 中容易被忽略的细节
很多团队搭完链路后发现 dashboard 里没数据，问题往往不在 Beego 本身，而在指标生命周期管理上：
- Beego 进程重启后，counter 类指标（如请求数）会重置——Grafana 的
rate()函数依赖历史数据，若 Prometheus 抓取间隔太长或实例频繁重建，rate(http_requests_total[5m])会返回空 - Beego 默认不记录状态码细分（如 401/403/429），若没在 filter 里显式提取
context.Output.Status并打点，statuslabel 就只有200或空 - 如果你用 Beego 的
logs模块做访问日志，别指望它自动转成 Prometheus 指标——日志和指标是两套体系，混用会导致高 cardinality 和查询变慢
真正卡住的从来不是“怎么连上”，而是“指标是否稳定、label 是否合理、Prometheus 是否持续抓到有效样本”。
