Loki比ELK更适合Go微服务日志采集，因其不索引日志内容、仅索引标签，写入快、存储省、查询快；Go服务可直发HTTP POST至Loki，需正确设置labels、Unix纳秒时间戳，并配置Loki的auth_enabled、chunk_age及scrape_configs。
为什么Loki比ELK更适合Go微服务日志采集
因为Loki不索引日志内容，只索引标签（labels），写入快、存储省、查询快——尤其适合Go服务高频输出结构化日志（如logrus或zerolog打标的JSON日志）。ELK的Elasticsearch在小规模微服务里常因内存爆满、JVM GC卡顿、Mapping爆炸而崩，而Loki用Prometheus式TSDB存日志流，单节点撑住几十个Go服务完全没问题。
Go服务怎么把日志直发Loki（不用Filebeat）
别走“文件→Filebeat→Loki”老路，Go进程直接HTTP POST到Loki，延迟更低、链路更短。关键点是：用loki-go客户端或原生http.Client构造/loki/api/v1/push请求，且必须带streams数组和正确labels。
-
labels至少包含{job="my-go-service", instance="10.0.1.23:8080"}，其中job要和Loki配置里的scrape_config匹配 - 每条日志的
timestamp必须是Unix纳秒整数（time.Now().UnixNano()），Loki拒收毫秒或字符串时间 - 推荐用
zerolog+zerolog.NewConsoleWriter()本地调试，但上线时关掉控制台输出，只发Loki - 别把整个
http.Request对象塞进日志字段——Loki不索引正文，但大payload会拖慢HTTP传输，建议只打关键字段如status_code、duration_ms、trace_id
Loki配置里最容易漏掉的三个地方
Go服务能发出去，不代表Loki能收进来。常见失败不是网络不通，而是配置没对齐。
-
auth_enabled: false必须显式设为false（默认是true），否则Loki会返回401 Unauthorized，哪怕你根本没配认证 -
chunk_store_config下的max_chunk_age建议设为1h，不然新日志可能因chunk未flush而查不到（尤其开发环境低流量时） -
scrape_configs里static_configs的targets可留空——Go服务是主动推，不是Loki拉，但job_name必须和客户端发的joblabel一致，否则日志进不了对应stream
查日志时为什么{job="my-go-service"}有数据但{job="my-go-service", level="error"}查不到
因为Loki只索引labels，不索引日志行内字段。level="error"如果是JSON日志正文里的字段（比如{"level":"error","msg":"timeout"}），它不会自动变成label。你得在Go代码里显式提取并加入labels：
立即学习“go语言免费学习笔记（深入）”；
log.With().Str("level", "error").Str("trace_id", tid).Logger().Error().Msg("timeout")
然后发Loki时，把level作为label传进去（不是放entry正文里）。或者用promtail做预处理——但那就绕回ELK式架构了，失去直发意义。
真正轻量的方案，是让Go日志库在写入前就完成label提取，而不是依赖后端解析。这点容易被忽略，结果查半天发现不是Loki慢，是自己没把关键维度打到label里。
