日志大字段 gzip+base64 压缩存储，支持 trace 查询完整内容

[shenenqing]

背景

当前 ConsoleLogRepo 的 LOGGER 在日志序列化后超过 bella.log.max-size-bytes 时，直接移除 request/response 字段。这导致通过 trace ID 在 ES 中查询日志时无法看到完整的请求和响应内容，影响问题排查效率。

FULL_LOGGER 虽然保留完整内容，但默认关闭且为本地文件存储，不被采集到 ES。

诉求

LOGGER 输出的日志保留完整的 request + response 内容，对超过阈值的大字段采用 gzip 压缩 + base64 编码 内嵌存储，替代当前的直接截断策略。查询侧增加解压逻辑，使前端通过 trace ID 能展示完整日志。

具体方案

1. 新增压缩工具类 CompressUtils

   • compress(String) → String：gzip 压缩 + base64 编码
   • decompress(String) → String：base64 解码 + gzip 解压

2. 改造 ConsoleLogRepo.record()

   • 当单字段（request 或 response）序列化后超过配置阈值时，对该字段单独压缩为 base64 字符串
   • 添加 requestCompressed / responseCompressed 布尔标记字段
   • 未超阈值的字段保持原样输出（可读 + 可 ES 全文检索）

3. 新增配置项 bella.log.compress-threshold-bytes（建议默认 10KB）

4. 查询侧解压（前端 BFF 层或 Workflow 层）

   • 检测 *Compressed 标记字段，对压缩内容执行 base64 decode + gunzip 后返回前端

日志 JSON 示例

{
  "requestId": "xxx",
  "bellaTraceId": "yyy",
  "request": "H4sIAAAAAAAAA6tWKkktLlGyUl...",
  "requestCompressed": true,
  "response": { "code": 200, ... },
  "responseCompressed": false
}

预期影响

• 通过 trace ID 查询可获取完整请求/响应内容，提升排障效率
• JSON 文本 gzip 压缩率约 80-90%，base64 后约 73-87%（即 1MB 原文 → ~130-270KB）
• 未超阈值的日志完全不变，向后兼容
• 不影响现有 Filebeat → ES 采集链路（仍为单条 JSON）

证据

• 当前大请求（如长文本 completion）在 ES 中只能看到 [REMOVED: Log size exceeded X bytes]
• ConsoleLogRepo.java 第 28-36 行为现有截断逻辑

相关链接

• api/server/src/main/java/com/ke/bella/openapi/db/log/ConsoleLogRepo.java
• api/sdk/src/main/java/com/ke/bella/openapi/EndpointProcessData.java
• api/server/src/main/java/com/ke/bella/openapi/utils/JacksonUtils.java