研发效能 · 实时监控 · 5W2H分析Android实时监控体系

友情链接: BaguTree B站分享

微信公众号: 小木箱成长营

你好，我是小木箱，欢迎参与小木箱成长营的研发效能系列教程。今天我们将分享研发效能 · 实时监控 · 5W2H分析Android实时监控体系的内容，专注于移动端实时监控体系的建设。这一体系基于过去在端上已经上线并使用的监控能力，移动架构组对移动中台体系建设进行了深入思考和总结。

今天的主题将围绕四个核心维度展开。首先，我们会讨论为何需要建设端侧实时监控；其次，我们将深入了解如何进行端侧实时监控的建设；最后，我们将探讨端侧实时监控的规划。

通过学习小木箱的体验优化系列教程，你将能够在移动客户端提高工作效率，为自己创造更多机会展现才华。

1. 为什么要建端侧实时监控

1.1 业务痛点

出发点是解决三个当前项目存在的业务痛点。首先，项目的复杂性使得维护老代码和开发新功能变得困难，导致指标数据在大盘数据上不统一，可能产生混乱。

1.1.1 项目复杂

首先，我们说说第一个业务痛点特征项目复杂，随着功能需求的累加，既维护老代码，又开发新功能，项目越来复杂庞大，指标数据在大盘数据上没有完全统一，各自可能会有各自指标，甚至混乱。

1.1.2 迭代周期短

然后，我们说说第二个业务痛点特征迭代周期短，为支持业务需求，从开发、测试到上线，两周一迭代，迭代周期短，线上稳定性面临很大的挑战。

现阶段迭代周期追求敏捷开发，一般两周一个迭代，从开发到上线，迭代周期短造成App 线上的稳定性面临很大挑战。

应用既支持单发布单能力也支持多发布单能力，开发迭代当中，版本既有技术需求发布也有业务需求发布。因此，版本风险衡量点和版本稳定性需要借助线上大盘监控能力进行查看。

1.1.3 指标各自为战

最后，我们说说第三个业务痛点特征指标各自为战，业务、性能、技术以及网络等数据指标打到各自的系统，没有统一布局和管理。

现阶段各个指标各自为战的，有后端监控，有端上代码度量监控，有端上APM监控，有端上启动耗时，也有端上网络监控。指监控标在各自系统承接和展现方式百花齐放，缺乏统一布局和管理能力。

基于以上项目复杂痛点、迭代周期短和指标各自为战，三个痛点，因此要建设移动端的统一的实时监控的能力。

1.2 对比

说我业务痛点，我们对比企业现有能力。差异点主要体现在神策、实时日志和定制化服务三个方面。

1.2.1 神策

第一个方面是神策，神策有三个缺点，分别是实时性低，T+1才有数据、人工查看数据，无告警能力和因数据安全，需要申请权限

实时性低，T+1才有数据；

首先，我们来说说神策的第一个缺点: 实时性低，T+1才有数据， 神策是趋向于对业务或技术的埋点，对数据 UV 和 PV 打点统计。神策可以按照时间或系统进行展示。但是神策缺点是缺少实时性，需要 T + 1 才能看到数据。

人工查看数据，无告警能力；

然后，我们来说说神策的第二个缺点: 人工查看数据，无告警能力， 数据需要人为分析查看，神策缺少自动告警能力，变好变差，要手动到系统查看。如果数据变坏，神策没有告警告线上指标劣化信息。

因数据安全，需要申请权限；

最后，我们来说说神策的第三个缺点:因数据安全，需要申请权限。因为数据安全的原因，因此企业对神策权限把控严格，很多人没有权限查看神策，很难通过神策进行线上问题定位 。

1.2.2 实时日志

第二个是实时日志用来分析线上问题，实时日志分析线上问题有三个缺陷，分别是查看分析线上个例问题、缺失告警，线上问题后置和没有大盘数据。

当线上反馈过来 case 有问题，比如说无法下单。我们根据用户反馈账户信息，比如 user fid 或手机号，去实时日志系统查日志，查到关键信息定位问题。但同样缺失告警能力。

线上问题反馈很后置，无法第一时间自动化告诉线上多少用户，哪个版本有问题，实时日志没有此功能。实时日志缺少大盘能力，实时日志体系大，每天有3TB存放到ES集群里，因此实时日志做大盘数据分析性能差。

1.2.3 定制化服务

第三个是定制化服务，定制化服务的原因有三个，分别是:

• 开发维护成本高；
• 新增指标需要后端额外开发；
• 无统一通道，增加App负担；

比如: 启动耗时服务，走定制化。如果有需求去采集特定数据，需要定制化开发需求，从 SDK 到前端到后端服务一条龙进行收集、落库和渲染定制化开发。

