IT 基礎設施監控與告警系統建置指南

前言：看不見的問題是最危險的問題

「伺服器掛了嗎？」「網路為什麼變慢？」「磁碟快滿了嗎？」——如果 IT 團隊是靠使用者報修才知道問題，那就已經太遲了。有效的 IT 監控系統能在問題影響到使用者之前，就發出預警並自動觸發處理流程。

一、監控的四大類別（外加最常被遺忘的第五類）

1. 基礎設施監控

監控伺服器、儲存設備與網路設備的硬體健康狀態：

• CPU 使用率、溫度、頻率
• 記憶體使用率與 Swap 使用量
• 磁碟 I/O、空間使用率、SMART 健康狀態
• 風扇轉速、電源供應器狀態（透過 IPMI/BMC）

2. 網路監控

• 交換器/路由器 port 流量（SNMP、NetFlow）
• 連結狀態（Up/Down）與錯誤計數
• 頻寬使用率與瓶頸偵測
• 延遲與封包遺失率

3. 應用程式監控（APM）

• HTTP 回應時間與狀態碼
• 資料庫查詢效能（慢查詢偵測）
• 應用程式錯誤率與日誌
• 使用者體驗指標（頁面載入時間、交互延遲）

4. 安全監控

• 登入失敗次數與帳號鎖定事件
• 防火牆阻擋紀錄
• 異常流量偵測（DDoS、Port Scan）
• 憑證到期提醒（疏於監控的真實後果，見 SSL 憑證自動續期失靈 8 天才發現）

5. 環境與電力監控（最常被遺忘的第五類）

嚴格來說這是加碼的第五類，卻是中小企業機房最常出事的地方：伺服器本身再穩，冷氣半夜跳掉、UPS 電池老化沒人知道，一樣整個機房停擺。該監控的項目：

• 機房溫濕度（高溫是硬體壽命殺手，超標應視同緊急事件）
• UPS 電池健康度、負載率、剩餘備援時間
• 市電斷電／復電事件（頻繁跳電往往是更大問題的前兆）
• 漏水偵測（冷氣冷凝水、管線滲漏）

多數 UPS 與環控設備都支援 SNMP，可以直接納入同一套監控系統，不需要另外買平台。UPS 的選型與電池汰換週期，可參考 UPS 不斷電系統選型與電力保護完整指南。

怎麼收資料：Agent、SNMP、IPMI 一次說清楚

類別清楚了，下一個實務問題是「資料怎麼收進來」。主流做法有三種，各有明確的適用對象：

• Agent（代理程式）：在伺服器作業系統內安裝小程式，能拿到最深入的資料——程序與服務狀態、事件日誌、甚至自訂腳本的檢查結果。Zabbix agent、Prometheus 的各種 exporter 都屬此類。適合所有 Windows／Linux 伺服器。
• SNMP（免裝軟體）：交換器、防火牆、印表機、UPS 等網路設備幾乎都內建 SNMP，設定好 community 或 v3 帳號即可由監控系統定期輪詢，適合「不能裝軟體」的設備。Windows 環境另有 WMI 可以在不裝 agent 的情況下讀取基本指標。
• IPMI／BMC（帶外監控）：直接詢問伺服器主機板上的管理晶片（Dell iDRAC、HPE iLO 等），就算作業系統當機也量得到溫度、風扇、電源供應器狀態，是硬體層監控的最後防線。

選用原則一句話：伺服器用 agent、網路與周邊設備用 SNMP、硬體底層用 IPMI——三者並用不衝突，成熟的監控平台都能同時支援。

「該監控什麼」：一張可以直接照做的清單

監控對象	至少要監控的項目	建議檢查頻率	告警給誰
伺服器	CPU／RAM／磁碟使用率、關鍵服務程序存活、事件日誌關鍵字	1–5 分鐘	IT 人員（P2 以上即時通知）
網路設備	存活狀態（ICMP／SNMP）、port 流量與錯誤計數、WAN 延遲	1 分鐘	IT 人員
備份作業	每日備份結果、備份檔大小變化、定期抽測還原	每日檢查＋每季還原演練	IT＋主管（連續失敗要升級）
憑證／網域	SSL 憑證到期日（至少 30 天前預警）、網域與 DNS 到期	每日	IT 人員
關鍵服務	網站／ERP／郵件的 HTTP 或連線探測、回應時間	30 秒–1 分鐘	IT 人員（對外服務中斷＝P1）
機房環境	溫濕度、UPS 電池與負載、市電事件	1–5 分鐘	IT＋總務（機房高溫＝P1）

特別提醒備份那一列：很多企業把備份監控做成「job 有跑就好」，但 job 顯示成功、備份檔卻還原不了的案例並不少見。監控的目標是「備份成功且可還原」，所以除了每天看 job 結果，還要定期抽測還原——完整做法見 3-2-1-1 備份策略實作：保護企業關鍵資料。

二、關鍵監控指標

類別	指標	警告閾值	嚴重閾值
CPU	使用率	> 80% 持續 5 分鐘	> 95% 持續 3 分鐘
記憶體	使用率	> 85%	> 95%
磁碟	空間使用率	> 80%	> 90%
磁碟	I/O 延遲	> 10ms（SSD）	> 50ms
網路	頻寬使用率	> 70%	> 90%
網路	封包遺失率	> 0.1%	> 1%
應用	回應時間	> 2 秒	> 5 秒
應用	錯誤率	> 1%	> 5%

閾值是起點，不是答案

上表的數字是通用起點，不是照抄就能用的答案。每個環境的「正常」長得不一樣，實務上建議監控上線後先觀察 2–4 週建立 baseline（基準線）：看清楚日常負載的尖峰落在哪裡、備份與排程時段的資源曲線長什麼樣，再把閾值收斂到「超過就真的有事」的位置。跳過這一步直接套通用值，最常見的下場就是第一週被誤報淹沒，第二週開始沒人看告警。

閾值要依伺服器角色調整。資料庫伺服器把記憶體吃到 90% 往往是正常現象——資料庫的快取設計本來就該把記憶體用好用滿，照表設 85% 警告只會天天叫；反過來，檔案伺服器磁碟用到 80% 就該啟動清理或擴容，因為使用者資料的成長不會自己停下來。同一個指標，DB 伺服器、檔案伺服器、應用伺服器應該各有各的閾值。

「持續時間」條件比「瞬間值」重要。CPU 飆到 100% 撐十幾秒通常什麼事都沒有——排程作業、防毒掃描都會造成瞬間高峰；真正有意義的條件是「超過 90% 且持續 5 分鐘」。把持續時間納入告警規則，是消滅誤報最有效的一招。

三、告警策略

告警分級

級別	定義	回應時限	通知管道	範例事件
P1 緊急	服務中斷、資料遺失風險	15 分鐘內回應	電話＋即時通訊（要能叫醒值班）	對外網站全掛、ERP 資料庫離線、機房高溫
P2 高	效能嚴重下降、資源即將耗盡	1 小時內回應	即時通訊（LINE／Telegram／Slack）＋Email	磁碟使用率超過 90%、備份連續失敗兩天
P3 中	效能輕微下降、資源趨近閾值	當個工作日內處理	Email	磁碟使用率超過 80%、憑證 30 天內到期
P4 低	資訊性告警、非緊急異常	週會統一檢視	Dashboard 彙整顯示	單次瞬間高負載、非關鍵服務自動重啟

Escalation 路徑：沒人回應時，告警要往上走

告警送出去只是開始，真正要設計的是「沒人處理怎麼辦」。以 P1 為例，常見的升級路徑：

• 告警發給主值班，要求在時限內認領（ack）
• 15 分鐘內無人認領 → 系統自動升級通知副值班
• 再 15 分鐘仍無回應 → 升級通知 IT 主管

多數告警工具（Alertmanager、PagerDuty、Zabbix 的動作升級）都內建這種逾時升級機制，重點是要真的設定，而不是把所有告警丟進同一個群組聽天由命——群組裡「每個人都以為別人會處理」，是最常見的告警失效方式。

值班輪替怎麼排

• 主／副雙人制：每週一位主值班負責第一線回應，一位副值班當 escalation 後盾，避免單點失效。
• 週輪替優於日輪替：交接成本低、責任明確。固定在週一交接，用簡短 checklist 交接未結案事件與本週維護時段。
• 2–3 人小團隊的務實做法：與其硬排 24/7（排不出來也撐不久），不如明確定義「上班時間全級距回應、下班後只回 P1」，並把 P1 嚴格控制在真正值得半夜叫醒人的少數事件。若連這樣都吃緊，可把夜間與假日的告警值守交給維運廠商（見第七節）。

避免告警疲勞

過多無意義的告警會讓 IT 團隊麻痺，反而忽略真正重要的警報。這不是感覺問題，而是可量化的營運風險：2026 年一份針對 1,039 位 SRE 與 IT 維運人員的調查顯示，44% 的組織在過去一年曾因「被壓抑或忽略的告警」直接導致停機事故；77% 的值班團隊每天收到至少 10 則告警；57% 的受訪者表示可付諸行動的告警不到三成。告警太多的最終結果，就是真正重要的那一則被淹沒。基本原則：

