go应用可观测性需prometheus与elk协同：前者采集四类核心指标（请求、运行时、业务、健康），后者通过结构化日志与统一标签/时间戳关联分析，再经grafana/kibana打通下钻。
Go 应用要实现可观测性，监控和日志不能割裂——Prometheus 负责指标采集与告警，ELK（Elasticsearch + Logstash + Kibana）专注结构化日志分析，二者通过统一标签、时间戳和上下文关联，才能真正定位问题。
用 Prometheus 监控 Go 服务的核心指标
Go 标准库 expvar 和官方客户端库 prometheus/client_golang 是基础。优先暴露以下四类指标：
-
请求维度：HTTP 请求总数（
http_requests_total）、延迟直方图（http_request_duration_seconds_bucket）、错误率（带status_code标签） -
运行时指标：Goroutine 数量（
go_goroutines）、GC 次数与耗时（go_gc_duration_seconds）、内存分配（go_memstats_alloc_bytes） -
业务自定义指标：如订单创建成功率（
order_create_success_total）、缓存命中率（cache_hit_ratio），用Gauge或Counter暴露，务必加业务标签（service="payment",env="prod"） -
健康探针：/metrics 端点需稳定响应；配合
up{job="my-go-app"}判断实例存活，避免只看 HTTP 状态码
让日志与指标对齐：结构化 + 上下文注入
Go 日志不能只打字符串。用 zerolog 或 logrus 输出 JSON，并强制注入关键字段：
- 每个日志行包含
trace_id、request_id、service、env、level、ts（ISO8601 时间戳） - 在 HTTP 中间件中生成
request_id，透传到下游调用和日志；结合 OpenTelemetry 可自动注入trace_id - 错误日志必须包含堆栈（
err.Error()+debug.Stack()或fmt.Sprintf("%+v", err)），且标记level="error" - 避免在日志里拼接敏感信息（如 token、密码），用占位符 + 结构化字段替代（
"failed to call /api/user: status=%d, user_id=%s"）
ELK 链路：从 Go 日志到可查看板
Logstash 不是必须项——现代部署更倾向用 Filebeat 或 Fluent Bit 收集容器日志，直传 Elasticsearch：
立即学习“go语言免费学习笔记（深入）”；
- Filebeat 配置 focus on
json.keys_under_root: true和json.overwrite_keys: true，确保 Go 输出的 JSON 字段扁平化为 ES 字段 - Elasticsearch 建议开启 ILM（Index Lifecycle Management），按天滚动索引（如
logs-go-app-2024.05.20），避免单索引过大 - Kibana 中用
Discover快速筛选service:"auth-api" AND level:"error"；用Visualize做错误率趋势图，横轴时间、纵轴count() / count(service) - 关键技巧：在 Kibana 中保存常用查询为
Search，再基于它建Dashboard，比如“支付失败根因分析”面板组（含 trace_id 分布、下游调用耗时、DB 错误码 TOP5）
打通 Prometheus 与 ELK：用指标驱动日志下钻
当 Prometheus 告警触发（如 rate(http_requests_total{status_code=~"5.."}[5m]) > 0.01），运维人员需要快速看到对应时段的错误日志：
- 在 Grafana 告警面板中，添加 Link：跳转到 Kibana 的 Discover 页面，预填查询语句
service:"payment" AND timestamp:[now-5m TO now] AND level:"error" - 在 Kibana 中启用 Correlation 功能（7.12+），输入一个
trace_id，自动关联该 trace 下所有服务的日志与指标（需各服务上报trace_id标签到 Prometheus） - 写一个轻量脚本（Go 或 Python），接收 Prometheus webhook 告警，提取 label（如
instance,path），调用 Elasticsearch API 拉取最近 100 条匹配日志，发到内部群
不复杂但容易忽略：时间同步（所有节点 NTP 对齐）、标签一致性（service 名在 Prometheus 和日志中完全一致）、以及把 /metrics 和 /healthz 端点纳入 SLI 计算——这才是生产级可观测性的起点。
