询价异常分组里没有新记录，不足以说明网站没有出错。错误可能已经进入日志，只是藏在外层记录的一段字符串中，没有被提取成分流规则能读取的字段。对于使用日志管道管理询价接口的团队，先确认“规则看见了什么”，比先加一条告警更有用。

AWS于10月14日介绍CloudWatch日志管道的条件路由和串联解析器：路由按处理后的字段判断去向，后面的解析器可以消费前面解析器生成的字段。公告举例，先解析JSON外壳，再对其中提取出的字段使用Grok解析。这是解析与路由之间的具体依赖，并非自动判断业务是否成功。

外层请求与内层业务，可能说的是两件事

外贸网站的日志常经过不止一层系统：接收请求的服务记录一次调用，内部程序再把业务结果写进消息。假设一条外层记录说明接口已正常返回，内层文字却写着附件处理失败，两者并不矛盾。前者描述调用过程，后者描述某个业务步骤。

如果分流规则只读外层状态，就可能把这条记录归到普通请求。反过来，内层文字出现error也未必表示当前询价失败，它可能是被引用的旧错误信息。不能只用全文关键词搜索替代字段解释。

应先确定要监测的对象：是表单接收、附件保存，还是写入业务系统。再找到对应字段、生成它的程序和取值含义。不同来源都叫status，不代表它们共享同一套含义；必要时给提取后的字段加上来源明确的名称。

解析顺序决定后面的规则有没有依据

串联解析器解决的是“先打开哪一层”的问题。如果内层消息仍是字符串，下一步就必须对那个字符串进行合适的解析，而不是对已经处理过的外层重复运行同一种规则。一个步骤成功，也不能代替最后所需字段确实存在。

调整管道时，可保留经过脱敏的代表性样本，分别覆盖正常、业务失败、字段缺失和格式变化。逐步检查：内层消息是否已被提取、解析后字段是文本还是数字、分流条件是否使用了同一个字段名。类型或名称不一致，也可能让看似正确的条件无法命中。

未解析或未匹配的记录也要有明确去处，方便排查。不要为了让告警面板整洁，把无法识别的事件直接当成普通成功。是否单独存放、保留多久和谁能读取，应按资料敏感程度决定；并不需要把完整买家消息复制到所有分组。

销售说“没收到”，运维要能找到同一条记录

日志分得更细以后，还应保留跨步骤可关联的请求标识。否则，接收、附件与业务写入各有记录，却无法确认是不是同一次询价。建立故障时间线时，分流前后的记录都应能回到原来的业务事件。

中国外贸企业不必因为云服务多了一个功能就重建整套日志。若当前格式单一、已有字段足够清楚，简单规则可能更容易维护。只有当嵌套格式和混合来源确实妨碍判断时，分阶段解析才有明确用途。

最后，不要把“错误分组为空”单独放在日报里当健康结论。它最多说明当前观察范围没有匹配记录。还要确认管道持续接收、预期字段确实生成、未匹配事件有人查看，再结合真实询价步骤的结果判断。问题可能发生在业务里，也可能发生在看问题的那条路径上。

参考来源