42 | 分析日志真的没那么简单
周志明
你好，我是周志明。
在上节课明确了可观测性的概念、特征与现状之后，我们知道了可观测性一般会被分成三种具体的表现形式，分别是日志、追踪和度量。那么这节课，我们就来讨论其中最普遍的形式：事件日志。
日志主要是用来记录系统运行期间发生过的离散事件。我想应该没有哪一个生产系统会缺少日志功能，不过我也相信，没有多少人会把日志看作是多关键的功能。它就像是阳光与空气，不可或缺但又不太被人重视。
除此之外，我想在座的很多人也都会说日志很简单，其实这是在说“打印日志”这个操作简单。打印日志的目的是为了日后能从中得到有价值的信息，而今天只要是稍微复杂点的系统，尤其是复杂的分布式系统，就很难只依靠 tail、grep、awk 来从日志中挖掘信息了，往往还要有专门的全局查询和可视化功能。
此时，从打印日志到分析查询之间，还隔着收集、缓冲、聚合、加工、索引、存储等若干个步骤，如下图所示：
日志处理过程
而这一整个链条中，会涉及到大量需要我们注意的细节，其复杂性并不亚于任何一项技术或业务功能的实现。所以接下来，我就以这个日志的处理过程为主线，以最成熟的 Elastic Stack 技术栈为例子，给你介绍该链条每个步骤的目的与方法。
好，下面我们就先来了解下日志处理中的输出工作。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文深入探讨了日志处理在系统运行中的重要性和复杂性，以Elastic Stack技术栈为例，详细介绍了日志处理链条中的每个步骤的目的与方法。文章首先强调了日志输出的重要性，指出好的日志应该恰当记录信息，避免出现敏感信息、慢操作、追踪诊断信息等内容，同时应该包含TraceID、系统关键事件、启动时配置信息等内容。作者还提到了日志处理链条中的收集和缓冲环节，强调了日志处理的复杂性和重要性。在介绍日志收集与缓冲环节时，文章提到了Elastic.co公司推出的Beats家族，以及利用Kafka或Redis作为缓冲层的做法。另外，文章还详细介绍了日志加工与聚合的过程，以及Logstash在这一步骤中的作用，包括通过Grok表达式语法转换非结构化数据为结构化数据，以及实现聚合统计等功能。文章还介绍了Elasticsearch在日志存储与查询中的核心地位，强调了其与日志分析需求的完美契合。总的来说，本文通过深入浅出的方式，为读者呈现了日志处理的复杂性和重要性，为读者提供了深入了解日志处理的基础知识和技术实践。
该试读文章来自《周志明的软件架构课》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(13)
- 最新
- 精选
Jxin
1.以前在小公司，日志基本不是给人看的。没有索引键，随意的打印几个字段，除了写代码的人，没人找得到也没人看得懂。深受其害后，就下决心整改。后面，一个请求在项目里面的事件流转基本看日志就行了。排查问题也容易，定位到具体的事件再深入到对应逻辑里面去排查就好。 2.跑到大公司，发现，能做到这种程度的项目真的凤毛菱角。你可以制定日志的规范，但没办法决定开发人员在什么地方基于什么意图去打日志。规范虽然重要，但对日志埋点的觉察心更重要。 3.对外交互的接口，排开批量查询的接口，还是建议能打则打。避免扯皮。 4.事件:(进入了什么逻辑，操作了什么，因为什么终止了逻辑等等...)。怎么判断日志好坏:当初我整改日志时,写完是让测试同学看的，测试同学能仅通过日志理解逻辑走向就算合格，测试同学发现有什么逻辑事件需要看到就加。从他人的眼里来验证，可以规避认知陷阱。2021-03-04438
Goku谢谢老师的分享，非常受益！Elasticsearch确实是一个用来存储和搜索日志数据的利器，不过有个问题就是Elasticsearch的成本和Scalability。如果是一家中小型公司，也许把所有日志热数据都存储在一个Elasticsearch的集群里是完全没问题的。不过如果是一家超大型互联网公司，每天数十万的服务器，TB甚至PB级的数据量，用Elasticsearch作为所有日志的存储和搜索核心成本就非常高昂，而且单个Elasticsearch集群也是不可能有那么大的容量。我曾参与过一个大型公司一个大的部门的日志搜索服务建设，我们采取的做法是多个Elasticsearch集群，而且Elasticsearch还只是用来存储metadata/label数据，原始数据是压缩后存入S3。后来发现grafana loki的设计也是这个思路。不知道老师对于建设超大规模的日志分析服务有何见解。2021-03-0112- Helios日志看起来没有什么，但是在分布式中是绝对的基石，就像我们能忽略空气一样忽略日志。我们公司的一个业务在致命错误的时候没有打印日志，这暴露了两个问题，1、这个开发这是在糊代码，2、不用公司框架要自己处理很多东西，出了问题也没有锅可以甩。 在分析日志这一套，其实老师这一套组合拳说下来看似很简单，但是还有很多门路和细节。 比如因为es的写入速度有限才有的缓冲层，缓冲层是选择kafka还是redis这也是技术选型问题，kinana还是比较耗费资源所以社区又有了loki，要不要用。 这都是问题，把日志流程搞到达到这篇文章的要求可能要一个技术专家半年到一年了。2021-03-095
neohope个人觉得，如何正确的记录日志，用何规则做日志分级，要记录哪些东西，比用什么技术栈分析日志重要的多。老师能否分享一下，日志规范如何在团队中落地呢？ 有两种情况，多记录一些日志有好处的。一类是部署于第三方的系统，宕机时要多记录日志，最好有dump文件，利于排查问题。第二类是跨公司做集成对接，输入输出一般都会记得很清楚，为了防止扯皮。2021-04-142
zhanyd就单体应用来说，我喜欢在日志中打印尽可能多的调试信息，以便跟踪解决问题，程序出错了看下日志就行，甚至直接定位到了哪个文件第几行的出错位置，马上就能定位错误，方便快捷。 分布式系统就不一样了，涉及海量的日志数据，分散日志的聚合统计，复杂的服务调用链接，原本简单的日志功能也会因此变得超级复杂，人工跟踪问题犹如大海捞针，专业的事情还得靠专业的工具来做，追踪诊断应该由追踪系统去处理最好。2021-03-012
stonejianbu类python(try...except)、nodejs(try...catch)去捕获大块代码逻辑的异常，因为难以去判定具体错误，这时直接输出堆栈信息可能比较便捷些，假如试图去自定义错误可能会产生误导。 类golang这类语言，几乎每个函数都有error捕获，这个时候去自定义错误信息是比直接输出堆栈信息更合适的。2022-03-301
阿昕日志是典型的数据到使用时方知少的场景，程序员自由发挥必定五花八门，使用统一的规范很有必要。日志规范应该包括：数据格式、数据聚合、链路追踪、使用场景。2021-03-011- hillwater打印追踪信息，在我的使用中，是一种好的模式，甚至用AOP来自动打印。我用在了上亿日活的服务中，日志是多了点，但是查问题真的是容易，磁盘增加的费用和查问题节省的时间比起来，不值一提。其中提到的一些困难是可以绕开的，比如一行日志过长可以截断，相同日志过多，可以过滤掉，或者抽样打印。同时我推荐用json格式打印结构化日志2023-09-05归属地：上海
xuanbg打印错误堆栈信息是毫无用处的。如果不能通过抛出的异常信息来判断代码的错误在哪的话，也只有通过调试才能快速定位故障点。2023-07-26归属地：上海- 守望_Wilbur我觉得是否打印追踪信息也需要根据具体情况而定，对问题定位有帮助的必要信息应该打印，而开发测试过程中的调试信息则不应该打印。2023-01-15归属地：广东
收起评论