• 設定合理的閾值，避免過於敏感
• 使用持續時間條件（如 CPU > 90% 持續 5 分鐘才告警，排除瞬間飆高）
• 告警聚合：同一事件多個指標同時異常時，只發送一則告警
• 定期審查告警規則，移除不再相關的告警

在原則之上，建議建立三個治理機制：

• 每月告警審查會議：把過去一個月「發出但沒人採取動作」的告警列出來，逐條決定收斂閾值、降級或刪除——沒人動作的告警就是噪音。
• 維護時段（maintenance window）靜音：排程更新、備份高峰等可預期的時段，預先靜音相關告警，避免「每週三凌晨都在叫」把團隊訓練成無視告警。
• 每則告警附 runbook 連結：告警訊息裡直接放「這個告警代表什麼、第一步查什麼」的處理文件連結，讓半夜被叫醒的人不必從零開始想。

四、工具選擇

類型	開源方案	商用方案
基礎設施	Prometheus + Grafana、Zabbix	Datadog、PRTG、SolarWinds
網路	LibreNMS、Cacti	PRTG、WhatsUp Gold
APM	Jaeger、SkyWalking	New Relic、Dynatrace
日誌	ELK Stack、Loki	Splunk、Graylog Enterprise
告警	Alertmanager（Prometheus 生態）	PagerDuty、Jira Service Management

兩個 2026 年要特別注意的過時資訊：Grafana OnCall 開源版已於 2026 年 3 月正式封存（repo 唯讀，官方導向 Grafana Cloud IRM），不要再列入新建置的選項；Atlassian Opsgenie 已於 2025 年 6 月停售、2027 年 4 月將終止支援，既有用戶需及早規劃遷移至 Jira Service Management 或其他告警平台。網路上大量舊文章仍在推薦這兩者，照做會選到已進入淘汰週期的產品。

依規模選型：一張決策表

工具清單很長，但中小企業真正需要的判斷只有兩個：環境規模與手上有什麼技能的人。

你的情境	建議方案	需要的人力技能
20 台設備以下，或只需要知道「網站／服務活著沒」	Uptime Kuma（v2 世代）	會基本 Docker 即可，半天可上線
20–100 台、以 Windows 為主、沒有 Linux 人力	PRTG（100 個 sensor 內免費）	Windows 管理經驗即可，全圖形化設定
100 台以上，或 Windows／Linux／網路設備混合環境	Zabbix 7.0 LTS（或其後的 8.0 LTS）	需要 Linux 基礎，與投入範本調校的時間
有容器／Kubernetes／雲原生工作負載	Prometheus 3 世代＋Grafana 現行版	需要 YAML 與 PromQL，學習曲線最陡

版本提醒：Zabbix 採 LTS 政策（約每 1.5 年一版，3 年完整支援加 2 年安全性支援），新建置應選 LTS 版而非最新 stable 分支，升級週期才排得動。Uptime Kuma 已進入 2.x 世代（新增 MariaDB 支援與 rootless Docker 部署），網路上大量 1.x 時代的舊安裝教學已不是首選做法。

告警怎麼送到 LINE：Notify 停用後的做法

很多台灣中小企業的監控通知在 2025 年「悄悄斷線」了——LINE Notify 已於 2025 年 3 月 31 日終止服務，舊監控系統裡設定的 Notify webhook 從那天起就再也發不出訊息，而且多數監控系統不會主動告訴你通知失敗。如果你的告警當初是接 LINE Notify，第一件事是立刻確認並更換通知管道。現在的三條路：

• LINE 官方帳號＋Messaging API：官方替代方案。申請 LINE 官方帳號並建立 Messaging API channel，由監控系統呼叫推播 API 發送。免費方案每月 200 則訊息，適合只送 P1／P2 的低量緊急告警；量一大就會產生訊息費用。
• Telegram bot：免費、無則數上限，Zabbix 與 Uptime Kuma 都內建 Telegram 通知，十幾分鐘可設定完成。缺點是團隊要多裝一個 App。
• Email 保底：無論走哪條路，Email 都應保留為「所有告警都寄」的紀錄管道，方便事後回溯與稽核。

務實建議採雙軌制：LINE 或 Telegram 只收 P1／P2 緊急告警——少而精，確保每一則都值得看；Email 收全部告警留存紀錄。把全部告警都灌進即時通訊群組，等於親手製造告警疲勞。

五、Dashboard 設計建議

• 總覽 Dashboard：全環境健康狀態一目了然（紅綠燈 + 數字摘要）
• 網路 Dashboard：核心交換器流量、Top Talker、WAN 使用率
• 伺服器 Dashboard：各主機 CPU/RAM/Disk 趨勢圖、Top 10 資源消耗
• 應用 Dashboard：回應時間趨勢、錯誤率、活躍使用者數

