系統監控警示判讀（IT）

ERP 的自動化鏈（排程作業 → 警示／通知信 → 郵件佇列 → Mailgun）平常沒人盯著，壞掉時最糟的情況是靜默：沒人收到信，也沒人知道沒收到。為此系統有兩支「自己顧自己」的監控警示，命中就寄信給系統管理員：

警示（規則代號）	監控對象	回答的問題
排程健康監控（SKD_HEALTH）	排程派發執行紀錄（log_sys_skd）	排程任務跑了但失敗，或跑到一半卡住了嗎？
郵件佇列監控（MAILQ_STUCK）	郵件佇列（twork_skd_mailqueue）	信件寄不出去、卡在佇列或被放棄了嗎？

本頁是收到這兩封信之後怎麼判讀的 SOP，對象是 IT／系統管理員。規則的門檻與收件人在警示規則維護設定，SP 部署與排程掛法見排程作業 · 警示通知。

兩支出廠都是停用的

SKD_HEALTH 與 MAILQ_STUCK 的規則種子出廠時 是否啟用 = N。要開始收信，需在警示規則維護改成 Y、填 IT 的收件信箱，並各掛一筆排程事件——兩者缺一不可。

監控的是「自動化鏈」，不是資料庫或主機

這兩支只看 ERP 自己的排程與郵件佇列。硬體、磁碟、SQL Server 服務、網路等基礎設施監控不在範圍內，請另以貴司既有的監控工具處理。

排程健康監控（SKD_HEALTH）

信件內容

主旨：「【排程健康監控通知】<日期>　排程異常共 N 筆」。摘要列出檢查時間、回看（幾小時）、卡死門檻（幾分鐘）與異常排程筆數（紅字）。本文是一張清單，依開始時間由新到舊排序：

欄位	說明
狀況	執行失敗 或 執行中卡住——先看這欄分流，兩者的處置完全不同
排程方法	該次派發實際執行的預存程序名稱（例如 TWORK_AUTO_AR_OVERDUE）
參數1	該次執行帶入的第一個參數（多為觸發事件的 pkid）
開始時間	開始執行的時間
結束時間	結束時間；卡住的列這欄是空的
狀態	派發器記錄的結果碼；NG 即失敗

命中口徑

狀況	判定條件
執行失敗	狀態為 NG，且執行時間落在回看小時（預設 24 小時）內
執行中卡住	有開始時間、沒有結束時間，且開始時間早於「現在 −卡死分鐘」（預設 60 分鐘）

不偵測「該跑卻沒跑」

本監控只認兩個確定性訊號：有跑但失敗、有跑但沒收尾。排程「漏跑」（例如工作排程器被停用、主機關機整晚）不會被這支警示抓到——因為根本不會產生執行紀錄（ADR 0104 刻意不做，避免以推導的排程週期誤報）。要確認排程是否還活著，請直接看 Windows 工作排程器的「上次執行結果」與 C:\temps\scheduler\ 當日 log。

收到信時依序檢查

1. 看「狀況」分流：執行失敗 走第 2 步，執行中卡住 走第 3 步。同一封信兩種都有時，先處理失敗（多半是根因）。
2. 執行失敗：
   1. 記下排程方法與參數1，到 C:\temps\scheduler\yyyy-MM-dd.txt 找同時間點的 [ERROR] 行，取得實際錯誤訊息。
   2. 對照常見根因：預存程序未部署／改名（換客戶或新版功能未跑部署腳本）、參數個數不符（proc_param 的 param_qty 沒同步改）、權限不足（派發帳號對 auto／log 庫無執行權）、跨庫物件缺席（該客戶沒有對應的 auto 庫）。
   3. 修好之後手動觸發一次該任務驗證（見排程作業 · 手動跑一次驗證），不要等隔天。
3. 執行中卡住：
   1. 先判斷「現在還在跑」還是「遺留的孤兒紀錄」：主機或排程行程若曾被強制終止（重開機、被 kill、逾時砍掉），該次紀錄的結束時間永遠不會被補上。
   2. 確認 Windows 工作排程器的 TsERP Scheduler 目前狀態與最近一次執行結果（見排程作業 · Windows 工作排程器設定）。
   3. 若確認是遺留紀錄：它會每天持續命中（條件只看「有開始、無結束」，沒有時間上限），直到該筆紀錄補上結束時間或被清理。請由 DBA 依貴司的 log 保留政策決定處置，並在處置前後各跑一次確認。
4. 整批同時失敗時，優先懷疑共通依賴：信件風格函數（TWORK_FN_HTML_*）未部署、auto 庫連線異常、或該客戶的 log／auto 庫對應設定有誤。
5. 檢查完把結論記下來——同樣的內容 24 小時內只會再提醒一次，不處理它明天還是會出現。

郵件佇列監控（MAILQ_STUCK）

先理解佇列的狀態機

所有系統信（排程通知、警示信、報表附件信）都先寫進郵件佇列，再由排程作業的寄送階段撈出來交給 Mailgun：

