本文联合创作作者：刘进步(石季)、隰宗正(霜键)
日志记录着每一次请求、每一个异常、每一行代码的执行轨迹。然而，当日志量从每天几万条膨胀到数亿条时，传统的关键字搜索和人工筛选方式已经力不从心。新版日志聚类正是为了解决这一困境而设计——它能够从海量日志中自动发现日志类别，提取日志模板，让工程师从“大海捞针”式的排查中解放出来。
为什么需要智能日志聚类
1.1 “日志洪水”中的认知困境
在分布式系统日益复杂的今天，一个典型的微服务架构可能包含数十甚至上百个服务组件，每个组件都在持续产生日志。据统计，一个中等规模的互联网应用，每天产生的日志量可达数 TB。面对如此海量的数据，传统的日志分析方式面临严峻挑战：
信息过载： 当告警触发时，工程师打开日志系统，面对的是刷屏般的日志流。哪些是关键信息？哪些是噪音？全凭经验判断。
关键字依赖： 传统方式依赖预设的关键字（如 ERROR、Exception）进行过滤。但问题是未预料到的异常模式可能被完全忽略。
上下文割裂： 即使找到了可疑日志，理解其含义仍需要大量的上下文信息。同一类问题可能以略有差异的形式出现成千上万次，人工难以归纳。
1.2 SLS 日志聚类的演进
阿里云日志服务（SLS，Simple Log Service）是一款面向日志场景的云原生观测与分析平台，为用户提供日志采集、存储、查询、分析等一站式服务。作为日志分析的核心能力之一，SLS 很早就推出了日志聚类功能（以下称“旧版日志聚类”），帮助用户从海量日志中自动提取模式。
旧版日志聚类采用“写入时聚类”的架构：在日志写入时预先计算聚类索引，将每条日志映射到对应的模式。这种方式的优点是聚类较全面，但也带来了额外的索引存储成本，对于大规模日志场景可能成为负担。
本文介绍的“新版日志聚类”是对旧版的一次架构升级，采用了“查询时聚类”的全新设计思路。 它不再需要预先建立聚类索引，而是在用户发起查询时实时计算日志模式，从而实现了零额外索引流量、更灵活的分析能力和更优的成本效益。
1.3 从“看日志”到“懂日志”
新版日志聚类的核心思想是：让机器自动发现日志中的模式。
日志聚类基于一个关键洞察：虽然系统的日志量可能十分庞大，但这些日志往往是由有限数量的日志输出语句产生的。每一个日志输出语句产生的日志格式相同，可以用同一个“日志模板”来表示。
例如，以下三条日志：
Got exception while serving block-123 to /10.251.203.149
Got exception while serving block-456 to /10.251.203.150
Got exception while serving block-789 to /10.251.203.151
可以被归纳为一个模板：
Got exception while serving <BLOCK_ID> to /<IP>
其中 <BLOCK_ID> 和 <IP> 是变量部分，会随每条日志变化；其余部分是常量，在同类日志中保持不变。
通过这种抽象，原本需要逐条查看的成千上万条日志，被压缩为少数几个日志类别。工程师可以先在日志模板层面定位问题，然后再深入查看具体日志样例——这正是日志聚类带来的认知升级。
核心设计理念
2.1 零索引流量：轻量化的成本优势
与旧版日志聚类相比，新版日志聚类最大的架构优势是零额外索引流量。
旧版日志聚类需要在数据写入时预先计算聚类索引，这意味着每条日志都会产生额外的索引存储成本。对于大型 LogStore，这个成本可能相当可观。
新版日志聚类采用了完全不同的策略：它基于已有的字段索引，在查询时实时计算日志模板。这种“查询时聚类”的方式，避免了预索引带来的存储开销，同时也让聚类结果能够即时反映最新的日志数据。
| 特性 | 新版日志聚类 | 旧版日志聚类 |
|---|
| 索引方式 | 查询时实时计算 | 写入时预计算索引 |
| 额外索引流量 | 无 | 有 |
| 成本模型 | 纯分析操作 | 按新增索引流量计费 |
2.2 智能采样：平衡精度与性能
当日志量特别大时（例如时间窗口内有数千万条日志），全量分析既不现实也无必要。新版日志聚类内置了智能采样策略：
// 采样策略：当日志量超过阈值时，自动降采样
const sampleQuery = logCount > 50000
? `| sample -method='bernoulli' ${getSampleNumber(logCount, 50000)}`
: ''
采样算法采用伯努利采样（Bernoulli Sampling），确保每条日志被选中的概率相等，从而保证采样结果的代表性。在模型构建阶段，系统会采样最多 5 万条日志用于模式发现；在结果匹配阶段，会采样最多 20 万条日志进行模式匹配和统计。
这种分层采样的设计，让系统在处理海量数据时仍能保持秒级响应，同时不会显著影响聚类效果。
2.3 变量智能识别：超越简单的模式匹配
日志聚类的核心挑战之一是准确区分日志中的“变量部分”和“常量部分”。新版日志聚类采用了更智能的变量识别算法，能够处理多种复杂场景：
数值型变量： 自动识别数字、IP 地址、端口号等数值模式，并支持范围统计。
枚举型变量： 对于取值有限的变量（如状态码、服务名），系统会自动统计 Top N 取值分布。
复合型变量： 对于复杂的变量模式（如 UUID、Trace ID），系统会智能识别其边界。
// 变量摘要统计
| extend var_summary = summary_log_variables(variables_arr, '{"topk": 10}')
变量摘要（var_summary）不仅记录变量的取值样例，还包含变量的类型推断（range / enum / gauge）和分布统计，为后续的深入分析奠定基础。
技术实现亮点
3.1 SPL 算子驱动的聚类流水线
新版日志聚类的核心计算逻辑通过 SLS 的 SPL 实现，形成了一条完整的聚类流水线：
3.1.1 第一阶段：模型构建
*
| stats content_arr = array_agg("Content")
| extend ret = get_log_patterns(
content_arr,
ARRAY['分隔符列表'],
cast(null as array(varchar)),
cast(null as array(varchar)),
'{"threshold": 3, "tolerance": 0.1, "maxDigitRatio": 0.1}'
)
| extend model_id = ret.model_id
get_log_patterns 是核心的模式提取算子。它接收一组日志内容，通过聚类算法自动发现其中的日志模板。算法参数包括：
threshold：识别某个位置的 token 是否是变量的最小值支持度，threshold 越大，token 越不容易被判定为变量。tolerance：变量识别的容忍度，容忍度越小，高频出现的 token 越容易被判定为常量。建议使用默认值。maxDigitRatio：数字字符的最大比例阈值。
3.1.2 第二阶段：模式匹配
*
| extend ret = match_log_patterns('${modelId}', "Content")
| extend pattern_id = ret.pattern_id, pattern = ret.pattern,
pattern_regexp = ret.regexp, variables = ret.variables
| stats event_num = count(1), hist = histogram(time_bucket_id)
by pattern_id
match_log_patterns 将每条日志与已发现的模式进行匹配，提取出：
pattern_id：所属的模式 ID。pattern：日志模板。pattern_regexp：模式的正则表达式。variables：变量部分的具体取值。
3.1.3 第三阶段：对比分析（可选）
| extend ret = merge_log_patterns('${modelId1}', '${modelId2}')
| extend model_id = ret.model_id
对于对比分析场景，merge_log_patterns 可以将两个时间段的聚类模型合并，从而在统一的模式空间中进行对比，发现新增、消失或变化的日志模式。
3.2 前端渲染：高性能的大数据展示
在前端实现上，日志聚类组件面临的核心挑战是：如何高效地渲染和交互大量的聚类结果？
3.2.1 虚拟滚动与分页
聚类结果可能包含数百甚至数千个日志模式。系统采用分页加载的方式，每页只渲染 15 条记录，配合虚拟滚动技术，确保界面始终流畅：
// 分页逻辑
const [currentPage, setCurrentPage] = useState<number>(1)
const pageSize = 15
const pagedResult = useMemo(() => {
const startIndex = (currentPage - 1) * pageSize
return filteredResult.slice(startIndex, startIndex + pageSize)
}, [filteredResult, currentPage])
3.2.2 高亮变量的交互设计
日志模板中的变量部分需要高亮显示，并支持点击查看变量分布。系统实现了一个专门的 Highlight 组件，能够：
- 解析模板字符串，识别变量占位符。
- 为每个变量生成独立的可点击区域。
- 点击后展示该变量的分布统计。（枚举型显示 Top N 取值，数值型显示范围分布）
3.2.3 对比视图的双柱状图
在对比分析模式下，每个日志模式需要同时展示两个时间段的数据分布。系统使用双色柱状图实现这一需求：
- 深色柱状图： 当前时间范围（实验组）的日志数量。
- 浅色柱状图： 对比时间范围（对比组）的日志数量。
通过视觉对比，用户可以直观发现：
- 新出现的日志模式。（实验组有、对比组无）
- 消失的日志模式。（实验组无、对比组有）
- 数量变化显著的日志模式。
3.3 正则反查：打通分析到查询的最后一公里
在日志聚类页面发现了问题模式后，如何查看该类别的全部日志？
新版日志聚类通过正则表达式解决了这个问题。每个日志模板都会自动生成对应的正则表达式（pattern_regexp），用户可以复制这个正则表达式，配合 regexp_like 算子进行精确查询：
* | SELECT * FROM log WHERE regexp_like(Content, '复制的正则表达式')
这种设计将聚类分析与原始日志查询无缝连接，让用户能够在发现问题模式后，立即深入查看具体的日志详情。
典型使用场景
4.1 场景一：快速定位故障日志
某电商平台在促销活动期间收到大量告警。运维工程师打开日志聚类页面：
- 设置时间范围为告警开始后的 10 分钟。
- 在查询语句中过滤掉正常的 INFO 日志：
* and not LEVEL: INFO。 - 查看聚类结果，发现一个新出现的模式：
Got exception while serving <*> to /<IP>: Connection timeout。 - 点击该模式查看变量分布，发现
<IP> 集中在 10.251.xxx.xxx 网段。 - 判断可能是该网段的网络问题，立即进行排查。
整个过程不到 5 分钟，而传统的关键字搜索可能需要尝试多个关键字组合，耗时数倍。
4.2 场景二：版本发布对比分析
开发团队发布了新版本，需要评估对日志模式的影响：
- 设置当前时间范围为发布后 1 小时。
- 配置对比时间为发布前 1 小时。（向前偏移 2 小时）
- 查看对比结果，关注以下情况：
- 新出现的错误日志模式
- 消失的日志模式（可能是修复了某些问题）
- 数量显著变化的模式
- 对于可疑的新模式，点击查看日志样例进一步分析。
4.3 场景三：多模块分组分析
当日志库中包含多个模块的日志时，可以使用分组聚类功能：
- 选择聚合字段为
Component 或 ServiceName。 - 系统会先按模块分组，然后在每个分组内独立进行聚类。
- 通过分组视图，可以快速发现哪个模块产生了异常日志。
这种分层分析的方式，特别适合大型系统的日志分析，避免了不同模块的日志相互干扰。
算法设计思考
5.1 为什么选择“查询时聚类”？
在设计新版日志聚类时，我们面临一个关键的架构决策：是在写入时预计算聚类索引，还是在查询时实时计算？
最终我们选择了后者，主要基于以下考虑：
灵活性： 预计算方式需要预先定义聚类的字段和参数，一旦配置就难以更改。而查询时计算允许用户动态选择聚类字段、过滤条件和时间范围，提供了更大的灵活性。
成本效益： 并非所有日志都需要聚类分析。预计算方式对所有日志统一处理，产生不必要的成本。查询时计算则是“按需付费”，只有真正需要分析时才消耗资源。
算法演进： 聚类算法是一个持续优化的领域。查询时计算让我们可以随时升级算法，新的分析自动受益于最新的算法改进，而无需重新处理历史数据。
5.2 采样的艺术：如何在效率和精度间取得平衡
采样是新版日志聚类的关键设计之一。一个自然的担忧是：采样会不会遗漏重要的日志模式？
我们的策略是“分阶段采样”：
模式发现阶段： 采样 5 万条日志用于发现模式。由于日志模式的数量通常远小于日志数量（这是日志聚类的基本假设），5 万条采样通常足以发现绝大多数模式。
模式匹配阶段： 采样 20 万条日志进行统计。这个阶段的采样主要影响数量统计的精度，而非模式的发现。
变量统计阶段： 对于每个模式，保留 Top 10 的变量取值。这足以让用户理解变量的分布特征。
实践表明，这种分层采样策略在绝大多数场景下能够提供足够准确的聚类结果，同时保持秒级的查询响应。
总结与展望
新版日志聚类代表了日志分析领域的一次范式转变：从被动的关键字搜索，到主动的模式发现；从人工的逐条排查，到智能的类别归纳。
它的核心价值在于：
- 效率提升： 将数百万条日志压缩为数百个日志类别，让工程师能够快速把握日志全貌。
- 洞察发现： 自动识别新出现或消失的日志模式，发现人工难以察觉的变化。
- 成本优化： 零额外索引流量的设计，让聚类分析不再是成本负担。
- 灵活分析： 支持对比分析、分组聚类等多种分析模式，适应不同场景的需求。
展望未来，日志聚类还有更多可能性：
- 与异常检测结合： 自动识别数量突增或突降的日志模式，提前预警潜在问题。
- 与 AI 大模型结合： 利用大语言模型理解日志语义，协助分析日志模板，提供更智能的模式归类和问题诊断。
- 与 UModel 融合： 实体联系 LogSet 查看日志聚类结果，构建更完整的可观测知识图谱。
我们相信，随着这些能力的不断演进，日志分析将从一项繁琐的运维任务，转变为一种智能化的系统洞察工具。
这张图片中小人的颜色和名字的对应关系
这张图片中小人的颜色和名字的对应关系
