日志、在線用戶、系統(tǒng)監(jiān)控出問題時的三個第一現(xiàn)場本文是「geejing WebBuilder 快速開發(fā)平臺」管理運維系列的第 5 篇約 2300 字預計閱讀時間 9 分鐘。系統(tǒng)出問題時運維最怕的不是故障本身而是兩眼一抹黑。本篇基于平臺自帶的三類監(jiān)控工具——操作日志、在線用戶、系統(tǒng)信息把出事后先看哪里講成一套固定動作截圖來自實際運行環(huán)境。一、操作日志誰在什么時候干了什么geejing WebBuilder 快速開發(fā)平臺把用戶會話行為自動記錄成日志無需開發(fā)者埋點。打開日志工具admin/log頂部一排過濾條件開始時間、結(jié)束時間、日志級別、日志類型、用戶名稱、內(nèi)容、IP 地址點重置清空條件。列表按時間倒序展示截圖里能看到典型的 session 類記錄——logged in/logged out交替出現(xiàn)系統(tǒng)已積累 268 條。查詢?nèi)罩镜膬蓚€高頻套路按人查輸入用戶名稱看這個賬號什么時間登錄過、活躍在什么時段——排查賬號是不是被盜用就靠它按時段查設(shè)定故障發(fā)生的時間窗過濾出該時段全部記錄重建時間線。注意列表里的IP 地址列。全部記錄都是0:0:0:0:0:0:0:1IPv6 的 localhost說明訪問都來自本機一旦生產(chǎn)環(huán)境里某個 IP 短時間內(nèi)出現(xiàn)大量登錄失敗就要警覺暴力破解嘗試——配合下一篇要說的封禁功能處理。日志會自己長大268 條只是開始。運維上要定期關(guān)注兩個數(shù)字總量影響查詢速度與磁盤占用日志通常落庫或落盤。按平臺日志配置設(shè)置保留周期過期的歸檔或清理別讓記錄一切變成拖垮一切。查詢時還有兩個字段值得認識日志級別與日志類型。級別區(qū)分 info/warn/error 這類嚴重程度——日常巡檢直接過濾 error 級別一屏看完所有異常類型區(qū)分記錄來源session 會話、模塊訪問等排查登錄問題時先鎖 session 類型排查接口問題時再看模塊訪問類。兩個條件疊加過濾比在幾千條記錄里肉眼翻找快一個數(shù)量級。二、在線用戶實時會話的一塊屏幕第二個工具是在線用戶admin/online-users頁面很直接上表是當前在線用戶用戶名稱、顯示名稱、IP 地址、會話創(chuàng)建時間、最后訪問時間。下表是IP 維度的會話匯總。截圖里只有一個 admin 在線——正是截這張圖的會話本身。這個頁面的價值在兩個時間差會話創(chuàng)建時間 vs 最后訪問時間差值大的是掛著沒動的僵尸會話差值小的是正在活躍操作的在線人數(shù) vs 授權(quán)數(shù)如果系統(tǒng)按并發(fā)數(shù)授權(quán)這塊屏幕就是實時的占用儀表盤。上表左上角有一個紅色注銷按鈕——這是運維的緊急斷電手段。場景很具體發(fā)現(xiàn)某賬號異常操作、或需要發(fā)版前清場選中會話點注銷該用戶下次請求即被踢回登錄頁。比改密碼溫和不影響正常用戶比重啟服務(wù)精準其他會話不受影響。發(fā)版窗口的標準動作之一發(fā)版前看一眼在線人數(shù)非高峰時段執(zhí)行注銷殘余會話。三、系統(tǒng)信息一頁看清服務(wù)器的健康度第三個工具是系統(tǒng)信息admin/sysinfo也是信息密度最高的一頁頁面分三塊左上系統(tǒng)屬性表。當前時間、系統(tǒng)啟動時間、可用處理器 16 核、CPU 使用率、JVM 內(nèi)存四件套Total/Used/Free/Max截圖里 128MB 總量、91MB 已用、上限 4008MB、主機名、IP、操作系統(tǒng) Windows 11、Java 版本 21.0.5。這 42 行屬性里最該盯的是內(nèi)存四件套Used 長期貼近 Max 就是擴容信號系統(tǒng)啟動時間則幫你確認剛才的重啟生效了沒。右上模塊執(zhí)行統(tǒng)計。每個被調(diào)用模塊的名稱、CPU 耗時秒、調(diào)用次數(shù)、平均耗時毫秒、最后訪問時間。截圖里admin/perm/select-modules累計耗 CPU 4 秒、平均 4230 毫秒sys/session/verify平均 659 毫秒。這張表就是慢在哪個接口的直接答案——不用裝 APM打開這一頁按平均耗時排個序優(yōu)化目標自己浮出來。下方監(jiān)控曲線。CPU 使用率與內(nèi)存用量的折線圖隨時間刷新。趨勢比瞬時值重要偶爾沖高是正常業(yè)務(wù)波動持續(xù)爬升不回落才是內(nèi)存泄漏或慢查詢堆積的信號。給你一張健康水位參考表巡檢時對照著看指標健康區(qū)間需要行動的信號CPU 使用率日常 40%持續(xù) 70% 且無對應(yīng)業(yè)務(wù)高峰JVM Used / Max 50%長期 80% 或只漲不跌會話在線數(shù)遠低于設(shè)計并發(fā)接近授權(quán)/設(shè)計上限模塊平均耗時與歷史基線持平無改動情況下明顯變大水位的意義在于對比知道正常長什么樣異常才一眼可見。這也正是每天掃一眼這條建議的由來。四、出問題時的固定動作清單把三個工具串成一套事故響應(yīng) SOP先看系統(tǒng)信息服務(wù)活著嗎內(nèi)存爆了嗎CPU 異常嗎啟動時間是預期的嗎——30 秒內(nèi)判斷是資源問題還是業(yè)務(wù)問題再看模塊統(tǒng)計按平均耗時排序找到最慢的接口結(jié)合調(diào)用次數(shù)判斷是高頻慢還是單次巨慢然后查日志以異常時間點為中心拉時間線看異常模塊調(diào)用前后的用戶操作與報錯記錄必要時動用在線用戶故障由某賬號的極端操作引起時先注銷該會話止血再慢慢修。這套動作的價值在于全部在瀏覽器里完成——不需要登服務(wù)器翻日志文件不需要裝監(jiān)控探針出問題的人往往不在服務(wù)器旁邊也能第一時間自查。五、給運維的三條預防性建議監(jiān)控工具是事后看的但用法可以是事前防每天上班先掃一眼系統(tǒng)信息頁記住內(nèi)存與 CPU 的正常水位。沒有基線異常就看不出來每周導出一次模塊耗時統(tǒng)計平均耗時持續(xù)變大的模塊就是要優(yōu)化的下一個目標日志保留策略與備份一起定日志是審計的證據(jù)也是排錯的線索刪太早會在下一次故障時讓你后悔。