企业官网建设流程全解析

十年前接到线上故障，最顺手的动作是ssh登上服务器，先tail -f /var/log/nginx/access.log，看不到异常就grep -i error /var/log/app.log，再不行就cat /var/log/messages | sort | uniq -c | sort -rn数一数错误行出现的次数。当时的日志就是“文件”，排查就是“命令行文本操作”，没有采集、检索、分析这些概念，一切全凭手上那几台机器。这十年里，日志从没人当回事的txt，硬生生演变成了分布式系统里最基础也最关键的基础设施：它不再只是文本，而是经过采集传输、清洗结构化、集中存储、检索分析、可视化、甚至AI根因定位的一条完整数据链路。

这篇就是围绕“日志十年演进”这条主线，把这十年里日志的形态变化、采集方案、存储检索、清理维护、排障实战、以及现在热度越来越高的AI日志分析一次讲透。不管你是后端、运维、SRE，还是做嵌入式、管Windows服务器、写脚本跑任务的，文中涉及的实操命令和排查思路都可以直接拿去用。

1. 日志形态的十年变迁：从“文件”到“数据流”

1.1 本地日志时代：tail加grep就是全部

回忆一下2015年左右的典型环境。那时候大部分应用还是单体部署，日志散落在各台服务器上：Nginx的access.log、Tomcat的catalina.out、MySQL的slow.log、系统的messages，再加上计划任务输出。要查问题，靠的是tail、less、grep、awk这几个命令的组合。这就像把便签纸随手扔在办公室各个角落，找一张关键纸条要翻遍所有抽屉。

那时候大家问得最多的问题就是“日志文件怎么看”。这里的“看”分两种情况。一种是普通文本日志，用cat、tail -f、less就能读；但有些特殊格式，比如嵌入式车载领域常见的DLT日志（Diagnostic Log and Trace），它有二进制头结构，纯cat会看到乱码，完整解析要使用对应的DLT Viewer工具，命令行里可以用file dlt文件判断格式、用xxd查看头部字节。这个例子告诉我们：日志文件不等于纯文本，读取方式取决于生成端的格式定义。

另一个高频问题是“crontab执行日志怎么看”。老派的CentOS/RHEL系统，cron作业的执行记录写在/var/log/cron里，直接tail -f /var/log/cron就能看到任务是否被触发、执行结果如何。但到了systemd时代，日志走了journald，要看crond的日志就得换命令：

# 老系统 tail -f /var/log/cron # systemd时代 journalctl -u crond --since "1 hour ago"

这些命令到现在我都还在用。本地日志时代最大的问题不是“能不能看”，而是“日志分布太散、格式不统一、多个服务之间的时间线对不上”。当服务器从三五台涨到三五十台，这套手工方案就彻底撑不住了。

1.2 集中采集时代：ELK为什么能成为事实标准

大约从2013年到2016年，ELK（Elasticsearch、Logstash、Kibana）这套组合逐渐成为日志处理的事实标准。Logstash负责在服务端做采集、解析、清洗，Elasticsearch负责存储和全文检索，Kibana负责展示面板。它的意义不在于“工具多华丽”，而在于把散落的日志从“便签纸”变成了“档案库”：所有服务器产生的日志汇总到一处，可以按时间、关键字、IP、日志级别做秒级检索，还能画趋势图。

当时我接手的第一套ELK部署，每天处理大概5GB日志，两台4核8G的ES节点就跑得动。配置Logstash时最痛苦的其实是grok正则解析，一行Tomcat访问日志要用一大串正则才能抽出IP、时间、URI、状态码。后来随着日志格式逐渐规范化，这条链路才慢慢不那么痛苦。

ELK普及之后，“filebeat日志采集”这个词开始频繁出现。filebeat是Elastic官方推出的轻量采集器，用Go写的，内存占用远低于Logstash。它的定位非常清晰：Logstash太重，不适合直接跑在每台业务服务器上做采集；filebeat只负责“把文件读出来、发出去”，把解析和清洗交给服务端的Logstash或ES Ingest Pipeline。采集端越轻，对业务影响越小，这就是它取代Logstash采集器地位的根本原因。

1.3 容器时代：日志跟着容器“跑”

