最近考虑日志收集的事情,主要出发点是:
1、在问题出现后能方便快速地收集相关的线索和证据,帮助快速定位和解决问题。因为反馈问题往往在发生之后,如果在这个时候能快速方便地拿到有用信息是件很舒服的事情,而在获取日志这块,我们目前的体验应该是不太好的。
2、发现潜在问题:通过收集一段时间的实际运行日志来分析,发现使用过程中存在的潜在问题。这样能发现一些平时未曾暴露或未被成功反馈的问题,帮助我们去完善产品,进而增进产品的稳定性并提升用户体验。
然而要想做到这些,还是有不少挑战。其中一个要点则是日志的内容——除了通常的程序执行或命令调用的报错信息,更有意义的应该还是针对性的一些内容。比如,运行过程中的重启及重新安装等非常规操作、特定接口调用的错误及超时等异常状况、发生频率超出正常范围的重连及出错、结合业务特点的一些情况等。而这些往往需要预先设计,并且配合工具和人工的分析去达到效果。
然后就是实现的机制,最好能做到自动上报和事后一键采集。当系统识别到预设的特定错误条件时,程序自动标定上报点,并根据需要定时或实时采集日志。这种方式应该能降低使用难度,减少对人工的依赖,还能有效减轻采集工作的负担。
另外,这个事情似乎不太可能一次性就做得完善,需要在过程中根据情况不断总结、调整和完善。
这种方式相对于主动分析优化去提升程序的稳定性而言,应该是相辅相成的,属于目的一致的两种方法。