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

如果在使用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运行的步伐，在现实生产中，异常是很常见的，需要有这样的容错机制。但是否碰到所有异常，都要立刻挂掉再重启呢？显然不是，甚至在一些场景下，你纵然重启了，还是会继续挂掉。我们的办理思绪是：尽大概把异常包住，让异常发生时，暂时不影响服务。

图 2 作业异常重启架构图
如图2所示，包住异常，并不意味可以忽略它，必须把异常收集到Spark Driver端，接入监控（报警）系统，人工判断问题的严肃性，确定修复的优先级。 为了更好地掌控Spark Streaming服务的状态，我们还单独开发了一个作业调度（重启）工具。美团点评数据平台安全认证的有效期是7天，一样平常离线的批处理作业很少会运行凌驾这个时间，但Spark Streaming作业就不同了，它需要不绝保持运行，所以作业只要凌驾7天就会出现异常。因为没有找到优雅的办理方案，只好粗暴地使用调度工具，每周重启刷新安全认证，来包管服务的稳定。
升级重导

Spark提供了2种读取Kafka的模式：“Receiver-based Approach”和“Direct Approach”。使用Receiver模式，在极端环境下会出现Receiver OOM问题。 使用Direct模式可以避免这个问题。我们使用的就是这种Low-level模式，但在一些环境下需要我们本身维护Kafka Offset： 升级代码：开启Checkpoint后，如果想改动代码，需要清空之前的Checkpoint目录后再启动，否则改动大概不访问效。但当这样做了之后，就会发现另一个问题——步伐“忘记”上次读到了哪个位置，因为存储在Checkpoint中的Offset信息也一同被清空了。这种环境下，需要本身用ZooKeeper维护Kafka的Offset。 重导数据：重导数据的场景也是，当希望从之前的某一个时间点开始重新开始计算的时候，显然也需要本身维护时间和Offset的映射关系。 本身维护Offset的成本并不高，所以看起来Checkpoint功能很鸡肋。其实可以有一些特殊用法的，例如，因为Python不需要编译，所以如果使用的是PySpark，可以把主要业务逻辑写在提交脚本的外边，再使用Import调用。这样升级主要业务逻辑代码时，只要重启一下步伐即可。网上有不少团队分享过升级代码的“黑科技”，这里不再睁开。 实现24/7监控服务，我们不但要办理纯稳定性问题，还要办理耽误问题。
低耽误

App异常监控，需要包管数据耽误在分钟级。 虽然Spark Streaming有着强大的分布式计算本领，但要满足用户角度的低耽误，可不是单纯的能计算完这么简朴。
输入问题

iOS App瓦解时，会生成Crash Log，但其内容是一堆十六进制的内存地址，对开发者来说就是“天书”。只有经过“符号化”的Crash Log，开发者才华看懂。因为符号化需要在Mac环境下进行，而我们的Mac集群资源有限，不能符号化全部Crash Log。纵然做了去重等优化，符号化后的数据流还是有耽误。每条异常信息中，包含N维数据，如果不做符号化只能拿到此中的M维。

图 3 双耽误乱序数据流融合示意图
如图3所示，我们将数据源分为符号化数据流、未符号化数据流，可以看出两个数据流的相对耽误时间T较稳定。如果直接使用符号化后的数据流，那么全部N维数据都会耽误时间T。为了低沉用户角度的耽误，我们根据履历加大了时间窗口：先存储未符号化的M维数据，比及拿到对应的符号化数据后，再覆写全部N维数据，这样就只有N-M维数据耽误时间T了。
输出问题

如果Spark Streaming计算结果只是写入HDFS，很难碰到什么性能问题。但你如果想写入ES，问题就来了。因为ES的写入速率大概是每秒1万行，只靠增长Spark Streaming的计算本领，很难突破这个瓶颈。 异常数据源的特点是数据量的波峰波谷相差巨大。由于我们使用了 Direct 模式，不会因为数据量暴涨而挂掉，但这样的“稳定”从用户角度看没有任何意义：短时间内，数据耽误会越来越大，暴增后新出现的异常无法实时报出来。为了办理这个问题，我们制定了一套服务降级方案。

服务降级方案示意图
如图4所示，我们根据写ES的现实瓶颈K，对每个周期处理的全部数据N使用水塘抽样（比例K/N），包管始终不凌驾瓶颈。并在空闲时候使用Spark批处理，将N-K部分从HDFS补写到ES。既然写ES这么慢，那我们为什么还要用ES呢？
高性能

开发者需要在监控平台上分析异常。现实分析场景可以抽象描述为：“实时 秒级 明细 聚合” 数据查询。 我们团队在使用的OLAP办理方案可以分为4种，它们各有各的优势：

