日志中心建设:洞察数据脉络,解锁运维与运营的智慧之门

45 阅读13分钟

前言

在当今数字化浪潮汹涌澎湃的时代,数据已然成为企业与组织的“生命线”,而日志作为数据的重要组成部分,犹如隐藏在系统深处的“宝藏”,记录着每一个微小的运行细节与关键事件。

然而,海量且分散的日志数据往往如同散落的珍珠,难以被有效串联与挖掘,这使得许多组织在面对复杂多变的业务需求与运维挑战时,犹如盲人摸象,难以精准洞察全局态势。

本文从日志功能入手,思考为什么需要构建日志中心?

一、运行治理与可观测性 Observability

SRE(Site Reliability Engineer) 站点可靠性工程内容较多,其中一项是运行治理,或者说是事件响应

当今社会对 IT 系统业务连续性要求是 99% 以上。像知名App 如美团、抖音,新功能一直在上线,但基本上没有出现系统故障,可以想到的原因:

  1. 大厂程序员写代码水平高;
  2. 建立了有效的流程管理机制,例如严密的代码审查与测试;
  3. 运行治理做的好,出现系统故障时第一时间发现,第一时间故障恢复。

要做到 3 的必要条件是构建系统的可观测性,其包括三大支柱:指标Metric、日志Log、链路Trace。

二、日志 Log

日志是系统在运行过程中生成的记录文件,用于描述事件、操作、错误、状态变化等信息。它是一种重要的数据形式,能够反映系统的行为、性能、安全状态以及用户活动等关键信息。

日志的主要作用是帮助系统管理员、开发人员和运维人员监控系统运行情况、排查问题、分析性能瓶颈、进行安全审计以及支持业务决策。

简单了解日志的特点:

  • 时效性:记录系统在特定时间点或时间段内的运行状态、事件和行为;
  • 顺序性:按照事件发生的先后顺序生成的,记录了系统的运行轨迹;
  • 信息丰富性:记录了系统运行的详细信息,包括事件类型、操作结果、错误信息、用户行为、系统状态等;
  • 不可变性:日志一旦生成,其内容通常不应被修改,以保证记录的真实性和完整性;
  • 大量性:系统运行过程中会产生大量的日志数据,尤其是在高并发和复杂的业务场景下;
  • 多样性:日志的格式和内容因系统、框架和业务需求而异,常见的有文本日志、JSON 格式日志、二进制日志等;
  • 分布式特性:在分布式系统中,日志可能分散在多个节点上,需要集中管理和分析;
  • 重要性分级:通常根据重要性分为不同的级别,如 DEBUG、INFO、WARN、ERROR 等。

本文从业务 IT 系统软件开发工程师角度,将日志简单分为两类:系统日志和业务日志。

2.1 系统日志

系统日志是由开发框架或中间件(由水平极高的开发者定义)生成的日志,主要用于记录系统运行状态、配置信息、性能指标以及底层框架的运行情况。

开发工程师不需要手动编写这部分日志,但需要关注它们以排查问题。其特点包括:

  • 自动生成:由框架或中间件自动记录,无需手动编写;
  • 标准化:格式和内容通常由框架或中间件定义,具有统一的规范;
  • 底层信息:主要记录系统层面的信息,如启动、错误、性能等。

例如 Spring 日志、Redis 日志、Nacos 日志、MySQL 日志、Nginx 日志。

Spring 日志:

2025-05-28 10:00:00 [main] INFO  o.s.b.SpringApplication - Starting application on localhost with PID 12345
2025-05-28 10:00:05 [main] ERROR o.s.b.SpringApplication - Application run failed
java.lang.NullPointerException: Some error occurred
  at com.example.service.MyService.doSomething(MyService.java:42)

MySQL 日志:

2025-05-28 22:41:25 2025-05-28 22:41:25+08:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.4.3-1.el9 started.
2025-05-28 22:41:26 2025-05-28 22:41:26+08:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql'
2025-05-28 22:41:26 2025-05-28 22:41:26+08:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.4.3-1.el9 started.
2025-05-28 22:41:27 '/var/lib/mysql/mysql.sock' -> '/var/run/mysqld/mysqld.sock'
2025-05-28 22:41:27 2025-05-28T14:41:27.128286Z 0 [System] [MY-015015] [Server] MySQL Server - start.
2025-05-28 22:41:27 2025-05-28T14:41:27.393086Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.4.3) starting as process 1
2025-05-28 22:41:27 2025-05-28T14:41:27.401134Z 0 [Warning] [MY-010159] [Server] Setting lower_case_table_names=2 because file system for /var/lib/mysql/ is case insensitive
2025-05-28 22:41:27 2025-05-28T14:41:27.479811Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2025-05-28 22:41:31 2025-05-28T14:41:31.116967Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2025-05-28 22:41:32 2025-05-28T14:41:32.797247Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.
2025-05-28 22:41:32 2025-05-28T14:41:32.797813Z 0 [System] [MY-013602] [Server] Channel mysql_main configured to support TLS. Encrypted connections are now supported for this channel.
2025-05-28 22:41:33 2025-05-28T14:41:33.052484Z 0 [Warning] [MY-011810] [Server] Insecure configuration for --pid-file: Location '/var/run/mysqld' in the path is accessible to all OS users. Consider choosing a different directory.
2025-05-28 22:41:33 2025-05-28T14:41:33.171347Z 0 [System] [MY-011323] [Server] X Plugin ready for connections. Bind-address: '::' port: 33060, socket: /var/run/mysqld/mysqlx.sock
2025-05-28 22:41:33 2025-05-28T14:41:33.171484Z 0 [System] [MY-010931] [Server] /usr/sbin/mysqld: ready for connections. Version: '8.4.3'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  MySQL Community Server - GPL.

2.2 业务日志

业务日志是由开发工程师在编写业务代码时手工编写的日志,主要用于记录业务逻辑的执行过程、用户操作、业务数据等。

这部分日志是开发工程师根据具体需求编写的,具有很强的针对性。其特点包括:

  • 手动编写:由开发工程师根据业务需求编写;
  • 针对性强:记录业务逻辑的关键信息,便于调试和分析;
  • 格式灵活:可以根据业务需求自定义日志格式和内容。

例如业务操作日志、调试日志、性能日志。

在业务代码中自定义日志:

log-info.png

服务执行时,日志输出:

spring-log-info.png

2025-05-28 22:42:03.755 [main-57] INFO  cn.xiaolin.has.HasApplication 57 logStarted - Started HasApplication in 13.236 seconds (process running for 14.52)
2025-05-28 22:42:03.758 [main-77] DEBUG o.s.b.a.ApplicationAvailabilityBean 77 onApplicationEvent - Application availability state LivenessState changed to CORRECT
2025-05-28 22:42:03.759 [main-90] INFO  cn.xiaolin.has.config.AppConfig 90 run - 项目启动,自定义初始化...
2025-05-28 22:42:03.759 [main-93] INFO  cn.xiaolin.has.config.AppConfig 93 run - 当前主机 home 目录: C:\Users\xingxiaolin
2025-05-28 22:42:03.759 [main-99] INFO  cn.xiaolin.has.config.AppConfig 99 run - 视频文件目录已存在:C:\Users\xingxiaolin\hls-video
2025-05-28 22:42:03.760 [main-77] DEBUG o.s.b.a.ApplicationAvailabilityBean 77 onApplicationEvent - Application availability state ReadinessState changed to ACCEPTING_TRAFFIC

三、日志的作用 Usefulness

影视剧导演总喜欢用这样的镜头体现黑客的专业性与神秘性:一名电脑黑客屏幕上密密麻麻持续输出海量文本,背景是黑色的,专注地盯着屏幕!

使用 豆包AI 根据上述语言描述生成图像

黑客操作电脑.png

其实可能就执行了一条指令:

tail -f /var/log/myapp.log

依据笔者的开发和运维工作经验,基础日志使用场景:

  1. 健康巡检:版面发布后检查异常日志;
  2. 故障诊断:记录故障现场,用于故障发生后运维专家或开发人员介入;
  3. (特别地)审计需要,满足审计部门要求;

进阶使用场景:

  1. 故障预警:在很多场景中,系统故障是累计的结果(量变到质变),发生前会输出异常日志;
  2. 数据挖掘:从海量日志中挖掘有效信息,大数据分析。

四、建立日志中心的必要性 Necessity

在默认情况下,日志的形态通常是比较原始和简单的,这种状态可以被称为裸奔状态,无论是取用,还是检索分析,都非常不人体工学。

4.1 非结构化

非结构化日志是指日志内容没有统一的格式和规范,通常以纯文本形式存在,记录的内容和格式因应用程序、框架或开发人员的习惯而异。存在以下问题:

  • 解析困难:由于格式不一致,难以通过自动化工具解析和分析日志内容;
  • 分析效率低:人工分析日志时,需要花费更多时间理解日志格式和内容;
  • 难以扩展:随着系统复杂度的增加,非结构化的日志难以满足大规模数据分析的需求。

4.2 分散存储

