Blog Details

Linux 作業系統 cutexyz > Blog > 伺服器管理 > 伺服器管理必學 100 招 > 伺服器管理必學 100 招｜Part 7：系統監控、指標與即時告警

伺服器管理必學 100 招｜Part 7：系統監控、指標與即時告警

前言
「在使用者打電話來抱怨系統壞掉之前，你必須先收到告警。」維運最忌諱的是「瞎子摸象」——伺服器當機了卻不知是 CPU 算力不足、記憶體洩漏、磁碟 I/O 堵塞，還是單純網路斷線。本篇精選 10 個核心系統監控與告警調校技巧，從解讀關鍵負載指標、精準定位 I/O 瓶頸，到自建無相依性的輕量 Webhook 告警機器人，助你建立主動式防禦機制。

技巧 061：解讀系統負載真相！深入理解 Load Average 的真正含義

  • 痛點場景：
    下 uptime 看到 Load Average 顯示 4.5，但不知道伺服器到底算不算過載、是否需要立刻擴充核心。
  • 解決方案：
    Load Average 代表「處於可運行狀態（R 狀態）與不可中斷睡眠狀態（D 狀態，通常卡在磁碟 I/O）的平均程序數」：
# 1. 取得當前 CPU 核心數
nproc

# 2. 檢視 1 分鐘、5 分鐘、15 分鐘的平均負載
uptime
  • 解讀黃金法則：
    • Load < CPU 核心數：運算資源餘裕充足。
    • Load ≈ CPU 核心數 × 0.7：健康基準線（建議維持在此水位）。
    • Load > CPU 核心數：程序正在排隊等待 CPU 或磁碟 I/O。若 1 分鐘負載遠大於 15 分鐘負載，代表突發流量或卡死正在發生。
  • 專家提醒：
    若 CPU 使用率很低但 Load Average 卻極高，通常是程式在狂讀寫慢速磁碟（卡在 D 狀態），請立刻檢查磁碟 I/O。

技巧 062：揪出硬碟讀寫拖油瓶！善用 iostat 排查 I/O 瓶頸

  • 痛點場景：
    資料庫查詢極慢、整台伺服器反應遲鈍，但 CPU 使用率只有 15%，懷疑是磁碟讀寫拖慢整體速度。
  • 解決方案：
    安裝 sysstat 工具包，使用 iostat 查看硬碟即時吞吐量與等待延遲：
sudo apt install sysstat -y

# 每 2 秒輸出一次詳細磁碟數據，顯示單位為 MB（-x 顯示進階指標）
iostat -x -m 2
  • 核心觀察指標：
    • %util：磁碟繁忙度百分比。若持續接近 100%，代表該磁碟已達物理極限，產生嚴重佇列排隊。
    • await：I/O 請求的平均等待時間（毫秒）。一般 SSD 應小於 5ms；若數值飆破數十甚至數百毫秒，代表儲存裝置嚴重堵塞。
  • 專家提醒：
    確認是磁碟卡死後，搭配 sudo iotop -o 指令，可直接按 I/O 讀寫速率排序，精準找出是哪個 PID 正在狂刷硬碟。

技巧 063：看懂記憶體的虛與實！別被 free -h 的 Buff/Cache 嚇壞

  • 痛點場景：
    初學者下 free -m 看到「free 只有 100MB」，誤以為伺服器記憶體快要爆滿而緊張重啟。
  • 解決方案：
    正確解讀 Linux 的記憶體管理哲學（Linux 把閒置 RAM 當作快取使用以加速硬碟讀取）：
free -h
  • 觀察重點：
    • total：實體總記憶體。
    • buff/cache：Linux 核心用來緩存磁碟讀寫的記憶體。當應用程式需要記憶體時，這部分會瞬間無條件釋放。
    • available：最重要的核心指標！代表在不引發 Swap 交換的前提下，系統還能調配給新程式的真實可用記憶體。
  • 專家提醒：
    判斷伺服器是否缺記憶體，永遠只看 available 是否低於 15%，以及 Swap 是否在頻繁換入換出（Swap In/Out）。

