一文了解 SLS 文本分析作业

使用场景与限制

在海量日志场景下，由于信息爆炸，传统的关键词过滤、正则匹配等手段依赖大量的专家知识，因此我们很难快速的从日志中获取关键信息。对此文本分析作业首先对海量日志数据进行聚类，聚类得到的日志类别数量往往远小于原始日志的数量，这样我们就可以方便的浏览这些日志类别获取日志的整体信息，如果出现某些高风险的日志类别，可以根据类别信息进一步查找与之相关的原始日志，快速定位需要关注的原始日志。在得到日志的聚类结果之外，文本分析作业还会持续跟踪各个日志类别的状态变化，包括是否有新的、未知的日志类别产生，某类别日志的日志量是否发生了突变，以及出现的低频的、罕见的日志，这三类状态变化很有可能与系统的潜在风险相关，用户可以通过查看这几状态变化，进一步缩小问题定位时的排查范围。

文本分析作业以滑动窗口的形式准实时的处理数据，依次对每一个时间窗口内的日志进行聚类，再将不同时间窗口中的日志类别进行关联，以便实现对于不同日志类别状态的跟踪检测，如下图所示

时间窗口中的日志聚类情况要在这个窗口结束后才会产生，分析结果有大约一个时间窗口长度的延迟，目前可选的时间窗口长度大于5分钟，因此对于时效性要求比较高的场景可能不适用。日志聚类算法的准确性会受到日志结构、复杂性的影响，如果日志中包含超过50%的变量成分（logging 语句中动态填充的部分），聚类算法的准确性会降低，因此文本分析作业更适用于稳定、规范的系统日志，对于复杂度、灵活度较高的业务日志，如果聚类的准去性较低，可以考虑使用 SLS 数据加工能力对原始数据进行一定的预处理，去除日志中不需要考虑的变量成分后再使用文本分析作业进行处理。文本分析作业持续消费日志库中的原始日志，如果日志库中的日志量太大，比如一个时间窗口中日志量超过了分析作业的处理能力，那么文本分析作业的进度相对于日志产生进度越来越滞后，最终丧失时效性。目前文本分析作业可以处理每分钟30w左右的日志，如果日志结构比较简单，那么可以处理更多日志。如果日志量超过了处理能力，那么一方面可以用算法提供的黑白名单能力过滤掉需要用关心的日志（比如 debug, info 等级的日志），减少处理的日志量，另一方面如果日志分布在多个 shard 上，可以申请增加文本分析作业的资源，提高分析的并行度。

作业配置说明

文本分析作业的配置主要包含两类配置

• 数据配置：指定待分析的文本数据所在的日志库与日志字段，文本分析作业使用数据配置读写指定的日志库
• 算法配置：指定文本聚类算法的参数，文本分析作业使用这些参数对算法进行初始化

数据说明

在上一节我们提到日志聚类算法对于日志的结构和复杂性有一定的要求，如果变量成分太多会影响聚类的准确性。因此我们待处理的日志最好是结构化和半结构化的数据，文本分析作业可以使用日志结构方便的忽略日志中不需要考虑的变量部分。以 K8S 运行时日志为例，我们在日志采集时将日志整理成了以下的结构

{
"eventId": { 
"metadata": {
"name": "fxs8k4kpprzxfm7.16c9b3e37060acb6",
"namespace": "default",
"selfLink": "/api/v1/namespaces/default/events/fxs8k4kpprzxfm7.16c9b3e37060acb6",
"uid": "5e9a03f8-7f67-4fbd-8e5a-3e5a2ac979fd",
"resourceVersion": "143303381",
"creationTimestamp": "2022-01-13T02:35:28Z"        }, 
"reason": "FailedMount",
"message": "Unable to mount volumes for pod",
"source": {
"component": "kuberenetes-events-generator"        },
"firstTimestamp": "2022-01-13T02:35:28Z",
"lastTimestamp": "2022-01-13T02:35:28Z",
"count": 1,
"type": "Warning",
"eventTime": null,
"reportingComponent": "",
"reportingInstance": ""    },
"__time__": 1642041328,
"hostname": "",
"__topic__": "",
"__pack_meta__": "1|MTYzMjcwMzAzOTA0NjQ2NDA2NA==|7|6",
"level": "Warning",
"__source__": "",
"pod_id": "f340de16-ff1f-4e25-910f-3b238e10d800",
"pod_name": "fxs8k4kpprzxfm7"}

