Spark Streaming + Elasticsearch构建App异常监控平台10

如果在使用App时遇到闪退，你可能会选择卸载App、到应用商店怒斥开发者等方式来表达不满。但开发者也同样感到头疼，因为崩溃可能意味着用户流失、营收下滑。为了降低崩溃率，进而提升App质量，App开发团队需要实时地监控App异常。一旦发现严重问题，及时进行热修复，从而把损失降到最低。App异常监控平台，就是将这个方法服务化。

低成本

小型创业团队一般会选择第三方平台提供的异常监控服务。但中型以上规模的团队，往往会因为不想把核心数据共享给第三方平台，而选择独立开发。造轮子，首先要考虑的就是成本问题。我们选择了站在开源巨人的肩膀上，如图1所示。

图1 数据流向示意图

Spark Streaming

每天来自客户端和服务器的大量异常信息，会源源不断的上报到异常平台的Kafka中，因此我们面临的是一个大规模流式数据处理问题。美团点评数据平台提供了Storm和Spark Streaming两种流式计算解决方案。我们主要考虑到团队之前在Spark批处理方面有较多积累，使用Spark Streaming成本较低，就选择了后者。

Elasticsearch

Elasticsearch（后文简称ES），是一个开源搜索引擎。不过在监控平台中，我们是当做“数据库”来使用的。为了降低展示层的接入成本，我们还使用了另一个开源项目ES SQL提供类SQL查询。ES的运维成本，相对 SQL on HBase方案也要低很多。整个项目开发只用了不到700行代码，开发维护成本还是非常低的。那如此“简单”的系统，可用性可以保证吗？

高可用

Spark Streaming + Kafka的组合，提供了“Exactly Once”保证：异常数据经过流式处理后，保证结果数据中（注：并不能保证处理过程中），每条异常最多出现一次，且最少出现一次。保证Exactly Once是实现24/7的高可用服务最困难的地方。在实际生产中会出现很多情况，对Exactly Once的保证提出挑战：

异常重启

Spark提供了Checkpoint功能，可以让程序再次启动时，从上一次异常退出的位置，重新开始计算。这就保证了即使发生异常情况，也可以实现每条数据至少写一次HDFS。再覆写相同的HDFS文件就保证了Exactly Once（注：并不是所有业务场景都允许覆写）。写ES的结果也一样可以保证Exactly Once。你可以把ES的索引，就当成HDFS文件一样来用：新建、删除、移动、覆写。 作为一个24/7运行的程序，在实际生产中，异常是很常见的，需要有这样的容错机制。但是否遇到所有异常，都要立刻挂掉再重启呢？显然不是，甚至在一些场景下，你即使重启了，还是会继续挂掉。我们的解决思路是：尽可能把异常包住，让异常发生时，暂时不影响服务。