日志分析 | DouPHP 开发手册 | 文档中心 | DouPHP企业建站系统

日志分析

简介

本指南面向DouPHP项目的运维、开发与产品人员，系统化说明系统内各类日志的结构、含义与使用方法，覆盖错误日志、访问日志、业务审计日志与调试日志；解释日志级别配置、输出格式定制、日志轮转与清理策略；提供常用命令行工具（grep、awk、tail）与ELK Stack等平台的采集与分析建议；并给出基于日志的性能分析与用户行为追踪方法。

项目结构

DouPHP的日志体系由“运行期日志”和“业务审计日志”两部分组成：

运行期日志：统一通过核心日志类写入到 storage/log 下按日命名的 log_YYYY-MM-DD.log 文件，支持前台、后台、API三端隔离目录与通道过滤、采样限流、敏感信息脱敏。
业务审计日志：通过审计服务写入数据库表 user_log、book_log、admin_log，用于可追溯的业务操作记录。

graph TB
A["应用入口<br/>admin/index.php / api/index.php"] --> B["初始化与异常捕获<br/>core/init/InitTrait.php"]
B --> C["运行期日志门面<br/>core/infra/log/Log.php"]
C --> D["存储路径<br/>storage/log/"]
D --> E["按日日志文件<br/>log_YYYY-MM-DD.log"]
A --> F["业务审计服务<br/>core/service/audit/AuditService.php"]
F --> G["数据库表<br/>user_log / book_log / admin_log"]

图表来源

core/infra/log/Log.php:162-178
core/infra/log/Log.php:289-342
core/service/audit/AuditService.php:71-83
core/service/audit/AuditService.php:145-177
admin/index.php:76
api/index.php:65
core/init/InitTrait.php:547-576

章节来源

core/infra/log/Log.php:162-178
core/infra/log/Log.php:289-342
core/service/audit/AuditService.php:71-83
core/service/audit/AuditService.php:145-177
admin/index.php:76
api/index.php:65
core/init/InitTrait.php:547-576

核心组件

运行期日志门面：提供分级写入、自动上下文补全、敏感字段脱敏、通道白名单、采样率与限流、按日落盘与清理能力。
云服务API日志：独立于主站的日志实现，结构与主站一致，便于云侧集中采集。
审计服务：将关键业务动作持久化到数据库，便于检索与报表。
入口异常捕获：在管理端与API入口捕获未处理异常并写入错误日志，配合运行期日志定位问题。

章节来源

core/infra/log/Log.php:30-151
core/infra/log/Log.php:289-342
core/infra/log/Log.php:393-499
core/infra/log/Log.php:792-878
_'/.api/lib/Log.php:22-65
_'/.api/lib/Log.php:290-341
core/service/audit/AuditService.php:71-83
core/service/audit/AuditService.php:145-177
admin/index.php:76
api/index.php:65

架构总览

下图展示一次请求从入口到日志落盘的完整链路，以及业务审计日志的写入路径。

sequenceDiagram
participant U as "用户"
participant R as "路由/控制器"
participant L as "运行期日志门面<br/>Log : : write(...)"
participant FS as "文件系统<br/>storage/log/"
participant A as "审计服务<br/>AuditService"
participant DB as "数据库"
U->>R : 发起HTTP请求
R->>L : info/warning/error(...)
L->>L : 自动上下文补全/脱敏/采样/限流
L->>FS : 追加写入 log_YYYY-MM-DD.log
R->>A : writeUserLog/writeAdminLog(...)
A->>DB : 插入 user_log/admin_log/book_log
R-->>U : 返回响应

图表来源

core/infra/log/Log.php:289-342
core/infra/log/Log.php:518-571
core/infra/log/Log.php:393-499
core/service/audit/AuditService.php:71-83
core/service/audit/AuditService.php:145-177

详细组件分析

运行期日志门面（核心）

日志级别：emergency/alert/critical/error/warning/notice/info/debug，默认最小级别为debug，可通过配置调整。
自动上下文：自动补充 request_id、scene、ip、route、request_uri、method、module、action、user_id、admin_id、work_id 等。
安全脱敏：对敏感键名进行掩码，并对URL查询串中的敏感参数值进行脱敏。
通道与级别白名单：支持 enabled_channels 与 enabled_levels 精细控制。
采样与限流：sample_rate 与 max_per_minute_per_key 控制高频日志。
落盘与清理：按日生成 log_YYYY-MM-DD.log；提供 clean() 与 tryAutoCleanFromConfig() 清理历史日志。

