写点什么

五个问题,三大策略,手把手教你定制 App 性能监控方案

发布于: 2021 年 03 月 17 日

作者:友盟+U-APM 团队

Why? 为什么要做应用性能监控?

首先,我们要知道应用性能监控具体指什么?以及目的:

监控是一套完整的“监视+报警”的系统。对于像我们这样的 App 开发者来说,应用性能监控是衡量 App 的第一道关卡,如果应用的质量不好,会给用户带来最直接的体验伤害。App 上线后,开发者是无法 7*24 实时获取到用户使用及体验情况的,这时就需要一套优质的监控工具。

那么,我们到底需要监控哪些指标?

安卓和 iOS 的客户端监控指标就有很多不同,比如说安卓需要的是 Java、Native、ANR 错误等等,iOS 需要的是 Objective-C、Swift、C++层的错误等等。

在定义错误指标上,最基础的是不同类型的错误数,如果考虑到错误数与整体应用使用量的对比,可以考虑用比值的方式,比如可以定义错误率:


如果要关注错误的发生次数,及错误的影响用户数,则可以在错误数的基础上,根据用户排重计算得来影响用户数。

如何定义独立用户呢?我们可以考虑用设备 ID 辨别,比如 imei、idfa、AndroidID 等等,如果这些信息很难获取,也可以使用业务上的用户 ID,比如登录账号,会员名等。除此之外,使用第三方 SDK 提供的设备识别定义 ID 也是个不错的选择。在使用这类 ID 排重后,就可以得到错误的影响用户数。

如果我们已知错误的影响用户数,但无法确定它的影响范围占比,则可以看以下这个指标:

总结下来,我们可以统计不同类型错误在某一个时间范围内的错误数、错误率、影响用户数、影响用户占比等指标。在指标的细化分类上,我们还可以用不同的维度定义监控,比如版本号。

How? 如何灵活地制定属于你的告警计划?

我们先请您做个小测验来判断下您的监控告警类型(一共 5 道题,仅需 1.5 分钟)

规则如下:A 选项记 5 分,B 选项记 10 分,C 选项记 15 分,D 选项记 20 分

Q1: 请问您的产品目前处于什么阶段?

A: 已经上线,处于比较稳定的状态,对监控告警的需求较低

B: 还在开发阶段,需要捕捉一些测试中的错误,对监控告警的需求一般

C: 刚刚上线,整体来说比较稳定,对监控告警的需求较高

D: 刚刚上线,效果未知,非常需要 7*24 小时实时关注,对监控告警的需求非常高

Q2: 请问您在您的公司/部门的职务是什么?

A:领导者,关注应用的质量做得如何

B:运维人员,负责监控整体应用性能的线上问题监督官

C:测试人员,负责应用发版前的质量把控

D:安卓/iOS 端的客户端开发人员

Q3: 请问您所属团队有多少人在关注应用性能质量,并参与其中呢?

A: 1,光杆司令干活靠自己

B:2~5 人,小型开发团队

C:6~25 人,相互打配合,一起优化应用质量

D:25+,超大型的开发团队,不谦虚的说算是行业龙头

Q4: 您日常关注哪些应用性能监控指标:

A: 最基本的错误数就可以

B:考虑到客户端影响的用户使用范围,在上述的基础上需要监控影响的用户数以及占比

C:在上述的错误数以及影响用户的基础上,还要考虑各个版本的分布

D:需要制定组合型的告警规则:比如:错误数>100 且错误率>1%或者影响用户数比 1 天前多 1%时触发告警,也要考虑版本分布

Q5: 请问您对告警的通知方式有精细化设置的要求么?

A:没什么要求,只要能收到就行

B:在时间上有一些要求,半夜不想被打扰

C:在通道上有一些要求,需要邮件或者特定的办公聊天软件

D:对时间和触达通道都有要求

What?那么如何设置告警计划呢?

