先给结论
访问日志记录"谁在什么时候请求了什么、返回了什么状态"，用来定位页面与流量问题；错误日志记录"程序在哪一步报了什么错"，用来定位功能故障。排查时按场景选日志，再把两者的时间线对照着看。
两类日志的分工
| 排查场景 | 优先看 | 关注什么 |
|---|---|---|
| 页面大面积报错或打不开 | 错误日志 | 报错时间、错误类型、出错的位置 |
| 某些页面 404 增多 | 访问日志 | 请求路径、来源、返回状态码 |
| 流量突然异常增长 | 访问日志 | 请求来源分布、访问特征、高频路径 |
| 改版后旧链接失效 | 访问日志 | 旧路径是否还在被请求、返回了什么状态 |
| 后台某个功能操作失败 | 错误日志 | 操作对应时间点的报错与账号信息 |
排查时的常用字段
- 时间：先把故障时间点确定下来，再缩小日志范围；
- 请求路径：确认是全站问题还是个别页面问题；
- 状态码：成功、未找到、重定向、服务器错误各有含义，先分类再细看；
- 来源：区分用户访问、搜索引擎抓取与异常流量；
- 错误信息：错误日志中的关键行，是判断问题位置的直接线索。
日志管理的注意事项
日志要开启并保留足够的时间跨度，否则出问题时无据可查；同时注意访客信息的保护，控制日志访问权限，对外提供数据时做脱敏处理。日志会持续占用磁盘，要设定保留与清理策略，并纳入磁盘监控。比起只在出事时翻日志，周期性抽查更能提前发现隐患。
日志排查是运维托管服务中故障定位的基础动作。
常见问题
日志文件太大看不过来怎么办？
先按时间缩小范围，再按状态码或路径过滤，只看与故障相关的部分。日常应设定轮转与保留策略，避免日志无限增长撑满磁盘。
没有错误日志说明没有问题吗？
不能这么判断。有些问题只体现在访问日志里，比如大量 404 或重定向异常；也可能是日志级别设置过低，把告警信息过滤掉了。要看日志配置是否完整。
访问日志可以对外提供吗？
日志中包含访客 IP 等信息，属于需要保护的数据。对外提供前应评估必要性并做脱敏处理，同时限制日志的访问权限，只开放给需要的人员。
网站刚上线，日志该开哪些？
至少开启访问日志与错误日志两类，覆盖站点入口与后台功能。上线初期正好借机验证日志是否正常写入，别等出故障才发现日志没开。