业务监控整理总结

Posted on

监控范围

  1. 用户体验跟踪
  2. 应用质量跟踪
  3. 应用性能跟踪

跟踪相对指标, 不是绝对指标

监控分层

用户体验监控(前端)

因成本(研发成本)原因忽略用户手机的性能

只关注请求超时和请求错误的记录

因为成本(研发成本)原因无法获取所有的记录

所以我们使用总用户数作为比较的指标

CDN 加载监控

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
基础点位
    必定加载的资源点->用户id去重->总用户数
加载超时(5s)
    记录结构
        超时时间
        资源名
        资源大小
        平台id
        用户id
    统计指标
        超时记录数
        超时用户数
        超时资源名Top10
    趋势指标
        超时用户比
            超时用户 / 总用户数
        每个超时用户的超时次数
            超时次数 / 超时用户数
加载失败
    记录结构
        错误状态(一般是http status_code)
        资源名
        资源大小
        平台id
        用户id
    统计指标
        失败记录数
        失败用户数
        失败资源名Top10
    趋势指标
        失败用户比
            失败用户 / 总用户数
        每个失败用户的失败次数
            失败次数 / 失败用户数

应用消息监控

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
基础点位
    必定加载的资源点->用户id去重->总用户数
消息超时
    描述
        用户点击按钮后从 `发起请求->服务器处理->收到响应` 的时间
    记录方式
        在客户端进行记录, 当收到响应消息时, 判断是否超时
    记录结构
        超时时间
        超时消息名
        用户id
        平台id
    统计指标
        超时数量
        超时用户
        超时消息Top10
    趋势指标
        超时用户比
            超时用户 / 总用户数
        每个超时用户的超时次数
            超时次数 / 超时用户数
消息错误
    描述
        经了解, 目前只能监控websocket链接的异常
    记录方式
        当出现请求错误时上报错误信息
    记录结构
        错误状态
        错误消息名
        用户id
        平台id
    统计指标
        错误数量
        错误用户数
        错误消息Top10
    趋势指标
        错误用户比
            错误用户 / 总用户数
        每个错误用户的错误次数
            错误次数 / 错误用户数

登录/充值响应监控

登录/充值记录的数量总体上不大, 所以采用全量的方式采集.

难点在于对 SDK 的监控, 不一定能够监控, 但却是个非常重要的指标.

虽然很重要, 但涉及到合作方, 推进成本较高, 所以暂缓不做.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
充值SDK
    描述
        监控用户点击登录/充值按钮时跟踪SDK的响应时间
    监控方式
        当用户打开充值面板后tick一次
        当充值面板关闭后tick一次
    记录结构
        开始期间
        结束时间
        用户id
        平台id
    统计指标
        充值SDK响应时间
    趋势指标
        充值SDK响应时间
发货记录
    描述
        用来监控用户充值后发货的的时间
    监控方式
        当用户完全支付后tick一次
        收到发货物品后tick一次
    记录结构
        开始期间
        结束时间
        用户id
        平台id
    统计指标
        充值SDK响应时间
    趋势指标
        充值SDK响应时间

服务质量监控(后端)

应用质量监控

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
消息超时
    描述
        用来监控用户服务内消息请求处理超时
    监控方式
        当单个消息执行过长时打印log
    记录结构
        消息名
        时间
        用户id
        平台id
    统计指标
        超时数
        消息名TOP10
    趋势指标
        超时用户比
            超时用户数 / 总用户数
        每个超时用户的超时次数
            超时次数 / 超时用户数

消息错误
    描述
        当服务端错误时用户出现的卡死情况
        区别于消息异常, 这种错是服务端可以捕获的
    监控方式
        当消息执行出错时打印log
    记录结构
        消息名
        时间
        用户id
        平台id
    统计指标
        错误数
        消息名TOP10
    趋势指标
        错误用户比
            错误用户数 / 总用户数
        每个错误用户的错误次数
            超时次数 / 错误用户数

消息异常(后端)
    描述
        当服务端异常时用户出现的卡死情况
    监控方式
        一般不需处理, 通过log来捕获
    记录结构
        记录结构不可控
    统计指标
        异常数
        异常文件TOP10

中间件质量监控

对基础设施要求较高, 暂时不做

1
2
3
4
nginx(websocket的跟踪, 有点难)
    连接数, 请求数, 响应时间
mysql
    连接数, 慢日志, 错误日志

服务性能监控(后端)

1
2
3
4
5
6
7
8
9
基本思路:

需要应用暴露接口, 通过定期抓取的方式获取应用的状态

应用指标, 每秒请求数, 每秒事务数, 响应时间, 吞吐量

系统指标, CPU占用比, 内存占用比, IO占用比

收益比低, 暂时不做

总结

我们监控跟踪的目的有两个

  1. 提升用户的体验
  2. 降低运营的成本

用户体验监控是为了能够长期跟踪用户的体验

服务质量监控是为了找到科学的方式去改进用户的体验

服务性能监控是为了找到服务的瓶颈提高服务的事务能力, 在规模较小, 基础不完善的情况下, 收益比很低, 暂时不做