AI 日志聚类：相同错误不一定是同一问题
一、日志相似容易误导
AI 做日志聚类很有用，可以把海量错误归成几个主题。但相同错误文本不一定来自同一问题，不同错误文本也可能指向同一个根因。只按文本相似度聚类，可能把排障方向带偏。
日志聚类要结合服务、时间、拓扑、请求链路和指标。
二、聚类特征要多维
flowchart TD
A[日志] –> B[错误模板]
A –> C[服务实例]
A –> D[时间窗口]
A –> E[TraceId]
A –> F[指标上下文]
错误模板只是基础。服务名、实例、版本、调用链、最近发布和指标异常，都应该参与聚类。
log_cluster_features:
message_template: high
service_name: high
trace_id_relation: medium
time_window: high
deploy_version: medium
否则一个通用 timeout 会聚成一团，根本无法定位。
三、聚类要能解释边界
一个聚类结果要说明为什么这些日志被放在一起，也要说明哪些相似日志被排除。值班人员需要判断聚类是否可信。
cluster_summary:
reason:
– same_error_template
– same_downstream_dependency
– same_deploy_version
excluded:
– different_region
边界解释能减少误判。
四、从聚类走向根因
日志聚类只是整理症状，不是根因分析。聚类后要关联指标、拓扑和变更，判断是下游故障、配置错误、容量瓶颈还是代码异常。
next_steps:
check_dependency: payment-api
compare_version: v1.8.3
inspect_metric: p99_latency
还要避免吞掉小众错误。高频错误容易被注意，低频但高危的安全、数据一致性错误也要保留独立告警。
最后，聚类结果要反馈到日志规范。相同问题如果日志字段缺失，就推动业务补字段，而不是永远靠模型猜。
日志聚类还要处理采样。高流量服务为了控制成本可能会采样日志，聚类系统必须知道采样率，否则会低估问题规模。错误日志和安全日志通常不应该和普通访问日志使用同一采样策略。
log_sampling_context:
access_log_sample_rate: 0.1
error_log_sample_rate: 1.0
security_log_sample_rate: 1.0
聚类结果也要给出代表样本。每个聚类挑几条最典型日志，并保留原始 trace、实例和时间。没有样本，值班人员很难判断聚类是否合理。
最后，日志聚类要和告警联动。某个错误聚类突然出现，不一定立刻告警；但如果它同时影响核心接口和 SLO，就应该升级。
还要处理多语言日志。不同服务可能用中文、英文、错误码、异常栈表达同一个问题。聚类前可以先抽取标准字段和错误码，再让模型处理自然语言部分。
log_normalization:
extract_error_code: true
extract_exception_class: true
normalize_stack_trace: true
异常栈也要压缩。完整堆栈很长，直接丢给模型成本高且噪声多。保留异常类型、顶部业务栈、根因 caused by，通常更有价值。
最后，聚类结果要能一键下钻到原始日志。AI 摘要只是入口，真正排障仍需要看原始证据。
五、总结
AI 日志聚类要结合错误模板、服务、时间、调用链、指标和变更，并解释聚类边界。
相同错误不一定是同一问题。聚类是排障入口，不是根因终点。