2018年前后Docker和Kubernetes大规模落地，日志这个问题又变了一个层次。容器应用通常把日志打到stdout，由容器运行时收集成JSON文件，比如/var/log/containers/下能看到的那些软链接。容器一旦被杀，日志可能随存储一起消失，所以K8s集群里必须跑一个DaemonSet采集器，逐节点读取容器日志，再送进后端。这套思路到现在还是主流。

与此同时，systemd把服务日志的管理方式也改了。以前写init脚本，应用自己输出到文件；现在systemd service默认把进程的标准输出和标准错误接到journald，统一通过journalctl查看。在unit文件里可以这样配置日志去向：

[Service] ExecStart=/opt/app/bin/run StandardOutput=journal StandardError=journal SyslogIdentifier=myapp

这样配置之后，应用在终端打印的所有内容都会进journal，运维端执行journalctl -u myapp -f就能实时看。如果只想让某些日志输出到当前终端做调试，可以把StandardOutput改成inherit或console。很多新手纳闷“systemd服务启动后日志去哪了”，十有八九就是没理解这个输出重定向逻辑。

容器时代还带来一个之前不怎么被重视的问题：存储寿命。嵌入式设备、安卓类终端的日志落在flash分区上，如果应用刷日志太频繁，完全没有规律地写，很可能把flash写坏，甚至导致设备无法启动。所以这类场景下，日志区要单独规划flash分区，限定日志文件大小和轮转策略，必要时做磨损均衡。“flash分区如何分配”这个问题的本质，其实是“日志的写入量必须受控”，这个原则到现在都没有变。

2. 采集与接收：那些年踩过的日志坑

2.1 为什么采集端一定要“轻”

我见过不少团队试图用一台胖Logstash把采集、解析、告警全干了，结果业务高峰期CPU直接飙到90%。原因很简单：Logstash基于JVM，启动就占几百MB内存，还做大量正则解析，跑在业务机上是灾难。而filebeat这类Go采集器，默认内存占用几十MB，没有JVM的GC抖动问题，非常适合长期驻留。

filebeat真正好用的几个设计，我推荐有条件的都去试一下。一是“多行合并”，Java异常堆栈往往几十行，如果不合并，一条异常就被拆成几十条日志，检索时非常痛苦。在filestream输入里这样配置：

