CLS HTTP 错误率统计：用十条日志验证分母与查询口径

结论：先固定分母，再统计错误

在腾讯云日志服务 CLS 中分析 HTTP 错误率，最容易出错的不是 SQL 拼写，而是查询范围。若先在检索条件里只保留 5xx，再把 SQL 中的总行数当成全部请求数，得到的就不是业务错误率。

本文给出一套可复核的最小流程：明确一条日志代表什么，固定日志主题与时间范围，按状态码统计，再计算错误数占比。示例采用演示数据，不代表任何线上环境的实测结果。

一、先约定日志口径

假设应用入口输出结构化访问日志，每个已完成请求恰好对应一条记录，至少包含以下字段：

{"service":"checkout","request_id":"demo-001","status":200}

这里的 status 是入口最终返回给客户端的 HTTP 状态码，不是内部某一次重试的结果；service 用于区分业务服务；request_id 用于抽查请求链路。

必须先检查三个条件：

• 不把入口日志与上游调用日志混在同一个统计口径里，否则一次请求可能被数多次。
• 不把成功请求采样、错误请求全量采集后的行数直接当成请求错误率。
• 明确“错误”的定义。本文只统计 500 至 599；4xx 是否属于业务失败，要另行约定。

即便 SQL 正确，重复采集、日志丢失和采样也会使结果偏离真实请求量。日志错误率适合排障；是否能作为服务等级指标，还要看采集完整性。

二、准备字段索引和统计能力

进入目标 CLS 日志主题的索引配置，检查 service 和 status 的键值索引及统计配置。本文建议 service 使用文本类型、status 使用数值类型；以实际采集后的字段结构为准，不要只检查应用代码里的定义。

腾讯云官方《语法规则》说明，参与统计分析的相关字段需要配置键值索引并开启统计。不能因为原始日志界面能看见字段，就认定 SQL 一定能使用它。

若配置刚调整，建议写入一批新的演示日志验证；不要默认修改索引后历史数据立即具备同样的分析能力。此处不需要改动生产日志保留策略。

三、用十条日志建立可手算的基线

在隔离的演示主题里，按已有采集链路写入十条访问日志，全部使用 service=checkout，request_id 分别为 demo-001 至 demo-010。状态码按下面的清单安排：

• 200：七条。
• 404：一条。
• 500：一条。
• 502：一条。

选择覆盖这批数据的固定起止时间。先查看原始日志，确认十个请求标识都存在且没有重复。不要用不断向前滚动的“最近几分钟”反复对比查询，否则两次查询可能覆盖不同数据。

本文定义下，预期总请求数为 10，5xx 数量为 2，错误率应为 20%。这是演示数据的计算预期，不是已经在读者账号中执行的结果。

四、先跑分布，再算比率

CLS 查询由检索条件与管道后的 SQL 组成。先只限定服务，不过滤状态码：

service:"checkout"
| SELECT status, count(*) AS request_count
  GROUP BY status
  ORDER BY request_count DESC
  LIMIT 20

在这批演示数据里，应该出现 200、404、500、502 四组，计数分别为 7、1、1、1。排序中计数相同的组，彼此先后不作为验收条件。

然后独立查询总行数：

service:"checkout"
| SELECT count(*) AS total_requests

两条查询必须使用相同主题、相同时间范围、相同检索条件。把 500 和 502 两组相加，再除以总行数：

5xx 错误率 = (1 + 1) / 10 × 100% = 20%

先采用两步法，是为了让分母和分子都可以人工核对。没有流量时分母为零，结果应标为“无请求”或“无数据”，不要伪装成 0% 错误率。

五、三个容易忽略的陷阱

只检索错误，再计算总量。 如果检索条件已经排除了 200 和 404，管道后的 count(*) 只会统计剩余日志。它可以给出错误数量，却不能作为全量请求分母。

把分组结果的前几行当成全集。 示例 LIMIT 20 对四种演示状态码足够，但迁移到 URL、租户或错误码分组时，可能截断结果。不要拿截断后的分组计数之和代替独立查询出的总量。

混合日志缺少状态码。 健康检查、启动日志和业务访问日志混在一起时，即使都带有 service，它们也不一定代表请求。应先用稳定的日志类别字段划定入口访问日志集合，并在所有查询里一致使用这个条件。

六、上线前的验收清单

• 固定时间范围后，十条演示记录可以逐条追溯。
• 分组数量与手工清单一致，总量独立查询为 10。
• 5xx 分子为 2，按约定口径计算为 20%。
• 无流量、重复采集、非访问日志混入时，都有明确处理方式。
• 迁移到真实服务前，确认不存在不同状态码采用不同采样率的情况。

先把这些条件验证清楚，再接入仪表盘或告警。一个口径明确、能从原始记录反查的统计值，比一条看起来复杂却无法解释分母的 SQL 更可靠。

参考文档

• 腾讯云 CLS：语法规则
• 腾讯云 CLS：SQL 案例