站管家日志优化：生产上线核验与前后对比

1. 结论

1. VIN 图片和 AES 成功响应日志优化已在生产生效；请求、返回、重试和业务处理未改动。
2. 上线前后同一 15 分钟窗口对比：VIN 图片日志字符量下降 99.96%，AES 响应日志字符量下降 98.42%。
3. 生产仍有独立的下游超时日志，主要集中在 AES 调用；当前没有证据表明超时由本次日志格式改造引起。
4. 商品报价搜索响应摘要（9451433c6b）尚未在生产生效，不能计入本次收益；下一步优先治理 VinAudit 服务端成功整包日志。

2. 本轮已完成

Robot/AI 的入口去重、对象摘要和商品结果截断属于 9/4 之前的既有基线，本轮不重复计算。

3. 同时间窗口效果

统计窗口：上线前生产 logstash-2026-09-08、上线后生产 logstash-2026-09-10，均为 10:00–10:15；统计字段为 message.length()，单位是字符；两次查询均为 8/8 分片成功。

说明：全部日志和 AES 请求量同时受业务流量影响，不能单独作为改造收益；VIN 日志和 AES 响应日志的字符量对比才是本次改造的直接结果。已加密 命中数用于确认新格式已生效，不作为流量对比指标。

4. 改造前后日志样例

4.1 VIN 图片识别

优化前：

[默认]调用接口#...# {"url":".../ext/v2/vin","data":{"imgData":"<Base64 图片>"}}

优化后：

VIN图片识别结果 {"image_data_bytes":...,"code":...,"message":...,"vin":...,"retry_code":...}

业务请求和识别结果不变，只移除公共日志中的图片内容。

4.2 AES 响应

优化前：

接口返回#请求ID#: ["{\"code\":200,\"data\":\"<完整密文>\"}"]

优化后：

接口返回#请求ID#: ["{\"code\":200,\"data\":\"已加密\"}"]

优化后样本单条约 153 字符；AES 失败、解密、密钥接口及业务返回值保持原逻辑。

5. 当前高量日志与治理计划

统计窗口为 9/9 10:00–10:15，当前总量约 5,037.3M 字符。前三类合计约 2,724.6M 字符，是后续主要优化对象。

5.1 VinAudit 四个核心接口量级

统计窗口：生产 logstash-2026-09-09 10:00–10:15；字符量按 message.length() 计算。8 个分片均查询成功。

条数是“进入 Kibana 的日志数”，不是业务请求数。同一次调用可在 DGJ/Sale 调用端和 VinAudit 服务端重复记录。“1 小时”仅为按当前 15 分钟流量线性折算，不代表全天实际值。

按系统拆分后，四个接口的日志占用如下：

5.2 原来的真实日志长什么样

下列结构来自同一生产窗口的真实日志。RequestId、VIN、IP、签名和服务站值已脱敏；数组在文档中用“N项”缩写，原日志中是完整展开的。

VinAudit 服务端的原始格式是：

.request.api.INFO: {
  "requestId":"[已脱敏]",
  "request":{"ip":"[已脱敏]","url":".../product/search?","header":{"sign":"[已脱敏]",...},"data":{...}},
  "response":{"code":0,"message":"请求成功","data":{...}},
  "costTime":292
}

DGJ 会把同一次调用再记两条：

RequestId#[已脱敏]# [默认]调用接口#[调用ID]# {"url":".../product/getAttributes","headers":{...},"data":{"sku_id":"1601000592",...}}
RequestId#[已脱敏]# 接口返回#[调用ID]#: ["{\"code\":0,\"message\":\"请求成功\",\"data\":{\"attributes\":[...],\"images\":[...],\"car\":[...]}}"]

Sale 会合并记一条：

provider.INFO: http_client {"time":0.277,"request_id":"[已脱敏]","url":".../product/search","method":"POST","config":"{完整请求}","responseBody":"{完整响应}"}

四个接口的真实样例摘要：

5.3 建议如何优化

不建议直接删除请求结果，而是将“正常全量整包”改为“正常摘要 + 异常脱敏证据”。