filebeat.inputs: - type: filestream id: app-log paths: - /var/log/app/*.log parsers: - multiline: type: pattern pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}' negate: true match: after

含义是“不是以日期开头的行，都合并到上一条日志后面”。这样一来，堆栈、消息续行都能归到同一条日志记录里。

二是“背压处理”。当下游ES或Logstash不可用时，filebeat不会傻乎乎地丢弃日志，而是把读取位置记录在本地registry文件里，等下游恢复后继续发送。这个机制在实际运维中救了我很多次：ES重启、网络抖动、Kafka分区不可用，都没导致数据永久丢失。这比很多自研采集脚本强太多——很多人用tail -f | curl的方式送日志，下游一断，中间的数据就无声无息丢了。

2.2 应用日志规范：结构化是分水岭

采集端再稳，也要应用侧愿意配合。我发现一个很普遍的现象：很多项目庆祝完了“日志上了ELK”，团队里没人看日志，因为打出来的都是夹杂着中文编码问题、多行堆栈、没有时间戳的“毛坯日志”。日志十年演进里真正翻天覆地的变化，不是工具，而是应用开发者开始懂“日志怎么写”。

Python场景我用了很多年，logging模块配合RotatingFileHandler是标准做法：

import logging from logging.handlers import RotatingFileHandler logger = logging.getLogger("order") logger.setLevel(logging.DEBUG) handler = RotatingFileHandler( "order.log", maxBytes=10 * 1024 * 1024, backupCount=5, encoding="utf-8", ) handler.setFormatter(logging.Formatter("%(asctime)s %(levelname)s %(name)s %(message)s")) logger.addHandler(handler)

这里涉及一个常被忽略的概念：日志作用域。logging模块里的logger是层级结构的，例如order是root的子级。默认情况下，子logger的日志会向父logger传播（propagate），如果root logger也配了handler，同一行日志会被打印两次。排查这种“重复日志”时，先查是不是多个handler叠加，再看是不是propagate导致的，确认后:

logger.propagate = False

还有一个真实高频问题：uvicorn/fastapi日志丢失或打印不出来。很多人写完FastAPI接口，发现自己的logger.info在终端里看不到，或者uvicorn访问日志没了。根因通常是uvicorn自带一套log_config，里面默认disable_existing_loggers=True，它会把你提前创建好的logger全部禁用。解决办法很简单，启动时关掉它的默认配置，换成自己的：

if __name__ == "__main__": uvicorn.run("app.main:app", host="0.0.0.0", port=8000, log_config=None)

然后自己在应用入口统一配置root logger。还有很多项目踩过这个坑十几次，问题不在代码，而是没用过这种“框架自带日志配置覆盖全局”的场景。

2.3 传输不丢：Kafka缓冲这条路

日志量一旦每小时超过几十GB，直接让filebeat怼到ES就会出问题：ES索引写入跟不上，bulk请求积压，甚至触发熔断，日志就丢了。我在2020年遇到的一个项目就是双11流量压过来，ES集群CPU打满，日志延迟数小时，排障时根本看不到实时日志。

后来团队采取的方案是“filebeat -> Kafka -> Logstash -> ES”的三段式结构。Kafka在这里只做缓冲，不关心日志内容，只要分区足够，吞吐基本是无限的。filebeat侧配置输出时改一下：

output.kafka: hosts: ["kafka-01:9092", "kafka-02:9092"] topic: "app-log" partition.round_robin: reachable_only: false required_acks: 1

Kafka的ack机制保证了写入副本成功才返回成功，filebeat会根据返回结果决定是否重发。这样即便ES突然挂了，日志也只是在Kafka里堆积，不会蒸发。这套架构至今仍是中等以上规模的日志系统标配。日志十年演进，本质上就是“采集—缓冲—清洗—存储—消费”这条管道越来越成熟的过程。

3. 存储与检索：从grep到搜索引擎，再到“够用就好”

3.1 Elasticsearch：把日志当文档搜

ES能把日志处理变成“搜索体验”，核心是倒排索引：把每行日志的词语切词后建立索引字典，查询时直接查字典，而不是全文扫描。你可以想象一下，没有索引的 grep 是每本厚厚的书从头翻到尾，而ES相当于给所有书做了目录。

排障时最常用的ES查询，我一般写成这样：

GET /app-logs-*/_search { "query": { "bool": { "must": [ { "match_phrase": { "message": "OutOfMemoryError" } } ], "filter": [ { "range": { "@timestamp": { "gte": "now-1h" } } } ] } }, "sort": [ { "@timestamp": "desc" } ], "size": 100 }

这里的match_phrase是短语匹配，比单纯的match更精确；filter里的时间范围不进评分，查询更快。Kibana里可以直接用KQL写成message: "OutOfMemoryError" and @timestamp >= "now-1h"，更简单。

ES用久了会产生一个巨坑：索引数量失控。日志类索引一般按天或按小时分索引，如果不管旧索引，磁盘迟早被塞爆。必须配置索引生命周期管理（ILM）或定时任务删除过期索引。这个“日志清理”的问题，几乎是每个用ELK的人都会碰到的老大难，下面单独展开细讲。

3.2 轻量级方案：Loki与ClickHouse各有所长

不是所有团队都需要上ES。我后来在一些中小项目里用了Grafana Loki，它走的是“标签索引＋日志原文”的思路：不为日志内容建全文索引，只按标签（如app、namespace、pod）建立索引，查询时先按标签过滤、再扫日志内容。就像你不需要给每本书做全文目录，只需要知道它在哪个书架，再直接翻。优点是资源消耗极低，适合日志量不大、检索需求简单的场景。缺点是复杂查询能力不如ES，比如深度的正则、聚合分析就别指望了。

ClickHouse则是另一个极端：列式存储、压缩率极高、分析性能极强，适合海量日志做统计分析。我之前参与过一个每天上亿条日志的项目，ES集群撑到5个节点就开始吃力，换成ClickHouse后两个节点就扛住了，聚合查询秒级返回。代价是没有全文检索那么顺手，需要自己建表、写好查询SQL。

选型这条路没有标准答案：团队熟悉什么、日志量多大、预算多少、检索场景偏关键字还是偏统计，都要摆到桌面上聊。一条比较稳妥的经验是：初期日志量百万级一天，用Loki或自带日志服务，别一上来就上ES；日增量过千万且需要复杂分析，再用ClickHouse或ES都不晚。

3.3 日志清理：十年里最折腾人的一件事