如果新增指标需要前后端排期开发，维护成本高，无法具备通用性，而且无法统一通道，比如每个指标都来一套服务，流量、内存和线程方面都会给App性能造成负担。

1.3 全景

实时监控监控体系的建设，是从面到点，从急到缓过程，从实时监控用户反馈到事故现场还原崩溃。第三点，说一下实时监控的全景。实时监控、用户反馈、事故冒烟和Crash奔溃是由面到点分析过程。

首先如果有实时监控，那么实时监控第一时间通过告警方式协助我们发现通知到具体App下面。

某指标劣化，跟同期的比如: T - 7 或 T- 1 时间维度去做对比。因为用户反馈、事件事故、冒烟、 crash 崩溃是相对滞后的线上问题的反馈，所以可以直接通过实时日志和离线日志去进行查询数据恶化情况。

通过以上场景反馈过来问题，再借助实时、离线日志结合代码和数据对问题归因。

王阳明说过： 志不立，如无舵之舟，无衔之马，漂荡奔逸，终亦何所底乎？

如果志向不确定，像没有舵的船，没有衔的马。实时监控有异曲同工之妙。

如果没有实时监控，线上稳定性、线上指标是失控的。如果没有实时监控，我们线上故障现场难以还原。

如果没有实时监控，只能24h oncall、团队轮流值班，定时观测上线情况，人肉发现线上问题。

如果通过实时监控，相当有了上帝之眼对App 关键指标进行观测。因此，着重下面讲解怎样建设端侧实时监控。

怎样建设端侧实时监控

1. 平台化设计：

   • 实现实时查看线上数据，提供可查能力的平台支持。
   • 确保系统具备可监控的能力，满足实时监测的需求。
   • 设计统一通道，以避免性能和流量的浪费。

2. 可扩展性目标：

   • 通过抽象定义线上网络 APM 和业务指标，以及协议，实现系统的可扩展性。
   • 提供便捷的新增协议方式，只需在协议基础上更改名字和指标类型即可支持。
   • 后端和前端无需改动，通过 SDK 收集的指标数据，通过前端面板配置即可实现可扩展性。

3. 零成本新增新指标监控：

   • 确保新增指标监控的零成本，降低维护成本。
   • 以易用性为目标，通过工具化的方式维护指标，保障两端指标在查看时的统一性。

4. 高性能目标：

   • 针对端上 App 的上传承载通道和数据写入的 SDK，设定高性能的要求。
   • 着眼于高效的写入速度，点上传流量的最小化，以及存储和上传的高安全性。

通过以上目标的设计，系统实现了平台化、可扩展性、零成本新增监控和高性能的要求。这确保了系统的稳健性、可维护性和易用性，满足了实时监控的核心需求。

平台化设计的三层架构

1. 客户端层：

   • 在第一层客户端中，Web 前端负责管理指标，而安卓和 iOS SDK负责集成和自定义指标的上传。
   • Web 层作为数据查看的后期能力，通过网关层的负载均衡，将前端、安卓和 iOS 的数据请求传递到最小的 handler S SVC 服务。这相当于 mount 服务的 gateway 层，同时参与额外服务相关能力。

2. 攻击防御和过滤策略：

   • 针对攻击防御，实施对 IP 抓包、恶意攻击、数据重复上传和设备重复上传的防护，并对 IP 和设备进行降级处理。
   • 设定过滤策略，对线上指标数据进行过滤处理，防止不合法或时间节点错传的数据。例如，防止上传昨天的数据，以避免对实时监控造成脏数据干扰，导致误导。

3. 合法性校验和黑名单管理：

   • 实施合法性校验，由于采用注册制，确保只有注册过的指标才能传达到后端服务。这考虑到指标数据存在容量限制，需要进行合法性校验以降低后端成本。
   • 管理黑名单，用于配置处理端上接入时无法预知的域名，拉黑名单管理不关心的指标数据。

4. Label 检查：

   • 在安卓和 iOS 接入文档中强调 Label 检查，以避免同一指标名在不同平台上的数据展示污染。例如，安卓和 iOS 同指标名时，通过 iOS key 取A1，而安卓则取相同的A1，以确保数据展示的准确性。

通过这样的架构和策略，平台化设计能够实现高效的数据管理和可靠的数据展示，同时保障系统的安全性和稳定性。

2. 怎样建设端侧实时监控

2.1 目标

2.1.1 平台化

• 实时查看线上数据；

•提供监控告警能力；

•统一上传通道能力；

2.1.2 可拓展性

•抽象监控指标需求；

•支持多种指标类型；

•0成本新增指标；