技巧 064：監控 Swap 活躍度！用 vmstat 辨識記憶體抖動

  • 痛點場景：
    伺服器啟用了 Swap，雖然記憶體沒爆，但整台機器的回應延遲從毫秒級跌落至秒級。
  • 解決方案：
    使用 vmstat 監控虛擬記憶體與頁面置換頻率：
# 每 1 秒刷新一次系統綜合指標
vmstat 1
  • 關鍵觀察欄位：
    • si（Swap In）：每秒從磁碟 Swap 區換入記憶體的量（KB）。
    • so（Swap Out）：每秒從記憶體換出至磁碟 Swap 區的量（KB）。
  • 專家提醒：
    若 si 與 so 數值持續大於 0，代表系統正處於嚴重的「記憶體抖動（Thrashing）」，磁碟 I/O 正在被頻繁的 Swap 換頁拖垮，應盡速擴充實體 RAM 或限縮耗能程序。

技巧 065：極簡自動告警！Bash 腳本定時監控磁碟並推播 Discord / Telegram

  • 痛點場景：
    中小型伺服器不想架設龐大的 Prometheus 叢集，但需要第一時間知道「磁碟使用率超過 85%」。
  • 解決方案：
    撰寫輕量監控腳本 /usr/local/bin/disk-alert.sh：
#!/usr/bin/env bash
set -euo pipefail

# 設定臨界值（85%）與 Webhook URL
THRESHOLD=85
WEBHOOK_URL="https://discord.com/api/webhooks/YOUR/WEBHOOK/URL"
CURRENT_USAGE=$(df -h / | awk 'NR==2 {print $5}' | tr -d '%')

if [ "$CURRENT_USAGE" -ge "$THRESHOLD" ]; then
    MESSAGE="⚠️ [伺服器磁碟告警] 根目錄使用率已達 ${CURRENT_USAGE}%！請盡速上線排查清理。"
    curl -s -H "Content-Type: application/json" \
         -X POST \
         -d "{\"content\": \"${MESSAGE}\"}" \
         "$WEBHOOK_URL" > /dev/null
fi
  • 設定執行權限並加入排程（每 30 分鐘巡檢一次）：
sudo chmod +x /usr/local/bin/disk-alert.sh
(crontab -l 2>/dev/null; echo "*/30 * * * * /usr/local/bin/disk-alert.sh") | crontab -
  • 專家提醒：
    發送 Webhook 時加上 -s 靜音輸出，並將標準輸出導向 /dev/null，避免 Cron 重複寄發本機郵件。

技巧 066：服務死掉立刻救！自動偵測 Port 斷線並重啟 + 發報

  • 痛點場景：
    API 或遊戲服務因不明原因崩潰，等到早上進辦公室才發現已經停擺了整夜。
  • 解決方案：
    撰寫看門狗腳本（Watchdog），偵測本機連接埠是否在線，若斷線則自動嘗試重啟服務並發送通報：
#!/usr/bin/env bash
PORT=8000
SERVICE_NAME="myapp"
WEBHOOK_URL="https://discord.com/api/webhooks/YOUR/WEBHOOK"

if ! ss -tuln | grep -q ":${PORT} "; then
    # 連接埠未在監聽中，嘗試重啟
    systemctl restart "${SERVICE_NAME}"

    PAYLOAD="{\"content\": \"🚨 [嚴重中斷] 偵測到 ${SERVICE_NAME} (Port ${PORT}) 斷線！已自動執行重啟程序。\"}"
    curl -s -H "Content-Type: application/json" -X POST -d "$PAYLOAD" "$WEBHOOK_URL"
fi
  • 專家提醒：
    除了 Watchdog 外，Systemd 原生的 Restart=always 仍是第一線自動防線，外掛腳本是用於發送即時告警通知與跨服務聯動。

