从1.0到2.0:民生银行数据库智能运维的探索升级与实践

孔再华 2021-11-05 10:23:27

本文根据孔再华老师在〖deeplus直播:金融业数据库转型与国产化改造〗线上分享演讲内容整理而成。(文末有回放的方式,不要错过)

图片

孔再华

民生银行 数据库专家

 

  • 民生银行资深数据库专家,具有丰富的数据库环境问题诊断和性能调优经验,尤其擅长同城双活、集群、多分区、分布式等项目咨询和实施。

  • 现致力于数据库分布式架构建设和智能运维(AIOps),建设了民生银行基础软件智能运维平台,实现基础软硬件的产品深度智能运维,引导传统运维向智能运维发展。

 

今天我给大家带来的主题是民生银行数据库的智能运维实践。之前我在 dbaplus社群曾经给大家分享过一次,那个当做是1.0的版本《不谈宽泛的智能运维,聊聊我在用的异常检测核心算法。而这次我又补充了很多新的内容,所以作为智能运维2.0的版本给大家分享。

 

一、基础软件智能运维平台

 

首先介绍一下我做的这样一个智能运维平台,在这个智能运维平台里面,大致分为这样4个部分:

 

图片

 

 
1、运维数据中台

 

首先,大家知道关于智能运维,我们其实最看重的还是数据质量。作为一个运维大数据的分析平台,我们需要对运维大数据做一些分类,把不同类型的数据都汇总到一个运维数据中台里面去。

 

我们可以采用不同的技术手段来存放这些数据,并通过统一的消费来做智能分析。首先需要一个比较夯实的数据基础,所以运维数据中台里面可能需要分这样几类数据:

 

一种是监控数据。监控数据包括性能数据、状态数据。监控数据的来源非常多,可能我们都有这种集中监控平台,它会去采集一些各个软硬件产品比较核心的性能指标。有些可能还有其他各种各样的平台,里面都会放着跟业务、交易、产品、软件、硬件相关的信息和日志。这些数据我们要想办法把它们集中到一起,进行统一的消费。

 

还有一种数据是所谓的元数据。或者也可以看作是像CMDB的一个关系类的数据。这种关系类的数据它也是一样散布在很多不同的地方。CMDB可能是一个比较集中的、管理着所有的这些关系数据的地方,它只是汇总了一部分,还有很多其他的系统也包含相关的数据,并且有很多关系数据是要经过分析才能得出来的。所以关系数据可能不仅仅是我们已知的一些关系,还是我们总结出来的一些关系。

 

最后一部分数据是知识库相关的数据,比如说我们建的问题库、知识库等等,它可能包含了你运维过程中总结的一些知识,或者是跟产品相关的一些知识。而这些数据基本上就是我们需要去关注和处理的这种运维大数据。

 

 
2、实时计算引擎

 

当我们拥有这些数据之后,会在上层建一个实时的计算引擎。这个实时计算引擎主要是做实时的数据分析以及历史的数据分析。

 

 
3、智能算法库

 

再上一层相当于构建了一套智能算法库。智能算法库里面在不停地补充各种各样的智能场景。这些智能算法库,我们的想法是让它通用一些,能够采用一些通用的方法解决比较个性的一些问题。

 

 
4、智能运维服务

 

最后是在智能算法库、在大数据的基础上封装一些智能运维服务。这些智能运维服务,通常是深度分析软硬件的产品的运行状态、产品的问题发现,根因分析等等。

 

在这个基础上,我们甚至还可以再有一些自助服务。比如说可能不在我们采集的产品、数据上面,还有一些其他系统自己的数据,它们也希望用我们的智能算法和一些服务。那它们可以通过我们比较通用的接口来推动数据,获取这个服务所取得的信息。

 

为了做这件事情,我在这几年构建了这样一个基础软件智能运维平台。针对这些智能场景,这个运维平台里面主要分为这样几个部分:

 

图片

 

第一个是产品的深度智能运维。这里面内容比较多,比方说我们会围绕某一个数据库的产品,对它各个智能场景、组件形成相关的服务。

 

