4.2.可观测性应用场景

4.2.1.基于Elasticsearch实现预测系统

创作人：田雪松

审稿人：李捷

业务背景介绍

当代商业组织面临的最基本挑战，是互联网已经不再是一个替代或可选渠道，它已经成为许多企业最主要的、甚至是惟一的销售平台。网上店面在现实中往往比实体店面还要重要，所以人们就必须要像监视实体店面一样，监控网上应用。

监控系统通常会以推送（Push）或拉取（Pull）的方式，从服务或应用中获取监控指标

（Metrics），并在监控指标出现异常时，发送警报或恢复服务，以实现网上店面实时可用的目标。

监控系统在提升了应用可用性同时，还在日积月累中形成海量监控数据，而从这些监控数据中可以挖掘出巨大的商业价值。监控指标会包含一些特定业务场景下的业务数据，借助大数据分析工具对它们进行处理和建模后，就可以辅助人们作出正确的市场决策。

本章要介绍的案例就是基于 Elasticsearch 对监控数据进行商业挖掘的一次尝试，我们内部称这套系统为 Prophet（大预言家）。Prophet 通过机器学习对历史监控数据进行处理，并创建预测模型，最终可以实现对单次用户请求处理的全面预测，包括处理结果是否成功、处理执行时长等等。

Prophet预测系统架构

Prophet 虽然只是监控数据最终的分析处理服务，但支撑 Prophet 实现智能预测的整个系统

却涵盖了四个主要部分：

l 第一部分是产生海量监控数据的监控系统，它从被监控的业务系统中拉取监控数据，并提供实时告警服务。

l 第二部分则是将监控数据，从监控系统中导入到 Elasticsearch 集群的数据系统，它还负责对监控数据进行清洗、转换。

l 第三部分是用于存储历史监控数据的 Elasticsearch 集群，我们借助 Elasticsearch 冷热模型，延长了监控数据的保存时间。

l 而最后一个才是最终处理这些数据的 Prophet 服务，它通过 Spark 运算集群，实现智能预测功能，未来还会添加更多数据分析功能。

四个系统之间的数据流动关系如图 1-1 所示：

图1-1 Prophet周边生态

除了 Elasticsearch 以外，HDFS 也是存储历史监控数据的一种不错选项，并且 HDFS 更容易与 Hadoop 的大数据生态系统集成。

我们之所以采用 Elasticsearch 主要还是被 Elasticsearch 强大的检索能力所吸引。同时，

Elastic Stack 家族中的 Kibana 还提供了强大的数据可视化能力，至于数据分析则可以利用 elasticsearch-hadoop 插件整合 Hadoop 生态。

使用 Elasticsearch 存储监控数据

在 Prophet 诞生之前，我们的业务系统已经使用 Prometheus 做到了实时监控，同时还通过 Grafana 对监控数据做了可视化处理。

但 Prometheus 监控数据存储，在其内置 TSDB（Time Serie Database）中，Prometheus

TSDB 中并没有分片和副本等概念，而只是简单地将数据保存在本地硬盘上。这意味着 Prometheus 无法支持数据高可用，同时也意味着 Prometheus TSDB 中的数据不能保存太久，否则本地硬盘迟早会被积累的数据撑爆。所以 Prometheus 默认只保存监控数据 15 天，超过这个时间后监控数据就会被直接删除。

对于一个监控系统来说这并不算什么大的问题，因为监控系统通常对实时数据更感兴趣，它只要能够实时快速地反映，被监控系统的异常就足够了。而历史数据分析和处理，并不能算是监控系统的职责范畴，应该交由 Elasticsearch 这样更专业的数据检索与分析工具来实现。

从另一个角度来说，由于预测系统，必须要基于历史数据创建预测模型，而如果直接在 Prometheus TSDB 上进行高频度的模型运算，则有可能会对监控系统本身造成性能上的影响。从系统监控与数据分析的职责角度来看，监控系统的稳定性无疑比数据分析更为重要。所以预测系统使用的历史数据，应该与 Prometheus 隔离开来，这就要求监控数据得从 Prometheus 中同步到 Elasticsearch 。一旦数据从 Prometheus 进入到 Elasticsearch ，我们就可以利用

Elasticsearch 冷热架构对数据进行优化以保存更长时间。

《Elastic Stack 实战手册》——四、应用实践——4.2 可观测性应用场景 ——4.2.1.基于Elasticsearch实现预测系统(2) https://developer.aliyun.com/article/1226133