AWS CloudWatch Log Insights count减count_distinct结果为负异常

这个负数结果和datefloor()函数、正则逻辑、Lambda日志输出逻辑都没有关系，核心原因是对CloudWatch Log Insights的count_distinct()统计规则理解有偏差：
count_distinct()从设计上就不是精确去重函数，它基于HyperLogLog概率算法实现，官方标称的标准相对误差在2%左右，且误差是双向的——既可能低于真实的唯一值数量，也可能高于真实的唯一值数量。当统计的日志规模较大、唯一键基数较高时，count_distinct()返回的近似值偏大的幅度，超过了日志中实际重复键带来的差值，就会出现count(字段) - count_distinct(字段)为负的情况。测到的无分组差值-20347，刚好符合百万级基数场景下2%误差的典型区间。

之前怀疑的CloudWatch服务缺陷概率极低：count_distinct()的近似特性是官方明确标注的设计行为，不是bug。

• 第一步先做误差验证：直接运行查询统计两个值的绝对值

parse @message /(?<@unique_key>Processing key: \w+\/[\w=_-]+\/\w+\.\d{4}-\d{2}-\d{2}-\d{2}\.[\w-]+\.\w+\.\w+)/
| filter @message like /Processing key: \w+\/[\w=_-]+\/\w+\.\d{4}-\d{2}-\d{2}-\d{2}\.[\w-]+\.\w+\.\w+/
| stats count(@unique_key) as total_count, count_distinct(@unique_key) as approx_distinct_count

如果20347 / approx_distinct_count的结果在2%上下，就可以100%确认是近似算法导致的误差。

• 如果需要得到精确的重复差值，不要直接使用count_distinct()，改用两层聚合的写法实现精确去重：
  1. 第一层先按唯一键（按天统计时加上日期分组字段）分组，统计每个唯一键的出现次数
  2. 第二层再聚合得到总日志数、精确去重后的唯一键数，最后计算差值
     无分组精确查询示例：

parse @message /(?<@unique_key>Processing key: \w+\/[\w=_-]+\/\w+\.\d{4}-\d{2}-\d{2}-\d{2}\.[\w-]+\.\w+\.\w+)/
| filter @message like /Processing key: \w+\/[\w=_-]+\/\w+\.\d{4}-\d{2}-\d{2}-\d{2}\.[\w-]+\.\w+\.\w+/
| stats count() as key_occur_cnt by @unique_key
| stats sum(key_occur_cnt) as exact_total, count(@unique_key) as exact_distinct
| eval delta = exact_total - exact_distinct

按天分组的精确查询示例：

parse @message /(?<@unique_key>Processing key: \w+\/[\w=_-]+\/\w+\.\d{4}-\d{2}-\d{2}-\d{2}\.[\w-]+\.\w+\.\w+)/
| filter @message like /Processing key: \w+\/[\w=_-]+\/\w+\.\d{4}-\d{2}-\d{2}-\d{2}\.[\w-]+\.\w+\.\w+/
| eval stat_date = datefloor(@timestamp, 1d)
| stats count() as key_occur_cnt by stat_date, @unique_key
| stats sum(key_occur_cnt) as exact_total, count(@unique_key) as exact_distinct by stat_date
| eval delta = exact_total - exact_distinct
| sort stat_date asc

• 注意精确去重查询的运行延迟、扫描资源消耗会比直接用count_distinct()高很多，日志量越大差异越明显。如果只是做趋势观测、对数值精度要求不高，可以继续用count_distinct()；如果需要做精确的重复调用、重复处理统计，必须使用两层聚合的写法。
• 可选验证项：可以单独抽取100~200条匹配filter规则的日志，检查parse出来的@unique_key字段是否存在空值、截断问题，当前使用的parse正则和filter正则完全一致，且没有可选匹配段，这一步基本不会发现异常，仅作兜底校验。

内容的提问来源于stack exchange，提问作者magnanimousllamacopter