除此之外,我们还会跟监控告警那边一块儿去合作,通过和集中监控打通,然后通过智能运维服务,向集中监控提供更多、更准确性的告警服务。

 

二、数据库产品深度运维1.0

 

我们先回顾一下去年曾经给大家分享过的,关于智能运维的1.0的版本。在1.0的版本里,我主要给大家介绍过三种比较重要的智能场景:

 

图片

 

一种是做异常检测,在做完异常检测的基础上,我们再做一定的根因分析,通过根因分析找到问题的根因所在。

 

有了异常检测和根因分析之后,就可以去通过创造一些所谓的智能场景,通过场景告警的方式,收敛这些告警和根因分析,给普通用户或者专业的DBA提供决策相关的信息。

 

 
1、异常检测

 

首先说一下异常检测。大家想想:我为什么要做这样一个异常检测?当我们做监控的时候,可能只需要对一些指标设置一定的阈值,我就可以说我关于指标的异常检测已经搞定了。这也是我们把一些核心指标提供给监控系统,然后由监控系统帮我们告警的一个方法。

 

但事实上,如果大家在平时使用的过程中发现:监控确实告警了。而它告完之后,你拿着它的告警去查看你的数据库。想要去分析更深层次的问题时就会很困难。因为可能告警出来的只是结果,但是真正的原因、真正的告警的细节的点在什么地方呢?其实大家并不知道。我们知道,像数据库里面其实有很多很多的性能数据,它可能在不同的层次、不同的组件上,都有相关的性能数据的采集。如果这部分内容不被利用起来,对于我们来讲这个数据库就是一个黑盒。

 

但是如果我们能够把这些所有的指标,比方说可能有成千上百的这种指标,全部都监控起来,并且不通过人为的方式去进行判断,而是通过机器的智能算法,去寻找这些指标运行有异常的情况。那这样我在问题点的时候能够看到:到底是什么地方发生异常了?那我是不是就可以找到更细的那个点,并且知道是什么原因。

 

所以在过去的异常检测里,我们做了针对全时段和分时段的异常检测,就像这张图右边的两张小图:

 

图片

 

右上角的这张是全时段的异常检测,也就是说,我会参考整个过去的时间段里面所有的指标运行情况,来判断:有没有可能,现在运行的跟以前所有的时间都大不相同?

 

还有一种就是:比如说我对交易的类型,我的数据库它的运行状态是有一定的周期性的。无论是工作日也好,还是日间和夜间不同的工作负载也好,我可能需要不同的更细力度的检测才可以。那这样也没问题,我们可以通过分时段,将整个的阈值线做一个分时段的设置。

 

 
2、根因分析

 

图片


在做完异常检测之后,我们还需要找到什么?我们还需要找到问题的根因SQL。我们可以基于日常的异常检测,去找到这个点。这个点它如果有异常了,那到底是哪个SQL导致的呢?我们可以基于这个点和SQL的一些指标进行排序,然后得到对这个点的贡献最大的这些 SQL。

 

当我找到这个SQL之后,我就可以去看这个SQL的历史执行情况。第一,我可以看这个SQL当前的执行时间分布图。它到底是在什么地方花的时间比较多?然后我还要去看 SQL的历史执行情况。它之前也跑了这么多次,也是在这样的一些时间点运行,那它整个的响应时间、整个的执行时间有没有什么太大的变化?

 

通过这种和历史的对比、和当前的细致的分析,我们就能够把根因分析做得非常好!

 

 
3、智能场景

 

最后是智能场景。我刚刚说了,当你真的把所有的、1000多个指标都监控起来,这些指标可能会有很多是相关联的,它们可能都喜欢一块儿出现运行不一样的情况。

 

在对历史的这种运行不一样的情况进行分析之后,我们可以把相关的指标组合在一起。组合在一起之后我可以告诉说:如果这一类的指标发生异常,它其实说明的是一个什么样的场景。

 

图片

 

