AIOps入门之路：自定义日志或非结构文本的轻松ETL

前言 （#TLDR）

在上一篇文章中，我们说过，随着企业数字化发展，AIOps作为企业数字化转型关键支撑力，AIOps不仅仅关注异常检测、根因分析的情况，还包括行为分析、客户参与和识别潜在机会。并且会需要和NLP进行结合。

因此，非常的不幸，我们面临的数据，绝不仅仅是机器数据，还会有大量的文本数据，甚至是销售，社交等各种数据的集合。

AIOps 平台的数据源包括：

• API
• Application logs
• CRM data （客户关系管理数据）
• Customer data (客户资料)
• Events (活动)
• Graph
• ITSM
• Metadata
• Metrics
• Social (社交数据)
• Traces
• Wire

更困难的是，无论给定数据集有多大或更新频率有多高，对单个数据源的限制往往会限制对系统行为的洞察力。现代 IT 系统——具有模块化和动态性——需要一种多视角的方法来了解正在发生的事情，因此，我们在需要打破数据孤岛的同时，也需要提供多维、多视角的分析能力。

好了，扯远了，我们今天先来看一下，面对这么多的数据，Elastic Stack如何处理数据摄入的问题的。

关系型数据库的同步

其中非常重要的一部分是来自于关系型数据库与ES之间的同步。这个部分可以在腾讯云Elasticsearch Service专栏中，搜索同步二字，你应该会得到比较专业的解答：

image.png

标准机器数据的ETL

而对于标准的机器数据，你可以在Elastic官网上找到标准的数据集成解决方案：

image.png

自定义，或者非结构化文本的ETL

但对于自定义，或者非结构化的文本的摄入呢？大多数时候，就需要自己动手丰衣足食了。这里涉及到ETL的工作，通常来说，这是工作量相对较大，也最烦人的部分：

image.png

那如何轻松且愉悦的完成自定义，或者非结构化文本的ETL的工作，将是本文的主题

文件结构分析

首先，我们需要分析成自定义日志或者非结构化文本的结构分析。因为不是标准日志，我们不会轻易事先知道文本的结构，对应的字段和mapping，因此，需要通过上传样本文件，进行预分析。这个补助，我们只需直接打开Kibana，在主页上找到上传文件按钮：

image.png

选择自己的样本文件上传：

image.png

这里我选择一份AIOps竞赛（微服务应用系统故障发现和根因定位）的数据集，样本数据内容为：

serviceName,startTime,avg_time,num,succee_num,succee_rate
osb_001,1586534400000,0.333,1,1,1.0
osb_001,1586534400000,0.5869,360,360,1.0
osb_001,1586534460000,0.5497,343,343,1.0
osb_001,1586534520000,0.6091,359,359,1.0
osb_001,1586534580000,0.5231,359,359,1.0
osb_001,1586534640000,0.5268,385,385,1.0
osb_001,1586534700000,2.3971,216,216,1.0
osb_001,1586534700000,14.6484,9,9,1.0
osb_001,1586534760000,4.5274,143,143,1.0
osb_001,1586534820000,3.3041,159,159,1.0
osb_001,1586534820000,17.0701,8,8,1.0
osb_001,1586534880000,5.0794,133,133,1.0
osb_001,1586534940000,3.9917,71,70,0.9859
osb_001,1586534940000,72.6047,10,6,0.6

上传文件后，Elasticsearch会通过机器学习模型，自动分析样本文件内容。生成：

文件摘要

即文本内容的大概格式，应该如何提取等。JSON，CSV等格式化比较好的内容，会选用对应的processor进行处理，而日志型的，则选用Grok处理器，通过正则表达式匹配的方式，进行字段提取：

image.png

文件字段统计

即文本中，按照摘要中的处理方式进行字段提取后，每个字段的值分布，与字段类型

image.png

ETL管道调整

分析完之后，我们需要对ETL的管道做调整，因为机器学习模型生成的模型可能会与我们的最终需求有偏差，很多时候，我们希望对字段，类型，值三个主体做更多处理的。

对于提取的字段和解释方式，我们可以在摘要页面，选择替代设置，进行定制化

image.png

而对于类型和值，我们在导入之后，选择高级，进行额外的处理：

image.png

以下是一个demo视频：

管道应用于数据流

通过文件上传功能处理之后，我们将得到所需的：

• 索引
• 索引模式
• 采集管道

image.png

我们可以通过这些工具，对我们的实时数据进行流式处理。首先，进入集成页面，选择Custom Logs

image.png

添加对应的集成后，添加文件路径、dataset等基础信息的配置：

image.png

然后，通过fleet，可以将配置远程下发到代理中

image.png

而这里，最重要的一步，是我们需要配置索引模板，在索引模板的settings中，将该索引的默认pipeline指定为，我们在上一步中生成的采集管道：

image.png

这样，我们就完成了整个ETL的过程。

总结

通过Kibana上提供的文件上传功能，我们可以快速的通过样本分析，获得对数据内容的初步理解。通过调整字段提取模板，以及修改字段类型，并通过pipeline管道进行数据处理，我们可以获得最终的采集管道的配置。

最后，我们通过custom logs集成与索引模板，将采集规则下发，并与处理管道绑定。完成了整个ETL的过程。

这里的主要优势是，我们可以在单一界面上完成数据的分析、采集、处理的过程，无需跳转和使用其他工具。整个过程清晰，简单。即便不是专业的数据处理团队，比如运营团队，数据分析团队等都能够按需自己完成ETL工作。

因此，在数字化背景下，实现AIOps所面临的多数据源，多视角分析，多团队参与的需求，能够通过快速简单的ETL功能让我们的工作变得简单。