2026/9/4 10:45:58
FEATURED · 精选文章 
Wiki.js 操作日志全链路拆解从一次误删到一条告警【免费下载链接】wiki-Wiki.js | Next Generation Open Source Wiki项目地址: https://gitcode.com/GitHub_Trending/wiki78/wiki-Wiki 里一个关键页面刚被删掉了。是谁删的、几点删的、删除前又改过什么——答案都在 Wiki.js 操作日志里。这篇文章带你走完 Wiki.js 日志系统的全链路一次操作之后发生了什么、日志落在哪里、Wiki.js 日志配置只动两个键怎么动、以及怎么把连续登录失败变成一条实时告警。读完你能独立配好日志、读懂任意一条日志的含义并据此做一次安全排查。跟一条日志走完全程从操作到落盘用户在页面上点保存或删除请求先过中间件。GraphQL 层挂了一个限流指令按键是IP 父类型.字段名防登录爆破的第一道闸就在这一层。之后业务代码在关键动作上调用WIKI.logger.info(...)、WIKI.logger.warn(...)等方法产出消息。真正接住消息的是启动时建好的 winston loggerserver/core/logger.js 里创建 logger 时级别直接取自配置文件的logLevel每行日志带上 label实例标识和 timestamp 两个字段再按级别路由到已启用的 transport。控制台输出是哪来的Console transport 是写死在logger.init里的——你什么都不配终端里就有彩色日志。想让日志真正落到文件不用改任何代码仓库自带server/modules/logging目录下的 12 个现成 loggerdisk、logstash、sentry、syslog、papertrail 等每个由一份definition.yml声明。启动时 server/models/loggers.js 扫描这个目录把定义同步进loggers表除控制台外默认全部禁用到管理后台的日志页打开开关、填级别和参数即可updateLoggers变更负责持久化。级别路由怎么工作Winston 把消息从低到高分成五档即 Wiki.js 日志级别debug、info、warn、error、critical。logger 上的level是下限设成warndebug 和 info 直接被丢掉warn 及以上才放行。生产环境日常挂在warn最省心排障时临时切debug查完再切回来别让它常开。用 config.yml 里的两个键改完 Wiki.js 日志配置全局日志行为集中在你部署环境里config.yml的两个键注意是部署配置不是仓库文件# config.yml logLevel: info # 日常 warn 更省排障时 debug logFormat: default # 终端彩色要接采集就换 jsonlogFormat: json让每行输出一条 JSON 对象label、level、timestamp、message 各自成字段ELK、Splunk 之类的采集管线能直接解析不用再写正则。全局级别只是下限单个 logger 的级别还能在面板里再调一层两层各管各的互不打架。把连续登录失败变成一条实时告警登录侧的防御已经内置passport 的 failCallback 在连续失败后回 401 Too many failed attempts见 server/controllers/auth.js限流指令在 GraphQL 层按 IP 掐流量。但防御只是上半场你还得知道。每条命中 logger 的消息都会触发WIKI.GQLEmitter上的livetrail事件。后台面板的实时日志控制台、以及你自己写的小服务都通过 server/graph/resolvers/logging.js 订阅同一个流subscription { loggingLiveTrail { level output timestamp } }返回的LoggerTrailLine就三个字段。订阅服务收到level为 warn 或 error 的行直接转发到 Slack、飞书频道一个 Wiki.js 登录失败告警就搭完了——整个方案多出来的东西只有一个订阅进程。用一条查询跑完 Wiki.js 安全审计审计要回答两个问题现在有哪些 logger 在跑、跑出来的行长什么样。前者走 GraphQL 的logging.loggers查询需要manage:system权限返回每个 logger 的 key、isEnabled、level 和 config 参数字段结构完整定义在 server/graph/schemas/logging.graphql。后者直接看实时流或落盘文件。单行日志的读法固定2026-09-03T08:14:02Z [web-1] warn: failed login attempts from IP 203.0.113.7。时间戳给你事发窗口label 告诉你哪个实例output 里的 IP 和事件摘要锁定来源再拿时间窗口去对照页面历史谁在何时改了什么就闭环了。排查时盯住两点同一个 IP 在 warn 行里反复出现或者非工作时间出现权限类操作的 error 行——这两类都值得拉进清单逐个过。接手后的 30 天日志巡检清单所以接手一个 Wiki.js 实例的头 30 天实际要做的就这几件 第 1 天确认logFormat是json采集管线能解析出真实样本行第 1 周启用一个持久化 loggerdisk 或 logstash验证文件真的在写第 2~3 周开着实时日志控制台观察三天每条 warn 人工过一遍再关第 3~4 周统计登录限流的触发频率单一 IP 反复命中就查源之后每月到日志页对照 logger 的启用状态和级别与你的安全基线核对一遍【免费下载链接】wiki-Wiki.js | Next Generation Open Source Wiki项目地址: https://gitcode.com/GitHub_Trending/wiki78/wiki-创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Wiki.js 操作日志全链路拆解：从一次误删到一条告警
Wiki.js 操作日志全链路拆解从一次误删到一条告警【免费下载链接】wiki-Wiki.js | Next Generation Open Source Wiki项目地址: https://gitcode.com/GitHub_Trending/wiki78/wiki-Wiki 里一个关键页面刚被删掉了。是谁删的、几点删的、删除前又改过什么——答案都在 Wiki.js 操作日志里。这篇文章带你走完 Wiki.js 日志系统的全链路一次操作之后发生了什么、日志落在哪里、Wiki.js 日志配置只动两个键怎么动、以及怎么把连续登录失败变成一条实时告警。读完你能独立配好日志、读懂任意一条日志的含义并据此做一次安全排查。跟一条日志走完全程从操作到落盘用户在页面上点保存或删除请求先过中间件。GraphQL 层挂了一个限流指令按键是IP 父类型.字段名防登录爆破的第一道闸就在这一层。之后业务代码在关键动作上调用WIKI.logger.info(...)、WIKI.logger.warn(...)等方法产出消息。真正接住消息的是启动时建好的 winston loggerserver/core/logger.js 里创建 logger 时级别直接取自配置文件的logLevel每行日志带上 label实例标识和 timestamp 两个字段再按级别路由到已启用的 transport。控制台输出是哪来的Console transport 是写死在logger.init里的——你什么都不配终端里就有彩色日志。想让日志真正落到文件不用改任何代码仓库自带server/modules/logging目录下的 12 个现成 loggerdisk、logstash、sentry、syslog、papertrail 等每个由一份definition.yml声明。启动时 server/models/loggers.js 扫描这个目录把定义同步进loggers表除控制台外默认全部禁用到管理后台的日志页打开开关、填级别和参数即可updateLoggers变更负责持久化。级别路由怎么工作Winston 把消息从低到高分成五档即 Wiki.js 日志级别debug、info、warn、error、critical。logger 上的level是下限设成warndebug 和 info 直接被丢掉warn 及以上才放行。生产环境日常挂在warn最省心排障时临时切debug查完再切回来别让它常开。用 config.yml 里的两个键改完 Wiki.js 日志配置全局日志行为集中在你部署环境里config.yml的两个键注意是部署配置不是仓库文件# config.yml logLevel: info # 日常 warn 更省排障时 debug logFormat: default # 终端彩色要接采集就换 jsonlogFormat: json让每行输出一条 JSON 对象label、level、timestamp、message 各自成字段ELK、Splunk 之类的采集管线能直接解析不用再写正则。全局级别只是下限单个 logger 的级别还能在面板里再调一层两层各管各的互不打架。把连续登录失败变成一条实时告警登录侧的防御已经内置passport 的 failCallback 在连续失败后回 401 Too many failed attempts见 server/controllers/auth.js限流指令在 GraphQL 层按 IP 掐流量。但防御只是上半场你还得知道。每条命中 logger 的消息都会触发WIKI.GQLEmitter上的livetrail事件。后台面板的实时日志控制台、以及你自己写的小服务都通过 server/graph/resolvers/logging.js 订阅同一个流subscription { loggingLiveTrail { level output timestamp } }返回的LoggerTrailLine就三个字段。订阅服务收到level为 warn 或 error 的行直接转发到 Slack、飞书频道一个 Wiki.js 登录失败告警就搭完了——整个方案多出来的东西只有一个订阅进程。用一条查询跑完 Wiki.js 安全审计审计要回答两个问题现在有哪些 logger 在跑、跑出来的行长什么样。前者走 GraphQL 的logging.loggers查询需要manage:system权限返回每个 logger 的 key、isEnabled、level 和 config 参数字段结构完整定义在 server/graph/schemas/logging.graphql。后者直接看实时流或落盘文件。单行日志的读法固定2026-09-03T08:14:02Z [web-1] warn: failed login attempts from IP 203.0.113.7。时间戳给你事发窗口label 告诉你哪个实例output 里的 IP 和事件摘要锁定来源再拿时间窗口去对照页面历史谁在何时改了什么就闭环了。排查时盯住两点同一个 IP 在 warn 行里反复出现或者非工作时间出现权限类操作的 error 行——这两类都值得拉进清单逐个过。接手后的 30 天日志巡检清单所以接手一个 Wiki.js 实例的头 30 天实际要做的就这几件 第 1 天确认logFormat是json采集管线能解析出真实样本行第 1 周启用一个持久化 loggerdisk 或 logstash验证文件真的在写第 2~3 周开着实时日志控制台观察三天每条 warn 人工过一遍再关第 3~4 周统计登录限流的触发频率单一 IP 反复命中就查源之后每月到日志页对照 logger 的启用状态和级别与你的安全基线核对一遍【免费下载链接】wiki-Wiki.js | Next Generation Open Source Wiki项目地址: https://gitcode.com/GitHub_Trending/wiki78/wiki-创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