“日志日志，越攒越大，想删又不敢删”，这几乎是所有人的心声。清理日志不是执行一条命令那么简单，它关乎哪些文件能删、删了会不会影响运行中的进程、以及数据库日志和系统日志各自有不同的坑。

先看Linux系统常见的清理操作，我整理了一张速查表：

这里最经典的坑是：直接rm /var/log/app.log，磁盘空间却不释放。原因是应用进程还持有这个日志文件的文件描述符（fd），文件被标记为删除，但进程仍在写入，磁盘块没释放。正确做法是truncate -s 0清空而不是删除，或者重启进程/用logrotate的copytruncate方案。

再看数据库类日志。“sql2008日志文件过大怎么删除”是我被问得最频繁的问题之一。SQL Server的日志文件承载事务记录，不能直接拿文件删掉，必须用DBCC SHRINKFILE收缩。常规套路是：

USE YourDB; -- 先备份，或临时把恢复模式改为简单 ALTER DATABASE YourDB SET RECOVERY SIMPLE; DBCC SHRINKFILE (N'YourDB_log', 1024); ALTER DATABASE YourDB SET RECOVERY FULL;

注意这只适用于日志文件可以释放的场景。如果数据库开启了完整恢复模式且日志里有未备份的活动部分，shrink也收缩不动；生产环境改恢复模式一定要先评估备份策略，别把灾备链路弄断。

MySQL的binlog也是一个高频问题，“binlog日志可以删除吗”的答案是：可以，但别直接rmbinlog文件，那会破坏binlog索引。要用MySQL自己的清理机制：

-- 删除指定时间之前的binlog PURGE BINARY LOGS BEFORE NOW() - INTERVAL 7 DAY; -- 或设置自动过期 SET GLOBAL binlog_expire_logs_seconds = 604800;

如果做了主从复制，清理binlog前务必确认所有从库都已完成拉取，否则从库追不上主库，整个复制链路就断了。

Oracle监听日志的清理，10g时在$ORACLE_HOME/network/log/listener.log，手动清空可以用> listener.log，但Oracle推荐用ADRCI清理诊断日志：

adrci exec="purge -age 7200 -type alert" adrci exec="purge -age 7200 -type trace"

Windows事件日志和普通文件日志还不太一样。事件查看器里可以设置“日志最大大小”和“按需要覆盖事件”，命令行里可以用wevtutil：

# 设置应用程序日志最大20MB，允许覆盖 wevtutil set-log Application /maxsize:20971520 /retention:false # 清空日志 wevtutil cl Application

国产银河麒麟这类基于Linux内核的系统，清理journal日志的方式和Ubuntu/CentOS一致：

sudo journalctl --disk-usage sudo journalctl --vacuum-size=200M

清理这件事，最重要的经验是“先轮转、再删除、设周期”。不要等日志把磁盘占满了才想起来清理，那是救火；真正成熟的方案是在每台服务器上配好logrotate或journald限制，让日志最多留30天或1GB，到期自动滚走。把清理交给自动化，而不是交给人的自觉。

4. 排障实战：日志如何还原“事故现场”

4.1 安全日志溯源：auth.log里的“案发时间线”

服务器疑似被入侵时，第一件事不是装杀毒软件，而是翻日志。Ubuntu/Debian系的用户认证日志在/var/log/auth.log，CentOS/RHEL系在/var/log/secure。我最常执行的一组命令是：

# 暴力破解尝试 sudo grep "Failed password" /var/log/auth.log | tail -20 # 成功登录的记录 sudo grep "Accepted" /var/log/auth.log # 按IP统计失败次数，找攻击源 sudo grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn # 最近登录用户和时间 last lastlog

有一次我从auth.log里看到用户mage在凌晨3点成功登录，但正常业务根本不该在那个时间登录。这个成功登录就是关键时间点。顺着它往下查：查mage的shell历史、查是否被加入sudo组、查~/.ssh/authorized_keys有没有多出可疑公钥、查crontab里有没有新增持久化任务。日志溯源的核心，其实就是把第一次“异常”的时间标记出来，然后一条一条往前和往后推，把攻击者做过的事串成完整时间线。

