从grep到可观测性：日志采集、清理与排查实战全解

设想一个场景十年前排查线上问题第一反应是ssh登到机器上cd到/var/logtail -f或者grep一把梭。今天大家遇到故障多半是打开日志平台输入关键字、选好时间范围几秒钟出结果。这种变化背后是整个日志体系在采集、传输、存储、分析、治理几个层面的十年演进。这篇文章不聊虚的只讲这十年里日志技术栈怎么变、如今的采集链路怎么搭稳、日志满了怎么清、排查问题有哪些实用套路以及这些年我自己踩过的坑和总结的操作经验。无论你是运维、后端、测试还是安全相关岗位只要日常跟日志打交道这篇内容应该都能给你一些直接能用的东西。1. 日志体系这十年从“翻文件”到“可观测性”1.1 单机时代日志就是一堆没人管的文本文件十年前大部分项目的日志策略非常简单应用在服务器上往本地文件写日志运维靠logrotate做轮转排查问题靠人肉登录。我还记得当时为了查一个接口偶发报错先后登录了六台应用服务器挨个grep ERROR /opt/app/log/xxx.log | tail -1000靠肉眼对比时间点附近的上下文。运气好半小时搞定运气不好日志轮转了或者被覆盖了就只能猜。那个时代的主要矛盾是日志只有一份却要满足所有人的排查需求。后端要看、运维要看、偶尔测试也得看。文件权限、磁盘空间、日志格式没人统一管。最惨的一次是某个服务写日志写得太疯狂半天把磁盘写满应用直接挂掉。当时处理方式也粗暴删log文件重启应用。但删完发现进程还占着文件句柄磁盘空间根本释放不了只能先kill再重启。这些痛点逼着大家往两个方向想一是能不能让日志集中存放二是能不能让日志别再成为事故的源头。前者催生了集中日志方案后者催生了后面完善日志治理的执念。1.2 集中采集时代syslog-ng 这类服务成了标配日志集中化最早大规模落地的方式就是syslog。Linux服务器、网络交换机、防火墙设备大多原生支持syslog协议只要配一个中央日志服务器设备把日志通过UDP或TCP发过去就行。我记得当时用syslog-ng搭交换机日志服务配置不算复杂但有个很实际的坑UDP默认不保证可靠网络抖动就会丢日志后来全改成TCP传输才稳定下来。syslog-ng相对rsyslog优势在于过滤规则灵活、支持多目标转发在日志量不大、格式以文本为主的时代非常合适。那时候所谓“日志分析”基本就是日志服务器上grep awk sort三件套按IP、按时间、按关键字统计。做安全审计时把交换机日志、防火墙日志、服务器登录日志集中到一起出问题好歹有地方查了。但集中采集只是第一步格式不统一的问题很快暴露出来同一个时间字段有人写2025-01-01 12:00:00有人写01/Jan/2025:12:00:00 0800IP格式、URL转义、状态码含义各有各的写法。纯文本时代分析靠肉眼和正则效率很低。这也为后面全文检索引擎的入场埋下了伏笔。1.3 存储与分析演进从文本文件到搜索引擎再到列式存储集中日志之后检索需求越来越强。ELKElasticsearch Logstash Kibana在那个时间点出现几乎是精准踩中了痛点Logstash做采集解析Elasticsearch做全文索引Kibana做可视化。第一次用Kibana输入一个关键字、几分钟出结果的体验确实比登录几十台机器grep舒服太多。再往后ClickHouse和Loki两个方向也发展起来。ClickHouse用列式存储和SQL语法处理海量日志查询分析能力极强适合对时序日志做聚合统计。Loki则另辟蹊径只存索引不存原文日志原文留在压缩文件里配合标签检索成本低很多。到了这个阶段日志已经不只是“排障用的文本”而是和指标、链路追踪并列的可观测性三大支柱之一。日志要能回答的问题也从“出了什么错”扩展到“为什么慢”、“哪里异常”、“用户行为路径是什么”存储和查询引擎也随之分化。2. 采集链路怎么搭才稳filebeat 实战与避坑2.1 选型逻辑为什么轻量采集端逐渐成为主流说到现在的日志采集绕不开两个名字Logstash和Filebeat。早期ELK方案里大家喜欢全用Logstash部署一个采集端filter里做正则解析、字段切分输出到ES。用过的人都知道Logstash能吃资源默认堆内存512MB起步业务稍微复杂能吃到1GB以上。在每台业务机器上都部署Logstash成本实在高。Filebeat的思路完全不同它是一个极轻量的采集Agent常驻内存大概几十MB只负责读文件、把内容原样或简单处理后转发出去不做重解析。所以现在的主流架构基本是Filebeat采集文件 - 发到Kafka/RabbitMQ缓冲 - 后端的Logstash或Fluentd做解析 - 写入ES或ClickHouse。好处很直观业务机上只放一个低消耗的采集端解析逻辑集中到管道后端出了问题方便统一修改。从热词里还能看到不少人在搜“filebeat日志采集”确实很多团队正在从“自己写脚本收集日志”切换到Filebeat。我的建议是单机日志量不大、团队没有专门日志平台的时候直接上Filebeat加一个ES就能跑如果每天日志量上亿条再考虑引入Kafka缓冲和ClickHouse。2.2 Filebeat 配置实操多行合并与输出链路Filebeat的核心配置文件filebeat.yml最基础的部分是input和output。下面这个配置是我在实际项目里用得比较顺手的简化版filebeat.inputs: - type: log enabled: true paths: - /data/app/logs/*.log fields: app: payment-service env: prod fields_under_root: true multiline: pattern: ^\d{4}-\d{2}-\d{2} negate: true match: after timeout: 5s output.kafka: hosts: [kafka1:9092, kafka2:9092] topic: app-logs partition.round_robin: reachable_only: true required_acks: 1这里最值得展开的是multiline配置。Java异常栈、Python的Traceback都是多行日志如果按行拆开采集一条报错会被拆成十几条碎片后期检索非常痛苦。上例的pattern表示“一条新日志以日期开头”negate: true表示不匹配该模式的行不算新日志match: after则是把不匹配的行合并到上一条日志后面。timeout参数也很关键设置了5秒防止最后一条日志迟迟等不来后续行导致缓存不释放。这里踩过的坑是如果日志里在同一行内恰好有异常栈的关键字正则会误判所以尽量用日志行首的可疑时间戳做断行标记。output到Kafka时required_acks: 1配合Kafka可以做到写入不丢。如果直接输出到ES可以这样output.elasticsearch: hosts: [es1:9200, es2:9200] index: app-logs-%{yyyy.MM.dd}索引按天分方便按日期删除和迁移也是我一直推荐的惯例。2.3 采集可靠性Filebeat的注册表机制与丢日志的真相Filebeat最让我放心的一点是它维护了一个registry文件记录了每个日志文件当前读到的偏移量。采集端重启后它会按registry记录的offset继续读而不是从头重新发一遍。所以正常情况下Filebeat能做到at-least-once语义日志不丢但可能重复。重复的问题由下游去重或通过写入时的时间戳ID处理。配置里容易忽略的参数有两个。一个是queue.mem.events控制内存队列中可缓存事件数默认4096。日志量突然飙升时如果输出端Kafka或ES撑不住事件会积压在内存队列积压太多可能触发背压或丢弃。另一个是close_inactive默认5分钟意思是文件超过5分钟没有新日志就关闭读取句柄。这个参数对长尾日志服务很关键但设置太短可能在高频小日志场景下频繁开关文件。我通常保留默认值只有对“低频但必须及时采集”的日志才调小到1分钟。我遇到过一个真实事故某服务重启后把之前日志文件轮转了Filebeat这边的路径正则*.log同时匹配到了轮转文件和新文件结果同一条日志被两个input读到均匀发到ES导致索引里数据翻倍。排查半天才反应过来是路径通配符写得太宽。后来统一改成明确的主日志文件名比如app.log轮转文件放子目录问题就没再出现。这类细节在官方文档里不太会被强调但实际运维中很重要。3. 日志分析和检索从抓耳挠腮的 grep 到类 SQL 查询3.1 检索工具选型Elasticsearch、Loki 与 ClickHouse 怎么选日志存下来之后检索体验直接决定这套系统是“好用”还是“没人用”。目前主流的三类方案各有定位。Elasticsearch是全文检索之王Kibana里写KQL查关键字极其顺手适合“根据某个关键字从海量日志中找相关记录”这类场景。缺点是索引开销大存储成本高热数据一多就要上冷热分层。ClickHouse是分析型数据库适合对日志做聚合统计比如“统计每个接口过去24小时的错误率趋势”、“统计某IP的访问次数”。写SQL比KQL更灵活基于列存储的压缩比也让成本低很多。缺点是点查单条日志的场景不如ES直观。Loki是轻量方案只索引标签不索引日志内容日志原文长期存对象存储。成本最低适合K8s环境里容器日志的快速检索但对内容全文搜索会很慢。选择逻辑可以简化成预算充足、重检索选ES重统计分析选ClickHouse追求低成本、只按标签过滤选Loki。3.2 MySQL 慢查询日志定位慢SQL的完整操作热搜词里“慢查询日志”出现频率很高实际操作中很多后端同学对慢查询日志又爱又恨。MySQL开慢查询日志有两种方式临时开关和写配置文件。临时开启只对当前会话有效适合应急SET GLOBAL slow_query_log ON; SET GLOBAL long_query_time 2; SET GLOBAL slow_query_log_file /var/log/mysql/mysql-slow.log;要长期生效需要在my.cnf里配置slow_query_log ON slow_query_log_file /var/log/mysql/mysql-slow.log long_query_time 2 log_queries_not_using_indexes 1long_query_time 2表示超过2秒的SQL才记录单位是秒支持小数。log_queries_not_using_indexes建议打开很多全表扫描的SQL单次执行可能很快但频繁执行就是灾难。分析慢查询文件我习惯先用自带的mysqldumpslow做粗筛mysqldumpslow -t 10 /var/log/mysql/mysql-slow.log这个命令按执行时间列出top10。如果需要更细的维度统计比如同一类SQL的累计执行次数、锁等待时间用pt-query-digest更好pt-query-digest /var/log/mysql/mysql-slow.log slow_report.txt一个常见的坑是log_queries_not_using_indexes会记录很多低耗时但没走索引的SQL慢查询文件膨胀得极快必须配好轮转和保留天数。3.3 xxl-job 日志怎么检索调度日志与执行日志的区别用xxl-job做分布式任务调度的团队很多搜索“xxljob日志如何检索”的频率也高。xxl-job的日志分两层第一层是调度中心的调度日志记录任务触发时间、调度结果、执行器返回信息在xxl-job后台“调度日志”页面能看到支持按Job ID、触发时间查询。第二层是执行器端的执行日志记录任务内部代码打出的日志后台在“调度日志-操作-执行日志”里也能看到但底层其实是执行器把日志文件内容上传回调度中心。实操时要留意的点是执行器日志的保存路径由xxl.job.executor.logpath指定。如果执行器所在机器磁盘紧张厚厚的任务日志也会成为隐患。xxl-job后台有自动清理过期日志的功能建议按“保留最近7天”来配。检索方面如果调度日志查不到内容先确认执行器是否正常注册再看执行器机器上的logback/Log4j配置是否被覆盖禁用掉了xxl-job的日志文件输出。这个问题我排查过两次最终都定位到是负责的同事自定义了logback配置把xxl.job.executor.logpath指向的目录漏掉了。3.4 adb logcat 抓日志与 uvicorn 日志丢失问题移动端定位问题adb logcat是绕不开的工具。几个高频操作# 按时间格式打印全部日志 adb logcat -v time # 过滤指定TAG adb logcat -v time -s TAG_NAME:D # 抓取崩溃日志 adb logcat -b crash -v time # 同时输出到文件方便后续分析 adb logcat -v time logcat.log # 清空日志缓冲区便于复现后重抓 adb logcat -c注意-v time只是显示格式真正过滤要靠-s加TAG和优先级。实测中抓系统级问题比如蓝牙、Wi-Fi要先清除缓冲区再复现否则混入大量旧日志干扰判断。另外日志缓冲区大小有限不同厂商默认值也不一样遇到日志被截断的情况可以加大缓冲adb logcat -G 64M后端方向FastAPI搭配Uvicorn的部署模式很流行但“uvicorn fastapi日志丢失”这个痛点也很典型。默认情况下Uvicorn会打印自己的access log和ERROR log但如果你的业务代码里用了Python的logging模块通过logging.getLogger(uvicorn)拿到logger不配置handler、不设置level输出就可能丢失。正确姿势是在启动入口统一配置import logging import uvicorn logging.basicConfig( levellogging.INFO, format%(asctime)s %(levelname)s %(name)s: %(message)s ) logger logging.getLogger(app)关键点有三个一是basicConfig要放在logger使用之前执行否则配置不生效二是业务logger的name不要和uvicorn重复避免传播链混乱三是尤其要检查propagate属性子logger默认会把日志向上传播到根logger如果某处设了propagate False同时又没挂handler日志就会在黑洞里消失。这类问题不能说Uvicorn有bug更多是Python logging配置习惯不严谨积累出来的。4. 日志清理与空间治理系统日志、binlog、数据库日志一次讲清4.1 磁盘总是被打满我见过最常见的四种死法日志导致磁盘打满基本逃不出四种情况第一应用日志文件夹没有任何轮转策略单个文件无限增长第二logrotate配置写了但权限不正确轮转根本没执行第三应用代码在异常分支里疯狂写日志死循环一般地输出第四数据库开着slow log或者audit log文件增长又快又猛。印象最深的一次是某服务在极端场景下进入“ERROR - 重试 - 再ERROR”的循环日志正确率极高每小时写出5GB文本文件。那台机器60GB数据盘两天就被填满。事后检查logrotate配了但文件属主和应用进程不同每天轮转时因权限报错应用因为文件被占用的问题轮转也一直失败。所以我现在定了一条规矩任何日志清理策略上线后必须第二天人工确认一次轮转结果看昨天的归档文件是否真的生成了。4.2 Linux系统日志清理journalctl 与 logrotate 的正确用法如果系统用的是systemd日志会统一进journal。查看占用空间和执行清理是高频操作journalctl --disk-usage journalctl --vacuum-size500M journalctl --vacuum-time7d更合理的做法是改journald配置文件限制上限避免每次手工来一次# /etc/systemd/journald.conf SystemMaxUse500M MaxRetentionSec7day改完记得重启服务sudo systemctl restart systemd-journald传统/var/log下的文件清理重点看logrotate配置。以应用日志为例/data/app/logs/app.log { daily rotate 14 compress missingok notifempty copytruncate }copytruncate这个选项值得多说一句它先复制日志文件再清空原文件应用进程不需要重新打开文件句柄。代价是复制和清空之间可能有少量日志丢失。对日志强一致性有要求的场景可以用create方案加SIGHUP通知应用重新打开日志文件但前提是应用支持。compress选项建议开着文本日志压缩率很高能省一多半空间。热搜词里还有“Linux清空日志log命令”这个要看清楚直接 /var/log/xxx.log虽然能腾空间但进程持有句柄时空间不会真的释放。正确做法是logrotate或者找到持有句柄的进程重启/重载。用lsof | grep deleted能找出被删除但仍占用空间的日志文件这个命令在排查空间问题时要常用。4.3 binlog 日志可以删除吗先说结论再给方案MySQL的binlog是二进制日志作用有两个主从复制和基于时间点的数据恢复。所以“binlog日志可以删除吗”这个问题答案是不能直接删文件但必须制定清理策略。最省心的方式是配置自动过期expire_logs_days 7 # MySQL 8.0及以上推荐用秒配置 binlog_expire_logs_seconds 604800需要手动清理时用SQL命令而不是rm-- 删除某个binlog文件之前的日志 PURGE BINARY LOGS TO mysql-bin.000012; -- 删除某个时间点之前的日志 PURGE BINARY LOGS BEFORE 2025-01-01 00:00:00;这里有个特别重要的避坑点执行PURGE之前先确认从库的同步状态。如果主库清理了从库还没拉取的binlog从库就会中断复制且无法恢复。查询方法是SHOW SLAVE STATUS\G;重点看Master_Log_File和Read_Master_Log_Pos确保要清理的位置小于从库已经拉取的位置。另外binlog文件占空间太多时先检查是不是有长事务没提交。长事务会阻止binlog purge让文件堆积这个比单纯清理更值得关注。4.4 SQL Server 日志文件过大与 Oracle 监听日志清理SQL Server的日志文件.ldf过大本质上是因为事务日志没有及时备份被截断。SQL Server 2008上经典处理是USE your_db; BACKUP LOG your_db WITH TRUNCATE_ONLY; DBCC SHRINKFILE (your_db_log, 1);但新版SQL Server已经移除了TRUNCATE_ONLY更标准的做法是先做一次完整备份然后单独备份事务日志再收缩。恢复模式改成“简单”可以避免日志无限增长但会牺牲时间点恢复能力生产环境要谨慎评估。Oracle的监听日志是另一个常见的空间杀手监听日志文件listener.log在Oracle 10g之后默认启用只增不减。清理前可以临时关闭日志记录避免再写入lsnrctl set log_status off然后删除或清空log文件再开回来lsnrctl set log_status onOracle的ADR诊断目录diag目录下trace文件夹里会积累海量trc文件也建议配合定时任务按天数清理find /u01/app/oracle/diag -name *.trc -mtime 30 -delete4.5 Windows 事件日志、蓝屏日志与移动端蓝牙日志Windows下查日志最常见的是事件查看器但命令行方式更适合批量操作。设置事件日志保留上限和天数用wevtutilwevtutil sl Application /rt:true /ab:true /ms:20480000其中/ms指定日志文件最大字节数比如20480000约20MB。/rt和/ab分别表示“按时间保留”和“按字节保留”两者同时开启时系统会以先达到的条件为准。蓝屏日志是排查莫名死机的关键热搜词里“电脑莫名关机”“蓝屏日志在哪里看”都是常见诉求。Windows蓝屏后一般有两个地方留痕迹一是在%SystemRoot%\MINIDUMP目录下的小内存转储文件比如Mini091234-01.dmp二是在事件查看器里看“系统”日志里的事件ID 41Kernel-Power和6008意外关机、BugCheck事件。拿到dmp文件后用WinDbg打开执行!analyze -v可以看到崩溃的具体驱动和堆栈。对于普通用户至少可以先在事件查看器中确认蓝屏代码再到微软官网查对应的BugCheck解释。移动端日志方面热搜词里的“realme 7蓝牙日志”这类问题通用解法是开发者选项里打开“蓝牙HCI日志”开关抓取HCI日志同时用adb logcat -s Bluetooth过滤蓝牙模块的日志。这类日志对于分析蓝牙连接不稳、配对失败很管用但不同厂商开关位置不完全一样大体都在开发者选项的“调试”分类下。5. 日志溯源与安全应急登录日志、异常关机与攻击处置5.1 Ubuntu 下通过 auth.log 做登录溯源安全应急场景下最常查的就是登录日志。Ubuntu系统里/var/log/auth.log记录了所有认证相关事件包括ssh登录、sudo授权、用户新增。要溯源某个用户比如输入里提到的“mage”的登录历史可以这样grep mage /var/log/auth.log | grep Accepted grep mage /var/log/auth.log | grep FailedAccepted password for mage表示该用户的成功登录Failed password for mage表示失败尝试。只看这两类还不够系统级用户登录历史还可以用last -a lastlog who /var/log/wtmp/var/log/wtmp存的是成功登录的历史/var/log/btmp存的是失败登录的历史。如果怀疑用户被创建为后门还要查grep useradd /var/log/auth.log grep sudo: mage /var/log/auth.logsudo记录同样重要能看到该用户执行过哪些特权命令。有一次排查被入侵的机器就是靠auth.log里的sudo记录发现异常时间段执行了/etc/shadow读取命令。这个思路值得记下来日志溯源不能只盯着成功登录还要连带看登录后执行了哪些操作。5.2 Windows 异常关机与安全日志排查Windows“电脑莫名关机”的原因大致分三类硬件电源问题、驱动崩溃导致蓝屏、系统更新或计划任务触发的重启。排查时先看事件查看器“系统”日志重点筛选几个事件ID事件ID含义常见说明41Kernel-Power系统异常断电/崩溃未正常关机6008意外关机上次关机是意外的1001BugCheck蓝屏事件关联dmp文件1074系统关机/重启记录了哪个进程或用户触发的结合这几个事件和蓝屏dmp文件基本能判断是硬件还是驱动层面。如果4624登录事件暴增且指定账户多次那就是另外的安全问题了需要检查安全日志。Windows安全日志里登录成功和失败对应事件ID分别为4624和4625。导出安全日志配合分析管理员权限下可以wevtutil epl Security C:\tmp\sec.evtx拿到evtx文件后再用事件查看器或工具分析。日常排查时我习惯用PowerShell快速统计失败登录次数最多的账户Get-WinEvent -FilterHashtable {LogNameSecurity; Id4625} -MaxEvents 1000 | Group-Object #{Message} | Sort-Object Count -Descending | Select-Object -First 10安全日志保留天数也可以通过wevtutil sl Security /rt:true /ms:104857600这类方式调整建议生产环境至少保留90天便于攻击溯源。5.3 针对恶意域名攻击的日志溯源与处置流程如果系统遭受恶意域名引发的持续攻击处置不能只靠封IP要建立完整流程。结合输入里的场景我把一个相对完整的处置路径整理如下第一步是确认和阻断。在网络层把恶意域名在DNS过滤设备、防火墙上加入黑名单禁止内网设备解析和访问在主机层通过hosts文件或者安全Agent禁止域名解析同时更新防火墙出站规则。这一步要快先止血。第二步是寻找攻击痕迹。通过日志溯源判断攻击入口。主要看几类日志Web访问日志中访问该恶意域名的记录、DNS解析日志中内网设备对该域名的解析记录、防火墙会话日志里与该域名IP的通信记录、应用日志里可疑的菜刀/命令执行特征。溯源思路是“由域名到IP由IP到会话由会话到进程由进程到文件”。第三步是加固和防御升级。WAF/IDS规则要做到针对该恶意域名的C2通信特征做正则匹配和封锁主机侧清理可疑启动项、计划任务、Webshell文件。这里要特别强调的是攻击者往往会留后门只删Webshell不找后门等于白搞。要排查持久化痕迹比如新增用户、新增SSH公钥、异常服务、计划任务。第四步是长期监控。恶意域名攻击经常反复出现处置完后要建立专项监控规则持续检测同类域名注册、相同通讯特征、类似攻击路径。定期复盘日志确认是否还有漏网流量。日志留存时间要足够长最好与安全事件响应要求对齐。整个过程必须记录完整处置台账包括时间、域名、IP、处置动作和负责人员这对后期复盘是不可或缺的证据链。5.4 日志驱动的 AI 根因定位什么条件才不是空谈近两年越来越多的团队尝试用AI从海量日志中做根因定位。但这类方案落地的前提是把日志质量做到位。至少需要三样东西一是日志结构化不能一坨文本要有明确的字段比如timestamp、trace_id、level、service、message二是链路关联通过trace_id把一次请求在多台机器上的日志串起来否则AI分析出再多元凶也无从串联三是基线数据AI需要知道“正常长什么样”才能判断当前的异常是不是根因。另外日志量越大“AI根因定位”越有价值但也不能指望模型直接给答案。比较现实的做法是先用聚类算法把相似异常日志聚成几类再按时间线、影响范围、异常分数排序给人工排查缩小范围。这个思路在硬件验证领域有人用UVM日志来做在服务端可观测性领域也有类似实践。它不替代人而是把人从“面对几百万行日志逐条grep”变成“看十几条聚类的异常摘要”效率提升是很实在的。6. 日志治理的几条底线与个人经验6.1 日志轮转、保留与告警先定策略再写代码日志治理这件事本质上是给日志定规矩。我的底线建议是三条第一所有日志文件必须有轮转策略要么logrotate要么框架级别的滚动不允许出现无限增长的日志文件第二必须有保留周期和配套清理按天分片的索引、按时长的journal、按文件数的rotate至少要有一层兜底清理第三磁盘使用率和日志采集状态必须纳入监控告警。落到实处时有几个容易被忽视的细节logrotate配置里su root adm这种权限指令要加上避免 cron 轮转时因权限失败journald 的SystemMaxUse要实际生效而不是只改不改Filebeat的registry文件要纳入备份范围一旦逻辑盘损坏registry丢失会导致采集断点错乱多实例应用日志必须带上实例标识和trace_id否则排查时不同机器日志根本无法关联。6.2 这些年实操下来最想提醒新人的三件事第一件事日志的时间字段一定要带时区并且统一成标准格式。混用本地时间和UTC、字符串和时间戳会让任何后续分析都变成灾难。我现在写日志规范时第一行就是“所有时间统一ISO8601带时区偏移”。第二件事日志不是写给别人看的是写给未来的自己排查用的。关键日志不要惜字如金上下文信息比如请求ID、用户ID、参数摘要、耗时尽量都打出来。但敏感数据别打手机号、身份证、密码绝不能进日志这是安全底线。第三件事日志系统本身也要监控。我见过太多人把日志平台搭完就撒手不管等到磁盘满了才发现采集早就停了什么日志都没留下。给日志平台所在的磁盘、ES分片健康状态、Filebeat运行状态都配好告警比给业务日志写一万条日志规范都管用。最后分享一个小技巧我每到一个新环境第一件事就是检查每天的日志是否真的成功轮转以及日志目录的磁盘占用变化趋势。这个习惯帮我避开了至少十次“日志把磁盘写满”的隐患。日志这个事从来没有“配好就不用管”的时候它需要像对待核心数据一样持续关注。