像这个例子里面,我跟日志写盘相关的有哪些指标?当这些指标发生异常的时候,那其实就是一个写盘的异常。那这个写盘的异常一般是什么原因导致的?有什么样的解决办法?那我把这些东西作为智能场景总结完之后,基本上有问题发生的时候,通过一键分析就可以告诉你:在当前,你应该去发现这个数据库是发生什么问题?然后怎么样去解决。

 

在去年做1.0的介绍的时候,可能还花了很多时间去介绍一些智能运维的算法,怎么样去做这些工作?但我觉得,像这些智能运维的算法,其实跟我们用的这些Java语言、Python语言一样,大家只要说思路上知道怎么去做这个东西,其实用什么样的算法都是好算法。所以今天我介绍的时候可能就不太注重说算法的研究,而是给大家提供一些做智能运维的思路。

 

三、数据库产品深度运维2.0

 

现在正式开始介绍所谓的数据库的智能运维2.0。2.0版本我大致会介绍这样几个新的内容:系统画像、容量预测和日志检测。

 

图片

 

 
1、系统画像

 

对于系统画像这个东西我们先想想。我们要做系统画像,那我们平时认识到的最多的画像是什么?其实是客户的画像、用户的画像。对于这些客户的画像、用户的画像,我们可以随便上网搜一些图。那我自己就去搜了一些图,这些图片都是网络上搜过来的:

 

图片

 

大家在做用户的行为分析或者用户的画像分析时。可能会看用户他的年龄、性别、收入、支出、所在的地理位置,还有他平时喜欢看的剧、喜欢听的歌、喜欢做什么样的事情、喜欢购买什么样的东西等等。

 

这些画像其实是从非常多的维度去描述一个人的特点。后续在有了这个画像的基础上,各种推荐系统就上线了。你如果是个卖东西的,你会说,我看这个画像,这个人我给他推荐什么样的东西他才会去购买?而有些东西可能不应该推给他,因为那只会让他觉得烦。

 

所以用户的画像现在已经是一个非常流行的东西,对于系统画像我们也是一样。可能大家现在做的不太多。因为大家会觉得:做系统画像干什么?但我如果把这个图画出来的话,大家应该会有一定的印象。因为当我想了解一个数据库的时候,我其实是想了解它平时的TPS的情况、CPU的使用情况、内存的使用情况、硬盘的使用情况等等。但我之前可能没想到过把这些东西汇总到一起,作为一个系统画像来看待。

 

我事实上是把这个东西作为系统画像给大家展示一遍。比如我将数据库的一些指标汇总列成这样一个主要的6大维度:

 

图片

 

在这6大维度里面可能是一些比较细节的指标。在这些指标的基础上,我们可以做一些聚类,做一些整体的、跟其他的数据库的横比。因为毕竟在银行或者是在其他的金融行业,大家其实并不缺数据,对吧?

 

就像我们卖衣服要把人的衣服分成 XL、XXL、XXXL等情况,对数据库我们也可以一样。比如说按照这些数据库的CPU的使用情况,把它们分为好几个档。当你分完好几个档之后,基本上你只要告诉别人,你的数据库是在某某档上,他立马就会对这个数据库有一定的了解。

 

比如我说这个人是穿XXXL的,你立刻就能想到他是一个高大的胖子,对吧?

 

通过这种方式,把这个数据库描述起来之后,我就可以知道它这个数据库在整个企业的数据库里面,是运行在怎样一个level里面,并且我也是基于不同的维度去做的。

 

通过这种系统画像,你可以很快地了解这个数据库的特征。

 

图片

 

在这个系统画像的基础上,我们还会做一定深度的运维。比如我们可以通过判断数据库运行的基线的趋势变化,像前面这张图,我们可以看到那个图里面,本次和上次曾经在某一个维度上发生了一定的变化,这种变化通常是比较大的。

 

就像你从XL的码数穿到XXL,要不就是你长个了,要不就是你增肥了。这都是一些需要去关注的事情,这是第一点。

 

