📊 Zabbix 代理與主動監控：模板設計與觸發條件調校
在大型環境（多站點、多網段、跨防火牆、或頻寬/延遲不穩）導入 Zabbix 時，最常遇到的兩件事就是：
- 監控點越多，Zabbix Server 壓力越大（poller / history sync / DB I/O 一起飆）。
- 告警越多，越容易「真假難辨」（閾值太緊、抖動、重複事件、或根因沒被凸顯）。
這篇用「Zabbix Proxy + Active Check」當作核心，帶你把模板（Template）與觸發條件（Trigger）做成可維護、可擴展、也更貼近實務的版本。
📌 目錄
- 1. Proxy 與 Active Check 的定位
- 2. 架構與流量路徑（誰連誰）
- 3. Proxy 安裝與基本設定要點
- 4. 主動監控（Active Check）設計策略
- 5. 模板設計：Item / Trigger / Graph / LLD
- 6. 觸發條件調校：去抖動、降噪、抓根因
- 7. 上線與驗收：逐步 rollout 的做法
- 8. 常見問題排查清單
- FAQ
- 🔗 延伸閱讀
1. Proxy 與 Active Check 的定位
✅ Zabbix Proxy 是什麼？
Zabbix Proxy 是「站點側的監控前哨站」：它可以代替 Zabbix Server 去收資料、暫存資料、再回送到 Server。 好處是：
- 降低 Zabbix Server 的直連壓力（poller 數量、連線數、跨網段延遲）。
- 站點短暫斷線時，Proxy 可緩衝資料，恢復後再補送。
- 跨防火牆時，Proxy 可做成「單向可控」的連線策略（更安全、更好維運）。
✅ Active Check（主動監控）是什麼？
Active Check 的概念是「Agent 主動出去拿設定，再主動回報資料」：
- Agent →（主動連線）→ Server / Proxy
- Agent 取得待監控的 item 清單後，定期把資料 push 回去
特別適合這些情境：
- 站點內主機無法被 Server/Proxy 反向連回（NAT、嚴格 ACL、零信任網段）。
- 大量端點（桌機、筆電、POS、IoT）不適合被動輪詢。
- 希望降低 poller 壓力，改成端點分散回報。
一句話： Proxy 解決「收集與緩衝」，Active Check 解決「連線方向與負載分散」。兩者搭起來通常就是大規模環境的標配。
2. 架構與流量路徑（誰連誰）
典型模式 A：Proxy 在站點內收資料（被動 + 主動混合）
[Agents (Passive/Active)] → [Zabbix Proxy] → [Zabbix Server] → [DB]- 站點內端點多：Agent 被動（Proxy poll）或主動（Agent push）都可以。
- 站點對外只需要允許 Proxy → Server 的一條路（更好控）。
典型模式 B：端點主動回報到 Proxy（主動為主）
[Agents (Active)] → [Zabbix Proxy] → [Zabbix Server] → [DB]- 跨網段、跨防火牆、NAT：只要端點能主動打到 Proxy 即可。
- Proxy 再集中回送到 Server。
3. Proxy 安裝與基本設定要點
以下以「Proxy + SQLite」做示範（小中型站點很實用、部署快）。若站點很大或 Proxy 壓力高，再改 PostgreSQL/MySQL。
3.1 Proxy 設定核心參數（zabbix_proxy.conf）
### Proxy identity
Server=10.0.0.10 # Zabbix Server IP/DNS
Hostname=SITE-A-PROXY # 必須與 Zabbix 前台建立的 Proxy 名稱一致
### Proxy mode
ProxyMode=0 # 0=active proxy（Proxy 主動連回 Server）建議
# ProxyMode=1 # 1=passive proxy
### Local DB（示範 SQLite）
DBName=/var/lib/zabbix/zabbix_proxy.db
### Cache / queue
CacheSize=256M
HistoryCacheSize=128M
HistoryIndexCacheSize=64M
Timeout=4
### Logs
LogFile=/var/log/zabbix/zabbix_proxy.log
LogFileSize=0
建議： ProxyMode 使用 active proxy（Proxy 主動連回 Server），跨防火牆時最省事；同時你只要在 Server 側開一個清楚的接收規則即可。
3.2 Proxy 在 Zabbix 前台的設定重點
- Administration → Proxies：建立 Proxy，名稱要與
Hostname完全一致。 - Proxy mode：Active（通常更穩）
- Hosts 指派：把站點內的主機指派到該 Proxy
4. 主動監控（Active Check）設計策略
4.1 Agent2（建議）Active 設定示範
### /etc/zabbix/zabbix_agent2.conf
Server=127.0.0.1
ServerActive=10.0.1.20 # Proxy IP（建議指向站點 Proxy）
Hostname=HOST-001 # 必須與前台 host name 一致
### 主動回報頻率相關（依環境調整）
RefreshActiveChecks=120若你希望「端點只出站、不入站」，那就以 Active Check 為主：
- 防火牆只需允許 Agent → Proxy（通常 10051/tcp）。
- Proxy 再回送 Server，不必讓 Server 直接碰站點端點。
4.2 Active Check 的「大規模」注意事項
- 不要把所有 item 都做成秒級更新（那會變成自己打自己）。
- 把「高頻（10~30s）」留給關鍵服務（核心 DB / API / GW），其餘以 60~300s 為主。
- 把「資料量巨大」的項目（例如大量 log / 多維度統計）改用 LLD 或採樣。
5. 模板設計：Item / Trigger / Graph / LLD
5.1 模板分層：共用層 + 角色層
建議你把模板做成兩層（維護會差非常多）：
- 共用層：OS 基礎（CPU/RAM/Disk/Net）、時間同步、基本可用性
- 角色層：DB、Web、Cache、Queue、Proxy、Firewall…（依主機角色套用）
5.2 Item 設計：先決定「要回答的問題」
一個好 Item 不是「能抓到」而已，而是要回答這幾種問題：
- 現在狀態如何？（current）
- 趨勢如何？（trend）
- 根因可能在哪？（diagnostic）
範例（Linux）：
system.cpu.util[,user]
vm.memory.size[available]
vfs.fs.size[/,pfree]
net.tcp.service[http,,80]5.3 Trigger 設計：先做「嚴重度分級」
實務建議至少分三級（你後續的告警路由/值班才會好做）：
- Info：可觀察，但不急（例如短暫尖峰）
- Warning：需要處理（例如持續高負載/空間逼近）
- High/Disaster：立即處理（服務中斷、磁碟滿、DB down）
範例 Trigger（磁碟空間，含抖動過濾）：
{Template OS Linux:vfs.fs.size[/,pfree].max(5m)}<10
AND
{Template OS Linux:vfs.fs.size[/,pfree].min(5m)}<12
上面用 max(5m) 與 min(5m) 做「連續性」判斷，比單點值更不容易誤報。
5.4 LLD（自動發現）策略：把「會變動的東西」交給機器
最常用 LLD 的項目：
- 磁碟/掛載點（新加盤、新 mount）
- 網卡介面（新增 bond/vlan）
- 服務/程序（多實例）
示例：對所有掛載點自動產生剩餘空間告警（概念示意）
LLD rule：vfs.fs.discovery
Item prototype：vfs.fs.size[{#FSNAME},pfree]
Trigger prototype：
{Template OS Linux:vfs.fs.size[{#FSNAME},pfree].min(10m)}<106. 觸發條件調校：去抖動、降噪、抓根因
6.1 三個最有效的降噪技巧
技巧 A：用時間窗判斷（min/max/avg）
{host:key.min(5m)}<threshold技巧 B：用 hysteresis（回復條件不同於觸發條件）
例如：CPU > 90% 持續 10 分鐘才告警；回復需降到 70% 持續 5 分鐘。
技巧 C：用依賴關係（Trigger dependencies）抓根因
當「上游斷線」時，讓下游告警被抑制，避免一斷線全站紅一片。
- 例：站點 Gateway Ping Down → 依賴它的服務告警全部抑制
- 例：DB Down → API error rate 的告警可以依賴 DB
6.2 建議的調校順序（很省時間）
- 先把「明確中斷」類（服務 down、ping 斷、port 斷）做準。
- 再做「資源耗盡」類（disk、inode、memory、fd、conn）。
- 最後才是「效能退化」類（latency、qps、response time、queue）。
6.3 Proxy / Active Check 特有的盲點：你要分清楚「端點問題」還是「回報路徑問題」
- 端點真的沒資料？（agent 掛了、key 失效）
- 端點有資料，但回報卡住？（Proxy queue、history sync）
因此建議你在 Proxy 上也監控這些：
- Proxy queue size / history sync 狀態
- Proxy 自身 CPU / I/O / DB（SQLite 檔案大小、寫入延遲）
- Proxy ↔ Server 網路延遲/丟包
7. 上線與驗收：逐步 rollout 的做法
- 先挑 5 台代表性主機（不同角色：DB/Web/一般主機/站點邊界）。
- 模板先上共用層，觀察 48 小時，修正誤報。
- 再逐步加入角色層模板（每次只加一層，容易定位噪音來源）。
- 告警動作（email/IM/工單）最後才開，避免一開始就被洗版。
驗收指標建議：
- 告警數量下降，但真正異常有被抓到（噪音下降、命中率上升）
- Proxy queue 不長期堆積（站點斷線可接受，但恢復後能追上）
- Zabbix Server poller / DB I/O 有明顯緩解
8. 常見問題排查清單
8.1 Active Check 沒資料
- 確認 host name 是否完全一致（Agent 的 Hostname vs 前台 host name）。
- 確認 Agent 能連到 Proxy 的 10051/tcp。
- 確認前台 host 的監控項目確實是「Zabbix agent (active)」。
- 查看 Agent log：是否拿得到 active check 清單。
8.2 Proxy queue 堆積很久
- Proxy 本身資源不足（I/O、CPU、磁碟滿、DB 過大）。
- Proxy ↔ Server 網路不穩（延遲、丟包、頻寬不足）。
- CacheSize 太小導致頻繁 flush/重試（需調大）。
8.3 告警太多、誤報多
- 把「單點判斷」改成「時間窗判斷」：min/max/avg。
- 加上依賴關係（上游斷線時抑制下游）。
- 把告警分級，並把低嚴重度告警先不要推送到即時通知。
FAQ
Q1：站點要用 Proxy 的 DB 用 SQLite 還是 PostgreSQL？
站點小（幾十到一兩百台）且你追求部署快、維護少：SQLite 通常很夠用。 若站點大、資料量高、或 Proxy 壓力長期偏高：用 PostgreSQL/MySQL 會更穩。
Q2：Active Check 一定比 Passive 好嗎？
不是絕對。Active 更適合「端點不可被連回」與「想把負載分散」的情境；Passive 則在內網穩定、網路拓樸單純時很直覺。 實務上常是混用：關鍵服務/跨網段端點用 Active，其餘用 Passive。
Q3：模板要不要「一台一套」客製？
不建議。模板的價值就是可重用與可維護。 若真的要客製，優先用：User macros（{$THRESHOLD}）、Host tags、或 Template inheritance（分層）。
你是用 Active、Passive，還是混用？Proxy 用 SQLite 還是 PostgreSQL？
若你願意貼一下你的規模（主機數、站點數、DB 類型、平均告警量），我可以幫你一起把模板分層與觸發條件做得更貼近你的實際狀況。
沒有留言: