說明：
因技術能力有限，本次只是記錄一下自己解決問題的過程，至於原理還需要繼續深入研究一下，請路過的看官不喜勿噴，當然，如有不妥之處還請不吝賜教。
入職接到的第一個任務：關注 Zabbix 的狀態！
很詫異，爲啥會有這樣的任務，原來就在不久前，Zabbix 出現頻繁的掛掉的情況。（em... 自己品！）話不多說，上乾貨！
背景
- 服務器：
- 系統：Centos 6.8
- 配置：12C 24G
- 數量：約500臺
- Zabbix
- 版本：4.2.1
- 模式：Zabbix-agent Active
- 監控項：30271
- 觸發器：13863
問題排查
htop查看系統負載：CPU 和 MEM 使用都不高，Tasks 很高 2000+；ss 或 netstat查看網絡請求狀態：正常ps aux查看任務詳情：發現有很多（1000+） discoverer、history、unreachable、poller、icmp、trapper 進程——大概確定 Tasks 很高的原因；- 雖然大概確定了爲什麼 Tasks 很高，但是並不能確定 Zabbix 爲什麼會掛掉！
- 接下來查看 zabbix 日誌：
- 發現比較多的慢日誌：
"delete from history_uint where itemid=115116 and clock<1645818652"； - 差資料，zabbix 相關參數：HousekeepingFrequency、MaxHousekeeperDelete
- 發現比較多的慢日誌：
本次排查並未定位到 Zabbix 具體爲什麼會頻繁的掛掉，不過也可以針對上面發現的情況優化一下！
原有配置（脫敏）
LogFile=/tmp/zabbix_server.log
LogFileSize=0
PidFile=/var/run/zabbix/zabbix_server.pid
SocketDir=/var/run/zabbix
DBHost=xxx.xxx.xxx.xxx
DBName=xxxx
DBUser=xxxx
DBPassword=xxxxxxxxxxxxxxxxxx
StartPollers=500
StartPollersUnreachable=100
StartTrappers=50
StartPingers=500
StartDiscoverers=50
JavaGateway=10.xxx.xxx.xxx
JavaGatewayPort=10052
StartJavaPollers=5
VMwareCacheSize=4M
SNMPTrapperFile=/var/log/snmptrap/snmptrap.log
HousekeepingFrequency=1
MaxHousekeeperDelete=50000
CacheSize=1024M
CacheUpdateFrequency=300
StartDBSyncers=20
HistoryCacheSize=1024M
HistoryCacheSize=6M
HistoryIndexCacheSize=8M
TrendCacheSize=8M
ValueCacheSize=1024M
Timeout=30
TrapperTimeout=120
UnreachablePeriod=60
UnavailableDelay=45
UnreachableDelay=15
AlertScriptsPath=/usr/lib/zabbix/alertscripts
ExternalScripts=/usr/lib/zabbix/externalscripts
LogSlowQueries=3000
StatsAllowedIP=xxx.xxx.xxx.xxx
優化後配置（脫敏）
LogFile=/tmp/zabbix_server.log
LogFileSize=0
PidFile=/var/run/zabbix/zabbix_server.pid
SocketDir=/var/run/zabbix
DBHost=xxx.xxx.xxx.xxx
DBName=xxxx
DBUser=xxxx
DBPassword=xxxxxxxxxxxxxxxxxx
StartPollers=100
StartPollersUnreachable=20
StartTrappers=250
StartPingers=250
StartDiscoverers=20
JavaGateway=xxx.xxx.xx.xxx
JavaGatewayPort=10052
StartJavaPollers=5
VMwareCacheSize=8M
SNMPTrapperFile=/var/log/snmptrap/snmptrap.log
HousekeepingFrequency=1
MaxHousekeeperDelete=50000
CacheSize=512M
CacheUpdateFrequency=300
StartDBSyncers=20
HistoryCacheSize=64M
HistoryIndexCacheSize=8M
TrendCacheSize=256M
ValueCacheSize=512M
Timeout=5
TrapperTimeout=120
UnreachablePeriod=60
UnavailableDelay=30
UnreachableDelay=30
AlertScriptsPath=/usr/lib/zabbix/alertscripts
ExternalScripts=/usr/lib/zabbix/externalscripts
LogSlowQueries=3000
StatsAllowedIP=xxx.xxx.xxx.xxx
變更項
| 變更前 | 變更後 | 含義 |
|---|---|---|
| StartPollers=500 | StartPollers=100 | 輪詢進程的初始實例數量。負責數據的聚合和計算。（0-1000） |
| StartPollersUnreachable=100 | StartPollersUnreachable=20 | 不可達主機 (包括IPMI 和 Java)的輪詢進程的初始實例數量，建議取值 （StartPollers x 20%）。（0-1000） |
| StartTrappers=50 | StartTrappers=250 | Trapper 進程的初始實例數量。 Trapper接收來自Zabbix發送者、主動agent和主動proxies的數據。（0-1000） |
| StartPingers=500 | StartPingers=100 | ICMP pingers進程的初始實例數量。（0-1000） |
| StartDiscoverers=50 | StartDiscoverers=50 | 服務發現進程的初始實例數量。 （0-250） |
| VMwareCacheSize=4M | VMwareCacheSize=4M | 儲 VMware 數據的緩存大小，只有 VMware 收集器啓用時才生效。 （256K-2G） |
| CacheSize=1024M | CacheSize=32M | 緩存大小, 單位爲字節。用於存儲主機、監控項、觸發器等數據的共享內存大小。 （128K-8G） |
| HistoryCacheSize=6M | HistoryCacheSize=64M | 歷史緩存數據大小, 單位爲字節，（可以看圖盤 Zabbix cache usage, % free 進行調整）。 （128K-2G） |
| HistoryIndexCacheSize=24M | HistoryIndexCacheSize=8M | 歷史索引緩存大小, 單位爲字節。緩存一個item大概需要大小爲100字節的空間。（128K-2G）按照100000個監控項來算：100000*100/1024/1024=9.6M |
| TrendCacheSize=8M | TrendCacheSize=256M | 用於存儲趨勢數據的共享內存大小。 (128K-2G) |
| ValueCacheSize=1024M | ValueCacheSize=512M | 歷史數據緩存大小, 單位爲字節。 當緩存大小超過共享內存時，每5分鐘會向服務器日誌寫入一條警告信息。（128K-64G） |
| Timeout=30 | Timeout=5 | agent, SNMP設備或外部檢查的超時時長(單位爲秒)。(1-30) |
| UnavailableDelay=45 | UnavailableDelay=30 | 在資源不可用期間，Zabbix多少秒檢查一次該資源是否可用(單位爲秒)。(1-3600) |
| UnreachableDelay=15 | UnreachableDelay=30 | 在資源不可達期間 ，Zabbix多少秒檢查一次該資源是否可達(單位爲秒)。(1-3600) |
優化結果 & 思考
經過上面配置的調整，zabbix 頻繁掛掉的問題竟然順便被解決了（歪打正着）。
說一下自己的想法：
- StartPollers：當前監控 agent 約500，Pollers 是輪訓的機制，啓動 100 個 poller，平均每個 poller 負責 5 個 agent 數據的計算和聚合，30000 個監控項，每分鐘採集一次，每個 poller 每分鐘處理約 300 條數據；
- StartPollersUnreachable：分配 20% 的 poller 對不可達的 agent 進行處理；
- StartTrappers：250 個 trapper 接收 500 個 agent 的請求，輪訓機制，每個 trapper QPS 約 2；
- StartPingers：ping 檢測，同理每分鐘每個 pinger 負責 5 個 agent；
- CacheSize 相關：查看 zabbi-server 自身監控指標 “Zabbix cache usage, % free” 逐步優化；
- HistoryIndexCacheSize：緩存一個item大概需要大小爲100字節的空間，根據現有 item 計算，留出一定冗餘量；
- 關於時間的幾個參數：Timeout、UnavailableDelay、UnreachableDelay
- Timeout：選擇 5s，都是內網資源，減少異常情況等待時間，及時釋放資源，有異常(Unreachable)會再次嘗試；
- UnavailableDelay、UnreachableDelay：選擇 30 秒，原因是每個監控項目前設置的是 UnreachablePeriod=60s/次 檢測頻率，如果 unavailable 或 unreachable ，等待 30 秒進行第二次嘗試，看公司業務故障容忍率，相信大部分業務故障 1 分鐘還是可以接受的吧。
以上是基於部分數據和文檔進行的參數調整，因爲對 Zabbix 瞭解並不多，其中有不明緣由甚至是不合理的地方，還請路過的大神多多指教！