客户端日志系统
使用场景
-
用户通过app store下载app后, 在使用过程中出现了异常情况, 例如 功能异常等.
-
例如BugHD 会自动捕获崩溃信息, 但开发人员想重现是不容易的.
设计方案
一. 收集
-
log模块化,暴露接口, 对日志分级, info, debug(支持打印类似
NSLog), warn, error等. -
收集崩溃日志
二. 存储
-
直接存储在本地数据库.
日期 , 等级, 内容, 用户信息,设备信息等 -
为防止日志过多,占用空间过大, 应该定期删除指定日期前的数据.
例如2周
三. 上传时机
-
如果有长连接,通过长连接发送命令 给app, app收到后,返回 ack, 如果未反馈需要持续发送. 类似mq的消息队列. 但是每个消息都有时效性, 如果过了3天以上可以不用再发.
-
如果没有长连接,可以考虑两个时机;
2.1 每次应用进入前台时候, 去主动获取下是否需要上传日志的接口. 2.2 每次用户进入反馈界面时候, 上传今日日志.
四. 上传内容
-
可以通过接口中指定上传的日期, 例如指定开始日期,截止日志.
-
默认3天, 到目前为止.
五. 上传格式
压缩上传, 按天为单位,进行压缩.
压缩加密, 可以采用对称加密, 加密key应该每次上传都不同. 具体的可以协商, 无法保证绝对安全, 就算走https.
后端方案
-
接口实现: 后台配置用户id, 则接口通知该用户,上传日志.
-
解密日志.
-
日志入库, 需要读取日志, 这里其实采用 mysql和 es都可以.
-
数据展示, 根据uid进行搜索, 按时间顺序展示, 显示日志等级
-
展示方式:
1. 前端页面 2. mysql客服端 3. es + kibana
建议可以采用ES + kibana, 后期能扩展,进行数据采样.
类似 Prometheus + Grafana