Trey blog.

日志记录---吐槽

吐槽

开始的时候有个同学,接到需求,给系统里用户及管理员的操作增加日志记录。

在其他人毫不知情的情况下,该同学花了大力气将系统里所有对数据库有变更操作的代码前增加一次查询操作,及变更后再增加一次查询操作,最后对比分析两个查询结果,分析出前后变更的字段,以一定格式写入到数据库中

该同学来公司只开发了这一个功能就离职了,并且这个功能被合并进去了。。

该功能后续对维护人员造成了成吨的伤害:

  1. 每一次变更操作的代码前后都得加上这牛皮癣一样的代码。某处变更原始代码可能4行,加上之后超过24行也是正常,并且额外多做了3次数据库操作。

  2. 该功能配置乱七八糟,和业务代码严重耦合,经常因为日志记录可能导致服务不可用。

  3. 升级维护困难,并且开了一个先例,导致后期开发都不用仔细思考,直接写代码了。

昨天小会上对这个方案又提出了质疑。。

然而遇上的是:

你的想法有xxxx的漏洞…(不可实现)

正面回答之后:

好,那就说如果给你做,你多少时间能完成。(缺少这个日志系统功能的这段时间可能会出现什么严重的后果)….

然而。。

我特么就是想提出一个想法,让大家发散一下思路,共同把系统优化好。。

诶。。

我的想法

我想,我这次做的是一个内部的服务,服务不应该处理更多的职责之外的东西。

你需要一个给运营查看操作日志的东西,应该是上层服务提供的。

那么,我下层服务应该做什么呢

  1. 以一个中间件的形式,规定格式,打印请求参数,响应结果到文件中。

  2. 另外有一个统计脚本,根据运营定下的查看规则,去分析这个日志,将分析结果录入到DB中(类似于点击PV统计脚本)

  3. 为了有助于脚本分析,还可以在关键的业务处打上日志

我的想法是,不同系统的服务通过统一的格式打印日志,汇集,交给专门处理日志的服务去做分析处理操作。