当前位置：首页 > wzjs >正文

广州做营销网站公司站长资源平台

wzjs 2025/8/23 14:08:50

广州做营销网站公司,站长资源平台,网站如何做reference,网络规划设计师下午考点汇总Loki日志排查实战：从ERROR日志丢失到流限制问题的完整解决过程问题背景在我们的微服务架构中，使用了经典的日志收集链路：K8s容器 → Promtail → Loki → Grafana。某天发现了一个奇怪的现象：同一个Pod的ERROR日志中&#xff…

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: timelevel: levelthread: threadclass: classmethod: methodline: linemessage: messagestack_trace: stack_tracetraceId: 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"