基礎篇
第1章 Zabbix監控系統簡介
1.1 Zabbix是什么
Zabbix是什么？可以用最簡短的一句話概括——Zabbix是一種企業級的分布式開源監控解決方案。
我想這句話對于熟悉Zabbix的人來說應該不會陌生，可能我們都知道分布式、開源、監控解決方案，那么這里的企業級又具體代表什么含義呢？對于一套成熟的企業級的監控解決方案，需要面對幾個問題，如監控接入的設備越來越多，需要分布式監控、多分支監控及防火墻后端的監控，需要支持高可用、多主機、無單點故障，安全加固，端對端加密，專業認證等。
很榮幸，在2020年，Zabbix獲評Gartner ITIM基礎架構監控工具第一名，并且在2021年上半年，在IT Central Station的IT基礎監控（IT Infrastructure Monitoring）、網絡監控（Network Monitoring）、服務器監控（Server Monitoring）、云監控（Cloud Monitoring）軟件榜單中，Zabbix均排名第一。
開發Zabbix的初衷是開發一款卓越的監控解決方案，并提供及時的響應和可靠的支持，以解決任何有關其安裝、操作和使用的問題。
1.2 Zabbix的誕生
Zabbix是由Alexei Vladishev創建的，根據Alexei先生在被采訪時的描述，那時他只是一名負責AIX和HP-UX的系統管理員，本想著如何通過自動化來簡化自己的日常工作，開始編寫各種工具。最初Zabbix只是一堆使用crontab運行的Perl腳本，后來他決定使用新的架構和技術來重寫，這也變成了他的業余愛好項目，他本人對編程非常感興趣，歷經4年的開發，他把這款軟件命名為Zabbix，并以開源軟件的形式發布。因此，Zabbix的第一個版本于2001年發布。
Zabbix由Zabbix SIA公司持續進行開發、更新與維護，同時為用戶提供Zabbix培訓、Zabbix認證及技術支持服務。
Zabbix遵循了GNU GPL（GNU General Public License，GNU通用公共許可證）V2協議設計和編碼，這就意味著Zabbix的源代碼是免費且完全公開的，可以供任何用戶下載使用。
Zabbix采用All in One的監控解決方案，并且Zabbix并不是為特定行業、特定客戶創建的一款產品，而是將Zabbix的可用范圍持續不斷擴大。從最初的傳統IT基礎監控到物聯網設備監控，從數據采集到屏幕數據可視化，從事件告警到趨勢預測等，Zabbix自始至終都在聽取用戶的反饋，并不斷努力推進Zabbix的多樣性。由于Zabbix的靈活性和極強的可擴展性，以及極低的維護成本，Zabbix常常成為大型企業首選的監控解決方案。
1.3 Zabbix的功能
在談論Zabbix的功能之前，我想請教讀者幾個問題：您之前是否使用過其他監控軟件？是什么促使您愿意選擇學習Zabbix的呢？Zabbix與市面上流行的監控軟件之間有哪些區別？我希望您能夠了解的是，Zabbix不僅是一款監控軟件，還是一套完善的、開箱即用的監控解決方案，我認為它的使用方式和監控理念對IT監控進行了一次系統的梳理和革新。
因為我個人之前也經歷過從自己寫各種監控腳本到使用各種監控軟件的過程。當我第一次使用Zabbix時，就被它的功能和處理邏輯吸引了，如自動生成監控項、模板的概念、基于界面的人性化操作，鼠標操作就可以完成配置、對外提供完善的API、各種開箱即用的功能等。
我再也不需要為維護某監控軟件的幾千行的配置文件而發愁，Zabbix的各種觸發器函數可以讓我更精準地判斷系統故障，避免“狼來了”的效應。
接下來，我將簡單、快速地介紹一下Zabbix具體有哪些功能。
1.3.1 數據采集
既然是講監控，不得不說的Zabbix的第一個點就是數據采集，那么Zabbix的數據采集都涵蓋了哪些呢？
這里先簡單地展示一臺服務器的Zabbix agent可用性狀態（見圖1-1）及CPU性能監控數據（見圖1-2）。以Zabbix agent存活狀態為依據判斷服務器是否在線、是否可用。可能會有人說：“Zabbix agent是否存活不能作為服務器是否存活的標準。例如，Zabbix agent停掉了，但并不代表服務器出現故障。”這就要看每個人的評判標準了，可以基于服務器是否能ping通，或者服務器某個端口是否存活為條件進行判斷。但是我認為的標準就是我的服務器Zabbix agent必須在線，服務器既然存活，就必須要納管到監控平臺，這就是一條規范或標準。
圖1-1
圖1-2
通過圖1-1和圖1-2可以看到，通過Zabbix，可以全方位地掌握自己的服務器的各項監控指標及狀態。
對于以上的監控數據，可以通過在操作系統上部署Zabbix agent來獲取，那如果監控對象是一臺交換機，或者是一臺路由器，又或者是一臺UPS，該怎么辦呢？Zabbix除了提供在操作系統上部署的采集客戶端Zabbix agent，還支持其他的采集方式，如SNMP（包括主動輪詢和被動捕獲）數據采集，只要為設備配置好SNMP功能，就可以采集基于SNMP的監控數據，不僅如此，Zabbix還提供了更多的數據采集方式，如IPMI、JMX、VMware等。
如果這些都不是我們想要的采集方式，那么Zabbix還可以自定義數據采集方式，我們可以通過自己擅長的編程語言，如Bash Shell、Python、Perl等來編寫數據采集的腳本，或者通過模塊進行監控數據的采集。
對于監控項的配置，我們可以靈活地定義數據采集間隔，可以設置1秒鐘1次，或者1小時1次。對于一些核心、重要的監控數據，可以采用秒級監控；對于一些非核心監控數據，就可以稍微延長采集間隔。后面會對Zabbix內置的每種監控類型做更詳細的描述。
1.3.2 靈活的閾值定義
現在我們已經采集到了監控數據，那可以用這些監控數據做什么呢？通過監控數據配置告警是運維工作必不可少的一項需求，Zabbix可以通過觸發器對采集值與參考值進行判斷，從而實現告警。例如，CPU負載大于90%就告警，這是一個非常簡單的故障場景（大于90%就告警，小于90%就恢復），這樣就會出現一個問題，即如果CPU負載一直在90%左右浮動，就會出現反復告警的情況，這種場景放在以前就會產生很多通知，因此，Zabbix提供了一種更為聰明的判斷方法。例如，告警條件為大于90%，但是Zabbix可以設置恢復條件為小于30%，這樣就避免了反復告警的情況。另外，我們還可以設置凌晨1點到早上7點不告警。了解觸發器的各種函數的功能，可以組合出更符合自己需求的表達式。
1.3.3 高度可配置化的告警
接下來，我們通過Zabbix提供的觸發器判斷是否發生了故障，如果發生故障，就對這個故障進行一系列的操作。例如，指定遞增計劃告警，在告警不同階段通知不同的接收者，通過媒介配置自定義發送告警內容通知（如常用的郵件、短信、微信、釘釘甚至電話通知等）。
1.3.4 實時圖形
對于監控數據的展示，Zabbix通過使用內置的圖形功能，可以將監控數據繪制成圖形，如圖1-3所示，任意展示不同時間區間內的數據趨勢，如5分鐘、15分鐘、30分鐘、1小時甚至幾天或幾個月的數據。
圖1-3
1.3.5 Web監控功能
Zabbix的Web監控功能不僅可以檢測HTTP請求的響應代碼及過濾頁面上的某些特殊的關鍵字符串，還可以追蹤模擬鼠標在Web網站上的點擊操作，以檢查Web網站的功能。
1.3.6 豐富的可視化
前面提到的實時圖形展示只是針對單個監控指標的圖形生成的，在Zabbix中，也可以創建將多個監控值組合到單個視圖中的自定義圖形（見圖1-4），還包括網絡的拓撲圖、自定義數據聚合圖、幻燈片演示圖、報表視圖、業務視圖、可鉆取視圖。
圖1-4
1.3.7 歷史數據存儲
Zabbix的監控數據保存在數據庫當中，這樣我們就可以隨時抽取歷史數據，而且Zabbix內置了數據管理機制，我們可以隨意自定義各種歷史數據的保存時間，Zabbix將依據配置的保存時間清理舊數據。
1.3.8 配置簡單
Zabbix監控項以模板為集合，模板采用模塊化的方式管理，如模板可以分為Cpu、Mem、Disk，如果只想監控CPU，那么只需插入Cpu模板即可，在Web界面添加監控設備為主機并將主機添加到數據庫中后，Zabbix agent就會采集主機數據用于監控，并且監控模板可以隨意插拔，這一切只需用鼠標操作即可。
1.3.9 模板套用
剛才講到了模板，模板之間也可以互相關聯。例如，現在有一個OS模板，接下來在OS模板當中關聯了Cpu、Mem、Disk 3種模板，關聯后，OS模板就繼承了上述3種模板的監控項目，當將OS模板插入監控主機后，主機就會自動繼承Cpu、Mem、Disk 3種模板的監控項目。
1.3.10 自動發現
我們在使用監控軟件時，最頭疼的莫過于添加監控設備，面對數量日趨龐大的服務器、網絡設備，作為管理員，不可能一臺一臺地手動把它們添加至監控平臺，而且人工操作會出現錯監、漏監等情況。Zabbix的Zabbix agent可以在部署完成并啟動后，根據配置自動注冊至監控平臺，還可以根據配置標識自動劃分至對應的業務組中，并自動添加所對應的監控模板；至于其他設備，也可以基于其他判斷條件，如通過SNMP，或者通過網絡掃描獲取設備的特定描述信息及標識，自動添加至Zabbix監控平臺。
對于單臺設備的監控項的生成，也可以采用自動的方式。例如，每臺服務器的磁盤分區可能不盡相同，那么通過低級發現功能，可以基于自身的磁盤分區生成對應的監控項目，如圖1-5所示；或者交換機有不同個數的網絡接口，通過低級發現功能，也可以生成不同端口的監控。這樣就省去了大量人工操作，做到了真正的自動化。
圖1-5
1.3.11 統一Web管理界面
Zabbix基礎PHP提供了一套Web前端管理界面，這樣我們就可以從任意地方訪問監控平臺，并且管理界面可以隨個人喜好進行定制。另外，對于前端所有的操作，都會有審計日志進行記錄，確保操作可追溯。
1.3.12 Zabbix API
Zabbix本身提供了完備的API，可用于批量操作、第三方軟件集成和其他用途等。尤其重要的是，Zabbix提供了詳細的API調用文檔，方便開發者查詢。
1.3.13 權限管理系統
對于一個完善的監控平臺，用戶權限劃分尤為重要，Zabbix提供了顆粒化的權限分配，可以為不同用戶分配不同監控視圖的訪問權限。
1.3.14 Zabbix agent
Zabbix agent主要部署于被監控對象上，幾乎可以部署在任何操作系統上，包括Linux、Windows、UNIX等。
1.3.15 二進制的程序
為了更好地提高性能，更少地占用資源，Zabbix采用C語言編寫，方便移植。
1.3.16 適應更復雜的環境
當監控網絡跨防火墻、跨數據中心的時候，通過Zabbix proxy進行數據采集，可以輕松實現分布式遠程監控。
1.4 Zabbix組件介紹
Zabbix中包含很多組件，本節將全面解釋Zabbix中各組件的功能。通過這些組件，可以了解Zabbix的監控思想，特別是Zabbix中的重要理念。
對Zabbix組件有基本的了解，將會了解本書中的其他內容的背景，對將來深入學習其技術細節會有很大的幫助。
1.Zabbix server
Zabbix server是Zabbix的核心處理程序，主要負責數據的主動輪詢與被動接收、觸發器的條件判斷、用戶通知等。它是Zabbix agent和Zabbix proxy報告系統可用性與完整性數據的核心組件。另外，還可以通過Zabbix server使用簡單的服務檢查來遠程檢查網絡服務（如Web服務器或郵件服務器）。
Zabbix server是所有配置、數據統計和數據操作的核心處理程序，也是Zabbix監控系統的告警中心。當監控系統出現任何異常時，Zabbix server都將發送警報通知給相應的管理員。
Zabbix server的基本功能分為3個不同的組件：Zabbix server、Web frontend（PHP前端）和數據庫（MySQL、PostgreSQL等）。
Zabbix的所有配置信息都存儲在數據庫中。例如，當在Web前端（或API）新增一個監控項時，此監控項會被添加到數據庫的監控項表item里，然后Zabbix server以每分鐘一次的頻率查詢監控項表中的有效監控項，并將查詢結果存儲到Zabbix server緩存中，這就是為什么Zabbix前端所做的任何更改都需要兩分鐘左右才能在最新數據中顯示的原因。
2.Zabbix agent
Zabbix agent部署在被監控的設備上，主動監控本地資源和應用程序（硬盤、內存、處理器統計信息等）。
Zabbix agent收集本地的性能數據并將數據報告給Zabbix server或Zabbix proxy，用于進一步處理。一旦出現異常（如硬盤空間已滿或有崩潰的服務進程），Zabbix server就會主動通知管理員指定機器上的異常。Zabbix agent的極高效率源于它可以利用本地系統調用來完成統計數據的采集。
3.Zabbix agent 2
Zabbix agent 2為新一代的Zabbix agent，未來可能會替代原Zabbix agent。Zabbix agent 2有以下優勢。
（1）減少TCP連接數。
（2）具有更好的檢查并發性。
（3）易于通過插件進行擴展。
Zabbix agent 2是用Go語言開發的（復用了原Zabbix agent的部分C代碼）。Zabbix agent 2需要在1.13+版本的Go環境中編譯。
Zabbix agent 2不支持Linux上的守護進程，而且從Zabbix 5.0.4開始，它可以作為Windows Service運行。
它的被動檢查的工作原理與Zabbix agent類似，其主動檢查支持scheduled/flexible間隔和并行檢查。
4.Zabbix proxy
Zabbix proxy可以從一個或多個受監控設備中采集監控數據并將數據發送給Zabbix server，主要功能是代理Zabbix server工作。所有收集的數據都在本地緩存，然后傳輸到Zabbix proxy所屬的Zabbix server上。
部署Zabbix proxy是可選的，它有利于分擔Zabbix server的負載。如果通過Zabbix proxy采集數據，則Zabbix server上會減少CPU和磁盤I/O的資源消耗。
Zabbix proxy是無須本地管理員即可集中監控遠程位置、分支機構和網絡的解決方案，同時，Zabbix proxy需要使用獨立的數據庫。
5.Zabbix Java Gateway
從Zabbix 2.0開始，Zabbix開始支持監控JMX應用程序，對應的組件為Zabbix Java Gateway。Zabbix Java Gateway的守護進程是用Java編寫的。為了在特定主機上找到JMX計數器的值，Zabbix server向Zabbix Java Gateway發送請求，Zabbix Java Gateway使用JMX管理API來遠程查詢相關的應用。被監控應用不需要安裝額外的軟件，只需在啟動時向命令行添加-Dcom.sun.management.jmxremote選項即可。
Zabbix Java Gateway接受來自Zabbix server或Zabbix proxy的請求，并且只能用作“被動Proxy”。在Zabbix server或Zabbix proxy配置文件中，可配置唯一的Zabbix Java Gateway。如果主機有Zabbix JMX agent或其他類型的監控項，則只將Zabbix JMX agent監控項傳遞給Zabbix Java Gateway進行檢索。
當必須通過Zabbix Java Gateway更新監控項時，Zabbix server或Zabbix proxy將連接Zabbix Java Gateway并請求該值，Zabbix Java Gateway將檢索該值并將其傳回Zabbix server或Zabbix proxy。因此，Zabbix Java Gateway不會緩存任何值。
Zabbix server或Zabbix proxy具有連接Zabbix Java Gateway的特定類型的進程，由StartJavaPollers選項控制。在內部，Zabbix Java Gateway啟動多個線程，由StartPollers選項控制。在服務器端，如果連接超過Timeout選項配置的秒數，則連接將被終止，但Zabbix Java Gateway可能仍在忙于從JMX計數器檢索值。為了解決這個問題，從Zabbix 2.0.15、Zabbix 2.2.10和Zabbix 2.4.5開始，Zabbix Java Gateway中增加Timeout選項，允許為JMX網絡操作設置超時。
Zabbix server或Zabbix proxy嘗試盡可能地將請求匯集到單個JMX目標中（受監控項取值間隔影響），并在單個連接中將它們發送給Zabbix Java Gateway以獲得更好的性能。
此外，建議StartJavaPollers選項的值小于或等于StartPollers選項的值，否則可能會出現Zabbix Java Gateway中無可用線程來為傳入請求提供服務的情況。
6.Web管理界面
為了從任何地方都可以輕松訪問Zabbix，Zabbix基于PHP編寫并提供了一套Web管理界面，可以使用市面上流行的Web服務中間件Aapche、Nginx等進行部署。該界面是Zabbix server的重要組成部分之一，通常（但不一定）和Zabbix server運行在同一臺服務器上，Zabbix的Web管理界面也是Zabbix API調用的入口。
7.Zabbix Sender
Zabbix Sender是一個命令行應用程序，可用于將性能數據發送到Zabbix server中進行處理。該實用程序通常用于長時間運行的用戶腳本，用于定期發送可用性和性能數據。如果需要將結果直接發送到Zabbix server或Zabbix proxy中，則必須配置監控項為trapper類型。
8.Zabbix Get
Zabbix Get是一個命令行應用，可以用于與Zabbix agent進行通信，并從Zabbix agent那里獲取所需的信息。該應用常用于Zabbix agent故障排錯，這里需要注意的是，此命令只能用于被動模式檢測。
1.5 Zabbix專業術語
在開始學習Zabbix之前，我希望大家能花點時間看一下Zabbix術語，因為這些術語也是Zabbix重要的概念組成部分。
1.主機（host）
主機是指需要監視的服務器或網絡設備等類型對象，在Zabbix的概念當中，一切監控設備都通過主機來實現，需要具有IP或DNS。
2.主機組（host group）
主機組是主機的邏輯分組，可以包含主機和模板。主機組中的主機和模板不會以任何方式相互鏈接。通過主機組可以為不同的用戶組分配主機的訪問權限。
3.監控項（item）
監控項用來從主機上接收特定的指標數據，數據分為5種類型：數字（無正負）、數字（浮點數）、字符、日志、文本。
注意：如果所需的數字有可能是負數的話，則要選擇數字（浮點數）。
4.值預處理（value preprocessing）
在數據被保存到數據庫之前，要對接收的指標數據進行轉換，這就是值預處理。目前，值預處理可以直接在Zabbix proxy上進行。詳細用法會在后續章節講解。
5.觸發器（trigger）
監控項只收集數據，為了自動判斷傳入的數據，需要定義觸發器。
觸發器包含一個表達式，通過表達式定義觸發問題的閾值。當接收的數據超過閾值時，觸發器從“OK”狀態進入“Problem”狀態；當接收的數據低于閾值時，觸發器保持或返回“OK”狀態。
6.事件（event）
事件是指發生的需要關注的事件，如觸發器狀態改變、自動發現/監控代理自動注冊。
7.事件標簽（event tag）
事件標簽是提前設置的事件標記，可以用于事件關聯、權限細化設置等。
8.事件關聯（event correlation）
事件關聯是一種靈活的、準確的解決問題的方法。
例如，自定義一個觸發器A報告的問題可以由另一個觸發器B解決，觸發器B甚至可以使用不同的數據收集方法。
9.異常（problem）
異常是指監控項處于“異常”狀態的觸發器。
10.異常更新（problem update）
異常更新是Zabbix提供的異常管理選項，如添加評論、確認異常、改變嚴重級別或手動關閉等。
11.動作（action）
動作是指預先定義的應對事件的動作。一個動作由操作（如發出通知）和條件（何時進行操作）組成。
12.動作升級（escalation）
動作升級是指用戶自定義的一個在動作（action）內執行操作的場景，是發送通知/執行遠程命令的序列。
13.媒介（media）
媒介是指Zabbix發送告警通知的方式、途徑。
14.通知（notification）
通知的作用是通過預先設定好的媒介途徑發送事件信息給用戶。
15.遠程命令（remote command）
遠程命令是預定義好的，在滿足特定條件的情況下，可以在被監控主機上自動執行。
16.監控模板（template）
監控模板是應用于一臺或多臺主機上的一套實體組合（如監控項、觸發器、圖形、聚合圖形、應用、LLD、Web場景等）。
監控模板的應用使得主機上的監控任務部署快捷方便，也使得監控任務進行批量修改更加簡單。監控模板直接關聯到每臺單獨的主機上。
17.應用（application）
應用是監控項的邏輯分組。
18.Web場景（web scenario）
Web場景是用來檢查B/S架構Web應用的可用性的一個或多個HTTP請求。
19.前端（frontend）
前端是指Zabbix提供的Web前端應用。
20.儀表盤（dashboard）
在自定義的Web前端模塊儀表盤中，用于重要的概要和可視化信息展示的單元稱為組件（widget）。
21.儀表盤組件（widget）
儀表盤組件是儀表盤中用來展示某種信息和數據的可視化組件（如概覽、map、圖表、時鐘等）。
22.Zabbix API
Zabbix API允許用戶使用JSON RPC協議創建、更新和獲取Zabbix對象（如主機、監控項、圖表等）信息或執行任何其他自定義的任務。
23.Zabbix server
Zabbix server是Zabbix軟件的核心進程，用來執行監控操作，與Zabbix proxy和Zabbix agent進行交互、觸發器計算、發送告警通知。
24.Zabbix agent
Zabbix agent是部署在監控對象上的進程，能夠主動監控本地資源和應用。
25.Zabbix proxy
Zabbix proxy是指代替Zabbix server采集數據，從而分擔Zabbix server負載的進程。
26.加密（encryption）
Zabbix組件之間的加密通信（Server、Proxy、Agent、zabbix_sender和zabbix_get工具）支持使用安全網絡傳輸協議（Transport Layer Security，TLS）。
27.網絡自動發現（network discovery）
網絡自動發現是指網絡設備的自動發現。
28.低級發現（low-level discovery）
低級發現是指特定設備上低級別實體的自動發現，可以發現必要的實體（如文件系統、網絡接口等）。
29.低級發現規則（low level discovery rule）
為自動發現設備中低級別實體設定的一系列規則稱為低級發現規則。
30.項目原型（item prototype）
項目原型是指有特定變量的指標，用于自動發現。低級別自動發現執行后，該變量將被實際自動發現的參數替換，該指標也自動開始采集數據。
31.觸發器原型（trigger prototype）
觸發器原型是有特定參數作為變量的觸發器，用于自動發現。在自動發現執行后，該變量將被實際自動發現的參數替換，該觸發器自動開始計算數據。
還有一些其他的Zabbix實體原型也被用于自動發現中，如圖表原型、主機原型、主機組原型、應用原型。
32.自動注冊（agent auto-registration）
自動注冊是指Zabbix agent自動注冊為一臺主機且開始監控的自動執行進程。
1.6 Zabbix版本及發布周期
前面已經大概解釋過Zabbix的各種專業術語，接下來解釋一下Zabbix SIA公司關于Zabbix軟件新版本發布的政策，并概述Zabbix早期版本的支持服務的時限。因為很多Zabbix初學者剛開始問的最多的一個問題就是“我應該選擇哪個Zabbix版本進行安裝呢？”
多年來，為了確保Zabbix為其用戶和客戶提供質量符合預期的產品與計劃性的支持，每個新的Zabbix軟件版本發布都遵循產品周期和到期時間的標準。對Zabbix終端用戶來說，Zabbix的產品周期使新版本的內容更具可預測性和可管理性。
自2001年Zabbix軟件首次發布開始，新的穩定版本每一年半發布一次，對于所有標準版本，Zabbix客戶都將獲得為期5年的服務與支持，可以根據表1-1查看當前Zabbix版本的支持服務及期限。
表1-1
注：1.全面支持服務包括修復一些基礎的、緊急的及安全性上的問題。
2.最低限度支持服務僅包括修復緊急的和安全性上的問題，Zabbix不保證對任何舊版本和不穩定版本的任意源代碼的修復。
1.6.1 Zabbix發布計劃
自從第一個穩定版本1.0發布以來，Zabbix版本控制使用小版本號來表示主要版本。每個小版本實際上實現了許多新特性，而變更級別的版本主要引入了錯誤修復。
Zabbix版本編號方案隨著時間的推移而改變。雖然最初的兩個穩定分支是1.0和1.1，但是在1.1版本之后，決定在開發版本中使用奇數，在標準版本中使用偶數。因此，1.3在1.1之后作為開發更新版本發布，標準版本為1.4。
目前，Zabbix的產品發布計劃周期為6個月，每6個月將有一個新的Zabbix標準版本發布。從發布計劃（見圖1-6）中可以看到，LTS release X就相當于5.0版本，每1年X加1，即下一個LTS版本為6.0版本。1年當中，每間隔6個月發布一個當前版本的X.2標準版本，即1年會發布兩個標準版本，如5.2、5.4。每個標準版本的支持期限為6個月。
圖1-6
總結一下：每一年半Zabbix將會發布的版本。
（1）Zabbix標準版本發布。Zabbix標準版本將在全面支持（基礎的、緊急的及安全性上的問題）的6個月內為Zabbix用戶提供支持服務，如圖1-7所示，直到下一個Zabbix穩定版本發布，再加一個月的最低限度支持（僅限緊急的和安全性上的問題）。Zabbix標準版本將會導致第二個版本號的變動。
（2）Zabbix LTS（長期支持版本）發布。Zabbix LTS在5年內為Zabbix用戶提供支持服務，如圖1-8所示，包括3年的全面支持（基礎的、緊急的及安全性上的問題）和2年的最低限度支持（僅限緊急的和安全性上的問題）。Zabbix LTS的發布將體現在版本號第一位數字的變動上。
注意：當任何Zabbix版本的生命周期到期后，Zabbix都將會停止對該版本進行進一步的維護更新，包括Blocker級和Cribical級的漏洞修復。因此，我們強烈建議用戶將Zabbix監控解決方案升級到最新版本。
圖1-7
圖1-8
1.6.2 關于Zabbix LTS
LTS代表長期支持版本。Zabbix LTS每一年半發布一次，且為Zabbix客戶提供5年的支持服務。
（1）3年全面支持：支持修復基礎的、緊急的及安全性上的問題。
（2）2年最低限度支持：僅限支持修復緊急的和安全性上的問題。
Zabbix LTS沒有任何額外的或隱藏的消費成本。Zabbix是一個100%的開源軟件，每個人都可以下載使用。
Zabbix LTS的特點如下。
（1）支持期限更長，如為潛在的安全問題及漏洞進行迭代更新。
（2）令人期待的高質量更新及全新的功能點。
（3）快速更新，可適用于多變的復雜環境。
（4）在版本升級方面，更容易規劃管理。
Zabbix LTS相較于標準版本的優勢如下。
（1）更適合大型企業環境。
LTS：新的Zabbix LTS每一年半發布一次。
標準版本：新的標準版本每6個月發布一次，意味著企業需要每半年進行一次升級，這對大型商業IT基礎設施來說會產生一些不可預計的問題。
（2）官方支持。
LTS：總計支持5年，包括3年基礎的、緊急的和安全性上的問題修復（全面支持），以及2年僅緊急的和安全性上的問題修復（最低限度支持）。
標準版本：新的標準版本每6個月發布一次，意味著企業需要每半年進行一次升級。
（3）更多測試驗證。
LTS：由于對緊急的和安全性上的問題的長期支持，Zabbix LTS更加穩定且可靠。
標準版本：Zabbix標準版本在完全穩定且安全之前不會停止測試，但由于其更頻繁的發布頻率和更短的支持時間，Zabbix標準版本用于問題修復的時間更短。
Zabbix LTS相較于標準版本的劣勢為無法更早體驗新功能。
LTS：Zabbix LTS每一年半發布一次，因此，如果客戶正在監控大型企業環境，那么僅升級到Zabbix LTS是最適合的方式，但是此時需要等待一年半的時間才能訪問使用此期間開發的功能。
標準版本：由于Zabbix標準版本的發布周期為6個月，所以客戶可以每6個月就體驗到最開發的新功能。
1.7 Zabbix版本兼容性
1.7.1 支持的Zabbix agent
從1.4版本開始，Zabbix agent與Zabbix 5.0兼容。但是，用戶可能需要檢查舊Zabbix agent的配置文件，因為可能會有一些參數的變動，如3.0以前版本的日志相關的參數與之前的不同。
想嘗試新的功能和改進的監控項、性能，以及更小的內存使用，請使用最新的Zabbix 5.0 agent。
注意：更新于5.0的Zabbix agent不能與Zabbix server 5.0一起使用。
1.7.2 支持的Zabbix proxies
Zabbix 5.0 proxies只支持與Zabbix 5.0 server一起工作。
這里值得注意一下，當升級完Zabbix server后，尚未升級的Zabbix proxies無法向Zabbix server發送監控數據（Zabbix proxy無法刷新其配置）。Zabbix官方之前不推薦使用低版本Zabbix proxy向高版本Zabbix server發送監控數據，現在官方正式禁用低版本Zabbix proxy向高版本Zabbix server發送監控數據，Zabbix server將忽略未升級的Zabbix proxy。
1.7.3 支持的XML文件
Zabbix 5.0支持使用版本號為1.8、2.0、2.2、2.4、3.0、3.2、3.4、4.0、4.2和4.4的Zabbix導出的XML文件導入。
在Zabbix 1.8 XML導出格式中，觸發器依賴項僅按名稱存儲。如果有幾個具有相同名稱（如具有不同的嚴重性和表達式）且在它們之間定義了依賴關系的觸發器，則不可能被導入，必須手動從XML文件中刪除這些依賴項，并在導入后重新添加。