好的 Dashboard 能讓 IT 團隊在 30 秒內掌握全環境狀態。至於安全監控類的訊號，光是看得到還不夠，還需要有人 24/7 判讀與處置——若內部沒有資安人力，可參考 沒有資安團隊的 MDR 服務評估指南，了解如何把偵測與回應交給外部 SOC 團隊。

六、SLO 入門：把「穩不穩」變成可以管理的數字

「我們的系統穩不穩？」如果答案只有「還行」「最近好像常出事」，代表穩定性還停留在感覺層面。源自 Google SRE 實務的 SLO 方法論，用三個詞把它變成可以管理的數字：

• SLI（服務水準指標）：實際量測到的數據，例如「過去 30 天 HTTP 請求成功率 99.93%」「95% 的請求在 800ms 內回應」。監控系統本來就在收這些數據，SLI 只是從中挑出最能代表使用者體驗的那幾個。
• SLO（服務水準目標）：替 SLI 訂的目標值，例如「30 天成功率 ≥99.9%」。這是內部管理目標，不等於對客戶的合約承諾（那叫 SLA）。
• Error budget（錯誤預算）：SLO 容許的失敗額度。訂 99.9% 的月度目標，代表這個月「還可以壞 43.8 分鐘」——額度還很多時，可以放心排更新、上新功能；額度快燒完，就該暫緩變更、先把穩定性的債還掉。它把「現在能不能冒險改東西」從各說各話變成看數字。

可用性目標與實際停機時間的換算如下——每往上加一個 9，難度與成本都是跳階式增加：

可用性目標	每年允許停機	直觀感受
99%	約 87.6 小時	平均每月停 7 小時以上，內部系統也嫌多
99.5%	約 43.8 小時	內部系統的務實起點
99.9%	約 8.76 小時（每月約 43.8 分鐘）	對外服務的常見目標
99.99%	約 52.6 分鐘	需要備援架構＋24/7 值守才撐得住

中小企業的務實建議：內部系統從 99.5% 起步、對外服務訂 99.9%，而且先量測 2–3 個月、看清楚現況實際落在哪，再往外承諾——不要一開口就 99.99%。訂一個達不到的目標，只會讓整套數字失去公信力。

七、監控建好了，誰來看？——沒有人值守的監控等於沒建

這是全篇最重要、也最常被跳過的一節：監控系統只負責「叫」，不負責「處理」。半夜三點磁碟告警發出來，如果沒有人看、沒有人上機處置，結果跟沒建監控完全一樣。很多企業花了幾週把 Zabbix 架起來，一年後回頭看，告警群組早已被全員靜音。

從零開始的四步導入路線圖

1. 盤點（第 1 週）：列出所有伺服器、網路設備、關鍵服務與備份作業，標出「掛掉會影響營運」的優先項目——第一節的清單表可以直接拿來用。
2. 小規模部署（第 2–3 週）：先讓最關鍵的 10–20 個監控項上線（對外服務存活、備份結果、磁碟空間、UPS），不要第一天就想監控所有東西。
3. 調閾值（第 4–8 週）：跑 2–4 週建立 baseline，每週檢視誤報並收斂閾值，直到「每一則告警都值得看」。
4. 演練通知鏈（第 8 週起）：實際模擬一次 P1（例如手動停掉測試服務），驗證告警幾分鐘內送達、escalation 是否照設計升級、值班的人是否知道第一步做什麼。沒演練過的通知鏈，等於沒有通知鏈。

沒有專職 IT 或人力不足：三種維運模式

模式	適合對象	要注意什麼
自建自看	有 2 人以上 IT 團隊、排得出值班	需自行負擔工具維護與值班制度；單人 IT 撐不了 24/7
自建＋維運廠商代看告警	有 1 位 IT，但下班與假日無人值守	監控自己建，夜間／假日告警由維運廠商判讀與初步處置；權責界線與升級規則要先白紙黑字寫清楚
整包交給維運服務	沒有專職 IT 的中小企業	工具建置、告警判讀、上機處置到月報告一次到位；合約要載明回應時限（SLA）與服務範圍

第三種模式的成本結構怎麼估、跟自聘 IT 人員相比划不划算，可參考 IT 人力自建與外部服務的真實成本比較。凱茂資訊的機房維運服務即涵蓋監控建置與告警值守——從工具選型部署、閾值調校、告警判讀處置到每月維運報告一次到位，讓「有人看」不再依賴某一位員工的手機永遠不關機。而無論選哪一種模式，怎麼檢驗供應商做不做得到承諾，見 IT 維運廠商評估指南的十個必問問題。