第二点,我可以通过对这些画像里面比较重要的指标的基线,做一定的资源分析和调度。比如说这个CPU用的比较多的,或者用的比较少的,它们适合用什么样的硬件环境去运行?

 

这就涉及到了后面:我们要基于画像的标签维度去进行资源的管理。像现在我们都用虚拟机、容器云等。那在这些云环境里面,动态调度是非常有用的一种方式,能够充分地利用你的资源。

 

如果有我的画像和我画像基线里面的这些数据的话,我就可以知道,某一些数据库的CPU和另外一些数据库的CPU,它们彼此之间的运行时间是互补的,有的白天忙,有的晚上忙。而在它们互补的情况下将它们凑到一起去,可能会充分地利用宿主机的 CPU。我们可以通过这种方式来做一些瓶颈分析和动态调度。

 

因为时间的关系,我不会把某一个功能里面的点讲得特别细致,但是我希望,通过跟大家探讨这种做法和它已经能够产生的效益,能够给大家一些做相关工作的思路。

 

 
2、容量预测

 

1)容量预测需求:

 

解决空间类容量的预测需求,先一步解决容量问题,避免出现容量事故。

 

实现性能容量类预测目标,适用于资源预测告警,资源调度等运维场景。

 

2)总体算法思路:

 

自主研发时序预测算法,分解数据的整体偏移性,周期性,趋势性和误差,从而实现稳定可靠的时序预测功能。(现有的算法验证效果较差,需要综合各类算法的思想自研。)

 

稀疏点与密集点需要采用不同的预测模型,需要兼顾预测准确性和训练预测性能。

 

3)容量报告和告警:

 

提升系统容量报告信息量,提供预测内容供参考分析。

 

实现容量类预测告警,提前发现容量瓶颈。

 

我们来看下面这几张图:

 

图片

 

在这4个小图里面,你会看到,右边的这两张小图,在某个时间点都出现了一个突然的下降。而在突然下降之后,后续是比较平稳的。这种突然下降可能是因为我解决了一个问题。假如它是CPU,那我可能杀掉了一个比较耗CPU的进程。我觉得它这个进程没用,那我干掉它以后,就再也不会有这部分加成了。

 

所以去掉它之后,整个曲线后面的预测会平稳一些。否则它会觉得:你的趋势是从一个很高的点往低的点走,那我后面在预测的时候它也会往低的点走。所以这部分加成去掉之后,对它整个的平稳性会有很高的帮助。

 

然后还有周期性。像左下角的这个图,其实它是很明显有一定的周期性的。周期性里面红色的部分是真实的点,黑色的则是我们的预测的点。可以看到,我们预测的点和红色的点其实差异并不是很大。所以总体来看,如果在周期性很明显的情况下,我们还是能够得到比较准确的预测的。

 

我们再看右下角的这张图。它其实整个的数据是有一定的趋势性的,它是在往上走。虽然它在前面曾经掉下来过,但我通过第一步的偏移性解决之后,最后在计算整体的趋势性的情况下,它也一样能够拟合它真正的趋势。

 

做完容量预测之后,我们拿一些数据库的表空间、数据库的大小还有大表来做检测:

 

图片

 

在做这个检测的时候,除了上文对未来的预测,同时我们也能对所谓的突变和增长做一些判断,把这些发生突变和发生增长很快的对象都拎出来,作为告警发给负责人。那负责人就知道这个问题,知道他的表一直在不停地变大,或者是近期突然变得很大,那可能就需要去关心一下。

 

这就是关于容量预测这块的内容。后面再给大家讲一下日志检测。

 

 
3、日志检测

 

日志检测我们首先从出发点上去看:我们为什么要做日志检测?我们怎样才能把它给做好?大家以前在发现产品问题的时候,你们是怎么办的?

 

图片

 

你们想到的可能是,当我发现问题了以后,我需要去分析它的原因;然后寻求官方支持;再按照官方要求收集数据,日志;拿到这些之后他会去分析。而很多时候厂家会告诉你:“这个问题以前已经碰到过了,这是我们一个case,并且已经在官方发布了一个文档,你们按照这个文档的步骤去进行配置解决,事情就搞定了。

 

