原文：曹镏 高效开发运维 2018/05/28

本文概述了有货 App 团队的同学，在资源有限的情况下，自己动手，借助多种数据工具，通过简洁的架构，为有货 App 开发一套多维实时的监控系统，从而更好地完成自己的工作，也给其他团队的小伙伴在自建 APM 的道路上提供一个参考，为移动端的 DevOps 打开一些思路。

得益于智能手机的发展，当下我们对用户的体验追求已经到了几乎极致的程度。主流的监控 OneAPM，New Relic… 由于面向广大用户，强调数据共性，很难通过 UDID 或者 UID 来定位一些比较难以复现或局部的问题。同时由于数据保密性等原因，对事件上报的信息量也是非常的有限。随着用户规模的增长，特殊问题，局部问题覆盖的用户越来越来，自建监控就一个必然的选择。

需求是迫切的，资源是有限的。为了尽快的上线监控系统。有货 iOS 和 Android 的小伙伴们本着 “流自己的汗，吃自己的饭，自己的事情自己干” 的原则，不强调客观条件，自己撸出了一套 App 的 APM 监控系统。

设计

我们把问题处理的流程大致梳理为 “持续监控”、“发现问题” 、“定位问题”、“修复问题”。这往复的四个步骤，其中“监控”，“发现” 和“定位”都依赖于系统的采集和上报。

通过对需求的分析，我们把数据以事件的形式上报，上报后数据根据场景分为两类：

1. 指标类数据
2. 日志类数据

1. 指标类数据

指标类数据主要是对用户上报的信息根据我们需要的维度做聚合，便于我们掌握 app 的整体情况，比如用户整体的网络错误，网络延时。从整体的角度观察我们 app 的健康程度。 这个过程概括为 “发现问题”。

2. 日志类数据

日志类数据则记录完整的上报数据，用于我们对问题的诊断。 这个过程概括为 “定位问题”。
围绕这两类数据的采集和分析，我们启动了第一阶段的项目。

第一阶段

App 将事件数据上报至 OpenResty，在 OpenResty 中对请求进行简单的处理和封装，拆分成指标和日志，然后将处理完成的数据分别写入 InfluxDB 和 MongoDB 中。再通过 Grafana 实现数据可视化。通过一个 Web 页面来查询存储在 MongoDB 中的日志。

App 上报的数据转换为有意义的指标, 这个过程是靠 “聚合” 来实现的。这套系统中 “聚合” 则是借助 InfluxDB 完成的。

InfluxDB

在 InfluxDB 中，我们先将所有数据写入不同类型的事实表中，然后通过多个 Continuous Query 对数据进行聚合处理，把大量的明细数据聚合成一定时间周期的聚合数据（主要的周期为 30 秒或 1 分钟），再通过 Retention Policy 来控制不同类型表的数据有效期，达到资源最高效利用的目的。

数据可视化部分则用 Grafana 来支撑的，我们的 Main Dashboard 通过 20 张的图表来展示整体的健康状况，同时在这 20 张图表背后，还有数个更加详细的图表支撑微观方面数据。

比如有张图表绘制的是当前全网用户设备发生的网络错误率。 通过这个指标和 24 小时前的对比，我们能够直观了解整体的网络健康状况。当该指标超过某个阈值或相比昨天同时段对比有明显上升，则触发告警。实现 “发现问题”。

当出现告警后，通过网络相关的 dashboard 查看是由哪个接口发生的，什么类型的错误。再根据错误类型去日志平台查询日志。完成 “定位问题”。

MongoDB

对于日志数据我们直接将上报的 json 内容逐条拆分后写入 Mongodb。直接通过 web 页面从 Mongodb 查询对应时间的 App 日志。

这套系统的优势体现在架构非常的轻盈，成本很低。只需要简单的 OpenResty 的开发以及对 InfluxDB 做一些连续查询。在日志量不大的情况下，完全可以满足基本的移动端性能监控以及异常监测的需求。

在运行了一段时间后，我们有了新的需求。

中国有 23 个省，5 个自治区，4 个直辖市，以及香港、澳门 2 个特别行政区。电信、联通、移动三大运营商。网络制式从 2G、3G、4G 到 WiFi，还有各种各样的移动设备。这些条件构成了数量难以想象的场景。当仅仅在个别场景下发生问题，或是部分场景下发生问题的时候。我们 “发现问题” 的即时性会变差，“定位问题”所用的时间也越发的变长。

为了缩短 “定位问题” 的时间。提高发现问题和解决问题的效率。多维分析能力是我们所渴望的，如果在原有的系统上做多维分析，存在如下问题：