以上的分加总,请先判定下您的测验总分(A 选项记 5 分,B 选项记 10 分,C 选项记 15 分,D 选项记 20 分),来看您的 App 在下面哪个监控告警需求等级范围内:(数据在哪个范围?还是监控告警在哪个层级?)

热血青铜(25~50 分):您属于监控告警的初级阶段使用者,您在日常工作中无需非常精细地查看各种错误的发生状态。可能是由于您的应用还在初始阶段,或者您位高权重,无需亲自修复告警信息,只需要整体监控就好。请查看下文中的方案 1

英勇黄金(50~75 分):您属于监控告警的中级阶段使用者,您或者您的团队已经有了监控告警的意识,并且在日常工作中会关注到实时的应用质量情况。您已经可以用一定精细化的规则设置告警了,请跳转至方案 2

荣耀王者(75~100 分):您已经属于监控告警的高能玩家了,只需要一点点引导,就可以成为监控告警界的“超级王牌”了

根据上述测验的分值高低,您可以判别您所需要的告警设置的难易,整体分为下面几个方案,实现程度由易到难。如果您想学习最全面的告警设置功能,请直接跳转到方案 3 哦

方案 1:简易型--整体应用质量监控

作为最初级的告警设置,您只需要考虑两个问题:

a. 我应该在什么情况下收到告警?

b.我如何能收到应用告警消息呢?

解决第一个问题,您可以考虑最简单的状态,只要有错误我就要收到预警,那么只要设置错误数>0 的条件就可以解决。如果您觉得这样被打扰的非常多,可以根据自身的应用情况,设置错误数>xx 个这类的告警规则

解决第二个问题,您需要有一个可以接收消息的媒介,最简单的就是邮箱:

一个简单的监控告警计划就这样设置好了

方案 2:进阶型--精细化应用质量监控

您已经可以对单一应用设置不同的告警消息了,可以按照监控的指标类型或者版本进行区分。比如说,我们对新上线的版本要求是,影响用户数>10 则触发告警,对老版本的要求是整体错误率相比于上周增幅不超过 5%就可以,那么我们就可以按照如下的方式设置:

a.新版本的告警规则:


b.老版本的告警规则:

在这个方案中,我们分别应用了阈值型和对比型的告警触发条件,这两种规则的定义如下;

阈值型规则

您可以选择一种指标(错误数、错误率、影响用户数、影响用户占比),并且选择「大于」某值或者某百分比

对比型规则

您可以选择一种指标(错误数、错误率、影响用户数、影响用户占比),并且选择「比」历史的时间段,增加多少比例,计算方式为:(过去 1 小时数值-历史 1 小时数值)/ 历史 1 小时数值,大于或等于所选值即发送告警

方案 3: 王者型--组合式指标监控

您已经可以非常熟练的设置监控告警了,那么通过下面的 hints,相信您可以根据您的日常工作需求,灵活制定属于您的告警计划

a. 灵活设置告警生效时间:


您可以添加告警生效的时间段,比如每周一至周五的 9 点至 19 点,周末的一 12 点至 20 点,灵活设置您的工作时间,不被无效信息干扰

b.重点错误类型/单条错误告警

您可以选择需要您重点关注的错误类型


或者直接针对某一条修复中的错误进行持续关注告警

c. 组合形式的告警触发条件

您可以通过多种指标以及阈值型或者对比型的规则,以交集/并集的组合方式,灵活设置您想要的告警触发条件

d.多种告警触达渠道

如果您还对监控告警的触达渠道有所要求,可以考虑使用公司的办公软件进行群触达,与您同组的其他同事一起关注并修复应用问题。

在此方案中提到的所有监控告警设置功能,可以通过 U-APM 体验,2 分钟制定告警计划。

用户头像

还未添加个人签名 2020.12.03 加入

还未添加个人简介

评论

发布
暂无评论
五个问题,三大策略,手把手教你定制App性能监控方案