做试客需要去哪些网站,比比西旅游网站建设,贵州建设厅考试网站准考证下载,微信授权登录第三方网站开发本文已发表在《程序员》杂志2016年10月期。 如果在使用App时遇到闪退#xff0c;你可能会选择卸载App、到应用商店怒斥开发者等方式来表达不满。但开发者也同样感到头疼#xff0c;因为崩溃可能意味着用户流失、营收下滑。为了降低崩溃率#xff0c;进而提升App质量#xf… 本文已发表在《程序员》杂志2016年10月期。 如果在使用App时遇到闪退你可能会选择卸载App、到应用商店怒斥开发者等方式来表达不满。但开发者也同样感到头疼因为崩溃可能意味着用户流失、营收下滑。为了降低崩溃率进而提升App质量App开发团队需要实时地监控App异常。一旦发现严重问题及时进行热修复从而把损失降到最低。App异常监控平台就是将这个方法服务化。 低成本 小型创业团队一般会选择第三方平台提供的异常监控服务。但中型以上规模的团队往往会因为不想把核心数据共享给第三方平台而选择独立开发。造轮子首先要考虑的就是成本问题。我们选择了站在开源巨人的肩膀上如图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所示包住异常并不意味可以忽略它必须把异常收集到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所示我们将数据源分为符号化数据流、未符号化数据流可以看出两个数据流的相对延迟时间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所示。 不用做优化ES聚合查询的性能就已经可以满足需求。因此我们只做了一些小的使用改进例如很多异常数据在各个维度的值都是相同的做预聚合可以提高一些场景下的查询速度。开发者更关心最近48小时发生的异常分离冷热数据自动清理历史数据也有助于提升性能。最终在生产环境中做到了90%的聚合查询场景1秒内返回。 可扩展 异常平台不止要监控App Crash还要监控服务端的异常、性能等。不同业务的数据维度是不同的相同业务的数据维度也会不断的变化如果每次新增业务或维度都需要修改代码那整套系统的升级维护成本就会很高。 维度 为了增强平台的可扩展性我们做了全平台联动的动态维度扩展如果App开发人员在日志中新增了一个“城市”维度那么他不需要联系监控平台做项目排期立刻就可以在平台中查询“城市”维度的聚合数据。只需要制定好数据收集、数据处理、数据展示之间的交互协议做到动态维度扩展就很轻松了。需要注意的是ES中需要聚合的维度Index要设置为“not_analyzed”。 想要支持动态字段扩展还要使用动态模板样例如下 {mappings: {es_type_name: {dynamic_templates: [{template_1: {match: *log*,match_mapping_type: string,mapping: {type: string}}},{template_2: {match: *,match_mapping_type: string,mapping: {type: string,index: not_analyzed}}}]}} } 资源 美团点评数据平台提供了Kafka、Spark、ES的集群整套技术栈在资源上也是分布式可扩展的。 线上集群使用的版本 - kafka-0.8.2.0 - spark-1.5.2 - elasticsearch-2.1.1