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