Higress项目中Envoy日志user-agent字段嵌套JSON的解析问题解决方案

问题背景

在Higress项目中，当使用Envoy作为数据平面时，access日志中的user-agent字段可能会包含嵌套的JSON数据。这种情况在实际生产环境中并不少见，特别是当移动端应用在User-Agent字符串中附加了额外的设备信息时。

问题现象

当accessLogFormat配置中包含"user_agent":"%REQ(USER-AGENT)%"时，如果User-Agent字符串本身包含JSON格式的数据，例如：

Mozilla/5.0 (iPhone; CPU iPhone OS 18_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) ###{"version":"7.0.0.0","platform":"iOS","os":"18.2","loc":"--","uuid":"750E8975-4CBA-486E-A5DB-F32E109A"}

会导致日志解析失败，出现LogParseFailure错误。这是因为默认的TEXT格式日志输出无法正确处理嵌套的JSON结构。

解决方案

方法一：修改日志编码格式

最直接的解决方案是将Higress配置中的accessLogEncoding从默认的TEXT改为JSON格式：

1. 编辑higress-config这个ConfigMap：

kubectl edit cm higress-config -n higress-system

2. 找到accessLogEncoding字段，将其值修改为JSON：

accessLogEncoding: JSON

这种修改会使得整个access日志以JSON格式输出，从而能够正确处理User-Agent字段中的嵌套JSON数据。

方法二：自定义日志格式

如果出于性能考虑不希望全部日志都使用JSON格式，也可以考虑自定义日志格式，对User-Agent字段进行特殊处理：

1. 在accessLogFormat中，可以为User-Agent字段添加转义处理
2. 或者将User-Agent中的JSON部分提取为单独的字段

性能考量

需要注意的是，使用JSON格式的access日志相比TEXT格式会有一定的性能开销：

1. JSON格式需要更多的序列化/反序列化操作
2. JSON日志通常会比纯文本日志占用更多存储空间
3. 日志收集和分析系统处理JSON日志可能需要更多资源

在生产环境中，如果日志量很大，需要权衡可读性和性能之间的关系。对于大多数场景，JSON格式带来的便利性通常值得付出这点性能代价。

最佳实践建议

1. 对于大多数生产环境，推荐使用JSON格式的access日志
2. 如果确实需要优化性能，可以考虑：
   • 只对包含特殊字符的字段进行JSON转义
   • 在日志收集端进行预处理
   • 使用采样日志而不是全量日志
3. 监控日志系统的性能指标，确保日志处理不会成为系统瓶颈

总结

Higress项目中Envoy日志的User-Agent字段嵌套JSON问题是一个典型的日志格式化挑战。通过将日志编码格式改为JSON，可以优雅地解决这个问题，同时保持日志的可读性和可解析性。虽然JSON格式会带来轻微的性能开销，但在大多数场景下，这种代价是可以接受的。