＜六＞ k8s + promtail + loki + grafana初探-EW帮帮网

Loki日志排查实战：从ERROR日志丢失到流限制问题的完整解决过程

问题背景

在我们的微服务架构中，使用了经典的日志收集链路：K8s容器 → Promtail → Loki → Grafana。某天发现了一个奇怪的现象：同一个Pod的ERROR日志中，只有特定类的日志能在Grafana中查到，其他类的ERROR日志都"消失"了。

具体表现为：

org.apache.catalina.core.ContainerBase.[Tomcat].[localhost].[/].[dispatcherServlet] 的ERROR日志能查到
org.pjlab.xscholar.service.impl.RecommendationAPIServiceImpl 的ERROR日志查不到

排查过程

第一步：确认原始日志输出

首先通过 kubectl logs 确认原始日志确实都正常输出了：

kubectl logs <pod-name> -n <namespace> | grep ERROR

发现两条ERROR日志都正常打印到了控制台，说明问题不在应用层面。

第二步：检查日志配置

检查了 logback-spring.xml 配置，发现了一个潜在问题：

<!-- test,daily环境的配置 -->
<filter class="ch.qos.logback.classic.filter.ThresholdFilter">
    <level>INFO</level>
</filter>

这个过滤器可能影响ERROR日志的输出。但进一步分析发现，ERROR级别应该能通过INFO过滤器。

第三步：统一日志格式

发现不同环境使用了不同的日志格式：

dev,prod 环境：JSON格式
test,daily 环境：普通文本格式

这种不一致可能导致Promtail解析失败。于是统一改为JSON格式：

<encoder charset="UTF-8" class="net.logstash.logback.encoder.LoggingEventCompositeJsonEncoder">
    <providers>
        <pattern>
            <pattern>
                {
                "appName": "${appName}",
                "time": "%date{yyyy-MM-dd HH:mm:ss.SSS}",
                "level": "%level",
                "pid": "${PID:-}",
                "thread": "%thread",
                "class": "%logger",
                "method": "%method",
                "line": "%line",
                "message": "%message",
                "stack_trace": "%xEx{2000}",
                "traceId": "%X{TRACE_ID}"
                }
            </pattern>
        </pattern>
    </providers>
</encoder>

第四步：检查Promtail配置

检查Promtail配置时发现了一个关键问题：

pipeline_stages:
  - match:
      selector: '{log_format="multiline"}'
      stages:
        # JSON解析逻辑
        - labels:  # 将解析出的字段作为标签推送
            time: "time"
            level: "level"
            thread: "thread"
            class: "class"
            method: "method"
            line: "line"
            traceId: "traceId"
            message: "message"
            stack_trace: "stack_trace"

问题所在：将太多字段设置为标签，导致Loki流数量激增。

第五步：发现真正的错误

在Loki的日志中发现了关键错误信息：

level=warn ts=2025-06-25T09:56:52.558387834Z caller=grpc_logging.go:43 
err="rpc error: code = Code(429) desc = Maximum active stream limit exceeded, 
reduce the number of active streams (reduce labels or reduce label values), 
or contact your Loki administrator to see if the limit can be increased"

Loki流机制详解

什么是Loki流（Stream）？

Loki中的**流（Stream）**是日志存储的基本单位。每个流由一组标签（labels）唯一标识，包含时间序列的日志条目。

流的创建规则

Loki会为每个唯一的标签组合创建一个新的流。例如：

# 原始配置 - 每个不同的class都会创建新流
labels:
  level: "ERROR"
  class: "org.pjlab.xscholar.service.impl.RecommendationAPIServiceImpl"
  method: "getArticleDetail"
  line: "177"
  thread: "http-nio-10019-exec-10"
  traceId: "1e224f52bcaf"

如果有100个不同的类，每个类有10个不同的方法，每个方法有20个不同的行号，每个线程有50个不同的traceId，那么理论上可能创建：

100 × 10 × 20 × 50 = 1,000,000 个流

流限制的影响

当流的数量超过Loki的限制时：

新的流无法创建
相关日志被丢弃
返回429错误

这就是为什么某些ERROR日志"消失"的原因。

为什么INFO日志没有被屏蔽？

INFO日志通常来自固定的几个类（如Spring框架类），流的数量相对稳定。而ERROR日志来自各种业务类，每个不同的类都会创建新的流，导致流数量急剧增加。

解决方案

方案一：减少标签数量（推荐）

只保留最重要的标签，其他字段作为日志内容：

pipeline_stages:
  - match:
      selector: '{log_format="multiline"}'
      stages:
        - json:
            expressions:
              log: log
        - regex:
            expression: "(?P<parsed_log>\\{.*\\})"
            source: log
        - json:
            source: parsed_log 
            expressions:
              time: time
              level: level
              thread: thread
              class: class
              method: method
              line: line
              message: message
              stack_trace: stack_trace
              traceId: traceId
        - labels:  # 只保留最重要的标签
            level: "level"
            class: "class"

方案二：只保留level标签（激进优化）

如果流数量仍然过多，可以只保留level标签：

- labels:  # 只保留level标签，最小化流数量
    level: "level"

方案三：增加Loki流限制

如果业务需要更多标签，可以增加Loki的配置：

limits_config:
  max_streams_per_user: 1000000  # 增加流限制
  max_global_streams_per_user: 1000000

最佳实践

1. 标签设计原则

高基数字段不要作为标签：如traceId、thread、line等
低基数字段适合作为标签：如level、namespace、app等
查询频率高的字段适合作为标签：如level、class等

2. 监控流数量

定期监控Loki的流数量：

# 查看当前流数量
curl -s http://loki:3100/loki/api/v1/labels | jq '.data[]' | wc -l

3. 日志查询优化

使用优化后的配置，查询方式：

# 查询ERROR日志
{app="xscholar-be", level="ERROR"}

# 查询特定类的ERROR日志
{app="xscholar-be", level="ERROR"} |= "RecommendationAPIServiceImpl"

# 使用JSON解析查询详细信息
{app="xscholar-be", level="ERROR"} | json | class="org.pjlab.xscholar.service.impl.RecommendationAPIServiceImpl"

经验总结

1. 问题定位思路

从源头开始排查：确认应用日志输出正常
检查中间环节：验证日志格式和配置
查看错误日志：Loki/Promtail的错误日志往往包含关键信息
理解底层机制：了解Loki的流机制是解决问题的关键

2. 常见误区

认为日志长度是问题：实际上流数量才是关键
过度使用标签：每个标签都可能成倍增加流数量
忽略错误日志：429错误明确指出了问题所在

3. 预防措施

设计阶段就考虑标签策略
定期监控流数量
建立日志配置审查流程
为不同环境制定不同的标签策略

结论

这次排查过程很好地展示了分布式系统中日志收集的复杂性。问题的根本原因是对Loki流机制理解不够深入，过度使用标签导致流数量超限。

通过减少标签数量，我们成功解决了ERROR日志丢失的问题，同时也优化了整体的日志收集性能。这个经验提醒我们，在设计和配置日志系统时，必须深入理解底层机制，合理设计标签策略。

关键词：Loki、Promtail、日志收集、流限制、标签设计、微服务监控

＜六＞ k8s + promtail + loki + grafana初探