这样我们就能在服务端把他们归类为一个接口。目前是正则匹配的全数字，刚好内部有此类接口的服务参数部分都是纯数字。如果动态参数部分会存在非纯数字的参数就会无法判别。只有SDK提供配置列表，业务方去一一配置相关链接，让SDK自动替换。但是这样对业务方使用不友好，也不好维护。所以一旦有此类情况发生，最好的建议就是用?或者消息体的方式带参数吧！
（2） 接口错误信息不固定前端监控收集到ajax业务错误响应信息以后，会按照接口路径+错误信息的方式聚合同一个错误。有发现过一个接口响应的错误信息带了随机值，随机值可能是当前请求的配置的唯一id。大致如下：
{ errMsg: '发生了异常（d1nbj1az5）',//括号内的为随机值 errcode: 1 }解决方法就是，和服务端约定好，如果需要返回额外设置一个字段，而不是放在错误信息中。
在迭代native版本时，对于表结构设计有多种方案的考虑。对于日志系统，最终决定还是使用反规范化设计，通过牺牲空间来提高吞吐。
4.3.2 查询优化（1）索引
当数据量变得越来越大，查询越来越慢时。我们对索引做了调整，以时间字段建立索引，同时客户端查询条件默认定义合理的时间范围，以此来优化查询速度。并适当的使用复合索引。
（2）慢查询
在早期，一些慢查询、比如分钟级定时任务使用的mapReduce语句，拉低了数据库性能，通过一定的优化、低效语句替换，我们解决了这些慢查询。线上优化前数据库24小时平均cpu使用率78%，优化后为27%。下图便是测试环境优化后的效果截图，峰值发生了明显下降。
最初前端监控系统和其他业务系统共享使用云数据库。由于前端监控在某段时期存在数据库慢查询的问题，而这个慢查询刚好也是分钟级别的定时任务。导致共享数据库有很多慢查询记录，CPU消耗也一直维持在较高位置。前端监控本身也会保持一定的监控数据并发量在做存储。前端监控拖累了整个数据库，并且由于慢查询日志很多，导致其它业务在排查数据库慢日志的时候，很难找到他们自己的日志。后来，运维同事就给单独配置了一个独享数据库给前端监控。
迁移前配置12核32g三节点（一主两从），迁移后为2核4g三节点。虽然配置变小了，但是前端监控独享数据库后平均响应速度反而变快了。前端监控的数据是属于日志数据，量更大，导致数据库性能下降，影响到业务数据服务。日志系统的数据库和业务分离也是正确合理的。
当然系统的迭代过程中还有很多问题和细节，这里就不一一列举了。
结语目前前端监控系统已经运行1年多，服务公司几十个应用，它仍然有很多不足，它也一直保持规划和迭代。记录于此，继续努力。