loki本身不支持千万级日志全文检索，仅通过标签索引+原始行存储实现高效查询；千万级聚合依赖合理打标、精准logql查询及grafana过滤能力，而非全量扫描。
直接上结论：Loki 本身不支持千万级日志“检索”，它只做标签索引 + 原始行存储；所谓“千万级聚合”靠的是合理打标、精准查询、配合 Grafana 的 LogQL 过滤能力，而不是靠全文扫描。Golang 后端要撑住这个量级，关键不在 Loki 配置，而在 Go 日志输出结构、采集链路设计和 label 划分策略。
zap 输出必须带顶层 service_name 和 trace_id 字段
Loki 不解析 JSON 内容，只提取 top-level 字段作为 label。如果 zap 把 service_name 嵌套在 fields 里（比如用 zap.Object("fields", ...)），Loki 就收不到这个 label，查 {service="order-svc"} 会永远为空。
- 初始化 logger 时用
zap.Fields(zap.String("service_name", "order-svc"), zap.String("env", os.Getenv("ENV")))，不是With()——With()是动态子 logger，Fields()才是全局静态字段 - HTTP 中间件中注入
trace_id必须用logger.With(zap.String("trace_id", tid)).With(zap.String("path", r.URL.Path))，且确保该子 logger 被复用到整个请求生命周期，别在 handler 里反复With() - 禁止调用
zap.String("error", err.Error())替代zap.Error(err)—— 后者会自动展开堆栈为err.stack字段，Grafana Explore 才能点开 - 时间戳必须是
time.Time类型传给zap.Time("timestamp", time.Now())，不能转成字符串，否则 Loki 解析精度丢失（__line__会丢毫秒）
Fluent Bit 必须显式提取 trace_id 并提升为 tag
默认配置下 Fluent Bit 把整条 JSON 当作一个字符串字段，trace_id 不会变成 Loki 的 label，{trace_id="xxx"} 查询完全无效。
- INPUT 段加
Parser json，并确保Path指向容器 stdout 日志路径（K8s 下通常是/var/log/containers/*_order-svc-*.log） - PARSER 定义里必须含
Time_Key timestamp和Time_Format %Y-%m-%dT%H:%M:%S.%LZ，否则时间解析失败整条日志被丢弃 - FILTER 段用
Modify插件把字段提级：Rule key_exists trace_id trace_id true—— 这句才是让trace_id变成 Loki label 的关键 - OUTPUT 到 Loki 时，
Label_Key设为service_name,env,trace_id，不要漏掉job（通常设为container）
LogQL 查询千万级日志的实操约束
LogQL 不是 SQL，它先靠 label 缩小范围，再对剩余日志行做流式过滤。查慢、超时、OOM，90% 是因为没压准 label 组合。
- 单次查询必须带至少两个 label，比如
{service_name="order-svc", env="prod"}—— 单{service_name="order-svc"}在千万级下基本不可用 - 避免用
|~ "timeout"全量正则扫描；优先用| json | line_format "{{.status}} {{.path}}"提取字段后再过滤 - 查 trace_id 时，必须确认该 ID 确实打到了所有服务的日志里 —— 常见坑是下游 gRPC 调用没透传 header，导致部分日志缺
trace_id字段，查出来断链 - 高频错误聚合用
count_over_time(...[1h])，别用count(...) by (level)直接扫全量 —— 前者是预聚合，后者是实时扫描
otelcol 接入 Loki 时 endpoint 路径不能少 /loki/api/v1/push
OpenTelemetry Collector 默认不转发日志到 Loki，即使 exporter 配了地址，漏掉路径也会返回 404，且错误日志不明显（只报 “failed to export logs”）。
-
exporters.loki.endpoint必须完整写成http://loki:3100/loki/api/v1/push，少任何一段都失败 - receiver.otlp 下必须显式开启
protocols: { grpc: {} }，Go 客户端默认走 gRPC，但 otelcol 不开就收不到 - 如果用
attributes_trace_id字段（otelcol 默认扁平化），LogQL 得写成{service_name="order-svc"} | json | trace_id == "xxx"，不能直接用{trace_id="xxx"} - 注意 otelcol 版本 —— v0.105.0+ 才默认支持 log record 的
severity_text映射为 Loki 的level标签，旧版本得手动 pipeline 转换
最容易被忽略的点：Loki 的 label cardinality。service_name、env、trace_id 这三个字段组合起来，如果 trace_id 是 UUIDv4，那每条日志 label 都不同，Loki 的 series 数会爆炸，内存和磁盘压力远超预期。真实场景中，trace_id 只应在 debug 或问题定位时启用，常态下应按 path + status + level 分组聚合，而不是默认打满所有字段。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
