Go应用接入ELK并实现可查、可看、可告警的关键在于：必须输出JSON格式结构化日志，Filebeat需配置json.keys_under_root:true启用解析，Logstash补充service_name等运维字段，Elasticsearch须预定义索引模板声明字段类型。
Go 应用要真正把日志送进 ELK 并能查、能看、能告警，关键不在“能不能连上 Elasticsearch”，而在于日志从 Go 进程里出来那一刻是否结构清晰、字段可控、格式稳定——否则 Filebeat 读到的只是一堆无法解析的字符串，Logstash 再强也救不回来。
Go 必须输出 JSON 格式结构化日志
标准库 log 输出的是纯文本，带前缀（如2026/06/02 02:55:12 main.go:15: info message），Filebeat 默认无法提取 level、service_name 等字段。必须切换到支持结构化输出的库：
-
zap（推荐）：性能最高，zap.NewProduction()默认输出合法 JSON，含ts、level、msg和自定义字段 -
logrus：需显式调用logrus.SetFormatter(&logrus.JSONFormatter{}) -
zerolog：默认 JSON，但要注意zerolog.ConsoleWriter是为终端设计的，生产环境应禁用或仅用于调试
错误示例：log.Printf("user_id=%s, status=%d", uid, status) → 日志是字符串拼接，无固定 schema，ELK 里只能当全文检索用，无法按 status: 500 聚合。
Filebeat 配置必须开启 json 解析
Filebeat 读取日志文件时，默认把整行当字符串塞进 message 字段。要让 JSON 字段“浮上来”，必须在 filebeat.yml 中启用解析：
立即学习“go语言免费学习笔记（深入）”；
- 设置
json.keys_under_root: true：把 JSON 的 key 提升到根层级（否则全在message下嵌套） - 设置
json.overwrite_keys: true：避免与 Filebeat 自带字段（如host.name）冲突 - 确保
input.type: filestream（Filebeat 7.16+ 推荐），并指定paths: ["/var/log/go-zero/*.log"]
漏掉 keys_under_root 的后果：Kibana 里看到的全是 message: {"level":"info","path":"/api/user"}，你没法对 path 做筛选或可视化。
Logstash filter 要补全缺失上下文字段
Go 应用日志里通常没有 service_name、environment、host.ip 这类运维维度字段，但 ELK 分析时又离不开它们。这些不能靠 Go 每次都手动打，得由 Logstash 补充：
- 用
filter { mutate { add_field => { "service_name" => "order-api" } } }统一打标 - 用
filter { dns { resolve => ["host.name"] } }或geoip插件丰富来源信息 - 如果 Go 日志里没
trace_id，但需要链路追踪，Logstash 可用uuid插件生成临时 ID（仅作兜底）
跳过这步的典型问题：多个服务日志混在同一个 log-* 索引里，却无法在 Kibana 里按服务名拆分图表——因为 service_name 字段根本不存在。
Elasticsearch 索引模板必须预定义字段类型
JSON 日志里的 duration 如果是数字，但 ES 映射成 text，你就没法做 avg(duration) 聚合；timestamp 如果没映射为 date，Kibana 时间范围筛选就失效。必须提前建好索引模板：
- 模板匹配
log-*索引名 - 明确声明
"duration": { "type": "long" }、"@timestamp": { "type": "date" } - 对高频查询字段（如
service_name、level）设为keyword类型，而非text
没模板就直接写入的后果：ES 自动 mapping 会把第一次出现的 "level": "info" 当成 text，后续想改类型只能重建索引——线上日志停写数小时。
