独立站日志管理：访问日志、错误日志、应用日志的收集与分析

独立站三类日志：访问、错误、应用日志的保留策略、收集管道与排障顺序

独立站日志管理：访问日志、错误日志、应用日志的收集与分析

结论先行：独立站的日志不是”一堆文件”，而是三类用途完全不同的记录：访问日志看谁来了、错误日志看哪里崩了、应用日志看业务流程走到哪。三类的保留时长、分析工具、告警阈值都不一样，混在一起存等于一份都找不到。最小可用方案不是上 ELK 全家桶，而是先把三件事做对：按天切割、集中到一处、错误率超 1% 告警。访问日志保留 90 天，错误日志保留 1 年，应用日志保留 30 天。

一、三类日志各管一件事，别混着看

很多人把服务器上所有 .log 文件当成”日志”一锅端，出了事挨个翻。其实三类日志回答的是三个完全不同的问题。访问日志（Nginx/Apache 的 access.log）回答”谁在什么时候请求了什么”；错误日志（Nginx error.log、PHP-FPM 错误）回答”服务端哪里报错了”；应用日志（你代码里自己写的 log）回答”这笔订单处理到哪一步、为什么没成功”。

反直觉的判断在这里：出了线上事故，最不该先翻的就是访问日志。访问日志量大、噪声多，先看它会被几千条 200 淹没。正确顺序是先看错误日志定位崩点，再用访问日志看影响面（多少用户、哪些 URL），最后用应用日志还原业务流程。这和AI爬虫日志分析强调”先分清谁在读你”是同一个思路：先分类，再分析。

日志类型	回答的问题	典型位置	建议保留
访问日志	谁、什么时候、请求了什么	Nginx access.log	90 天热数据
错误日志	服务端哪里报错、为什么	Nginx error.log / PHP 错误	1 年
应用日志	业务流程走到哪、卡在哪	代码自定义 log	30 天
系统日志	服务器本身的事件	/var/log/messages	30 天

二、收集管道：从”散落在各文件”到”一处可查”

单人团队常见状态是：Nginx 一个日志、PHP 一个日志、应用自己写一个日志，分散在不同目录，服务器一重启或换机器，历史就断了。日志管理的第一步不是分析，而是把它们集中起来。

管道分四段：程序写文件、按天切割、集中到一处、对错误设告警。切割用 logrotate 按天切、gzip 压缩，避免单文件几个 G 打不开；集中可以先简单做——rsyslog 或一个轻量 agent 把日志发到一台专门的机器或云日志服务。

单人团队不必一上来就上 ELK 这种重型栈，先用集中存储加一个搜索界面就够，量大了再考虑。CDN 站点还要把边缘日志和源站日志都收进来，这一点见CDN全球加速。

环节	做法	工具 / 配置	不做的后果
写文件	统一格式输出	combined 格式	字段不齐，分析脚本难写
切割	按天切割加压缩	logrotate	单文件过大撑爆磁盘
集中	汇总到一处存储	rsyslog / 云日志	换机即断历史
告警	错误率阈值通知	监控平台规则	出事靠用户投诉才知道

三、错误日志：单人团队最该盯紧的一类

三类里错误日志的单位信息密度最高、也最值得优先盯。访问日志一天几十万行，错误日志可能只有几百行，但每一行都是一次真实失败。把错误日志单独集中、单独设告警，投入产出比最高。

阈值给具体数字：5xx 错误率连续 10 分钟超过 1%，立即告警；单条异常错误（如数据库连接失败、支付回调失败）出现一次就告警，不等累计。错误日志要分级：warning 留着定期看，error 和 critical 必须实时通知。PHP 这类应用还要把致命错误和慢查询单独抓出来。

场景示例：某天上午告警响了，5xx 错误率从 0.1% 跳到 3%。你先打开错误日志，看到大量 “PHP-FPM: unable to connect”，定位到后端进程池满了；再用访问日志看是哪些 URL 触发的，发现是一个新上线的接口慢查询拖垮了进程池；最后看应用日志确认是哪条 SQL。十分钟内定位，这就是错误日志先行的价值。

错误级别	示例	处理方式	告警阈值
critical	数据库连不上、支付失败	立即通知	出现一次即告警
error	5xx、致命错误	实时通知	10 分钟内 > 1%
warning	慢查询、重试	每日汇总看	超基线 2 倍汇总
notice	正常业务提示	归档不告警	不告警

四、应用日志：让业务流程可追溯

访问日志和错误日志是服务器”客观”记录，但它们回答不了”这个询盘为什么没进 CRM”这种业务问题。这就要靠应用日志——你在关键业务节点自己写日志：询盘提交了、写入数据库了、推送到 CRM 了、CRM 回传失败了。

应用日志的关键是每条都带上一个业务标识，比如询盘 ID 或订单号。这样出问题时，你拿这个 ID 一搜，就能把这条业务从提交到结束的完整轨迹串起来。不要打无意义的日志（”执行到第 10 行”），每条都要能回答一个业务问题。日志量控制在每天几十 MB 以内，别把请求体整个打进去，既慢又泄露隐私。