可以看到 K8S 运行日志中包含大量的的变量字段，如 eventId.metadata.namespace, eventId.type 等等，对于这些结构良好的变量字段我们可以使用 SQL 查询分析进行实时统计，我们仅需要关心其中的自由文本字段，如 eventId.message。

数据配置

数据配置时首先需要指定文本数据所在的日志库（源日志库）以及分析结果要写入的日志库（目标日志库）。其中源日志库我们需要在作业基础信息配置页通过在相应配置项的下拉框中进行勾选，包括勾选源日志库所在 project 名称，以及源日志库的名称

对于目标日志库，智能异常分析 APP 中所有作业，包括文本分析作业，都将分析结果写到源日志库所在 project 中名为 internal-ml-log 的日志库中（如果作业创建时这个日志库不存在，作业将自动创建这个日志库），我们无法修改目标日志库。

完成基本信息配置后点击下一步，我们将进入数据配置和算法配置中。数据特征配置包括一下三项

• 日志实体字段配置：非必填项，这个配置项主要是用来帮助文本分析作业区分同一个日志库中不同来源的日志。日志实体字段是日志中的若干个字段（目前最多配置2个字段），这些字段值的组合可以唯一标识日志数据的来源。我们以 K8S 日志为例，不同的系统在 K8S 环境中往往通过 namespace 进行隔离，如果我们希望分析作业分别处理不同 namespace 下的日志，那么我们可以配置日志实体字段为 eventId.metadata.namespace；进一步的，在 namespace 的基础上，我们希望文本分析作业区分不同系统模块的日志，那么我们可以再增加一个实体字段 eventId.source.component。如果我们不配置任何日志字段，分析作业将认为日志库中的日志来自同一日志来源或者用户并不需要区分日志来源，直接处理全部日志。
• 日志文本字段配置：必填项，这个配置项主要用来指定日志中待分析的文本字段，以 K8S 日志为例，我们可以填入 eventId.message。如果有多个文本字段需要分析，我们可以在该配置项中填入多个字段，如 eventId.reason 等等。分析作业在处理时会依次拼接指定的文本字段成一个文本进行处理，如果指定的字段不是文本类型，将强制转化成文本类型处理。
• 日志等级字段配置：非必填项，这个配置用于帮助文本分析作业判断日志的等级。分析作业在检测日志异常状态时会考虑日志等级，例如 error 日志突增的严重项要大于 info 日志的突增。如果我们没有指定或者指定了错误的日志等级字段，日志等级将被赋值为 unknown。在 K8S 日志中，level 字段标志了日志等级。

算法配置

算法配置包括算法的基础配置与告警配置，在基础配置中我们需要选择分析作业运行的基本参数，而在高级配置中我们更加深入的定制算法的行为。对于这两类配置我们都提供了常用的初始值。在基础配置中，目前我们提供了两类算法

• 日志异常分析算法：该算法通过文本距离算法计算文本之间的相似度，将相似的日志聚为一类。适用于如系统日志等等规范、稳定的日志。
• 日志模板匹配算法：该算法完全通过用户指定文本正则模板对日志数据进行配置，适用于我们可以直接从源代码获取日志 logging 语句的场景。

在算法选择时，由于直接从代码的 logging 语句中获取日志模板往往比较困难，我们建议优先选择日志异常分析算法。另外为了应对一些业务场景中日志结构较为复杂、基于文本相似度的聚类算法效果可能较差的问题，我们将在近期上线基于词频的聚类算法。

这两类算法都包含了以下两个相同的配置项

• 时间窗口长度：我们在上面介绍过文本分析作业以滑动窗口的形式依次处理每个窗口中的日志数据，时间窗口长度用来配置滑动窗口的长度，以秒为单位。时间窗口长度越大，分析结果的实时性越弱。
• 异常总数阈值：在同一个时间窗口中，可能有多个日志类别出现异常。但是日志数据作为指示性相对较弱的观测数据，个别日志类别的异常可能是有系统的正常抖动引起，并不意味着系统异常。这里的异常总数阈值表示当一个时间窗口中的异常日志类别数超过了这个阈值，那么系统可能确实存在异常。我们可以配置正整数作为绝对阈值或者 0~0.5 的小数作为相对阈值。由于该值为经验值，忘完难以选择最合适的数值，我们刚开始可以直接使用初始值。