技巧 067：開箱即用的現代化美麗儀表！5 分鐘佈署 Uptime Kuma

  • 痛點場景：
    需要一個具備公開狀態頁（Status Page）、支援 HTTP(S) Ping、TCP Port、SSL 到期日監控的系統，但不想配置複雜的 Zabbix。
  • 解決方案：
    透過 Docker 一行啟動超強開源監控平台 Uptime Kuma：
# 建立專用儲存目錄並啟動容器
mkdir -p /opt/uptime-kuma
docker run -d --restart=always -p 3001:3001 -v /opt/uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:1
  • 瀏覽器打開 http://<SERVER_IP>:3001 即可進入儀表板，支援設定：
    • 每 60 秒檢測一次 HTTP 狀態碼與 Keyword。
    • 憑證過期前 7 天自動警報。
    • 內建支援 Telegram、Discord、Slack、Email、Webhook 等數十種通知管道。
  • 專家提醒：
    建議將 Uptime Kuma 架設在與業務主機不同的獨立小主機上，否則「主機整台死機時，監控平台也跟著沉沒」，失去外部監測的意義。

技巧 068：無代理秒級即時監控！部署 Netdata 觀測萬項微指標

  • 痛點場景：
    遇上間歇性卡頓，幾秒鐘後就恢復，事後查看 CPU 平均負載完全看不出端倪。
  • 解決方案：
    安裝高頻率（秒級採樣）的輕量監控系統 Netdata：
# 官方一鍵安裝腳本（資源消耗極低，單核心 CPU 佔用通常 < 1%）
wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh && sh /tmp/netdata-kickstart.sh --stable-channel
  • 啟動後預設監聽 19999 埠，提供包含「每秒磁碟佇列、TCP 重傳率、中斷次數（Context Switches）、各進程即時資源」等數千種微觀圖表。
  • 專家提醒：
    Netdata 預設未設密碼，若直接暴露 19999 埠至公網極度危險；務必透過 Nginx 加上 Basic Auth 密碼驗證或以防火牆阻擋外部存取。

技巧 069：終端機動態儀表進階版！使用 glances 跨平台多維度監控

  • 痛點場景：
    在終端機內除錯時，希望能同時看到 CPU、記憶體、磁碟 I/O、網路流量、容器狀態與感應器溫度，不必開 5 個視窗。
  • 解決方案：
    使用 Python 編寫的現代化監控工具 glances：
sudo apt install glances -y
# 直接啟動全功能終端儀表
glances
  • glances 的核心優勢：
    • 警報高亮（Color Coding）：超過安全水位自動由綠轉橘、轉紅。
    • 容器感知：若主機上有跑 Docker，會自動顯示各容器的資源消耗。
    • Web 伺服器模式：下 glances -w 可直接啟動簡易 Web 介面。
  • 專家提醒：
    按 1 可展開各核心 CPU 的獨立狀態，按 d 可切換顯示磁碟 I/O，按 p 依程序名稱排序。

技巧 070：追蹤 TCP 異常！監控連線狀態分佈與 TIME_WAIT 堆積

  • 痛點場景：
    在高流量反向代理或 API 閘道上，連線數莫名爆滿，導致伺服器無法再接受任何新連線。
  • 解決方案：
    快速統計當前作業系統中所有 TCP 連線狀態的分佈：
# 統計各 TCP 狀態數量
ss -ant | awk '{print $1}' | sort | uniq -c | sort -rn
  • 典型異常徵兆：
    • SYN_RECV 過多：高機率正在遭受 SYN Flood DDoS 攻擊。
    • TIME_WAIT 堆積數萬個：代表本機作為客戶端頻繁關閉短連線（如未開啟 HTTP KeepAlive），正將本機可用 Port 耗盡。
    • CLOSE_WAIT 堆積：應用程式嚴重 Bug！代表遠端已關閉連線，但本機程式沒有呼叫 close() 釋放 Socket，導致連線永久洩漏。
  • 專家提醒：
    遇到 CLOSE_WAIT 暴增時，問題出在應用程式層的連線池未正確關閉，調整系統核心參數無法根除，必須重啟該進程並修復程式碼。