尧图网站建设 
日志、在线用户、系统监控出问题时的三个第一现场本文是「geejing WebBuilder 快速开发平台」管理运维系列的第 5 篇约 2300 字预计阅读时间 9 分钟。系统出问题时运维最怕的不是故障本身而是两眼一抹黑。本篇基于平台自带的三类监控工具——操作日志、在线用户、系统信息把出事后先看哪里讲成一套固定动作截图来自实际运行环境。一、操作日志谁在什么时候干了什么geejing WebBuilder 快速开发平台把用户会话行为自动记录成日志无需开发者埋点。打开日志工具admin/log顶部一排过滤条件开始时间、结束时间、日志级别、日志类型、用户名称、内容、IP 地址点重置清空条件。列表按时间倒序展示截图里能看到典型的 session 类记录——logged in/logged out交替出现系统已积累 268 条。查询日志的两个高频套路按人查输入用户名称看这个账号什么时间登录过、活跃在什么时段——排查账号是不是被盗用就靠它按时段查设定故障发生的时间窗过滤出该时段全部记录重建时间线。注意列表里的IP 地址列。全部记录都是0:0:0:0:0:0:0:1IPv6 的 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 的正常水位。没有基线异常就看不出来每周导出一次模块耗时统计平均耗时持续变大的模块就是要优化的下一个目标日志保留策略与备份一起定日志是审计的证据也是排错的线索删太早会在下一次故障时让你后悔。 Geejing WebBuilder 日志、在线用户、系统监控，出问题时的三个第一现场
日志、在线用户、系统监控出问题时的三个第一现场本文是「geejing WebBuilder 快速开发平台」管理运维系列的第 5 篇约 2300 字预计阅读时间 9 分钟。系统出问题时运维最怕的不是故障本身而是两眼一抹黑。本篇基于平台自带的三类监控工具——操作日志、在线用户、系统信息把出事后先看哪里讲成一套固定动作截图来自实际运行环境。一、操作日志谁在什么时候干了什么geejing WebBuilder 快速开发平台把用户会话行为自动记录成日志无需开发者埋点。打开日志工具admin/log顶部一排过滤条件开始时间、结束时间、日志级别、日志类型、用户名称、内容、IP 地址点重置清空条件。列表按时间倒序展示截图里能看到典型的 session 类记录——logged in/logged out交替出现系统已积累 268 条。查询日志的两个高频套路按人查输入用户名称看这个账号什么时间登录过、活跃在什么时段——排查账号是不是被盗用就靠它按时段查设定故障发生的时间窗过滤出该时段全部记录重建时间线。注意列表里的IP 地址列。全部记录都是0:0:0:0:0:0:0:1IPv6 的 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 的正常水位。没有基线异常就看不出来每周导出一次模块耗时统计平均耗时持续变大的模块就是要优化的下一个目标日志保留策略与备份一起定日志是审计的证据也是排错的线索删太早会在下一次故障时让你后悔。