2.1.3 易用性

•指标管理工具化；

•两端指标统一；

•数据面板简单好用；

2.1.4 高性能

•写入快速高效；

•上传流量小；

•存储上传安全性高；

2.2 平台化设计

2.2.1 Prometheus架构

2.2.2 可拓展设计

2.2.2.1 Protobuf 设计

✔️ 统一指标抽象设计

✔️ 支持多种指标类型

✔️ 支持自定义扩展

✔️ 数据安全性高

2.2.2.2 指标类型

✔️ Counter

✔️ Summary

✔️ Histogram

2.2.2.3 易用性设计

✔️ 工具化管理监控指标和控制采样率；

✔️ 统一规范Android和iOS指标设计；

✔️ Monitor拖拽面板，配置方便；

✔️ 通过Monitor统一配置管理告警规则；

✔️ 数据展示形式丰富：线图、饼图、柱状图等；

2.2.3 可降级设计

2.2.3.1 攻击防御

加入IP和设备ID黑名单机制，避免被线上恶意用户破解攻击，做到攻击可降级。

2.2.3.2 采样管理

可按照appId、指标、时效等多维度控制采样率，避免数据量大引起服务宕机。

2.2.3.3 上传控制

可以通过后端Apollo配置控制App的上传周期，避免QPS过大引起服务宕机。

2.2.3.4 时序数据库降级

数据量大占用Promethues时序数据库内存，在monitor消费服务增加降级开关。

3. 端侧实时监控规划

3.1 Monitor体验

第一个优化点规划点是Monitor体验，需要手动写 pql， 不是自动配置规则，目标跟monitor告警规则一样，做简单配置。

• Monitor前端选择时间范围大就会卡死；
• Monitor面板配置成本高，需要简化易用；
• Monitor告警能力还没有发挥作用；

3.2 通道统一

第二个优化点规划点是通道统一。通道统一有两个特征。第一个特征是实时日志和实时监控两个短链的上传通道；第二个特征是接入Mqtt长链能力，提高上传实时性；降低对短链耗请求的问题，给App 造困扰。

3.3 全链路分析

第三个规划是全链路分析，健全从面到点分析能力，划点全链路分析，实时监控跟踪并打通实时日志数据。

收到实时监控告警，指标问题需要通过实时日志查看线上用户的业务问题。需要支持从面到点分析能力，提供模糊搜索日志查询能力，打通后端trace ID 查询跟进。

3.4 自动化发布

第四项规划旨在实现自动化发布，分为两个关键方面。首先，通过建设版本APM灰度监控能力，系统在发现告警或问题时可自动停止发布。其次，在CD基础上升级发布能力，支持版本的自动发布和自动回滚。

对指标内部值进行校验，确保一致性。通过清洗旧数据并替换为最新数据，避免数据两端的不一致。在安卓和iOS实时监控采集数据时，强调规范使用方法。

第六点关注服务限流，对SDK上传的数据进行采样项目的限流，根据App ID进行区分和定义采样率，可灵活调整。在数据量异常多时，可以降级为0。服务限流策略对SDK进行监控，上传周期可进行调整以减轻后端的压力。

基础服务能力包括MySQL、Redis、Apollo配置和集群。经过handle gateway的数据处理后，通过合法性过滤限流，如内部检查，数据会统一发送到Kafka集群。

采用Protobuf对数据进行编码，并发送到Kafka。选择Protobuf的原因是其相比JSON更轻量化，数据量更小，提高了50%的编解码效率。面对大量数据压力，线上QPS高达4000/秒。

数据通过Protobuf再发送到Kafka，Kafka有bound Consumer服务，真正对线上指标进行消费。通过订阅Kafka集群，批量取数据后对Protobuf数据进行解析。解析后，进行数据的组装、过期策略处理，包括降级容错。处理后的数据打到Prometheus client used，相当于数据mount到Consumer服务内存，其中包含Prometheus client服务能力。

之后，Prometheus搜索的集群可通过注册方式配置化，发现一些Consumer IP节点服务，通过定时30m/s的短链拉取数据，然后数据存储到Prometheus server端。

Prometheus的作用是时序数据库，按照时间戳统计和组织数据。在链路存储之后，通过mount web M，mount前端服务，打开后通过拉取Prometheus server端数据进行数据渲染和展示。

Prometheus的架构包括jobs、exporters等，将Consumer通过注册方式对外暴露，将IP和服务暴露给Prometheus server端，并通过定时方式拉取。通过Consumer服务，Prometheus主动将指标push到server端。

Prometheus与MySQL、realreal DB、squlite不同，是时序数据库，按照时间戳存储数据。在拉数据时，当前1000秒去拉取对应的数据，减少数据运算和查询，实现秒查询效率。

