在通过v1.0\~v1.4四个版本迭代后，SREWorks的外围底座曾经体现出极高的稳定性和成熟性。在v1.5版本中，SREWorks开发团队在外围底座上，进行了较多的数智化能力迭代。同时，在数智能力迭代过程中，咱们也维持着与SREWorks用户较高的沟通频率。咱们发现大家广泛对于监控数据之上的数智化能力比拟关注，于是咱们在这些点上做了一些深挖剖析，发现广泛都会遇到这样几个问题：

  1. 自研监控零碎在数据体量回升后，可靠性降落。
  2. 日志等各类非结构化的数据引入，导致工程复杂性急剧回升，实时性方面也面临更大的挑战。
  3. 简略的表达式(expression)往往无奈满足业务多样化的监控需要。

于是很多用户抉择从自研监控零碎切换至流计算引擎Flink，然而Flink Job自身的应用门槛以及运维又成为一大难题。SREWorks开发团队通过多轮的剖析钻研，决定将这些问题拆成两阶段解决：

  1. 升高Flink Job的应用门槛，赋能SRE将运维需要疾速转化为计算力，使SRE可能真正具备touch数据的能力。
  2. 利用SREWorks工程能力构建开源Flink运维产品，进一步升高Flink运维难度。

在v1.5版本中，咱们先将实现阶段1的开源，同时在实时作业平台之上，咱们会引入大家呼声较高的日志聚类作为这种数智能力的最佳实际：通过Flink ML极大地晋升海量日志的实时聚合效率。无关阶段2，近期会披露一篇无关Flink智能诊断利器——Flink Advisor介绍，本文暂不开展。上面先开始阶段1的开源产品：实时作业平台。

实时作业平台

在SREWorks刚开源的一段时间里，因为SREWorks中蕴含了社区版的Ververica Platform来治理Flink Job，有段时间，社区版vvp的应用答疑竟然占据了咱们大部分和用户沟通工夫。于是通过这些需要的积淀和打磨，咱们将实时处理链路也集成到作业平台中，作业平台中的作业分为定时作业 和 实时作业：

  • 定时作业提供分钟级的作业执行调度，实用于小数据量、低时效性的批处理场景。
  • 实时作业基于 Flink + 社区版Ververica Platform 提供实时作业管理。

在收集了大量的用户反馈之后，咱们决定将SRE较习惯的Step By Step的步骤型的编排作业能力交融到实时作业中去，进一步升高SRE的应用门槛，最终性能如下图所示：咱们将一个Flink Job拆成了三种构造便于管理：

  • 输出源: 对应Flink的Source源，可有多个输出源。
  • Python解决：对应Flink汇总的处理过程，以后基于pyFlink，可间接编写Python脚本，也能够依据业务需要拆分成多个Python处理过程。
  • 输入：对应Flink的Sink，可有多个输入。

输出源&输入

在输入输出这块，咱们间接读取Ververica Platform曾经注册的Connector供用户抉择，以及在配置参数时的下拉揭示，极大地防止用户手写CREATE TABLE时候字段及参数的疏漏。

运行环境

常应用Python的同学能够晓得，Python运行环境治理是一个比拟麻烦的问题：如果应用Docker镜像来治理出包过程过于简短，如果应用requirements来进行治理又经常会遇到包装不上的问题。于是实时作业平台中，咱们做了一个折中的解决，应用Python虚拟环境来进行治理。

同时，咱们也对环境这个概念进行了组合化的扩大：Flink的容器镜像、PyFlink的运行时Jar包等一系列的对象，都算作环境中的设置。因为环境收敛了所有的可变资源，大大降低SRE保护作业的复杂度，本来多个运行时资源间版本不兼容的问题一去不复返，所有同一环境作业，都应用同一组合。

以后v1.5提供两个环境可用：flink-ml 和 default，环境的自主治理能力会在下个版本上线。

Flink作业运维

实时作业平台做了较多形象，简化了作业提交的流程，但在Flink作业运维上咱们深知其中的复杂度，并没有额定做过多的包装，间接应用Flink Dashboard作为运行中的观测平台，不便相熟Flink的同学疾速上手排查问题。下图为实时作业平台中启动作业的Flink Dashboard页面：

日志聚类

在实时作业平台之上，本次v1.5版本同时开源了日志聚类算法，无关算法原理能够参考《基于Flink ML搭建的智能运维算法服务及利用》，本文次要论述开源工程实际。

日志聚类的算法代码位于目录https://github.com/alibaba/SREWorks/tree/master/saas/aiops/api/log-clustering

├── db-init.py├── log-clustering-job│   ├── pythons│   │   └── log_cluster_pattern.py│   ├── settings.json│   ├── sinks│   │   └── pattern_output.json│   ├── sources│   │   └── log_input.json│   └── template.py└── ...