整个的过程看起来,是我们日常处理过程中做的最多的地方。但我们深思一下,在整个过程里有没有问题?这个时间是不是太久了?来来回回的沟通成本和解决问题的时间成本是不是太长了?尤其是这些官方已经知道的问题,我们还需要把流程再走一遍,这简直就是浪费嘛!

 

所以我们想到要做日志检测,这样如果我们在日志里面发现问题,当时立刻发现,立刻解决,那是不是要更快一些,更好一些?我们要把这种被动地分析问题变为主动地发现问题。

 

那主动发现问题要怎么做呢?

 

图片

 

  • 建立产品问题库:包括通过爬虫获取官网问题和自建问题。

 

  • 建立产品日志白名单库:对于检测出来的无效问题,加入白名单,减少无效告警。

 

  • 日志实时检测:实时告警,展示命中的已知问题。

 

  • 问题库搜索:根据贴入的关键字或者日志查找最可能遇到的问题。

 

图片

 

总体算法思路:

 

基于机器学习自然语言处理的能力,将文本处理成向量,然后基于文本相似度来计算是否命中已知问题。

 

当前困难与解决思路:

 

  • 问题1:日志片段计算出来的词向量过少

 

思路:通过命中词多少或者向量总和大小设限,过滤日志。

 

  • 问题2:日志命中非关联问题。

 

思路:主要原因是问题库中的问题特征可能包含很多日志片段,当前日志命中的是非关键片段,导致误报。

 

一种方法是健全白名单库,将非关键片段放入白名单。另外一种方法是健全问题特征,将关键片段标注为问题特征。

 

  • 问题3:日志命中非关键问题。

 

思路:部分问题是可忽略的,不需要告警。这部分问题可标注为白名单。

 

  • 问题4:新问题不断产生,模型滞后。

 

思路:定期爬取新问题和定期重新训练更新模型。

 

我们来看一下效果,我这边是列了一个比较简单的例子:

 

图片

 

比如在这段日志内容里面,最上面有这样一串日志,模型会在你的问题库和日志内容里面都去寻找,把其中的一些关键词给列出来,并且把它的权重也列出来。那会发现说:这些关键词很可能是一个消息码,这个码如果对上的话那基本上就是一回事了。如果这些码对得上的时候,你基本上就能发现它们两个确实是很相关的。而最终,根本原因是不是这个还需要人为再判断一下。

 

但总体来说,它立刻就从你的已知的问题库里面,找到了跟这条日志相关的问题,这样就能达到一个很好的命中,然后自己去判断!

 

对于日志检测其实还有一定的改进的空间。

 

  • 自建问题库的价值更高,需要促进DBA们努力。

 

  • 连续的日志更容易精确反应问题,可以尝试对连续日志的分析检测。

 

  • 当前流行的转换日志文本为日志模板,再通过计算频率转化为数值分析问题模式,可以参考和研究是否具备可行性和可用性。

 

总体来说优化是无止境的,我们如果有想法、有思路、有时间的话,可以去把这些东西做得更好!

 

四、懂AIOps的DBA

 

最后跟大家探讨一下智能运维和DBA的关系。

 

我觉得我们DBA的运维工作也是一样,分为这样三个阶段:

 

第一个阶段是几年前,我们大家都是这种所谓的人力的经验运维。在这个阶段我们DBA都忙着做些手工的操作,装机、变更、监控、应急、巡检、调优等等。

 

现在大部分的企业其实都实现了所谓的工具运维,也就是自动化运维。自动化运维就是把以前我们重复的东西都扔到了工具里,让它去标准化、工具化。这样我们的工作就会变得更快一些。当然有一些任务可能工具搞不定,比如像应急、调优。对于工具来说,它不是标准化的东西,所以这还是需要更多地考验DBA的能力。我觉得我们现在的DBA还算是比较幸福的一代,只需要去做应急和调优就可以了。

 

