fix: optimize stdout

[StartE]

fix: 修复容器标准输出 Docker JSON 拆片丢失与 JSON 多行模式失效问题

背景

修复新版标准输出采集中 Docker JSON 场景的两个核心缺陷：

1. Docker 16KB 拆片无法合并（2026.04.15 截断问题）：ParseDockerJsonLogLine 未检测 log 字段末尾是否有 \n，导致拆片中间段没有 Part 标记，MergeByFlag 不生效
2. JSON 多行模式完全不可用（2025.12 多行 JSON 解析失败）：InputContainerStdio 在 JSON 多行场景错误地设置 RequiringJsonReader=true，导致 JsonLogFileReader 在容器格式剥离前提前做 {} 配对，破坏了 docker/containerd 的 runtime 解析

改动

1. Docker 拆片识别与 Part 标记（Step 1）

ProcessorParseContainerLogNative.cpp:

• ParseDockerJsonLogLine 新增拆片检测逻辑：log 解码后不以 \n 结尾 → 标记为 Partial（设置 PartLogFlag + HAS_PART_LOG）
• 以 \n 结尾 → Full line，去掉末尾 \n 后正常输出
• 复用现有 MergeType=flag 合并路径，与 containerd P/F 行为统一

2. JSON 多行从 Reader 层下沉到 Processor 层（Step 2）

InputContainerStdio.cpp:

• 移除 mContext->SetRequiringJsonReaderFlag(true)，确保容器 stdio 始终使用普通 LogFileReader
• JSON 多行模式改为创建 ProcessorMergeMultilineLogNative(MergeType=json)，而非 ProcessorSplitLogStringNative(SplitChar='\0')

ProcessorMergeMultilineLogNative.cpp/h:

• 新增 MergeType::BY_JSON 枚举和 MergeLogsByJson() 方法
• 基于 brace depth 状态机实现 JSON 块识别与合并（正确处理引号内 {}、转义引号 \"）
• 超限保护：累积大小超过 maxSize（默认 BUFFER_SIZE）时强制输出并告警
• 批次末尾未闭合 JSON 块不丢弃，合并后输出

架构

修复后的 inner processor 链路：

Split(\n) → Parse(docker/containerd) → MergeByFlag(拆片还原) → [可选] MergeByJson / MergeByRegex(业务多行)

关键设计原则：

• 先还原物理拆片，再做业务多行：保证 docker 16KB 拆片和 containerd P/F 在业务多行之前完成合并
• JSON 块识别在 processor 层完成：不再依赖 reader 层的 JsonLogFileReader，避免在容器格式剥离前破坏物理行边界

线下测试报告

https://alidocs.dingtalk.com/i/nodes/QG53mjyd800agdlKHwY7ePYe86zbX04v

后续 Step

项目	状态	说明
stdout/stderr 流隔离	待实现	MergeByFlag 按 _source_ 分桶合并，防止跨流拼接
Reader 回退优化（单行，Step 3）	待实现	StdioFileReader 基于 docker log 字段末尾 \n 做稳定切分点
Reader 回退优化（多行，Step 4）	待实现	正序扫描 {}/转义正则匹配回退
跨 read buffer / 跨 flush 拆片合并	已知风险	当前 MergeByFlag 仅在同一 PipelineEventGroup 内合并

[Takuka0311]

containerd有测试512K的例子吗？

[StartE]

containerd有测试512K的例子吗？

docker/contianerd的单行cri标准输出都是16k就截断，报告中有截断的测试；

接下来补充的是，是处理当多行场景，例如多行json时，超出块max read max size 512k的时候，合并及丢弃场景