1. InfluxDB 缺乏合理免费的集群方案，我们在建立了自己的 APM 以后，客户端同学对数据和监测的需求突飞猛进，数据量每天以几何级数增长，再对其进行多维分析，单机的 InfluxDB 很难满足性能要求。

2. MongoDB 在数据量很大的场景下，直接查询速度很慢。由于我们日志数据的多样性，在对多个维度建索引后，整体索引效率很低。

第二阶段

为了满足大量（这里暂时不成为海量）数据的多维实时查询的需求，我们对架构中数据库和数据摄入过程进行了升级，InfluxDB 变更为 Druid， MongoDB 变更为 Greenplum， 数据也不再由 OpenResty 直接插入，而是通过了 Kafka 和 log 文件把写入过程解耦，减少数据写入次数，提升处理数据的量级。

Druid

Druid 是在海量时序数据上面提供实时分析查询的开源 OLAP 数据存储。

Druid 本身对于 join 这样的操作很不友好，所以我们没有考虑用一些模型（星型或者雪花型），而是采用大的事实表，其中包含了一次事实关联的所有维度，看着很臃肿，但是查询的性能让人满意。在随时变更维度的情况下，Druid 实时查询依然维持在秒级。这不得不让人刮目相看。

同时丰富的查询组件和聚合函数，让复杂的查询得以简单的实现。所以在查询性能、便捷性、数据量等方面的综合考量下，我们选择了 Druid 作为 InfluxDB 的升级方案。

不同于 InfluxDB，我们不再通过连续查询来做数据聚合，Druid 自身在摄入的过程中可以对指定的 Dimension 进行 roll-up 操作。极大的压缩了数据量。我们的数据经过 roll-up，每分钟从 25 万条压缩到了 8 万多条，效果比较显著。不过压缩数据是以牺牲原始数据为代价的，预聚合仅保留指定的 Dimension 及 Aggregations 结果，所以请妥善设置 Dimension。 Dimension 会发生 SQL 中 Group By 的效果，参数维度多势必降低聚合效果。尤其需要的注意 Dimension 的选择，如果一不小心选择了高基字段作为 Dimension，那么压缩效率会低的惊人。我们曾经因为数据处理的失误，将一个 Dimension 的 Value 数从 2000 变成了 200W, 直接导致当天的 segments 占用的空间比以往大 22 倍。通过摄入周期的调整，还可以做到更大的压缩比，这个取决 queryGranularity 字段，它决定了压缩后的数据最小时间粒度，目前我们使用的是分钟。

在使用 Grafana 接入 Druid 的时候还是遇到一些小坑，由于 Grafana 官方集成的 Druid 插件实在是功能太有限，比如对 Time Range 的限制，我们不得不在源码的基础上做了部分调整。

Kafka

Druid 两种数据摄入源:

1. 流式数据
2. 静态文件数据

这两种数据源又都有两种方式摄入，分别为 pull 方式和 push 方式。我们采用了 real time index（push 的一种）方式，启动实时 task 来从 kafka 中摄取数据。

Greenplum

Greenplum 相比我们原先使用的 MongoDB, 支持列式存储, 并行查询效率更高。在不建索引的情况下，50 列千万级别的数据在 1，2 秒能查完，完全满足我们对日志查询的需求。

起初我们使用 Http 的方式批量插入 Greenplum，但是当写入速度超过 6 千条每秒时，查询速度直线下降。

明显写入不是 Greenplum 的强项，为了解决这个问题，我们是把日志以文件的形式写入 NFS 中, 由 Greenplum 定时摄入。

同时为了保证性能和简化写入，还对 OpenResty 的写入进行了优化，利用 nginx 的 subrequest 写 access.log 的功能来实现日志写入，并且整个过程封装到协程中执行。调整后每分钟能够轻松写入 50 万条。

总结

这套系统对个性问题，共性问题的快速甄别起到了关键性的作用，也极大的提升了定位问题的速度。在针对某些维度或特征做针对性的优化的时候，效果也更容易监控。

通过不同类型事件的采集，我们还实现了页面响应时间（多维）、http 请求分阶段响应时间（多维）、页面卡顿分析、页面加载性能监控等多方位的监控系统，为我们的优化工作指明了方向。对于 iOS 或者 Android 开发的同学，这样一套系统既能满足需求，也易于开发，相比传统 ELK 日志分析在实时性和简易性都提升很多。

如果技术团队的资源比较紧张，移动端的同学自己动手实践下 DevOps 也是不错的选择。