狀態	意義
N	待寄（剛入列）
R	寄送中（已被撈走、鎖定）
Y	已寄出
F	失敗、待重試
D	死信——重試次數已達上限（預設 5 次），不會再自動重送

失敗會以指數退避重試：30 秒、60 秒、120 秒、240 秒、480 秒（上限 8 分鐘）。撈信階段另有殭屍回收：鎖定超過 10 分鐘仍在 R 的會自動放回 N 重撈。

信件內容

主旨：「【郵件佇列卡件通知】<日期>　卡件共 N 筆」。摘要列出檢查時間、滯留門檻（幾小時）與卡件筆數（紅字）。本文清單依建立時間由早到晚排序：

欄位	說明
pkid	佇列列的識別碼；要進 DB 追這封信時用
狀況	死信／滯留／孤兒鎖——先看這欄分流
收件人	這封卡住的信原本要寄給誰
主旨	原信主旨（最多 50 字）——用來判斷是哪一支功能發的
重試/上限	已重試次數與上限（預設 5）
建立時間	入列時間；離現在越久越嚴重
最後錯誤	最後一次寄送失敗的錯誤訊息（最多 80 字）——死信要看的就是這欄

命中口徑

狀況	判定條件	一句話解讀
死信	狀態 D	重試用盡、已放棄，沒人補寄就永遠不會寄出
滯留	狀態 N 或 F，且建立時間早於「現在 −卡件小時」（預設 2 小時）	該撈的沒被撈走，或一直失敗重試中
孤兒鎖	狀態 R，且鎖定時間早於「現在 − 1 小時」（固定值，不隨門檻調整）	被鎖走卻沒有結果——最嚴重的訊號

「孤兒鎖」幾乎等於「寄送服務沒在跑」

撈信階段每次執行都會把「鎖定超過 10 分鐘」的 R 自動放回 N。因此若看到 R 已經鎖超過 1 小時，代表撈信階段本身根本沒有執行（排程作業停用、主機關機、行程反覆崩潰）。這時整條寄信鏈都是停的，請優先處理。

警示信自己被排除，不會自迴圈

本監控會把「來源為郵件佇列監控本身」的信件排除在外，避免「警示信卡住 → 再發一封警示 → 又卡住」的無限迴圈。

寄送服務全掛時，這封信也寄不出去

本警示信與其他信走同一條佇列。若寄送服務完全停擺，警示信只會排在佇列裡等，等服務恢復後才一併寄出（屬「事後補告」）。服務活著、只是部分信失敗的情境才會即時告警。因此不要把這支警示當作唯一的可用性監控——真正的「服務有沒有在跑」請看工作排程器與 log。

收到信時依序檢查

1. 看「狀況」分流，並注意三種混在一起時的優先序：孤兒鎖 > 滯留 > 死信（前者是現在進行式的故障，死信是已成定局的個案）。
2. 孤兒鎖／大量滯留（＝寄送鏈停擺）：
   1. 確認 Windows 工作排程器的 TsERP Scheduler 是否啟用、上次執行結果為何。
   2. 手動執行一次 TsERP.SchedulerWorker.exe，看 console 輸出與 exit code（0／1／2 的意義見排程作業 FAQ）。
   3. 看當日 log C:\temps\scheduler\yyyy-MM-dd.txt 的最後幾行。
   4. 服務恢復後，N／F 的信會自動被重撈補寄——不需要人工介入；R 的孤兒鎖也會在下一輪自動回收。
3. 死信（狀況 死信）：
   1. 讀最後錯誤判斷根因：收件人 Email 格式錯誤／不存在、Mailgun 金鑰過期或網域被停用、額度用罄、附件過大。
   2. 先修根因（改收件人、換金鑰、清額度），否則補寄只會再死一次。
   3. 死信不會自動重送。要讓某筆重新進入待寄，必須同時滿足撈信條件：狀態為 N／F、重試次數小於上限、且下次嘗試時間已到。實際是否補寄、補哪幾筆，請由 DBA 依情況決定。
4. 只有零星滯留（其他信都正常寄出）：多半是該筆本身有問題（超大附件、收件人被拒），比照死信處理。
5. 舊死信會一直被列進來：死信條件沒有時間窗，一年前的死信只要還留在佇列表裡，每次都會被列入清單。若信件越來越長且都是舊資料，請 DBA 依保留政策清理歷史死信——留著只會稀釋真正的新問題。

門檻參數與抑制

兩支的門檻都在警示規則維護的門檻參數欄以 JSON 設定：

排程健康（SKD_HEALTH）郵件佇列（MAILQ_STUCK）

{"回看小時":24,"卡死分鐘":60}

鍵	預設	說明
回看小時	24	只撈最近 N 小時內的失敗紀錄；設太小會漏掉夜間失敗，建議 ≥ 排程檢查週期
卡死分鐘	60	開始執行後超過 N 分鐘仍未結束即視為卡住；本來就跑很久的任務（大型報表產檔）要把它拉高，否則每次都誤報

{"卡件小時":2}