统一保留原则：

• HTTP 超时、非 2xx、业务 code != 0、JSON 解析失败：保留脱敏后的请求和响应。
• 正常但超过耗时或响应大小阈值：记录 warning，保留摘要和大小，必要时开启指定 RequestId 的临时详细采集。
• sign、Authorization、完整 User-Agent、完整 IP 不进入正常摘要日志。
• 只改日志输出的副本；实际请求参数、响应对象、超时、重试和业务解析逻辑保持不变。

5.4 落地顺序

1. VinAudit 服务端：先将 api/request 的正常成功日志改为四接口摘要，这一层占四接口字符量 93.0%。
2. DGJ Provider：在 VinAudit Provider 内按 URL 摘要请求/响应，不全局修改所有 Provider。
3. Sale Provider：针对 VinAudit http_client 做专用格式化，不直接改共享 vendor 的全局日志行为。
4. 验收：预发验证正常、空结果、超时、业务异常和 JSON 异常，上线后用同一 15 分钟窗口对比总字符、平均/最大单条及 RequestId 串联能力。

6. 2026-09-10 生产上线核验

核验窗口：生产 logstash-2026-09-10，10:00–10:15；8/8 分片成功。

同期异常观察

上线前后同一窗口的精确异常关键词对比：

cURL error 28 定位

default 超时均在约 5 秒触发。9/9 有 101 条、9/10 有 338 条提示未收到响应体；另有 35/37 条已返回预计超过 1 MB 的响应长度。该现象指向 AES 下游超时或大响应处理，和本次“成功响应只记录 已加密”的日志改造无关；超时分支仍按原逻辑记录并抛出异常，需单独治理 AES 下游耗时和响应大小。

生产样例（已脱敏）

VIN 新日志：

[时间][INFO][devcenter] RequestId#[请求ID]# VIN图片识别结果
{"image_data_bytes":1086282,"code":0,"message":"[识别服务消息]","vin":"[VIN]","retry_code":-1}

AES 新日志：

[时间][INFO][default] RequestId#[请求ID]# 接口返回#[调用ID]#:
["{\"code\":200,\"data\":\"已加密\"}"]

日志中不再出现图片 Base64 或 AES 完整密文；请求 ID、返回码、VIN 识别结果和异常码仍可用于串联排查。

7. 2026-09-10 商品报价搜索日志上线核验

核验截至 20:26，目标提交为 9451433c6b。生产 OfferProvider 日志仍为完整 data.rows，没有出现摘要字段 rowsCount。

9/10 同一时段比 9/9 字符量增加 26.9%，主要是请求量增加 26.8%，没有观察到日志压缩收益。6 个 DGJ 节点均仍能看到完整商品响应。

生产 Prod-DGJ-1 的 /data/www/dist/application/Providers/SaleService/OfferProvider.php SHA-256 为 277ae1a3961321369c1110e1151c2930d25192a952488f9cd89682f408481933，与当前 develop 一致；目标提交文件 SHA-256 为 a207754f270b80d72ceefe9a3835e01c1fcb80793dbb13214cbf6df98fa272ce，两者不一致。说明目标代码尚未加载到该生产节点，需确认发布分支是否包含 9451433c6b 后再重新核验。

本窗口未发现由该改动引起的新增异常：PHP Fatal 来自报表大查询，Uncaught 来自定时任务；未命中 ProviderErrorException、RequestTimeoutException。本次未修改生产代码或配置。

8. 验收标准

每次发布后使用相同 15 分钟窗口核对：总字符量、条数、平均/最大单条、RequestId 串联能力、成功/异常样例和业务返回值。日志压缩只改变日志展示，不改变请求参数、响应变量和业务结果。

证据来源：Kibana logstash-2026-09-08、logstash-2026-09-09、logstash-2026-09-10；10:00–10:15 及异常观察窗口查询；代码提交 39f00f72ea、cd27b0d5bb。生产查询 8/8 分片成功，未修改生产数据或服务配置。