Elasticsearch Machine Learning AIOps 实践

项目背景

公司内部封装了NLP通用算法的GRPC服务,比如文本情感识别、文本分类、实体识别等, 提供给大数据等其他部门实时调用。

RPC 服务的调用日志,通过Filebeat、Logstash 实时发送到Elasticsearch,现在需要通过对日志的调用情况实时统计分析,判断调用情况是否出现异常,并对异常情况能够实时告警。

业务场景分析

pic

使用ES 的watcher 插件创建一个threshold alert, 设置预警规则,当一个时间周期内的数据量达到阈值, 就进行告警。

这种方案优点是,设置起来比较简单,只要设置query的条件,以及阈值就可以快速完成。 缺点是,这种方案比较适合粗粒度,并且阈值明确的情况下设置。

设想一下,如果要做到分钟级实时监控,并且对异常点进行告警通知,如果用规则来设置,很难满足这种场景。 针对这种场景,很容易想到,使用Machine Learning (ML)的方法,根据以往的数据变化趋势,来主动发现异常点,那就简单多了。

针对这种需求, 有很多解决方案,比如,把日志实时发送到KAFKA,再用FlinkML 来做机器学习,训练异常检测模型, 不过多讨论这种方案。 如题, 这里介绍一种更简单的方案,使用 ES Stack 提供的 ML 模块, 很容在ES Stack上快速体验AIOps。

实践经验

Requirements
  • ELK 6.4.3
  • Xpack Machine Learning
日志结构
{
  "@timestamp": "2019-10-09T09:10:22.547Z",
  "@version": "1",
  "call_day": "20191009",
  "call_hour": "2019100909",
  "call_minute": "201910090910",
  "call_time": "10-09 09:10:21.714317",
  "cost": 0.004031,
  "method": "Nlp.ContentCategory",
  "month": "10",
  "service_name": "mg",
  "timestamp": "2019-10-09T09:10:22.547Z"
}
  • @timestamp 日志写入时间,后面的时序统计就是依据这个时间字段
  • cost 调用方法消耗时间,可以利用这个字段的平均值来预测方法耗时是否异常
  • method 调用的方法
  • service_name 调用的服务名称
目的
  • 使用历史日志数据,训练异常检测模型,并找出异常的点
  • 使用训练出来的模型,检测后面的实时日志数据,发现新的异常点,并进行告警
步骤

创建Job

JOB

有四种创建ML Job的模式:

  1. 单指标模式:使用单一指标作为模型特征参数
  2. 多指标模式:使用多指标作为模型特征参数
  3. 种群分析模式:种群分析,找出不合群的点
  4. 高级模式:可以灵活的设置各种模型指标

为了简单起见,这里使用单一指标模式来创建ML Job

pic

  • 选择时间段,尽量选择足够长的时间段,提供足够多的数据喂给ML模型
  • Aggregate: 聚合统计的方法,Count、High Count、Low Count、Mean、High Mean、Low Mean等,这里选择 Count方法, 表示统计特定时间窗口数据量,如果检测点的数据量超过模型计算值上下边界值的,都算作是异常点
  • Bucket Span 统计的时间窗口大小

配置告警阈值

pic

针对检测结果的严重程度进行邮件告警

查看检测结果

pic

通过Anomaly Explorer 可以很容易找到异常的点

pic

同时,通过Metric Viewer也很直观的查看异常周边的变化趋势,下面举例介绍一下,2019-09-19异常点的情况

pic

从上图可以看出,在10:00/09:00/08:00/07:00 分别检测出了不同程度的异常, 其中severity值的大小,表明了异常的严重程度,severity值越大,说明这个异常越偏离正常情况。

probability是事情发生的概率,值越小,这个事件发生的可能性越小,从而说明如果这个事件发生了,肯定是不寻常的,跟上面severity反应的情况也是自洽的。

typical 是典型值,就是根据以往数据学习的模型,预测这个时间段的数据量是应该是多少

actual 是实际值,是这个时间段的统计的真实数据量,如果跟typical差异越大,出现异常的可能性就越大

产生结果解释

上述的检测结果来自真实业务场景,在7点到10点之间的业务调用方出现异常,导致在7点到10点之间的RPC服务日志产生量减少。ML 通过对以往数据的特征的学习,对这个时间段的日志量进行预测,发现实际结果与预测结果不符合。 在10点以后,业务调用方恢复正常,预测的结果跟实际调用量也是相吻合,在最终的结果图上也是反映回到正常曲线。

Bucket Span 调优

Bucket (桶) ,在进行实时数据流分析的时候,使用桶来区分指定时间窗口的数据,桶的大小,反映了每个窗口的数据量的大小, 也就是每次给ML喂的数据量的大小。

上面的结果是对桶大小进行调优后的效果,选择的Bucket Span 是5min, 最初选择的Bucket Span是15min, 没有把异常点很好的检测出来。

pic

上图桶大小是15min,从图上可以看出来,没有把7点这个异常点检测出来,同时异常的重要程度不够。

pic pic

设置1min的效果,同样不能把异常点检测很好的出来,而且受到噪音的干扰比较大,检测到很多严重程度很低的小的异常点。

调优参考:

  • 桶的大小不宜设置太小,如果太小,虽然喂给ML的数据变多,但是在很小的时间段内,数据的变化比较频繁,产生大量的噪音,不利于模型的学习。反之,如果桶的大小设置太大了,将会丢掉很多细节信息,而且可能导致喂给ML的数据量不足,甚至把某个异常点给丢掉了。桶的大小要根据业务场景来,如上的场景,想尽快发现调用的异常,在数据量比较充足的情况下,设置5min是比较合适的。当然,这也不是绝对的情况,需要不断地调整这个值的大小,找到合适的值。

  • ES ML 提供了一键预估(Estimate bucket span) Bucket大小,但是这个功能并不是很智能,不能完全依赖,还需要自己不断调试

  • 尽量给ML喂更多充足的数据,数据量太少,ML不能很好的拟合数据,预测的结果也是不准确的

  • 排除掉一些已知的“异常”数据,比如,周末的数据调用量下降很多,如果也直接喂给模型的话,会对预测结果产生干扰。好在,ES 提供了calendar功能,可以把特定时间段的移除,这个时间段的数据不算做异常。

pic

  • 使用多指标模式,选择更多的影响因子,使训练出来的模型更加健壮

  • 由于数据不断变化,持续把更多更新的数据喂给模型,使其能够学习到新的特征,以适应新的数据

总结

一个完善的AIOps体系还有很多工作要做,上述只是整个体系中一小块,好在ES Stack现在越来越完善,下一步可以考虑把APM、Machine Learning整合起来,使用APM 对系统性能进行监控,使用ML对系统的各项指标进行建模,预测机器的使用趋势,并做到动态伸缩。