鍵	預設	說明
卡件小時	2	待寄／重試中的信超過 N 小時未寄出即視為滯留。不要設太小：重試退避最長 8 分鐘，設 1 小時以下容易把「正在正常重試」的信誤判成卡件

孤兒鎖的 1 小時判定為固定值，不受本門檻影響。

抑制行為與其他警示相同（見警示規則維護 · 多久提醒一次）：以「命中集合」計算指紋，同一批問題在抑制視窗（預設 24 小時）內只提醒一次；集合有增減才會再寄。無命中時完全靜默——收不到信是好消息。

警示	指紋看的是什麼
SKD_HEALTH	命中的排程紀錄集合（srvdbid ＋ pkid）
MAILQ_STUCK	命中的郵件集合（pkid ＋狀態）；排除警示信自己

誤報常見原因

症狀	多半不是故障，而是	處置
每天固定收到同一筆「執行中卡住」	主機／行程曾被強制終止，留下沒有結束時間的孤兒紀錄	確認該任務現在能正常跑，再請 DBA 處理該筆遺留紀錄
長時間任務被判卡住	卡死分鐘 設得比任務實際執行時間短（例如大型報表產檔）	拉高 卡死分鐘，或把該任務改到離峰時段
剛部署完就收到失敗警示	部署期間手動測試留下的失敗紀錄仍在回看小時視窗內	等視窗滾過即消失；確認之後的排程執行為正常即可
郵件佇列一直報「滯留」但信其實都有寄到	卡件小時 設太小，把正在退避重試的信也算進去	調回 2 小時以上
卡件清單很長且都是很舊的資料	舊死信沒有時間窗，會一直被列入	由 DBA 清理歷史死信
換客戶部署後完全收不到監控信	該客戶的 auto 庫或 SP 未部署，派發靜默回無資料不報錯	照排程作業 · 資料庫部署逐項實查物件

啟用步驟（一次性）

1. 部署 SP：sql\skd-health-deploy.sql、sql\mailq-stuck-deploy.sql；sql\html-fn-deploy.sql 必須先跑（兩支 SP 都引用信件風格函數）。朝陽（CY）用 cy- 前綴的對應腳本。詳見排程作業 · 資料庫部署。
2. 啟用規則：到警示規則維護把 SKD_HEALTH、MAILQ_STUCK 兩列的 是否啟用 改 Y，收件人填 IT 群組信箱（多筆以 ; 分隔），確認門檻參數與抑制視窗小時。
3. 各掛一筆排程事件：兩支都是 SQL 預存程序型，在事件參數把 Dispatcher 設 SKD、Procedure 分別指到 TWORK_AUTO_SKD_HEALTH／TWORK_AUTO_MAILQ_STUCK（其餘保持預設），掛法見排程作業 · 各警示怎麼掛排程與排程事件（專案）。建議頻率：排程健康每日、郵件佇列每日或每數小時。
4. 實測一次：手動製造一筆可控的失敗（例如把測試事件的 Procedure 指到不存在的名稱跑一次），確認收得到信、內容可讀，再把測試設定復原。

收件人請用群組信箱，不要用個人信箱

這兩封信是維運責任而非個人提醒。填部門群組信箱可避免承辦人休假、離職時整條監控線斷掉而無人察覺。

相關功能

• 排程作業（TsERP.SchedulerWorker）：部署、log 位置、失敗與殭屍狀態處理、FAQ
• 警示規則維護：門檻參數、收件人、抑制視窗與啟用開關
• 排程事件（專案）：排程事件的建立、審核與通知人員
• 行動儀表板受控網址設定：另一項 IT 專屬的一次性建置作業
• ADR 0104 警示源第二批與信件風格函數：口徑與「刻意不做」的範圍界定

---

查證邊界

本頁的命中口徑、門檻鍵名與預設值、狀態機與重試退避，均取自 repo 內的警示 SP 母本與郵件佇列相關預存程序。資料庫層的清理／補寄動作本頁刻意不提供現成指令——是否清理歷史紀錄、是否補寄死信涉及貴司的資料保留與稽核政策，請由 DBA 判斷後執行。

需補截圖清單

以下截圖尚未拍攝，請補上並放置於 docs/admin/images/（含收件人、信箱、主機名稱者請去識別化）：

1. system-alert-skd-health-mail.png — 排程健康監控通知信全貌：主旨、摘要列（回看／卡死門檻／異常筆數）與清單（紅框標示「狀況」欄，含 執行失敗 與 執行中卡住 各一列）
2. system-alert-mailq-stuck-mail.png — 郵件佇列卡件通知信全貌：摘要列與清單（紅框標示「狀況」與「最後錯誤」欄，含 死信／滯留／孤兒鎖 三種狀況）
3. system-alert-rule.png — 警示規則維護中 SKD_HEALTH 與 MAILQ_STUCK 兩列的設定（門檻參數 JSON、收件人、是否啟用、抑制視窗小時）

拍攝規格：1280×800 以上、PNG；請使用測試資料（公司以「岩月」示意），避免真實信箱與主機名稱。