但未来是属于智能化的时代。智能化的时代出现在两方面的提升,一方面,它大幅地提升了运维的质量;另一方面,其实也是提升了DBA的知识宽度和深度。比如说到了智能时代,都已经AI了,那还需要DBA干什么?

 

那DBA要干什么呢?DBA要做一个懂AI的DBA,知道要怎样去利用这些AI的技术来提升自己的运维能力。这件事情是要DBA去做的,而不是靠AI来做。因为AI如果你什么都不告诉它的话,它就是一个白痴。

 

所以我们DBA需要去想办法使用这些AI的技术,为AI的技术铺平道路,给AI的技术提供数据,建立相关的需求场景,帮助AI实现运维。

 

 AI实现完了之后,同时AI也会在整个数据分析里面获取到更多知识、更多经验。再把这些东西反馈给DBA。DBA拿到这些东西之后会觉得:我以前怎么没有发现这个?或者,我以前怎么还不知道这个?

 

那你现在已经从原来的"救火队员",变成一个更懂你的数据库的DBA了,所以你的经验和能力会更上一层。

 

图片

 

那么我们把DBA的工作和 AI的工作放在一起,从底向上怎样去实现运维的提升?

 

DBA需要去准备数据,提供给AIOPS来分析;

 

DBA还需要去创造智能模型,这些智能模型可能是DBA创造的,也可能是一些成型的,或者是行业里面其他的DBA发现的,又或者是其他厂家发现的。总体来说,这些智能模型是通过DBA的创新思路一点点总结起来的,并且一定能够去泛化开来。AI拿到模型之后,它会得出一些相关的结论;

 

这些结论会反馈给DBA,然后DBA从AI给的模型结果里面判断,AI是对的还是错的?大部分情况下它可能是对的,在对的情况下很简单,照着AI给的办法去做就可以了;如果它是错的,那我就需要思考:是不是还有什么地方做的不到位?为什么让它得出了这样错误的结论?是我以前的哪部分工作没做好?你需要去往前分析,让它做的更好一点,帮助AI做出更精准的决策。

 

所以AI能够辅助决策,而DBA就基于这些决策的动作去做你的决策。比如AI告诉你说:你这是一个日志写得很慢的问题,需要去调整一些相关的参数。那DBA现在就是很自动地就拿着这些方法去试一遍,看看是不是可以把这个问题解决。

 

当你发现你的AI做的挺好,每次决策大部分情况下都是对的;或者对于某一种类型基本上是百分百没问题。这种情况下就可以提升到下一个阶段,就是故障的自愈。这就不需要AI来辅助决策了。AI可以把这些列出来的决策作为一个固定的决策,自己发现、判断之后自己去做,当AI做完了之后,就相当于实现了故障自愈,因为这里面已经不需要DBA的参与了。

 

故障自愈就是AIOPS下一步的工作。DBA就拿着它的故障自愈和之前的一些告警信息等等,做一定的复盘和优化。这些复盘和优化,是有AI的数据基础和自己的经验基础的,做的这些事情,比现在没有AI的情况下其实要准确很多。

 

那最终:自动驾驶。如果我们通过复盘优化,通过以往攒的经验,将这个方面的东西都做到极致的情况下,我们是不是可以实现自动驾驶?放心地把故障的自愈、调配资源或各方面的任务都扔给 AI来做。让AI自己在整个云化的环境里面去控制这些东西。这是我们的终极目标。

 

今天的分享就到这里,其实我今天最主要是跟大家分享一定的思路,也希望大家能够将你们的、比较新颖的思路来跟我一起探讨!
 

获取本期PPT,请添加群秘微信号:dbachen

↓点这里回看本期直播

 

阅读原文

最新评论
访客 2021年09月03日

有没有1000多张表

访客 2021年08月28日

metrics =》 metrix 错误

访客 2021年08月25日

只看到如何避免,如何减少书写慢 sql

访客 2021年08月25日

没看到如何治理呀

访客 2021年07月23日

果然k8s不是神!

活动预告