当今 IT 系统流行的架构风格是:微服务架构。在部署平面上看,存在 MM 个微服务,NN 个服务实例。日志通常分散存储在各个节点上,每个服务实例生成的日志独立存储在本地文件系统中。存在以下问题:

  • 管理困难:需要手动访问每个节点查看日志,难以进行集中管理和分析;
  • 查询效率低:查询跨多个节点的日志时,需要逐个节点查找,效率低下;
  • 难以关联:难以将不同节点的日志关联起来,分析分布式系统的全局行为。

4.3 缺乏检索功能

默认情况下,日志文件通常是简单的文本文件,缺乏高效的检索功能,难以快速定位特定事件或问题。通常需要使用命令行工具(如greptail)手动查找日志内容。存在以下问题:

  • 查询效率低:对于大型日志文件,手动查找耗时较长;
  • 难以分析:无法进行复杂的查询和分析,难以发现隐藏的问题;
  • 缺乏实时性:难以实时监控和分析日志,无法及时发现和处理问题。

导出很大的日志文件,在特定的文本编辑器上打开,会存在文件过大,难以读取的问题。

4.4 日志丢失

日志的生命周期和服务实例一致,服务实例消亡后,日志也被清空删除。

在生产环境中,由于各种原因(如磁盘空间不足、日志文件被覆盖、系统崩溃等),日志可能会丢失,导致无法追溯问题。

五、权衡与思考

虽然上述已经较多描述了日志的作用,和建设集中化日志中心的必要性,但是还是要着眼现实问题。

在当今众多的 IT 系统中,绝大多数企业只关注核心业务功能,而忽视外围运维能力建设,甚至代码仓库、多分支多环境管理都没有!CI/CD 和 Observability 就更别提了。

很多大型企业在这方面也是差强人意!

狗屎代码.jpg

运维能力建设与业务功能开发在收益表现上有显著差异。业务功能直接面向用户,能够快速带来经济效益,而运维能力建设的收益往往较为隐蔽,难以直接量化。

因此,从成本与收益角度试着切入分析,为决策提供依据。

5.1 成本与收益

在南京花 300 万元买一套房子,那么房主会毫不吝啬地花费 30 万元进行房屋装修。在东北某县城花 10 万元买一套房子,那么房主花 2 万元装修都嫌花得多了。

同样的道理,软件开发成本是较高的,中小型系统本来投入成本就不高,招聘一名程序员工作 5 天的钱可以付一个普通员工 1 个月的工资了。运维能力建设投入与系统业务需求投入有一定的内在比例关系!

使用开源技术栈,则不需要购买软件许可证,否则还需要支付高昂的软件授权费用。

日志中心建设的成本主要体现在硬件成本和人力成本。以我们公司为例,与日志相关联直接收益与代价的场景:

  1. 开发域和运维域隔离,开发人员需要查看日志进行故障分析时,需要运维人员登录服务实例(容器 Pod)中捞取,运维人员登录到容器 Pod 需要管理员审批。购买代维合同需要投入不少的资金,管理员也需承担繁重的工单审批事务性工作;
  2. 系统出现故障,基于裸奔日志定位效率低,或者日志丢失故障完全不可追溯,对业务连续性产生较大影响,用户服务质量差。上级领导或用户的投诉,可能会带来很大的压力;
  3. 硬件资源如服务器、存储设备、网络设备、机房,以及电费、代维费用,仔细算一下还是很昂贵的。通过日志分析,了解系统资源的使用情况,优化资源利用,避免资源浪费。

5.2 决策

从我的视角看,对于微型开发团队(不超过 5 人),开发人员少,可能只有 1 个全栈工程师,几乎没有沟通成本,不需要进行日志中心建设,裸奔日志又不是不能用。

又不是不能用.jpg

如果必须要有日志中心能力,且没有本地部署的安全要求,建议直接购买阿里云 SLS 、腾讯云 CLS 日志服务,功能丰富强大且成本会比自建要低很多。

最后,实打实的算一笔账,如果因为日志能力薄弱,购买了更多额外的代维服务,或者造成了经济损失,那么有必要向领导汇报申请进行日志中心建设。

总结与下一步工作

本文对日志的分类、作用、以及当前日志管理存在的问题讨论分析,明确了日志中心建设的重要性。

同时,也从现实角度出发,分析了运维能力建设与业务功能开发在成本与收益上的差异,并提出了在不同场景下的决策建议。对于小型开发团队,日志中心建设可能并非必要;而对于有一定规模的企业,尤其是面临日志管理痛点的企业,建设日志中心或采用云服务的日志解决方案是提升运维效率和系统可靠性的重要举措。

下一步工作需要关注建设日志中心的目标,以及需要考量的因素,开始着手关键技术选型。