搜索 K
Appearance
博客正在加载中...
Appearance
不管是什么编程语言,都需要用到日志。
日志,和日记类似,都是记录东西的。现实生活中,很多行业都有用到日志:
通过日志,可以很方便的回溯发生过的事情,方便未来定位问题和总结。
在程序员的工作中,日志是非常重要的。可以说,如果系统遇到了什么问题,大部分都得靠日志去定位和解决
程序运行起来以后, 基本上就是一个黑盒子,如果程序的行为和预料的不一致,那就是出现 Bug 了,如何去定位这个 Bug 呢?
如果没有记录日志,那么对于已经发生过的事情,我们是无法得知其内部是如何变化的,例如变量的变化情况,数据库的执行情况等等;这时候如果根据问题发生从场景,来复现这个问题的话,还不一定能复现出来,因为我们不能准确的定位到为什么发生了这个问题。
有时候是用户操作失败了,但用户记错了,那么要复现问题就难上加难了……
所以,没有记录日志的话,遇到难排查的问题,基本就炸了 💥,特别是遇到一些紧急和重大的问题的时候
笔者曾负责一个电商系统,在该系统内,几乎用户的任何关键的操作,都会记录在日志里。这样,当客户反馈有什么问题的时候,就可以通过日志去定位用户操作到哪一步了,后台有什么错误输出,以此来复现和解决 这里也引用看到的一个总结:
在我们开发一些业务比较复杂的程序时,开发者们往往在重要时刻记录一些日志,这些日志在排查问题的时候,跟踪调用流程时特别有用。因为一旦程序出现问题,如果没有日志,又不能让用户去复现问题的话,我们往往需要大量时间去一步步排查和跟踪,如果有业务日志,就可以根据日志整理出一个业务处理链条,顺着这个业务链条就可以就可以得到程序处理的过程,定位并复现问题。 --《Electron 实战》第 188 页,刘晓伦著
日志的意义与价值,,用一些专业术语来说就是:
一个日志,笔者根据经验认为,应该记录如下内容:
这里提一下,一个日志文件一般以 .log 结尾
并不是所有事情都要打日志,确切的说,不是什么时候都应该打印全部日志。
例如,在系统刚上线的时候,尽可能的多打日志是对的,不管是错误的日志,还是正确的日志,甚至可能一些不太重要的日志;因为有一些问题可能没有暴露出来,当有问题的时候能很好的通过日志 定位和解决问题。
当系统运行稳定的时候,再打印这么多日志就没有必要了;大部分功能都已经稳定,还继续打印那些正常的日志,着实没有必要,因为此时大部分功能都不会有问题了,此时可以将系统设置为 只打印错误日志
也就是说,日志是可以分级别的。例如可以定个 3 级,1 级表示全部打印日志,2 级表示打印关键日志,3 级表示只打印错误日志,不同阶段需要不同的日志级别;
日志分级别,也是很合理的,不可能所有日志都一样重要。
举个生活中的例子,我们写日记的时候,可以先记录一些非常重要的事情;一些无关紧要的事情可以稍后在记录,或者不记录;当我们回顾的时候,优先看重要的日志
由于日志是如此重要,在一些大型的企业中,会对日志有专门的管理办法。这里说下笔者接触过的企业吧:
制定专门的日志管理制度,各系统原则上均要满足该制度的内容
日志文件应该有多个。如果不切分日志,那有些系统的日志很容易就达到几十 G,对于压缩、查看和移动都很占用时间
有的系统是 1 天 1 个日志文件 或 1 小时 1 个, 也有的按大小切分,当超过 100M 就自动生成一个新的日志 或者结合起来,一小时一个,当超过 100M 时则生成第二个日志文件,例如以.2 结尾
日志保存期限:一般在线的会保存一年,超过一年后的话可以考虑磁带等存储方式或直接清理。
日志的压缩:为了不让整体日志占用太多的空间,一般会压缩 3 天前的日志;
日志中通常含有敏感信息,得保护好日志不能被随意访问。例如用户的姓名,手机号,邮箱等,而且会体现代码的执行过程,如果被随意泄漏,会造成客户的损失,并且有可能被黑客抓到漏洞,进而攻击系统。 对于日志保存期限和大小,可以用 crontab 脚本压缩和清理一年前的日志。
上述日志管理的方法仅供参考,读者应结合自己的实际情况,来选择日志管理方法。也有的项目会将一些关键的日志记录到数据库里(这样就不用打开日志文件去搜索),方便搜索数据库。
那是不是使用日志就没有缺点了呢?有的 :
当然,大部分时候记录日志都是利大于弊的
例如 B 站崩溃的时候,也是要看日志:
视频版:2021.07.13 B 站是这样崩的_哔哩哔哩_bilibili
22:55 远程在家的相关同学登陆 VPN 后,无法登陆内网鉴权系统(B 站内部系统有统一鉴权,需要先获取登录态后才可登陆其他内部系统),导致无法打开内部系统,无法及时查看监控、 日志来定位问题。
欢迎补充其他的相关阅读~