性能慢和日志的关系也值得提：日志写太多、每次请求都同步写磁盘，本身就会拖慢响应。慢响应的指标怎么看，见Core Web Vitals。监控告警的整体框架，见站点监控与告警。

业务节点	应记录内容	带的标识	出问题时怎么查
询盘提交	表单字段、来源页	询盘 ID	按 ID 搜提交记录
入库	写入成功 / 失败	询盘 ID	看是否落库
推送 CRM	接口返回码、耗时	询盘 ID	看 CRM 是否接收
邮件通知	发送成功 / 失败	询盘 ID	看销售是否收到

五、避坑：日志管理里最常见的三个错误

第一个坑是”不切割不保留”。日志一直写一个文件，三个月后单文件几个 G，排障时 grep 一下卡半天，或者直接把磁盘写满，把自己站搞挂。按天切割加保留策略是底线。

第二个坑是”只留实时不归档”。磁盘满了就删最老的，结果想查两个月前那次故障的起点，根本没有。热数据留 90 天、超期压缩归档至少留一年，成本很低。第三个坑是”日志里写敏感信息”。把用户密码、完整信用卡号写进日志，等于在日志库里又建了一个泄露源。敏感字段一律打码或不落盘。

常见错误	表面现象	真实问题	纠正做法
不切割	单文件越来越大	磁盘写满、检索慢	logrotate 按天切
不留历史	磁盘满了就删	想回溯时没数据	热 90 天，归档 1 年
写敏感信息	日志方便调试	日志库成泄露源	敏感字段打码
三类混着看	出事挨个翻	定位慢、噪声大	错误先行，分类检索

FAQ 常见问题

独立站一定要上 ELK 这种日志平台吗？

不需要。单人团队一上来就搭 ELK 是过度投入。最小可用方案是先把三件事做对：按天切割日志、用 rsyslog 或云日志服务集中到一处、对错误率设告警。这三步用现成工具半天就能配完。只有当日志量每天几个 GB、需要多人检索和长期趋势分析时，再考虑上 ELK 或商用日志服务。

访问、错误、应用三类日志为什么不能放一起？

因为它们回答的问题完全不同。访问日志回答谁来了，错误日志回答哪里崩了，应用日志回答业务走到哪。混在一起，出了事要在几十万行噪声里找几行关键错误，效率极低。分开存放、分开索引、分开设保留期，排障时先查错误日志定位崩点，再用访问日志看影响面，最后用应用日志还原流程。

各类日志分别该保留多久？

访问日志热数据保留 90 天，超期压缩归档；错误日志保留 1 年，因为排障和安全事件常要回溯几个月；应用日志保留 30 天即可，量大且只用于近期业务追溯。按天切割加 gzip 压缩后，一年的日志通常只占几个 GB，不必为省存储丢历史。

错误日志的告警阈值怎么定？

分两级。5xx 错误率连续 10 分钟超过 1% 就实时告警，健康值应低于 0.5%；critical 级错误（数据库连不上、支付回调失败）出现一次就告警，不等累计。warning 级（慢查询、临时重试）不实时通知，每天汇总看一次。阈值上线后按真实基线校准，宁可比基线严，别放过真实故障。

应用日志应该打多详细，会不会影响性能？

在关键业务节点打，每条带询盘或订单 ID，不要把整个请求体写进去。同步写磁盘本身有开销，建议用异步日志或缓冲。控制每天日志量在几十 MB 以内。原则是每条日志都能回答一个业务问题，无意义的调试行（执行到第几行）上线前删掉。

日志里能记用户密码和支付信息吗？

绝对不能。日志会被集中存储、保留很久、可能被多人检索，把密码、完整卡号写进去等于在日志库里又建了一个泄露源。敏感字段一律打码或不落盘，比如卡号只留后四位。同时日志本身要限制访问权限，不是谁都能翻应用日志，尤其里面带业务数据。

写在最后

日志管理的价值不在”存了多少”，而在”出事能不能三分钟内定位”。对单人独立站，把三类日志分开、按天切割集中、错误率超 1% 告警，这套基础搭好，日常排障时间就能从”翻半天日志”降到”看一眼告警”。重型日志平台是规模上来之后的事，不是起步的必需。

落地三步：第一，把访问、错误、应用三类日志分开存放，按天切割分别设保留期；第二，用 rsyslog 或云日志服务集中到一处，能按业务 ID 检索；第三，错误率 10 分钟超 1%、critical 错误出现一次就告警。做完这三步，你对线上的感知就从”用户投诉才知道”变成”自己先知道”。维护节奏可对照官网维护期一起排。

一句可以记住的话：日志不是留着怀旧的硬盘文件，是事故现场的行车记录仪——平时不分类、不集中，出了事就只能凭印象猜。