日志、在线用户、系统监控，出问题时的三个第一现场
本文是「geejing WebBuilder 快速开发平台」管理运维系列的第 5 篇，约 2300 字，预计阅读时间 9 分钟。系统出问题时，运维最怕的不是故障本身，而是"两眼一抹黑"。本篇基于平台自带的三类监控工具------操作日志、在线用户、系统信息，把"出事后先看哪里"讲成一套固定动作，截图来自实际运行环境。
一、操作日志：谁在什么时候干了什么
geejing WebBuilder 快速开发平台把用户会话行为自动记录成日志，无需开发者埋点。打开"日志"工具（admin/log）：
顶部一排过滤条件：开始时间、结束时间、日志级别、日志类型、用户名称、内容、IP 地址，点"重置"清空条件。列表按时间倒序展示，截图里能看到典型的 session 类记录------logged in / logged out 交替出现，系统已积累 268 条。
查询日志的两个高频套路：
- 按人查：输入用户名称，看这个账号什么时间登录过、活跃在什么时段------排查"账号是不是被盗用"就靠它；
- 按时段查：设定故障发生的时间窗，过滤出该时段全部记录，重建时间线。
注意列表里的 IP 地址 列。全部记录都是 0:0:0:0:0:0:0:1（IPv6 的 localhost）说明访问都来自本机；一旦生产环境里某个 IP 短时间内出现大量登录失败，就要警觉暴力破解尝试------配合下一篇要说的封禁功能处理。
日志会自己长大，268 条只是开始。运维上要定期关注两个数字：总量（影响查询速度）与磁盘占用（日志通常落库或落盘）。按平台日志配置设置保留周期，过期的归档或清理，别让"记录一切"变成"拖垮一切"。
查询时还有两个字段值得认识：日志级别 与日志类型 。级别区分 info/warn/error 这类严重程度------日常巡检直接过滤 error 级别，一屏看完所有异常；类型区分记录来源（session 会话、模块访问等），排查登录问题时先锁 session 类型，排查接口问题时再看模块访问类。两个条件叠加过滤，比在几千条记录里肉眼翻找快一个数量级。
二、在线用户：实时会话的一块屏幕
第二个工具是"在线用户"（admin/online-users），页面很直接：
上表是当前在线用户 ：用户名称、显示名称、IP 地址、会话创建时间、最后访问时间。下表是IP 维度的会话汇总。截图里只有一个 admin 在线------正是截这张图的会话本身。
这个页面的价值在两个时间差：
- 会话创建时间 vs 最后访问时间：差值大的，是"挂着没动"的僵尸会话；差值小的，是正在活跃操作的；
- 在线人数 vs 授权数：如果系统按并发数授权，这块屏幕就是实时的"占用仪表盘"。
上表左上角有一个红色 注销 按钮------这是运维的"紧急断电"手段。场景很具体：发现某账号异常操作、或需要发版前清场，选中会话点注销，该用户下次请求即被踢回登录页。比改密码温和（不影响正常用户），比重启服务精准（其他会话不受影响）。发版窗口的标准动作之一：发版前看一眼在线人数，非高峰时段执行，注销残余会话。
三、系统信息：一页看清服务器的健康度
第三个工具是"系统信息"（admin/sysinfo），也是信息密度最高的一页：
页面分三块：
左上：系统属性表。 当前时间、系统启动时间、可用处理器 16 核、CPU 使用率、JVM 内存四件套（Total/Used/Free/Max，截图里 128MB 总量、91MB 已用、上限 4008MB）、主机名、IP、操作系统 Windows 11、Java 版本 21.0.5。这 42 行属性里最该盯的是内存四件套：Used 长期贴近 Max 就是扩容信号；系统启动时间则帮你确认"刚才的重启生效了没"。
右上：模块执行统计。 每个被调用模块的名称、CPU 耗时（秒）、调用次数、平均耗时（毫秒）、最后访问时间。截图里 admin/perm/select-modules 累计耗 CPU 4 秒、平均 4230 毫秒，sys/session/verify 平均 659 毫秒。这张表就是"慢在哪个接口"的直接答案------不用装 APM，打开这一页按平均耗时排个序，优化目标自己浮出来。
下方：监控曲线。 CPU 使用率与内存用量的折线图，随时间刷新。趋势比瞬时值重要：偶尔冲高是正常业务波动，持续爬升不回落才是内存泄漏或慢查询堆积的信号。
给你一张健康水位参考表，巡检时对照着看：
|----------------|-----------|--------------------|
| 指标 | 健康区间 | 需要行动的信号 |
| CPU 使用率 | 日常 < 40% | 持续 > 70% 且无对应业务高峰 |
| JVM Used / Max | < 50% | 长期 > 80% 或只涨不跌 |
| 会话在线数 | 远低于设计并发 | 接近授权/设计上限 |
| 模块平均耗时 | 与历史基线持平 | 无改动情况下明显变大 |
水位的意义在于对比：知道正常长什么样，异常才一眼可见。这也正是"每天扫一眼"这条建议的由来。
四、出问题时的固定动作清单
把三个工具串成一套"事故响应 SOP"：
- 先看系统信息：服务活着吗？内存爆了吗？CPU 异常吗？启动时间是预期的吗？------30 秒内判断"是资源问题还是业务问题"；
- 再看模块统计：按平均耗时排序，找到最慢的接口；结合调用次数判断是"高频慢"还是"单次巨慢"；
- 然后查日志：以异常时间点为中心拉时间线，看异常模块调用前后的用户操作与报错记录；
- 必要时动用在线用户：故障由某账号的极端操作引起时，先注销该会话止血，再慢慢修。
这套动作的价值在于全部在浏览器里完成------不需要登服务器翻日志文件，不需要装监控探针，出问题的人（往往不在服务器旁边）也能第一时间自查。
五、给运维的三条预防性建议
监控工具是"事后看"的，但用法可以是"事前防"：
- 每天上班先扫一眼系统信息页，记住内存与 CPU 的"正常水位"。没有基线，异常就看不出来；
- 每周导出一次模块耗时统计，平均耗时持续变大的模块就是要优化的下一个目标；
- 日志保留策略与备份一起定：日志是审计的证据，也是排错的线索，删太早会在下一次故障时让你后悔。