flowchart TD
Start(["调用 Log::write(level, message, context)"]) --> CheckEnabled{"是否启用?"}
CheckEnabled --> |否| End
CheckEnabled --> |是| LevelCheck{"级别是否满足阈值?"}
LevelCheck --> |否| End
LevelCheck --> ChannelCheck{"channel是否在白名单?"}
ChannelCheck --> |否| End
ChannelCheck --> AutoCtx["自动补全上下文"]
AutoCtx --> Sanitize["脱敏与规整"]
Sanitize --> Sample{"采样丢弃?"}
Sample --> |是| End
Sample --> RateLimit{"限流丢弃?"}
RateLimit --> |是| End
RateLimit --> Write["写入 storage/log/log_YYYY-MM-DD.log"]
Write --> End(["结束"])

图表来源

core/infra/log/Log.php:289-342
core/infra/log/Log.php:349-385
core/infra/log/Log.php:393-499
core/infra/log/Log.php:518-571

章节来源

core/infra/log/Log.php:30-151
core/infra/log/Log.php:289-342
core/infra/log/Log.php:349-385
core/infra/log/Log.php:393-499
core/infra/log/Log.php:518-571
core/infra/log/Log.php:792-878

云服务API日志

独立配置文件 _'/.api/config/log.php，定义 enabled、min_level、enabled_levels、enabled_channels、sample_rate、max_per_minute_per_key、keep_days 与各 channel 开关。
日志实现位于 _'/.api/lib/Log.php，与主站Log同形API，默认写入 API_ROOT/data/log/ 下的按日日志。

classDiagram
class ApiLog {
+const EMERGENCY
+const ALERT
+const CRITICAL
+const ERROR
+const WARNING
+const NOTICE
+const INFO
+const DEBUG
+static setPath(path)
+static setMinLevel(level)
+static setEnabledLevels(levels)
+static setSampleRate(rate)
+static setMaxPerMinutePerKey(max)
+static info(message, context)
+static error(message, context)
+static debug(message, context)
+static clean(keepDays)
}

图表来源

_'/.api/lib/Log.php:22-65
_'/.api/lib/Log.php:290-341
_'/.api/config/log.php:17-47

章节来源

_'/.api/config/log.php:17-47
_'/.api/lib/Log.php:22-65
_'/.api/lib/Log.php:290-341

业务审计日志

会员登录成功/失败、管理员操作等关键动作通过 AuditService 写入 user_log、admin_log、book_log。
登录流程示例：前端登录服务在失败时记录 LOGIN_FAIL，成功时记录 LOGIN_SUCCESS，并附带细节标签。

sequenceDiagram
participant U as "用户"
participant LS as "LoginService"
participant AUD as "AuditService"
participant DB as "数据库"
U->>LS : 提交登录
LS->>LS : 校验账号/密码/状态
alt 登录失败
LS->>AUD : writeUserLog(userId, LOGIN_FAIL, result=0, details)
AUD->>DB : 插入 user_log
LS-->>U : 返回错误
else 登录成功
LS->>AUD : writeUserLog(userId, LOGIN_SUCCESS, result=1, details)
AUD->>DB : 插入 user_log
LS-->>U : 返回成功
end

图表来源

front/service/user/LoginService.php:145-162
_'/module/user/front/service/user/LoginService.php:145-162
core/service/audit/AuditService.php:71-83

章节来源

front/service/user/LoginService.php:145-162
_'/module/user/front/service/user/LoginService.php:145-162
core/service/audit/AuditService.php:71-83

错误日志与异常捕获

管理端与API入口在发生未捕获异常时，会将异常信息与堆栈写入系统错误日志，便于快速定位致命问题。
建议在部署环境开启运行期日志，以便结合错误日志与业务日志进行根因分析。

章节来源

admin/index.php:76
api/index.php:65
core/init/InitTrait.php:547-576

依赖关系分析

运行期日志门面依赖：
- 会话与身份：Session 获取 user_id、admin_id、work_id。
- 请求上下文：Request 获取 routeString、routeModule。
- 配置：system.php 中可配置日志清理策略（如 keep_days）。
审计服务依赖：
- 数据库：DB 门面写入 user_log、admin_log、book_log。
- 请求：在写 admin_log 时可取 routeModule。

graph LR
Log["运行期日志门面"] --> Session["会话(Session)"]
Log --> Request["请求(Request)"]
Log --> Config["系统配置(system.php)"]
Audit["审计服务(AuditService)"] --> DB["数据库(DB)"]
Audit --> Request