除了这两项基本配置，当我们选择日志模板匹配算法时，我们需要指定预设的日志模板的地址。首先我们需要在智能异常分析 APP 中进入 辅助数据 -> 日志模板 页面，在其中配置日志正则模板，主要包括以下配置项

日志正则模板配置完成后，在日志模板匹配算法中的模板源配置项中，我们可以勾选日志正则模板来源，如下

除了算法的基础配置，我们可以展开下方的高级配置项对算法进行深度配置，包括以下配置项

• 初始化窗口数量：默认值是 24，表示分析作业在开始运行后的 24个时间窗口内只进行算法模型的训练，不输出异常事件，在后续的时间窗口中使用训练的算法模型对日志数据进行分析处理（算法仍然会在后续的时间窗口中持续训练更新）。
• 最大静默窗口数：默认值是 672，表示如果一个日志类别出现后的 672个时间窗口内这个日志类别没有在此出现，那么将认为这个日志类别已经消失。之后如果再次遇到该日志类别，将会产生新日志类别异常。由于分析作业同时会检测罕见日志类别异常，同样也会对于这类低频出现的日志类别进行提示，因此我们可以设置较大的最大静默窗口数。
• 采样率：如果日志数据量巨大，超过了分析作业的处理能力，那么可以通过配置较低的采样率，只对随机部分日志进行处理。
• 分隔符：文本分析作业使用这里配置的分隔符将文本数据进行切分。
• 数据过滤配置：如果我们只对特对日志等级的日志感兴趣，那么可以针对日志等级配置白名单和黑名单，例如只关心 warning, error 等风险度较高的日志。分析作业运行时只会处理满足过滤条件的日志。
• 通识字段配置：日志内容中的值可能满足特定的格式，比如时间、IP 和数字等等，我们可以针对这些特定的格式配置正则模板，分析作业运行时会使用正则模板（模板表达式）匹配日志内容，将满足模板的部分替换成统一的名称（模板名称）。默认提供 IP、日期、时间和数字的模板，可以根据日志内容的特定，配置其他正则模板。如果配置的模板太多，会影响分析作业的运行效率，建议总的模板数量在 5个以内。模板配置完成后可以通过下方的测试框进行测试，检查配置的正则模板是否符合预期。

最后我们需要在调度配置中设置任务运行的起始时间，如果起始时间为过去时间，那么文本分析作业将消费历史数据，直至追到当前数据产生进度；如果配置时间为未来时间，那么文本分析作业将等到对应时刻再开始运行。

上述配置完成后，点击下方的“完成”按键即完成了文本分析作业的创建。

仪表盘说明

在文本分析作业创建完成后，我们可以通过 智能异常分析 APP -> 文本分析 -> 作业标识 进入作业分析结果仪表盘，查看作业的分析结果。

文本分析仪表盘包括以下两个页签

• 日志模板管理页面：在这个页面中我们可以查看文本分析作业挖掘到的日志模板 ID，日志模板内容，日志等级等等信息 在这里我们可以了解日志的整体信息，快速浏览日志。我们也可以通过每个日志模板右侧的概览按键查看日志模板对应的日志数量的变化以及可能的异常情况
• 日志异常详情页面：这个页面主要关注于日志中的异常事件，这里我们可以查看各个日志类别在各个时间窗口中的异常情况，以及日志整体（包括各个日志类别）在各个时间窗口中的异常情况。我们还可以在下方的异常事件列表中查看各个异常事件的详情。

在定位问题时，我们可以在日志类别异常总览色块图中查看哪一个时间窗口日志整体的异常程度比较高，点击对应的色块，将在下方的异常事件类别中展示发生在该窗口的各个异常事件；我们也可以直接在下方的日志异常事件列表中过滤和某个日志等级相关的异常，或者某种类型的异常。目前我们正在进行文本分析作业与告警的集成，是得文本分析作业中发现的异常状态可以及时的推送给用户。