遇到恶意攻击域名反复投递、C2反向连接之类的场景，完整处置思路是“日志找证据、网络层阻断、主机加固、规则沉淀”。第一步：从Web访问日志、DNS日志、auth日志里找出恶意域名的解析记录和访问源IP。第二步：在网络层把恶意域名DNS解析给过滤掉，防火墙封禁来源IP。第三步：检查主机上是否留下后门文件、新启动的服务与计划任务，清理干净。第四步：在WAF和IDS里补上域名、IP、特征路径的拦截规则，形成长期监控。整个过程，每一步都依赖日志来验证——“这条规则生效了吗？还需要看有没有新的日志触达”。没有日志，安全运维就是盲人摸象。

4.2 Windows日志与蓝屏：从事件查看器找出“莫名关机”的真相

“电脑莫名关机”这个话题一出现，很多只懂Linux的同行就直接懵了。其实Windows的日志体系一样有规律，关键是把事件查看器里的Event ID对应起来。

最常见的几个事件ID：

蓝屏日志的位置一般在C:\Windows\Minidump，文件是.dmp格式，可以用WinDbg或者BlueScreenView打开，能看到崩溃的驱动和代码。

设置Windows日志记录天数，本质上就是事件查看器里的“日志属性”设置最大大小和覆盖策略，也可以用命令行：

wevtutil set-log Security /maxsize:104857600 /retention:false

如果只想看最近一段时间，PowerShell更顺手：

Get-WinEvent -LogName System -MaxEvents 100 | Where-Object Id -eq 41

4.3 应用与任务日志：每天跑的任务到底成没成

计划任务、定时脚本、调度平台，这类“没有人盯着跑”的日志最容易被忽略，但出问题也最隐蔽。

XXL-JOB的日志检索，核心在“调度日志”页面：按Job ID、执行器、触发时间筛选，点进去能看到“调度结果”和“执行日志”。这些日志后端落在xxl_job_log表里，同时会输出到执行器配置的日志目录。如果某条调度显示“成功”但业务没跑，多半是执行器日志文件里藏着真实异常。

Windows任务计划程序，右侧操作面板里有个“所有任务执行历史记录”，但它依赖事件查看器里的“Microsoft-Windows-TaskScheduler/Operational”日志，默认可能未启用，需要在事件日志属性里勾选启用，才能看到历史记录。很多人问“任务计划日志怎么看”，先检查这个通道是否开了，再谈别的。

安卓端的日志，最常见的坑是“真机上看不到print”。使用adb抓取日志是基本功：

# 实时输出到文件 adb logcat -v threadtime > bugreport.log # 先清除旧缓冲区，再重新抓取 adb logcat -c

uniapp不打印日志信息，很多时候不是代码问题，而是真机调试时还连着调试服务，但vConsole层没开启，或者日志输出到了release包之外的地方。此时抓一份logcat，在HBuilderX控制台和logcat里交叉对照，基本能定位是前端console写了但没触发，还是根本没执行到那行代码。

Redis的日志，默认输出到stdout，在生产环境建议在redis.conf里设置loglevel notice和logfile /var/log/redis/redis-server.log，否则daemonize配置不当，日志会消失得无影无踪。排查Redis慢操作也不一定非得看普通日志，直接SLOWLOG GET 10能看到慢命令记录，这个比翻日志快得多。

4.4 数据库慢查询与binlog：故障恢复的两个关键日志

MySQL性能卡顿，第一个要开的就是慢查询日志。合理的配置是：

slow_query_log=1 slow_query_log_file=/var/log/mysql/slow.log long_query_time=2 log_queries_not_using_indexes=1

开启后，超过2秒的查询都会被记录。分析慢日志可以用自带的mysqldumpslow：

mysqldumpslow -t 10 /var/log/mysql/slow.log

它会按SQL模式聚合，把“同一类慢查询”汇总成一条，而不是逐行列出几千条，看着不累。

binlog对运维来说不只是复制用的，它还是“后悔药”。当业务误删数据时，只要 binlog 还在，就可以通过mysqlbinlog解析出恢复语句：

mysqlbinlog --base64-output=decode-rows -v binlog.000123

不过要强调：binlog能恢复是锦上添花，真正的底线还是定期物理备份。日志是“线索”，备份才是“资产”，这个观念别搞反。

5. 日志的下半场：可观测性与AI分析

5.1 三大支柱：日志、指标、链路缺一不可

