一、 概述
為了提高應對突發事件的處置能力，在出現故障的情況下，使用該手冊中常見問題作參考能快速排出監控系統出現的故障，恢復監控系統正常運行。實現即時發現問題，快速處理問題，滿足監控系統在突發情況下保障和恢復工作機制。
二、 適用范圍
本手冊適用於zabbix server，proxy，agent在使用和運行過程中出現的異常問題，對常見問題提供解決方法參考。
三、 監控系統常見問題
三.1 Zabbix server
三.1.1 WEB頁面無法登陸
問題描述：
WEB頁面（http://40.2.214.18:8000/zabbix）無法登陸
解決方法：
使用zabbix用戶操作：
查看浮動IP地址是否在可用狀態：ping 40.2.214.18
如不通：在主服務器端執行：/usr/bin/vrrpd –I bond0 –n –v 54 –p 100 40.2.214.18
使用root用戶操作：
查看HTTP進程是否運行：ps –ef | grep httpd
如未運行：執行 /usr/local/apache2/bin/httpd –k start啟動HTTP進程
查看HTTP端口8000是否在監聽狀態：netstat –tulnp | grep 8000
如未在監聽狀態重啟HTTP進程
使用zabbix用戶操作：
查看zabbix server 進程是否運行：ps –ef | grep zabbix_server
如未運行：執行/usr/local/zabbix/sbin/zabbix_server
三.1.2 WEB頁面無法刷新
問題描述：
WEB頁面（http://40.2.214.18:8000/zabbix）選項無法刷新
解決方法：
使用zabbix用戶操作：
在zabbix server（主）端檢查MySQL的IP地址連通性：ping 40.2.215.25
如不通請在MySQL檢查網絡或在MySQL端檢查VIP
在zabbix server（主）端檢查MySQL能否被訪問：mysql –uzbserver_rw –pRRlwaKzp1SJS5s9T33up –P3358 –h40.2.215.25
如數據庫沒有問題查看zabbix_server進程是否正常運行：ps –ef | grep zabbix_server如未運行：執行/usr/local/zabbix/sbin/zabbix_server啟動zabbix server
三.1.3 Web界面出現Allowed memory exhausted
問題描述：
zabbix server web頁面ReportàNotifications項出現Allowed memory exhausted告警提示
解決方法：
需要將zabbix server主機上PHP配置文件相應內存配置調整，即/usr/local/php/etc/php.ini文件中memory_limit值進行增加。
三.1.4 監控項無數據
問題描述：
監控項沒有監控數據，也沒有任何錯誤信息
解決方法：
使用zabbix用戶操作：
在zabbix_server web頁面MonitoringàLatest dateà具體host 監控項都無最新數據變化：
1、登陸該host機器檢查/home/zabbix/zabbix-agent/etc/zabbix_agentd.conf中Hostname對應的值是否與Web頁面相應的host名稱一致，不一致修改成一致。
2、登陸該host機器重啟zabbix_agent,命令： /home/zabbix/zabbix-agent/zabbix_agentd restart
3、在該機器上檢查zabbix_agent進程：ps –ef | grep zabbix_agent 是否正常運行
三.1.5 Trigger告警未發郵件
問題描述：
出現監控項告警未發告警信息到告警平台
解決方法：
1、 zabbix server Web頁面Reports àAction log 界面查看是否有該告警觸發action日志，
2、 如有觸發action日志，查看zabbix server中告警日志 /tmp/具體日期zabbixAlertNew.log(如：2018-01-05zabbixAlertNew.log)是否有相應的日志。如有聯系告警平台檢查
3、 如無觸發action日志，Web頁面ConfigurationàActions 查看 SendEventNew 和sendevent狀態是否是Enabled，如不是請點擊Status列對應部分啟動。
三.1.6 主機40.32.67.1某個trigger頻繁觸發event再close再觸發
現象描述：收到大量告警，觀察該主機的events列表發現某個事件以兩分鍾為周期觸發然后再close，然后再觸發。並且該告警相關的監控項數據實際采集頻率與所設置的時間間隔不一致。
環境：zabbix server 3.0 + zabbix agent 3.0 + AIX
問題分析：
zabbix的trigger告警都是依賴於數據的，只要zabbix server收到數據就會對trigger進行重新計算並決定是否觸發event，因此首先檢查數據的內容和獲取情況。找到trigger所依賴的item，查看其最近一段時間的數據，觀察其采集數據的時間戳，發現相鄰的兩次值的時間間隔在1分鍾左右（但是並不是准確的1分鍾），而該監控項設置的采集間隔為2分鍾。正常情況下，單個agent會以固定的周期發送數據到server端。這種時間間隔的不一致，表明可能存在不止一個agent在發送該監控項的數據（zabbix server並不會主動驗證數據的來源ip是否合法，它只考慮agent hostname是否相符，當兩個不同ip的host以同樣的agent hostname發送數據時，zabbix server會照單全收，同時接受兩份數據，這兩份數據都會用於trigger的計算）。
對於如何找到具有同樣的agent hostname的另一個host的問題，請見下面的解決方法。
解決方法：
l 登錄zabbix原生頁面，查看告警主機的system.hostname監控項的值，會發現交叉出現兩個名稱，其中有一個名稱與當前host name不一致，這個名稱就是有問題的主機。
l 定位了問題主機以后，登錄該問題主機，查看其agent配置文件，會發現配置文件中的agent hostname是錯誤的，將其修改為正確的值，然后重啟agent即可解決。
l 需要注意的是：這一問題能夠暴露出來是因為問題主機發送的數據觸發了告警，如果問題主機發送的數據不能觸發告警，則有可能無法暴露出問題。需要通過數據獲取的頻率或者通過system.hostname監控項的值來檢查判斷是否存在問題。
三.1.7 監控項最新數據無趨勢圖
問題描述：查看某主機數值型監控項last data時，value處有最新數據
，但Graph沒有展示趨勢圖，具體選擇持續時間長的有趨勢圖展示，時間短的沒有
分析：zabbix4.0歷史數據和趨勢數據設置若無單位，默認按秒存儲，歷史數據保存時間為1小時到25年，趨勢數據保存時間為1天到25年，支持時間后綴，例如：h、d
解決方法：查看監控項歷史數據和趨勢數據保留時間，建議以d為單位，修改全部監控項的歷史數據和趨勢數據的sql腳本路徑為40.2.214.17：/home/zabbix/scripts/mysql_updatehistory.sh，查看items表中history和trends字段設置的時間是否包含單位，如：
update zabbixser.items set history=’1d’;
update zabbixser.items set trends=’30d’;
然后執行腳本即可修改成功，監控項修改歷史數據和趨勢數據保留時間后，即可正常查看任意時間段的趨勢圖。
三.2 Zabbix proxy
三.2.1 Proxy進程異常
問題描述：
Zabbix Proxy進行啟動異常，日志顯示無法連接數據庫
解決方法：
使用MySQL用戶操作
檢查zabbix_proxy MySQL數據庫進程是否異常：ps –ef | grep mysql
如無進程可執行啟動：/bin/sh /mysql/myinst1/service/bin/mysql_safe –defaults-file=/mysqldate/myinst1/etc/my.cnf
如無法啟動查看/mysqldate/myinst1/log/error.log記錄，根據報錯排除故障。
使用MySQL用戶操作：
檢查 zabbix_proxy端MySQL 數據庫是否可訪問：mysql -uzabbix -pjfldkjoi56k –P3306 –h127.0.0.1
三.2.2 Proxy無法收到server發送配置數據
問題描述：
Proxy正常工作會定時接受server發送的配置數據，Proxy日志顯示無法收到配置數據
解決方法：
1、 檢查配置文件/home/zabbix/zabbix3.0.6/etc/zabbix_proxy.conf 中Server對應的值是否是40.2.214.18如不是請更正。
2、 檢查配置文件/home/zabbix/zabbix3.0.6/etc/zabbix_proxy.conf中Hostname對應的值是否是與zabbix server Web界面配置的proxies名稱（AdministrationàProxies）是否一致，不一致請修改成一致。
3、 查看proxy日志（位於/tmp/zabbix_proxy.log）具體報錯信息，根據信息排除故障。
4、 修改完后重啟proxy進程。
3.2.3某個值的類型不可用
問題描述：
Value "XXX" of type "XXX" is not suitable for value type "XXXX" 或者Received value xxxx is not suitable for value type [xxxx] 此類報錯可能出現在所有監控類型，多是監控項中的信息類型配置出現錯誤。
解決辦法：
登陸zabbix web頁面修改監控項中的信息類型
3.2.4 某個proxy突然出現unreachable poller進程繁忙程度過高的告警
問題描述：收到某個proxy的告警，unreachable poller進程繁忙度超過90%。
環境：zabbix server3.0 + zabbix proxy3.0
問題分析：
unreachable poller進程負責對處於unreachable和unavailable狀態的主機進行檢查。當處於unreachable和unavailable狀態的主機數量較大時，就會導致該進程繁忙程度增加。在這種情況下，就需要定位到時哪些主機處於unreachable或者unavailable狀態。
解決方法：
登錄到告警的proxy，執行命令tail -f /tmp/zabbix_proxy.log|grep unavailable可以看到有哪些主機是unavailable狀態；
執行命令tail -f /tmp/zabbix_proxy.log|grep‘network error’，可以看到有哪些主機處於unreachable狀態以及造成該主機unreachable的item key。
定位到主機和item key以后，就可以查看問題主機有哪些監控項出現報錯。
在本次事件中，是因為該proxy下新加了一批主機，這些主機存在一些passive agent check，因為passive agent端口被禁用了，所以出現無法連接的情況，導致unreachable。
三.3 Zabbix agent
三.3.1 Zabbix_agent監控項無監控數據檢查
問題描述：
監控項無監控數據
解決方法：
使用zabbix用戶操作
在zabbix server端執行：zabbix_get –s hostname –P 10050 –k “key” （zabbix_get默認位於：/home/zabbix/zabbix-agent/bin/）是否能獲取到監控數據
三.3.2 Trapper 監控項無監控數據檢查
問題描述：
Trapper監控項無監控數據
解決方法：
使用zabbix用戶操作
在被監控主機端執行：zabbix_sender –z server –p 10051 –s host –k key –o 監控數據在zabbix server （zabbix_sender默認位於：/home/zabbix/zabbix-agent/bin/）端檢查是否能接受到測試數據。
如果server能收到數據,則問題出在被監控主機監控腳本上,聯系相關監控項維護人員處理。如果收不到數據，則需排查網絡或server端trapper服務問題。
三.3.3 Host not found處理
問題描述：
在zabbix_server.log和zabbix_proxy.log中 出現某host not found 信息
解決方法：
使用zabbix用戶操作
1、檢查該host的配置文件（默認：/home/zabbix/zabbix-agent/etc/zabbi_agentd.conf）配置hostname與zabbix_server web頁面配置的hostname名字不相同，確保兩者相同。
2、檢查該host與proxy的網絡是否能連通。
三.3.4 監控項not support狀態
問題描述：
WEB界面主機監控項顯示not support, 表示監控項可以收到監控數據，但數據異常。
解決方法：
在zabbix web界面
1、 web界面相應監控項配置數據類型是否與實際返回數據類型一致。
2、 檢查配置的KEY是否與定義的key一致
Zabbix agent主機端
3、 檢查相應監控項對應腳本返回結果是否有異常。
4、 檢查相應腳本是否有執行權限，自定義KEY是否正確。
三.3.5 監控項nodata
問題描述：
WEB界面主機監控項沒有數據同時也沒not support（如配置了nodata的Trigger會觸發告警），表示監控項無法收到監控數據。
解決方法：
1、 檢查被監控主機相應監控項對應腳本執行是否有異常（nodata一般意味着相關key的數據沒有任何返回，腳本執行異常的概率最大）。
2、 依次檢查Proxy Server相關poller /trapper /snmp等服務是否正常。
三.3.6 監控項延遲生效問題
1、檢查Proxy端配置文件
ConfigFrequency
2、檢查agent端配置文件
RefreshActiveChecks
主動式proxy+主動式監控項
最大延遲時間=（proxy的ConfigFrequency配置）+（agent的RefreshActiveChecks
）
被動式監控項，沒有proxy：
生效延遲時間：無，實時生效
Zabbix主動式監控項，沒有proxy:
最大延遲時間=（agent的RefreshActiveChecks）
被動式proxy+被動式監控項：
最大延遲時間=（Server的ProxyConfigFrequency配置）
被動式proxy+主動式監控項：
最大延遲時間=（Server的ProxyConfigFrequency配置）+（agent的RefreshActiveChecks
）
主動式proxy+被動式監控項：
最大延遲時間=（Server的ProxyConfigFrequency配置）
三.3.7 無法檢查到腳本文件
問題描述：
/home/zabbix/zabbix-agent/etc/scripts/a.sh: [2] No such file or directory
解決辦法：
檢查文件路徑，或者檢查對應server/proxy的ExternalScripts= 配置項
三.3.8 不支持的監控項的key值
問題描述：
Unsupported item key/ZBX_NOTSUPPORTED/Not supported by Zabbix Agent/Internal check is not supported。出現場景：所有監控類型
解決辦法：
非自定義監控項
官網確認當前版本key_值是否支持，確認agent版本，注意拼寫錯誤。注意key_值與對應的監控類型是否匹配
自定義監控項
確認自定義監控項配置，agent的UserParameter= 是否與頁面一致
三.3.9 腳本執行超時
問題描述：
Timeout was reached/Timeout while executing a shell script
解決辦法：
Zabbix客戶端(主動式)
Zabbix_agent的配置項，Time_out=(默認3秒)
Vmware監控
對應Zabbix_server/Zabbix_proxy 的配置項VMwareTimeout
SNMP TRAP/Zabbix采集器
對應Zabbix_server/Zabbix_proxy 的配置項， TrapperTimeout
其他
對應Zabbix_server/Zabbix_proxy 的配置項 Timeout
自定義監控項
嘗試優化腳本效率
三.3.10 無效的參數
問題描述：
Invalid % parameter案例：Invalid second parameter./Invalid first parameter.
解決方法：
官網確認該監控項的參數規范，確認server版本
錯誤案例：
比如 system.cpu.util[,idle]，
如果填system.cpu.util[,abcde],就會報該類錯誤
三.3.11 無法獲取一個文件的信息：沒有這個文件或者目錄
問題描述：
Cannot obtain information for file "%": [2] No such file or directory案例：
Cannot obtain information for file "/tmp/test.log": [2] No such file or directory
解決方法：
檢查日志文件存在性及權限
三.3.12 沒有一個進程
問題描述：
No "%" processes started案例： No "vmware collector" processes started出現場景：Zabbix內部監控
解決方法：
在對應的server/proxy上開啟對應的配置，或者屏蔽監控項
三.3.13 zabbix-agent啟動報錯
問題描述：
Windos主機：[[40.2.212.198]:10051]由於系統緩沖區不足或隊列已滿，不能執行套接字
解決方法：
此問題是windows主機的連接數占滿，無法建立新的連接。可重啟agent端服務器釋放連接，並重新啟動zabbix-agent。
三.3.14 zabbix-agent啟動報錯
問題描述：
45647：20160808：220507.717 no active checks on server [192.168.3.108：10051]：host [192.168.3.108] not found
解決方法：
此問題是zabbix-agent和zabbix-server配置了相同的hostname，可登陸agent主機將其主機名修改掉
三.3.15 Active agent監控項數據采集間隔變長
現象描述：某些host（40.40.0.1/2/3）的一些active agent監控項（UserParameter）采值間隔設置的是2分鍾，但是實際獲取到值的間隔卻為10分鍾左右，導致誤告警
環境：zabbix server 3.0+zabbix agent3.0+AIX
問題分析：
active agent監控項由agent調用腳本或者系統命令完成原始數據采集，然后通過TCP連接傳輸到proxy端，再由proxy傳到server端。出現采值間隔時間過長，可能是因為agent原始數據采集的間隔變長了，或者是數據傳輸過程變慢了。一般來說，數據傳輸變慢不會只影響zabbix agent，還會影響到系統上的其他服務。在這一事例中，並沒有人反映其他服務出現異常，因此初步判斷是zabbix agent采集原始數據的間隔變長了。
通過分析zabbix agent源碼，發現Zabbix agent的原始數據采集過程是：由zabbix_agentd服務進程調用zbx_popen函數，fork一個新的進程來執行所需要的命令，並等待返回結果（同步調用，而非異步）。需要注意的是，所有active agent監控項由單個zabbix_agentd進程負責，即采值命令都是順序地串行執行，因此如果某些監控項的命令執行時間過長就可能導致其他命令執行被推遲。假設一個host有60個監控項，每個監控項的采集間隔為60秒，則意味着平均每個監控項命令可用的執行時間為1秒，如果某一個監控項命令執行時間超過20秒，則意味着剩余的59個監控項需要在40秒內執行完畢，才能夠保證准時獲取到數據。如果不能在所需要的時間內執行完畢，zabbix agent並不會跳過一些監控項，而是繼續按順序執行，也就意味着采值間隔變長。
為了定位具體是哪些監控項導致間隔變長，我們開啟了zabbix agent的debug模式（配置文件中的DebugLevel參數改為4並重啟zabbix_agentd服務，或者執行命令./zabbix_agentd -R log_level_increase=4），然后跟蹤日志中每一次zbx_popen函數的調用以及其執行的命令。通過兩次調用之間的間隔可以計算出單次執行的時間長度。
通過分析日志，我們發現在所有600多個監控項中有30個監控項平均執行時間長度在10秒左右。為了解決這一問題，我們將這30個監控項的采集間隔調整到10分鍾一次，意味着每分鍾只需要對這30個監控項中的3個執行命令。這樣一來就可以有足夠的時間來完成所有的數據采集。
下圖為zbx_execute函數源碼截圖，該函數用於處理自定義監控項的命令，可以看到它進一步調用了zbx_popen函數來處理。
以下為zbx_popen函數截圖，可以看到它會記錄debug級別的日志，記錄內容包括函數名和所執行的command。
說明：該分析結果僅適用於用戶自定義的agent監控項，也就是使用UserParemeter設置的監控項。
解決方法：
l 首先，開啟zabbix agent端的debug模式。修改配置文件中的DebugLevel參數為4並重啟zabbix_agentd，或者執行命令：/home/zabbix/zabbix-agent/sbin/zabbix_agentd -R log_level_increase=4
l 然后，執行命令: tail -f /tmp/zabbix_agentd.log | grep zbx_popen 可以觀察到每次調用的命令內容及其調用時間，根據兩次調用之間的時間差可以計算出執行時間。
l 然后，對於執行時間明顯過長的，首先考慮優化命令執行的效率，壓縮執行時間。如果不能壓縮執行時間，可以考慮調大相應監控項的采集間隔時間，調整的目標值根據需要進行計算，需要保證zabbix agent有足夠的時間來執行所有item的采值命令。
三.3.16 Zabbix_agent心跳告警
現象描述：某一台主機有監控數據，但是采集數據時間跟當前時間不一致，導致反復出現zabbix_agent心跳告警
現象及解決方式：（1）心跳告警30秒出現一次且一直未恢復，可能是主機端有問題，配合查看有無ping監控告警確認是否是主機掛掉導致
（2）心跳告警及心跳恢復告警反復出現，可能是主機端數據上送延遲導致（大多發生在windows主機上），使用自動化重啟zabbix_agent查看數據采集時間是否同步成功。
（3）上述現象的另一種原因，如果重啟zabbix_agent后發現數據采集時間還未同步成功，說明主機的系統時間跟當前時間不同步，可適當調大心跳告警的默認閾值解決。
三.4 其他
3.4.1 監控部署所使用的AIX的tar包，用ftp傳輸以后再解壓時出現異常
現象描述：zabbix部署時所使用的tar包，使用ftp傳輸以后再解壓，有時候出現解壓以后缺少文件的情況。
環境：ftp+AIX/UNIX/LINUX
問題分析：
使用ftp在windows和unix/linux系統之間傳輸文件的過程中有可能出現內容的變化。因為ftp傳輸模式分為ascii和binary兩種模式，ascii模式下傳輸會對檢測到的換行符進行修改以適應目的系統，binary模式則是原樣傳輸不進行修改。
解決方法：將所有ftp的傳輸模式修改為binary模式。