目录次要由两局部组成：

  • db-init.py：特色工程的数据库初始化，须要用大量典型的日志样本初始化日志关键词列表以及日志样板特色。
  • log-clustering-job/*：日志聚类算法作业，在v1.5版本中已默认导入至作业平台中，手工将其打成zip包导入亦能实现雷同的成果。

上面咱们基于这个开源工程，实现一次残缺的日志聚类的实际。本次实际的输出为kafka（SREWorks内置的kafka）的日志流，输入为MySQL中的特色库。

STEP 1 特色工程初始化

咱们本次实际以SREWorks中利用引擎（AppManager）日志为例：

先用标签name=sreworks-appmanager-server查问出AppManager Pod的名称，这个标签在前面采集的时候还会被用到。

$ kubectl get pods -l name=sreworks-appmanager-server -n sreworksNAME                                         READY   STATUS    RESTARTS   AGEsreworks-appmanager-server-c9b6c7776-m98wn   1/1     Running   0          5h39m

而后提取该Pod的大量日志作为初始化日志样本，存储文件名为 example.log。

kubectl logs --tail=100 sreworks-appmanager-server-c9b6c7776-m98wn -n sreworks > example.log`

example.log外面日志的内容大略是这样：

[2023-05-26 21:46:02 525] DEBUG [http-nio-7001-exec-6][o.s.web.servlet.DispatcherServlet:119]- GET "/realtime/app-instances?stageIdList=prod&appId=&clusterId=1id&optionKey=source&optionValue=app", parameters={masked}[2023-05-26 21:46:02 526] DEBUG [http-nio-7001-exec-6][o.s.w.s.m.m.a.RequestMappingHandlerMapping:522]- Mapped to com.alibaba.tesla.appmanager.server.controller.RtAppInstanceController#list(RtAppInstanceQueryReq, HttpServletRequest, OAuth2Authentication)[2023-05-26 21:46:02 527] DEBUG [http-nio-7001-exec-6][o.s.w.s.m.m.a.RequestResponseBodyMethodProcessor:268]- Using 'application/json', given [*/*] and supported [application/json, application/*+json][2023-05-26 21:46:02 527] DEBUG [http-nio-7001-exec-6][o.s.w.s.m.m.a.RequestResponseBodyMethodProcessor:119]- Writing [TeslaBaseResult(code=200, message=SUCCESS, requestId=null, timestamp=1685137562527, data=Pagination( (truncated)...][2023-05-26 21:46:02 527] DEBUG [http-nio-7001-exec-6][o.s.web.servlet.DispatcherServlet:1131]- Completed 200 OK...

应用 db-init.py 进行特色工程数据库初始化，该动作会在数据库中减少一张表，并且将 example.log中的日志解决成特色行存入表中：

pyon3 ./db-init.py example.log --host *** --user *** --password *** --database *** --table***

这个数据库的连贯变量记一下，在下一步中马上就会用到。

STEP 2 作业参数运行配置并启动

关上SREWorks中的实时作业平台，点开《日志聚类模式提取》这个作业对应的【运行参数】按钮，在启动参数中，将STEP1 中数据库连贯参数填入：

填写实现后，咱们能够间接点击作业启动。作业启动后，咱们点击【运行中】的状态能够间接跳转到Flink Dashboard看到整个流计算解决链路曾经准备就绪，但还没有日志输出。

STEP 3 日志采集输出并聚类

ilogtail是阿里云开源的可观测工具，在阿里云的采集场景中有着十分宽泛的利用。ilogtail对于云原生的适配也十分好，采纳DaemonSet的形式在每个Node中拉起，Pod中只有蕴含对应的label就会对其进行采集。

于是，咱们能够通过运维市场，十分不便地将ilogtail装置进集群，同时装置的时候，对应的采集label配置为name=sreworks-appmanager-server即是对利用引擎（AppManager）进行日志采集。

在日志采集运行起来之后，通过Flink Dashboard咱们能够看到本来空空的实时处理链路一下子就忙碌了起来，像一个工厂的流水线一样，每个运算单元都在一直地收发解决数据。通过查看MySQL中的特色(pattern)表，咱们能够看到日志特色解决完之后曾经被落到了咱们在STEP 2中定义的MySQL表中。

特色表中的几个关键点咱们能够关注一下：

  • 特色表为日志的特色收敛，在初期数据量会迅速扩充，通过一段时间后，当没有新的特色之后，数据量会趋于平稳。
  • 特色表中的字段 pattern 为这行日志的摘要，字段 top_pattern 为聚类后处于核心的日志摘要，通过 top_pattern 咱们能够很不便地统计出总共有几类日志，也能够看出每一类日志下有哪些日志。

如下图能够看到这些文本十分类似但又不同的debug日志，被聚到了同一个 top_pattern 下。

日志聚类的实际利用

围绕日志聚类算法，能够开展很少数智化的实际。围绕《基于Flink ML搭建的智能运维算法服务及利用》已披露的案例，联合着上文的工程实际，咱们能够再来看一下残缺的链路：

  • STEP 3中咱们查看的特色(pattern)表能够进一步演进为一个日志知识库，疏导SRE联合运维教训来进行标注。
  • 日志知识库积淀的日志输出答疑机器人作为答疑语料，疾速解决用户问题，升高工单数量。

期待大家集成并应用日志聚类算法之后的反馈，同时SREWorks团队也会依据外部的运行成果和大家的反馈，继续打磨数智运维算法。

企业应用开发部署加强

在v1.5版本中，咱们同样对底座的利用开发能力进行了加强，蕴含以下这些性能点：

  • 企业应用减少多分支开发能力，适配企业的多版本迭代需要。
  • 企业应用实例部署残缺的OAM可视化。

在企业应用上，咱们经常联合SREWorks一线用户的声音，将外部应用的弱小能力通过产品化的打磨优化，提供给SREWorks的用户们。咱们也会放弃这种状态，冀望云原生的利用开发模式和数智运维体系，可能助力企业聚焦业务价值，进行疾速的性能产品倒退迭代。

如何从以后版本升级到v1.5

  • 降级蕴含底座，页面可能会有5-10分钟的不可拜访，请留神。
  • 用户自行开发的云原生利用不会受影响(不重启)，SREWorks网关到利用的流量会有中断。
git clone http://github.com/alibaba/sreworks.git -b v1.5 sreworkscd sreworks./sbin/upgrade-cluster.sh --kubeconfig="****"````如在应用过程中遇到问题，欢送各位在GitHub中提出Issues或Pull requests。**SREWorks开源地址：** https://github.com/alibaba/sreworks也欢送各位退出钉钉群（**群号：35853026**）分享和交换～