演进到最近几年，单看日志排障已经不够了，因为系统大多是微服务。你看到订单服务报错，但它调用了用户服务、支付服务、消息队列，错误因子可能在任何一个环节。这时候需要把日志与指标（Metrics）、链路追踪（Tracing）放到一起，构成“可观测性”三件套。

这个组合里，日志还是基础，但需要多打一个关键字段：Trace ID。当请求进来时生成一个唯一ID，传给下游服务，所有服务在日志里都带上这个ID。排障时先按Trace ID把所有相关日志拉出来，再对着时间线看哪个环节慢、哪个环节异常，效率比从日志里瞎翻提升几十倍。

Python里打Trace ID最简单的方式是加一个日志extra字段：

import uuid request_id = request.headers.get("X-Request-Id") or str(uuid.uuid4()) logger.info("创建订单开始", extra={"trace_id": request_id})

配合日志采集时把Trace ID提取为单独的索引字段，Kibana里点一下这个ID就能跳到该请求的所有日志。我自己在实际排查中，80%的微服务问题都能靠这个方式在三分钟内定位。

5.2 专业日志服务器与syslog-ng

网络设备（交换机、路由器、防火墙）的日志，格式相对老旧，最主流的协议还是syslog。很多团队对“专业日志服务器”的预期就是：能收、能存、能查、能告警。syslog-ng和rsyslog是服务器端的常青树，可以把多台设备发来的syslog按来源IP、facility分别落盘。

syslog里有个知识点是“日志设施”（facility），它定义了日志的来源类别：auth、daemon、kern、local0到local7等。网络设备和Linux系统配置日志时，都会指定facility和级别，比如 Cisco交换机上logging facility local5，接收端就可以根据facility判断数据来自哪类设备，分文件保存。syslog-ng典型配置：

source s_net { tcp(ip(0.0.0.0) port(514)); }; destination d_switch { file("/var/log/network/switch.log"); }; log { source(s_net); destination(d_switch); };

部署这类日志服务器最需要注意的，是端口和时区。设备默认发UDP 514，网络不通或防火墙挡了，日志就静默消失；时间不同步会导致日志排序混乱，排查时对不上海量事件。建议统一规划NTP，且接收端尽量开启TCP传输，增加可靠性。

5.3 AI能帮我们读日志吗

“请问用什么AI工具能精准分析日志”这个问题，我最近被问得很多。坦白说，现阶段不存在一个“喂进去几万行日志、吐出来根因结论且一定正确”的神器。但AI辅助日志分析已经能落地，前提是方法对。

我的实践是：先用规则和检索把日志量从几十万行压到几百行，再用LLM去做归纳。普通大模型适合做三类事：摘要总结（这几百行日志讲了什么）、异常聚类（哪些错误反复出现）、初步根因建议（根据已知错误代码给出排查方向）。给AI的输入不要直接扔原始文本，最好先转成结构化JSON，按字段（时间、级别、服务、消息）清洗后再投喂，准确率高很多。

要注意的点是日志脱敏。日志里经常混有手机号、身份证、token、SQL语句，直接把这些原始内容发给第三方大模型，会带来不小的数据风险。企业内部应该先在采集端做脱敏规则，把敏感字段替换成占位符，再把脱敏后的内容交给AI处理。

日志驱动的AI根因定位，在特定领域（比如UVM硬件验证）已经有了成功案例：把仿真日志和波形数据喂给模型，让它把失败原因归类。这说明自动化根因分析的方向是对的，但结果是“候选根因”，最终还是需要人坐在旁边确认。AI的价值不是取代人，是把“在一万行日志里找线索”的时间缩短成“在一百个候选里做判断”。

我这两年的体会是，日志演进到“可观测性＋AI辅助”阶段，真正考验团队的已经不是工具多先进，而是日志质量：有没有Trace ID、有没有结构化字段、有没有保留周期、采集端稳不稳。工具链可以堆得很漂亮，但如果业务日志全是无脑print，那后端的ES、Kafka、AI模型都只能当摆设。

如果你正在搭新项目的日志体系，我建议从第一天就定三件事：日志必须有时间戳、必须结构化、必须带请求ID。做完了这三件事，后面的采集、检索、分析才有意义。另外，日志清理不要等磁盘报警再做，把它写进系统和数据库的初始化脚本里，让轮转和保留周期变成默认配置，而不是救火动作。这些才是我在各种规模的系统里反复验证过、最值得投入的地方。