Prometheus server端通过短链拉取数据，集群比较简单，不使用tsdb，而是外置存储，直接存在Prometheus server端。tsdb有内存管理功能，可以持久化到HDD和SSD。

通过PQL方式查询，类似MySQL搜索语句，查询后进行展示。支持告警能力，配置规则后，在采集数据时进行运送，触发告警规则后通过root manager触发邮件。

企业一般采用混天仪相关的告警能力。稳定性大盘借助企业办公软件，飞书或钉钉的告警方式来通知服务问题。

仅采集在端上的指标，包括CI/CD前端注册时的指标。例如，与用户相关的指标，如"user App user user Modeo report error code"，旨在收集用户侧上报的错误信息，实现用户模块的相关错误监控。端上SDK采集后，数据存储方式如截图所示。

首先，"platform App washing"以及"app user"的"module"和"error code"实际上是标签（label）。标签的键和值分别是"platform"和"安卓"。在接入时，不能随意添加键值对，因为随着键值对的增加，维度数量会增加，对后端Prometheus的存储压力也会增加。

例如，版本号如果不是真实版本而是随机时间戳，会导致后端数据呈爆炸式增长，对存储和查询效率产生限制。因此，在接入时要求各端进行评审，架构组会审查埋点方式是否正确，人为控制键值对存储方式是否规范。对于键值对，如error code有限个数时允许，但超过百万级会对后端存储造成巨大压力。

关于可扩展设计，满足实时监控的要求。每种指标（例如message Matrix）定义了字段，包括App ID、platform、App wash、device ID、ctenm和Matrix item。前面的字段用于采集端上的基本数据，包括版本应用、App ID等。Matrix item是指标的扩展，时间戳由SDK采集。

Matrix step支持三种：count、summary和histogram。name可扩展，对于某一指标可能有特定的name，需要技术人员定义。例如，内存统计可以通过这两个组合方式实现可扩展能力。value在summary或histogram时记录传输的具体值，如内存的95分位、50分位、某版本的平均内存值等。

指标类型的键值如下：key是map，network指标用于统计App的网络监控，包括success标记、host域名、pass code等，通过protobuffer进行扩展。通过二进制方式实现压缩效率，体积小，decode和encode效率比JSON更高，提高安全性。

为了提高易用性，提供了mdouble web前端，通过注册指标，如采样率、指标描述，统一管理安卓和iOS。通过采样率控制指标线上数据上报情况，前端能力包括mount web编辑页面，用于统计网络成功率。

通过配置指标类型，如App ID等过滤条件，支持自定义pql字段，同时支持折线、柱状图和饼状图等能力。

为了提供攻击防御、采样管理、上传控制和实时数据库降级能力，特别考虑了Prometheus端的容量问题。如果指标太多，通过gateway层进行降级，对于mount Consumer服务的数据量过大情况，进行数据pull时进行降级，指标和采样率会相应降级。

高性能设计的主要目标是SDK，服务于应用层，提升用户体验，包括产品线A、产品线B和产品线C。这一层有三个核心能力，分别是实时日志制作、离线日志制作和实时监控，构成了上层服务层。Logan具备文件服务、上传服务和采集服务的功能。文件管理器支持Logan的读写，实现文件过期、权限管理、日志归档、压缩解压等自定义管理功能在Logan层面得以实现。

通过借助Linux mmap方式，采用内存映射解决了文件读写IO性能瓶颈。通过PB规范，实现了安卓和iOS数据的上传和存储协议，并通过message query管理上层Java和Swift OC的日志读写任务。

底层实现了message query和线程轮询，包括排队写入和读写，利用激励部门的能力实现了压缩和解压功能。通过mutext实现线程写控制，增加了安全加密能力，并将数据统一存储到第值班空间。

上传服务与后端协同控制上传周期，对上传数据进行格式化以控制上传包大小、日志大小和日志条数，同时由上传周期管理服务和端口轮询能力实现。

在线上，通过短链每分钟进行定时轮询上传，也可以通过MQTT方式实现实时上传的能力。采集服务与后端服务对接，通过后端下发的配置和过滤策略，实现对Vue控制、iOS控制等方面的日志采集。对于安卓，通过Activity、Fragment或Dialog的AOP方式进行日志采集，包括生命周期日志的采集，网络能力则通过hook方式实现。整体上，通过移动中台三驾马车，实现了对日志的拉取和写入的一体化服务，使得上传服务得到统一，服务端内核也实现了跨端能力，避免了重复开发，提高了效率。

与的腾讯数据相比，进行了10万次读写对比，在不同手机上性能提升了10倍;