图表来源

core/infra/log/Log.php:518-571
core/service/audit/AuditService.php:145-177
config/system.php

章节来源

core/infra/log/Log.php:518-571
core/service/audit/AuditService.php:145-177
config/system.php

性能与容量规划

日志级别与通道：生产环境建议将 min_level 设置为 warning 或 notice，并通过 enabled_channels 仅保留必要通道，减少I/O压力。
采样与限流：在高并发场景设置 sample_rate < 1 与 max_per_minute_per_key > 0，避免日志风暴。
存储路径与权限：确保 storage/log 目录可写且具备合理权限；按日分文件便于轮转与归档。
清理策略：使用 clean() 或 tryAutoCleanFromConfig() 定期清理历史日志，避免磁盘占满。

故障排查指南

快速定位错误：
- 查看最近错误日志：tail -f storage/log/log_$(date +%Y-%m-%d).log
- 筛选特定级别：grep -E "[(ERROR|CRITICAL|ALERT|EMERGENCY)]" storage/log/log_*.log
- 按通道过滤：grep '"channel":"xxx"' storage/log/log_*.log
关联请求：
- 通过 request_id 在同一时间窗口内串联运行期日志与审计日志。
登录问题：
- 检查 user_log 中 LOGIN_FAIL/LOGIN_SUCCESS 及 details 标签，结合运行期日志中的 IP、route、user_id 等信息。
未捕获异常：
- 查看 admin/index.php 与 api/index.php 的错误日志输出，结合运行期日志定位异常位置。

章节来源

core/infra/log/Log.php:289-342
core/infra/log/Log.php:518-571
front/service/user/LoginService.php:145-162
admin/index.php:76
api/index.php:65

结论

DouPHP的日志体系以“运行期日志+业务审计日志”双轨模式，兼顾运行时观测与业务可追溯性。通过合理的级别、通道、采样与限流配置，可在保障可观测性的同时控制性能开销。结合命令行工具与ELK平台，可实现高效的问题定位、性能分析与用户行为追踪。

附录

日志类型与用途

错误日志：系统级异常与未捕获错误，优先关注。
访问日志：通过运行期日志的 request_uri、method、route 等上下文还原访问轨迹。
业务日志：登录、订单、售后等业务关键事件，结合审计日志进行追踪。
调试日志：开发阶段开启 debug 级别，注意生产环境关闭或降低频率。

日志级别配置与输出格式

级别配置：
- 主站：通过 Log::setMinLevel、Log::setEnabledLevels 或系统配置项调整。
- API：在 _'/.api/config/log.php 中设置 min_level、enabled_levels、enabled_channels。
输出格式：
- 每行包含时间戳、级别、消息与JSON上下文；上下文自动脱敏，URL查询串敏感参数被掩码。

章节来源

core/infra/log/Log.php:203-231
core/infra/log/Log.php:677-688
_'/.api/config/log.php:17-47

日志轮转与清理策略

按日分文件：log_YYYY-MM-DD.log，天然支持轮转。
清理接口：
- clean(keepDays)：清理指定目录下历史日志。
- tryAutoCleanFromConfig(keepDaysRaw, minInterval)：按站点配置周期性清理。
建议：在生产环境配置 keep_days ≥ 7，并设置最小清理间隔以避免频繁IO。

章节来源

core/infra/log/Log.php:792-878

常用日志分析工具

grep：按关键字、级别、通道过滤日志。
awk：提取字段（如 request_id、user_id、route）并统计频次。
tail：实时跟踪最新日志。
组合示例：
- 查找某用户登录失败：grep 'LOGINFAIL' storage/log/log*.log | grep '"user_id":123'
- 统计每小时错误数：awk '/[.] ERROR/{print substr($1,2,10)}' storage/log/log_.log | sort | uniq -c

ELK Stack 集成建议

采集：使用 Filebeat 或 Logstash 采集 storage/log/*.log 与 API 日志目录。
解析：将JSON上下文解析为结构化字段（level、channel、request_id、user_id、route等）。
索引：按日期索引，保留策略与 keep_days 对齐。
可视化：构建仪表盘监控错误率、登录失败率、慢请求等指标。

性能分析与用户行为追踪

性能分析：
- 通过 route、request_uri、user_id 聚合热点页面与慢请求。
- 结合错误日志识别异常峰值。
用户行为追踪：
- 利用 request_id 串联一次请求的全链路日志。
- 通过 user_log 与 admin_log 还原用户与管理员的关键操作序列。

添加日期：2026-10-05