你好,我是吕蕴偲。
在日常工作中,需要 24 小时持续不断地对运行中的应用进行检测,以便及时发现问题、定位问题、解决问题。问题的发现基于监控,而问题的定位则基于日志。对于云上的每个应用来说,日志尤为重要,如果把云上服务比作一个自然人,监控就好比是为人做体检,而日志就相当于病例及报告。如果我们的体检出现了问题,医生需要翻阅病例进行排查诊断,根据病历(程序日志)结合临床症状(监控信息)进行身体症状的判断并治疗(解决问题)。
日志之于程序,就如同病历之于患者,通过日志,我们就可以及时、准确地追踪到程序的异常状态。由此可见,日志的使用、记录和设置都是十分重要的。
日志的用途
日志文件有多种用途,其中最关键的一种就是上面所说的定位问题,除此之外,日志还身兼数职:
审计操作。比如 Linux 堡垒机的 history 日志、message 日志等,就是为了满足审计需要。还有一些需要等保合规的公司设置日志也是为了满足审计的需要,比如等保三级要求日志保存期限不得小于 180 天。
安全追踪。对于用户的访问需要进行有效追踪,进行入侵检测,以防止恶意的流量和恶意的代码操作。
监控联动。监控日志的访问与告警系统结合,提供正常、危险、异常等多种告警模式,配合消息系统,给予运维人员更高的自由度。
大数据分析。采集数据,推送到大数据分析品台,提升研发、运维、运营、安全等场景的数字化能力。
日志的生命周期
明确日志的用途,知道了日志的重要性,我们再来看一看日志的生命周期。日志的生命周期由四部分组成:日志设置(信息、级别)、日志生成(位置)、日志备份(备份)和日志销毁(终结)。完成这四个步骤,日志才算完成了它的使命,现在,我们来逐一讲解一下日志的这四个生命周期。
日志的设置
一个良好的信息记录设置,可以快速定位消息,提升运维效率。日志的设置需要设置可读化的信息,为的是让人和机器能够读懂日志。日志设置没有统一的标准,通常根据经验来说,日志设置可分为日志信息设置和日志级别设置。
首先来聊一聊日志信息设置,日志信息遵循记叙文六要素:时间、地点、人物、起因、经过、结果。时间指的是实践发生的时间,地点是日志记录的位置,人物这里指程序,起因指请求信息,经过指处理过程,结果交代好处理程序的结局。
下面的代码是常用中间件 Nginx 的日志默认打印的信息,清楚地表明了六大要素:
access_log /var/logs/nginx-access.log main
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
123.123.123.123 [02/Feb/2022:23:24:25 +0800] "GET / HTTP/1.1" 200 190 "-" "Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Mobile Safari/537.36" "-"
通过六大要素,我们可以清楚地知道哪些程序在什么时候干了什么,结果是怎么样,方便我们梳理事故发生时候的问题。如果日志没有如此详细地记录,那也应该至少记录六项中的四项:时间、地点、人物和结果,以便于定位、调试问题。
除了日志的信息之外,日志的级别也是至关重要的。不同的场合打印不同的日志,良好的日志级别的定义习惯既能够优化日志的存储空间,又能够使我们的查找更加快捷高效。以著名开源日志管理工具 Log4j 为例,Log4j 将日志级别分为 8 个层级,分别是:
一般来说,我们会使用 DEBUG/INFO/WARN/ERROR 这四个等级的日志。同时也会在日志中定义颜色,如 ERROR 使用红色,WARN 使用黄色,DEBUG/INFO 使用标准色等,增强区分度,更好地识别日志信息。
日志的生成位置
根据不同的需要,日志的位置可以存储在本地、网络文件系统中或对象存储中。单机文件只需保存在单机中,如果需要统一管理,可以通过 agent 或者 crontab 传输到统一的日志管理磁盘中,或者传输到第三方日志分析软件进行数据分析,如阿里云通过 SLS 服务进行后续的分析。在分布式系统中,一般会挂载一个 NAS 文件存储来专门存储日志管理。在 NAS 中挂载的日志最终也是可以导入到 SLS 中,或者存储到对象存储中进行永久性存储。
日志的备份
日志备份是必须的,备份便于我们后续的调档,某些公司或者行业,要求日志必须备份一定的时间。日志的长期存储通常会选用对象存储,无论是本地存储,还是 NAS 存储,都不是备份的长期解决方案。由于一份数据有很大的丢失损坏风险,所以我们需要寻找一种更佳的解决方案。高可用、高可靠、高持久性的对象存储是我们的首选。
对象存储会至少存储 3 份的冗余系统,且保障数据 11 个 9 的持久性和 4 个 9 的可用性。我们可以通过对象存储工具,如 AWS S3 CLI、ossutil、OSSFS,结合 crontab 的方式将数据备份到对象存储中。请注意,在设置上传的过程中,为了保证对象存储环境的干净性和隔离性,我们必须在 RAM 的权限管控中设置 OSS 的 Bucket 权限只写,防止 DELETE 因为程序被攻击而启用。同时建议开启版本控制以及生命周期管理。
日志的销毁
日志的销毁是通过生命周期管理实现的。如果是单机,可以结合 corntab 定时任务销毁特定的日志,也可以通过 Logrotate 进行日志切割、保存及轮转。
weekly
rotate 4
create
/var/log/wtmp {
monthly
create 0664 root utmp
rotate 1
}
这是一种较为原生的方式,如果将数据存储到了对象存储中,对象存储的生命周期管理策略能够为我们很好地进行管理,可以实现到期自动流转存储层级、节省存储费用、自动删除文件等操作。
不同的日志所需要存储时间不同,访问次数也不同。如果某日志访问频率不高,还存储在标准层级中,会消耗我们的成本。我们可以根据对象存储的生命周期策略,设置不同的访问层级,合理管理日志,减少费用支出:
当日志存储 30 天后,自动转换为低频访问类型;
当日志存储 90 天后,自动转换为归档存储类型;
当日志存储 180 天后,自动转换为冷归档存储类型。
在完成了日志的销毁之后,日志也就完成了它的使命,光荣地退役了。
总结
好的,我们总结一下这节课的内容吧!
这节课我们就程序中的日志做了分析,解答了我们为什么要打印日志以及日志的意义又在于何处的问题。日志是为了方便我们进行问题的定位和数据的分析处理。没有日志,就好像看病没有病例记录,那么医生将无从下手。之后我们介绍了日志的生命周期,完整地介绍了生命周期的四个部分应该如何设置,并且引入记叙文“六大要素”,生动地讲解了日志需要的几个要素。
好了,今天的课程就到这了。我是吕蕴偲,欢迎你在评论区留言和我讨论,也欢迎你把这节课分享给身边的朋友。