日志处理

现代化分布式系统中的日志处理主要分为以下几个部分

  • 应用输出日志
  • 采集日志
  • 缓冲
  • 聚合,加工
  • 索引存储
  • 分析查询

我们使用常见的分布式日志系统 Elastic Stack (Elastic 家族软件) 来说明日志处理的流程。

Elastic Stack 主要包含以下几部分 (按照流程排序):

  1. Beats 日志收集工具
  2. Logstash 日志处理、传输工具
  3. Elasticsearch 分布式搜索引擎,日志索引,存储,查询,分析引擎
  4. Kibana 数据可视化工具,用于展示 Elasticsearch 中的数据,是 Elasticsearch 的 GUI。

应用输出日志

应用在输出日志的时候要适量输出内容,不能多也不能少了。

不该有的内容:

  • 不要打印敏感信息,比如用户的密码,手机号,身份证号等,不过用户的 id 是需要打印的,不然无法定位问题,最好是一个内容的 id 编号,跟外在的 id 分开
  • 打印的内容要避免引用内容,也就是说,那种需要大量计算才能获取的,或者跨数据库请求才能收集到的数据,甚至跨服务才能收集到的数据,不要打印,会大大增加系统的负载。
  • 不要打印调试的追踪诊断数据,日志的内容是记录事件,追踪诊断应该是追踪系统去搞定的,追踪的日志非常容易暴露关键信息,如果在生产环境中还容易出现慢引用数据的问题。
  • 不要埋入假日志,一单有意或者无意埋入假日志,根本无法调试

必须要有的内容:

  • TraceID,用于记录整条链路的日志,通过此 ID 快速找到与问题相关的日志
  • 关键事件,程序中发生的事件只要有价值,就应该去记录,只不过我们要分等级去标定日志级别。
  • 对于系统启动时或者配置中心更改时的内容,应该把数据记录到日志中,比如连接的某个数据库,数据库的配置信息。

采集日志

分布式的链路大多数都覆盖了多个节点,因此我们处理日志不能在每个节点单独处理,还是应该收集在一起去整体处理。因此我们只要能跨整个链路的全局日志去处理分布式系统日志。

elastic 公司的 beats 项目就是一个专门采集数据的工具,其中 beats/Libbeat 是一个通用的日志采集工具,可以采集各种日志

Beats 与 Go 语言的 ​slog 日志库属于不同层次的数据采集工具,两者可以互补协作,构建端到端的日志管理体系。以下是具体分析:

前者是日志传输管道,后者是日志生成工具,​ 应用层:用 slog 生成结构化 JSON 日志。 ​ 采集层:用 Filebeat 高效采集并解析日志文件。 ​ 存储层:通过 Elasticsearch 索引和 Kibana 可视化实现统一分析。 两者协作可兼顾开发灵活性与运维标准化,是云原生场景下的推荐方案。

除了 beats 之外,该项目中还有其他的日志采集工具,比如:

  • Auditbeat 用户收集 Linux 审计日志
  • Funcbeat 适用于 serverless
  • Heartbeat 用户监控心跳信号
  • Metricbeat 适用于聚合度量
  • Journalbeat 用于收集 Linux Systemd Journald 日志
  • Winlogbeat 用于收集 Windows 事件日志
  • Packetbeat 用于收集网络嗅探数据

日志收集系统不仅仅要覆盖全部的日志输出来源,而且还要保证日志的可连续性,因为日志数据其实是很巨大的,我们的日志系统不追求绝对的完整和精确,只追求在代价可承受的范围之内,尽量的保证日志的高质量数据。

因此我们要缓解日志收集器的压力的一个常见做法就是先讲数据导入到缓存中,比如 Kafka 或者 Redis,当日志收集器压力非常大时,因为前面的缓存,即便它自己宕机也不会影响数据的完整性。

预处理日志

当数据保存在日志收集齐中时,我们还无法直接让 elasticsearch 去处理查询数据,我们还要预先处理日志,格式化和聚合日志,我们会使用到 logstash,因为日志是非结构化数据,我们需要对日志进行结构化处理,这样才能让 elasticsearch 更加快速的去查询到日志,也能更加有利于统计和过滤。

Logstash 的基本职能是把日志行中的非结构化数据,通过 Grok 表达式语法转换为结构化数据,通常输出为 JSON 格式,然后把 JSON 格式的数据发送到 Elasticsearch 中。

聚合,这也是 Logstash 的另一个常见职能,我们可以使用 Elasticsearch 的聚合功能,比如使用聚合查询,当然也可以使用 Logstash 的聚合功能

前者一般用于应对即时查询,后者更多是用于应对固定查询。

处理查询存储日志

经过前面处理的数据直接放入 elasticsearch 中,进行索引存储已经查询。

Elasticsearch,会使用时间范围作为索引,所以它的特点刚好符合日志的特征。

我们选择保存日志的时候也应该设定好热日志和冷日志的区别,比如事件特别久远的没有特别大价值的冷日志,要放入特别便宜的存储设备肿,对于热日志,我们要充分利用,比如使用 SSD 硬盘,可以对日志进行更快速的查询。

如果我们要对于收集的日志去分析出用户的习惯等数据,这属于大数据分析的范畴,我们这里的查询日志还是可观测性方面的事情,如果真的牵涉到大数据了,HBase 与 Spark 的组合是一个不错的选择。

数据可视化

kibana 是一个可视化工具,可以展示 elasticsearch 中的数据,是 elasticsearch 的 GUI。

一图胜千言,使用这个工具可以快速将日志的内容可视化。