本文从以下问题出发,以解决实际的业务痛点为目标阐述实践经验
-
为什么要做移动端的网络监控
-
为什么使用 Sentry 来做监控
-
如何用 Sentry Flutter 做网络监控
-
Self Hosted 还是 Cloud?
为什么要做移动端的网络监控
移动端的网络性能监控对于应用的成功和用户体验至关重要
- 用户体验优化:移动应用的网络性能直接影响用户的满意度和使用体验。通过监控网络性能,可以及时发现并解决潜在的性能问题,提高应用的响应速度和加载时间,从而提升用户体验。
- 问题定位与解决:监控移动端网络性能可以帮助开发团队快速定位并解决网络相关的问题,如慢速加载、连接错误或请求超时。这有助于减少用户投诉,并提高应用的可靠性和稳定性。
- 优化网络资源使用:通过监控移动端网络性能,可以了解应用程序在不同网络环境下的性能表现,并根据实际情况优化网络资源的使用,确保应用在不同网络条件下都能正常运行。
- 数据分析和决策支持:移动端网络性能监控可以提供大量有关应用程序在网络层面的数据。这些数据可用于分析用户行为、用户地理位置、网络连接速度等信息,为产品和业务决策提供支持。
在没有端到端网络监控的情况下,我们收到用户投诉,说网络访问很慢,排查起问题来没有足够的数据支撑。
为什么使用 Sentry 来做监控
移动端有很多数据营销的 sdk,我们很难用单一的某个 sdk 同时完成归因、事件分析、应用性能监控(APM)这些功能。所谓术业有专攻,一个 sdk 做得好不好,除了数据上报,更重要的是数据处理和可视化。
以 Google 的 Firebase 为例,同时有 Firebase Crashlytics、Firebase Performance、Firebase Analytics、Firebase Messaging 等 sdk,分别实现了如下功能:
- 崩溃监控
- 性能监控
- 事件分析
- 消息推送
简单来讲,Firebase 的功能大而全,但除了消息推送掌握了 Android 系统级服务的主导权外,其他的垂直领域并没有明显优势,这就给了第三方服务机会。
Sentry 从很早就是 Flutter 官方首选的崩溃监控平台,它的优势就是崩溃监控和性能监控。
如果你用它来做用户行为事件上报和分析,那你可找错 sdk 了,但如果你用它来做 Http 网络监控,那简直就是量身定制。
Sentry 相比 Firebase 最大的优势在于以下几点:
-
Sentry 自身的上报没有地区限制,不存在被墙的问题
-
Sentry 在数据可视化、告警、过滤筛选、信息颗粒度上做得非常详细
-
Sentry 的集成上也更加方便
那么除了 Sentry 和 Firebase 有没有其他选项呢?
别浪费时间了,很多时候,你只是没把现有的工具玩明白而已。
尤其对于 Flutter 而言,不少 SAAS 已经站稳脚跟,无需再花时间进行一一对比。
比如私有包管理工具,就用 cloudsmith,ci / cd 就用 codemagic,其他都是将就,专业的事交给专业的人来做。
如何用 Sentry Flutter 做网络监控
重点来了,Sentry Flutter 做网络监控,最重要的就是搞明白,我们想看的是什么数据。
Sentry 里有一个很重要的概念叫 Transaction,也就是事务,事务有 start 和 finish 两个方法。
事务有一个属性叫 operation,可以理解为事务的类型,比如网络监控,就可以把 operation 赋值成 http,这样后续筛选过滤的时候就可以专门过滤出网络这部分事务。
每一个事务都有开始和结束时间,默认情况下,start 和 finish 的调用时间就是开始和结束时间,你也可以指定开始和结束时间,相当于自己来计算,这样的话 Sentry 只负责上报就行了。
用户使用应用时,网络请求通常比较多,所以这里就涉及到一个叫 trace sample rate 的东西,他表示上报数据的采样率,也就是上报的百分比,1 表示全部上报,0 表示全部不上报。
这个采样率可以是全局静态的,也可以针对每一个事务单独设置。
以下代码就是单独设置每一个 api 请求(根据 path)。
options.tracesSampler = (samplingContext) {
final ctx = samplingContext.customSamplingContext;
final path = ctx['path'];
if (path != null && path is String) {
switch (path) {
case ApiPath.path1:
case ApiPath.path2:
return 1;
default:
return 0.1;
}
}
return 0.1;
};
每一个事务都有一个 setTag 方法,其实就是一个字典,这可以用来做筛选,比如把本地的区域设置进去。
final span = Sentry.startTransaction(
path,
'http',
customSamplingContext: {_customContextPath: path},
startTimestamp: event.start,
);
span.setTag('region', event.region);
这样就可以在 Sentry 后台通过 region:[country] 筛选出某个地区的用户的网络监控数据。
在 Sentry 后台,我们可以看到 Performance 和 Alert 两个面板。
Performance 面板里可以看到所有的请求,其中有一个重要的参数是 User Misery。
User Misery 是衡量用户体验的指标,它表明有多少唯一用户等待时间超过了 4 倍的阈值。
Alert 面板可以创建各种 Alert Rule,用于告警开发者用户的网络访问出现了问题。
Self Hosted 还是 Cloud
如果团队有足够的运维资源,那么 Self Hosted 有更多的定制型和灵活性。
反之,如果没有太多运维资源进行依赖升级和维护,那么建议使用 Cloud,这样可以让后台的数据可视化紧跟最新版本。也要考虑 Cloud 的费用。
具体可以参考 Self Hosted or Cloud Sentry?