• SQL on HBase方案，例如：Phoenix、Kylin。我们团队从2015年Q1开始，一连在SEM、SEO生产环境中使用Phoenix、Kylin至今。Phoenix算是一个“万能选手”，但更得当业务模式较固定的场景；Kylin是一个很不错的OLAP产品，但它的问题是不能很好支持实时查询和明细查询，因为它需要离线预聚合。另外，基于其他NoSQL的方案，根本大同小异，如果选择HBase，发起团队在HBase运维方面有一定积聚。
  
• SQL on HDFS方案，例如：Presto、Spark SQL。这两个产品，因为只能做到亚秒级查询，我们平常多用在数据发掘的场景中。
  
• 时序数据库方案，例如：Druid、OpenTSDB。OpenTSDB是我们旧版App异常监控系统使用过的方案，更得当做系统指标监控。
  
• 搜索引擎方案，代表项目有ES。相对上面的3种方案，基于倒排索引的ES非常得当异常分析的场景，可以满足：实时、秒级、明细、聚合，全部4种需求。
  

ES在现实使用中的表现怎样呢？
明细查询

支持明显查询，算是ES的主要特色，但因为是基于倒排索引的，明细查询的结果最多只能取到10000条。在异常分析中，使用明细查询的场景，其实就是追查异常Case，根据条件返回前100条就能满足需求了。例如：已知某设备出现了Crash，直接搜索这个设备的DeviceId就可以看到这个设备迩来的异常数据。我们在生产环境中做到了95%的明细查询场景1秒内返回。
聚合查询

面对爆炸的异常信息，一味追求全是不现实，也是没必要的。开发者需要能快速发现关键问题。 因此平台需要支持多维度聚合查询，例如按模块版本机型城市等分类聚合，如图5所示。

图 5 聚合查询页面截图
不用做优化，ES聚合查询的性能就已经可以满足需求。因此，我们只做了一些小的使用改进，例如：很多异常数据在各个维度的值都是相同的，做预聚合可以提高一些场景下的查询速率。开发者更关心迩来48小时发生的异常，分离冷热数据，自动清算历史数据也有助于提升性能。终极在生产环境中，做到了90%的聚合查询场景1秒内返回。
可扩展

异常平台不止要监控App Crash，还要监控服务端的异常、性能等。不同业务的数据维度是不同的，相同业务的数据维度也会不绝的变化，如果每次新增业务或维度都需要修改代码，那整套系统的升级维护成本就会很高。
维度

为了加强平台的可扩展性，我们做了全平台联动的动态维度扩展：如果App开发职员在日志中新增了一个“城市”维度，那么他不需要接洽监控平台做项目排期，立刻就可以在平台中查询“城市”维度的聚合数据。只需要制定好数据收集、数据处理、数据展示之间的交互协议，做到动态维度扩展就很轻松了。需要留意的是，ES中需要聚合的维度，Index要设置为“not_analyzed”。 想要支持动态字段扩展，还要使用动态模板，样例如下：

1. {
2.     "mappings": {
3.         "es_type_name": {
4.             "dynamic_templates": [
5.                 {
6.                     "template_1": {
7.                         "match": "*log*",
8.                         "match_mapping_type": "string",
9.                         "mapping": {
10.                             "type": "string"
11.                         }
12.                     }
13.                 },
14.                 {
15.                     "template_2": {
16.                         "match": "*",
17.                         "match_mapping_type": "string",
18.                         "mapping": {
19.                             "type": "string",
20.                             "index": "not_analyzed"
21.                         }
22.                     }
23.                 }
24.             ]
25.         }
26.     }
27. }

复制代码

资源

美团点评数据平台提供了Kafka、Spark、ES的集群，整套技术栈在资源上也是分布式可扩展的。 线上集群使用的版本： - kafka-0.8.2.0 - spark-1.5.2 - elasticsearch-2.1.1


from :
Spark Streaming + Elasticsearch构建App异常监控平台 - 美团技术团队
Spring Data REST 远程代码执行漏洞（CVE-2017-8046）分析与复现 - 美团技术团队
LruCache在美团DSP系统中的应用演进 - 美团技术团队
iOS 覆盖率检测原理与增量代码测试覆盖率工具实现 - 美团技术团队
一样平常开发Guava提效工具库核心实用指南梳理_guava string转list-CSDN博客
从ES的JVM设置起步思索JVM常见参数优化_es jvm设置-CSDN博客
异步处理优化：多线程线程池与消息队列的选择与应用_模版模式使用-CSDN博客



免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。