APP日志上报的各种方法
- 使用类似Google Analytics的第三方工具上报,有点事无需开发,缺点是不能做个性或统计,扩展性差
- 自己定制私有协议进行上报(例如TCP二进制协议),有点是节省流量,缺点是开发成本高
- 使用HTTP上报,使用最广泛的方式
上报协议细节
一般是在Web Server放一个空文件,APP发起请求访问这个空文件,通过GET参数传递数据,然后通过分析accesse日志得到想要的数据,GET协议一般又有两种方式:
约定格式法:
http://daojia.com/up?[bj][20151021][1939][1][login]
如上所示,约定分隔符,约定占位符,按照字段顺序约定每个字段的含义.这种方式的缺点就是扩展性太差,有时候字段没有值,也要保留占位符,等等.
KV法:
http://daojia.com/up?city=bj&date=20151021&time=1939&uid=1&action=login
这个方法的扩展性好,缺点是上报数据量大,KEY其实是冗余字符.
一般采用KV法.
流量矛盾
- 无效的流量较多,HTTP请求内有很多无效数据
- URL冗余,每次都要上报URL
- KEY冗余,每次都要上报KEY
- 上报频度高,每当用户进行了一个操作都要上报日志的话,HTTP量很大
优化方法
- 手动构造HTTP请求,尽可能多的去掉HTTP中无效的数据,只保留GET /up HTTP/1.1和GET传递的数据
- 使用尽可能短的域名来接收上报的日志,例如: s.daojia.cn/a
- 使用尽可能短的KEY来标识数据,例如city=bj可以优化为c=bj,日志收集方对KEY进行统一规划
- 批量非实时上报,先将数据保存在APP本地存储,定时上报,这类上报对于UV类,SUM类,AVG类统计尤为有效,比如操作三次以后上报,或者没10分钟上报
时效性
- 特殊事件上报: APP打开关闭时
- 按时间上报: 例如每隔十分钟上报,微博是每10秒上报
- 按数据量上报: 例如每收集10条上报一次
另外的优化方式就是数据压缩.
58到家-沈剑: 无线APP日志上报优化实践&version=11020201&pass_ticket=SwpLRPTJXzjxutTx1a9A%2BYA5txavBKmHJSvqQR42fuymw3c2qEo6ofNBtigeVSQN “58到家-沈剑: 无线APP日志上报优化实践”)