干貨視頻 | Zabbix5.0升級最佳實踐以及常見問題排查

“分享升級5.0常見的問題和最佳解決方案，方便大家能夠在自己的環境中順利升級zabbix。”

——Arturs Lontons，高級技術支持工程師，zabbix SIA

本文整理自Arturs 在2020Zabbix中國峰會的演講，更多演講視頻可關注官方Bilibili賬號主頁（ID：Zabbix中國）。

01 - 升級準備

首先，在升級之前需要做一些準備，所以我想跟先大家講一下升級的一些新要求、備份和可能的停機等相關內容。我將分別說明新版本對php和數據庫后端的要求更新、備份Zabbix實例以及如何預估需要的停機時間，這些點對于更新而言非常重要，你肯定想要確定大概有多長的時間監控系統不能運行。首先我們來看一下新版本的基本要求更新，正如你所看到的，我們已經對php支持的最低版本進行了更新，之前是5.4，而現在則是7.2。我們不再支持embedTLS，因為它已經被棄用，安全性是我們最為注重的一個方面，而支持不受支持的加密庫（特別是不推薦使用的加密庫）的潛在風險和潛在成本太大。我們在較新的平臺比如RHEL8上添加了對LIBSSH的支持。MySQL也從5.0.3版升級到5.5.62至8.0.x。Oracle支持的版本也有更改，還有PostgreSQL，如果你使用的是Timescale，那么這正是我們的新功能之一，目前我們支持Timescale 1.0或更高版本。我們沒有找到關于IBM DB2的可行用例，我們確實有盡力的找，所以在新版本中，IBM DB2支持已被取消，因為這是一個非常小眾的數據庫后端，盡管我們在測試實驗室中使用這一數據庫后端，但似乎沒有其他人在使用。因此，我們決定放棄這項的維護，讓開發團隊集中于更有意義的任務。現在我們知道了新的最低要求，讓我們在考慮到這些要求的情況下開始做準備吧。

02 - 對所有的OS更新進行檢測

首先，我們需要對所有的OS更新進行檢測，如果我們有一些占存非常大的OS正在等待更新，那么我們就需要決定是否對它們執行更新，我們需要做一些規劃：我們需要做這件事嗎？會導致多久的停機時間？我們需要這樣做嗎？如果確實需要對它們進行更新的話，那么什么時候最為合適？如果我們決定更新，那么就讓我們來執行。在完成OS更新之后，需要記住的是，在進行下一步之前，我們需要在環境中運行幾天的時間，以便于對任何新出現的潛在問題進行詳細的盤查，因此，這里我們的基本思路是，一次只更新一部分，首先執行OS更新，然后掃描問題，然后檢查數據庫后端，必要時執行數據庫后端更新，然后查找和排除可能發生的任何問題、錯誤和性能故障，這樣我們可以根除這些潛在的問題，然后一旦所有這些都完成了，我們就已經準備好了基礎架構，準備好了運行環境，然后我們就可以繼續進行Zabbix本身的升級了。否則，如果我們同時進行所有的更新，那么在出現問題時，我們就真的很難找出問題的根源。就無法確定問題是不是來自Zabbix？還是來自OS？還是來自數據庫？因為我們在很短的時間里做了太多改動，這就是為什么需要一步一步來更新的原因。

03 - 為備份工作做好準備

接下來，為備份工作做好準備，這是在將Zabbix升級到5.0之前需要進行的一項大型工作。首先，確認下Zabbix監控實例中是否使用到了任何自定義解決方案。如果是，請備份，當然還要進行測試。這個非常重要。如果這些是專門為現有的舊版本定制的解決方案，那么就需要在新版本上首先進行測試，然后才能將其用于生產環境中。例如你采用的可能是某個社區開發的模板，它使用自定義腳本或一些前端修改、數據庫修改，雖然不是必然，但是在升級的過程中這些自定義很可能會導致一些問題。例如，如果你正在使用分區，要從版本等于或早于3.0的版本升級到5.0，則在繼續升級之前必須關閉這些分區。不過，對于較新的版本而言并不是一個問題，因為歷史表在升級過程中不會受到干擾。但是對于舊版本，我們需要在升級時禁用該分區，然后重新創建。就像我說的，自定義模塊和補丁，你是否有在使用？如果是，那么就需要首先對其兼容性進行測試，然后進行備份。另外一件事情，非常非常簡單，也非常基礎，但是大家總是忘記。我們的軟件包也可以在底層操作系統上運行。系統策略會允許下載這些軟件包嗎？網絡團隊允許你下載嗎？安全團隊允許下載嗎？如果不允許，那么我能否從源代碼編譯Zabbix或Zabbix軟件包將取決于這些前提條件，不同的情況下需要以不同的方式進行升級。如果你可以直接安裝新的軟件包，那就可以繼續。如果不可以，那么必須選擇其他的辦法，例如從源代碼編譯。這些都準備完成之后，就可以考慮對基礎架構進行備份。除此之外，我們還需要執行數據庫、后端、前端文件和備份，就像我說的那樣，不要忘記對你的自定義設置、自定義腳本（例如自定義配置文件、模塊等）進行備份。而且不僅要備份自定義配置文件，還要對常規配置文件進行備份，如果有些內容損壞了，只要有備份，我們可以完整的恢復過來。在屏幕上是一些關于如何備份Zabbix配置的示例。可以看到，我們正在執行外部腳本、Zabbix config目錄、Apache配置目錄（用于使用Apache）、我們的Web前端本身和doc目錄（可以包含基礎架構和其他一些內容）的副本。

然后，我們就需要執行非常重要的一步，那就是對環境配置進行備份。用戶需要明白的是，備份配置的重要性在很多時候都要大于歷史記錄的備份。因為如果我們丟失了所有的配置文件，那么我們就會遇到非常非常棘手的麻煩。歷史數據通常會自己備份，可能是通過分區進行備份，或者如果可以做到，我們可以單獨備份歷史數據，但配置可能是我們多年以來一直都在做的、修改和調整的。因此，我們肯定不想丟失配置。所以在這里我們有MySQL dump命令可用，這一命令會忽略我們的歷史和趨勢表。并能夠將其余內容轉儲到存檔之中，然后你就可以對其進行備份。

04 - 如何估計停機時間

那么我們如何估計停機時間呢？這非常重要，你的管理層會經常問你，這需要多長時間？一個小時？一天？還是更長時間？所以我們可以做一個非常粗略的估計，通過執行查詢，在這里查詢table_schema表，其中有幾個參數可以給我們提供數據庫的大小。這可以為我們提供一個粗略的估計，幾GB？幾百GB？還是超過1TB？通過這一信息，我們就可以估計出這個過程需要多長時間，是幾個小時，還是幾天還是更長。然后，在更細粒度的級別上，我們還可以查看數據庫表。這里有一個select語句，可以顯示前20個表。在此基礎上，了解不同版本之間的變化，通過查看“版本說明”，我們可以確定哪些表將進行升級。正如我們所看到的，我現在的屏幕上有一個配置表，非常簡單明了。可以看出，alerts是最上面的配置表，items甚至不是真正的配置表，只是包含alerts，但我選擇了除事件歷史趨勢之外的所有內容，所以alerts也會顯示出來，但這個表占用存儲空間也很小，只有1.64GB。items配置表大小為1.46GB，triggers配置表的大小也僅僅為0.4GB，真的很小。另一方面，在同一實例上，讓我們來看一下歷史事件和趨勢，你可以看到歷史表的大小為220GB，所以history表比alerts表大100多倍，events是156，trends是126，這是一個很小的示例。小型到中型實例，對于較大的實例，這些表就是變得很大（非常大）。因此，查看這些表的大小可以幫助我們估計停機時間，特別是從舊版本升級時，例如歷史表和事件表要升級。我們如何清理其中的一些呢？例如，對于事件，我們需要查看housekeeping設置，我經常看到客戶、社區成員、我的朋友，甚至是同事會使用非常長的數據存儲期，例如，存儲觸發數據的數據存儲期為一年，存儲內部數據的數據存儲期一年。而大多數時候并不需要如此長的儲存期，那么我們需要怎么做呢？我們可以將事件存儲期設置為一天，然后從命令行手動執行housekeeper進程，你的屏幕上會顯示該命令，你可以看到所有舊事件正在被刪除，表正在清理，完成此操作后備份的速度會快得多。也許我們在這里刪除了好幾GB的數據。升級時的停機時間時也會減少很多。

還有另一種方式，有時我們會這樣做，但對于一般的客戶或社區成員，或朋友們，如果你不知道自己在做什么，我不建議這樣做。這里有一個循環，可以手動清理事件表，如果housekeeper不夠用，或者有一些限制，我們可以使用我現在屏幕上的這個循環，50次迭代，在每次迭代中刪除大約100000個項。根據你所需的性能，你可以增加或減少該限制。所以，就像我說的，這是一種變通辦法，如果housekeeper不夠用，比如在非常大的情況下。但是要小心，你要知道你在做什么。我們在支持團隊中，在出現問題之前，我們可以互相咨詢，我們不會破壞一個實例。但在實際環境中，你必須小心，當然理想情況下，首先要在測試環境中執行此操作。另外一種情況下，如果連這個for loop循環都不夠用，我會怎么做呢？我將源為0的事件觸發，復制到新表中。因此，新的事件表僅包含源為0的事件，這里的問題是你必須刪除并重新創建所有約束，引用其他表上的事件。由于只是復制并重命名時間表，因此創建新的表事件（如Events），然后給它重命名，不能滿足引用的要求，約束仍然停留在包含所有舊事件的舊表上。所以我們需要在新表上重新創建約束，這里有一些示例查詢，我是如何重新創建它們的一些示例語句。請注意，事件表沒有任何更改，如果你是從4.0升級到5.0，那么根本不需要擔心這一點。還有一個相當普遍的做法，就是創建臨時歷史表。本質上是創建空的歷史表，對這些空表執行升級，它們的pattern會稍有改變。然后重新插入舊數據。這樣，你可以盡快啟動并運行Zabbix實例。空表上的升級將比滿表上的升級快得多，特別是因為pattern有一點變化。同樣，如果你要從4.0升級到5.0，表結構不會改變，因此你不必擔心這一點，你的歷史表將完全不受影響。

接下來，讓我們來看看這些逐步升級的示例。這里有兩個用例，首先是配置有Zabbix 3.0 server的CentOS 7，前端以及三個proxies，其中一個proxies使用的是Amazon Linux AMI OS，這可能會出現比較大的問題，正如我們看到的那樣，Zabbix server所使用的是MariaDB10.2作為后臺數據庫，而proxy使用MariaDB5.5和SQLite的組合。所以，我們這里該怎么做？首先需要創建臨時歷史表，安裝更新包，清理存儲庫緩存，執行升級，并對命令進行檢查，完成，希望成功。我們可以看到這一提示，是的，從數據包的角度來看，這是一個相當簡單的實例，我們可以在線下載軟件包，再安裝，我們不需要從源代碼編譯任何東西，一切都非常簡單和順利。然后安裝Zabbix 5.0存儲庫和CentOS SCL repo，這是基于我們使用的CentOS 7的操作系統的要求。讓我提醒你，在這一用例下，我們是在CentOS 7上執行運行，并從3.0升級到5.0。這就是為什么我們需要SCL repo，添加，然后安裝，啟用，除此之外，我們還需要在我們的Zabbix用戶配置中啟用前端存儲庫。然后，使用Apache配置重新安裝前端，我們需要專門重新安裝它，因為這里我們在使用一些新的軟件包，所以我們需要刪除舊的前端并安裝新的前端。安裝Zabbix web，MySQL，這就是MySQL前端，支持你MySQL查詢的前端，MySQL數據庫后端，我們正在從SCL存儲庫中安裝Apache配置。然后，更改默認的php配置，內存限制是你可能希望在較大實例上更改的內容。你可以根據實例所在的位置更改日期和時區，在我的情況下，是“Europe/Riga”。然后我導入回舊的歷史數據，所以我使用帶有空歷史表的臨時表進行了升級，我是從3.0升級的。然后，我將數據從舊的表導回到新的表中，好的一點是，這步可以在服務器運行的同時完成，這個非常好！因為它還在收集新的數據，而整個數據都很重要。所以在這種情況下沒有發生停機。在升級過程中有短暫的停機時間，但數據導入階段沒有停機時間。

05 - 繼續升級proxy

然后繼續升級proxies，在這里，我們使用兩種不同的方法。其中第一個非常順利，升級proxies，添加存儲庫，yum clean all, 升級proxies，使用MariaDB，一切都很順利。proxies啟動一切都很好，很簡單。我們甚至有一些使用SQLite3的proxy，這個可能就沒有那么簡單，因為我們必須刪除單個文件，雖然這有點耗時，但仍然不算復雜。我們刪除SQLite的數據庫文件，重新啟動proxies，一切都正常。然后我們使用另一種方法，發生了什么，這種單一用例為什么如此獨特可以被分成兩部分。如果有Proxy會怎么樣,在本例中運行的是Amazon Linux AMI，使用CentOS 6軟件包，在這種情況下，我們沒有事先檢查是否有適用于CentOS 6的軟件包。在CentOS 6上沒有5.0的server或proxy軟件包可用，那么我們此時能做什么？這里我們需要停下來，喝杯咖啡或茶或別的什么，然后我們決定如何繼續，我們是否需要從源代碼編譯proxy？在這種情況下，我們將來升級時，比如升級到5.2或6.0時，我們將需要重新編譯這個proxy，從頭開始，取決于你是否能接受這個，或者你的管理員或者其他執行人員是否同意。也許更好的做法是為整個環境做好未來的準備，并創建一個新的虛擬機，使用最新的操作系統。我們現在和將來都可以從包中安裝proxy，所以這實際上就是我們所做的。在實際環境中，這是一個真實的用例。這里，我們決定啟用一個帶有CentOS 8的新虛擬機，并安裝軟件包中的所有內容，實際上速度相當快。我認為這比錄制整個編譯過程、將來校對、提供客戶的文檔都要快得多。客戶熟悉從軟件包開始的升級，從軟件包開始安裝，所以這是最好的解決方案。你得做個決定。

接下來，安裝agent，要么是C agent，要么是GO agent，記住新的版本中已經有GO agent了，還提供很多新的插件可以使用，真的很不錯。再次由你來決定，是否要執行升級，然后你需要在C agent 和GO agent 之間做出選擇，但是由于它們可以后端可兼容，因此如果你非常疲憊，也可以推遲決定這個選擇，比如目前你已經升級了三個proxies，其中一個運行在不受支持的操作系統上，你可以稍后、明天、一個月后確認，視情況而定，或者如果你現在需要新功能，那么你現在就可以執行此操作。

06 - 升級之后要做的事

檢查錯誤消息和日志

好的，我們已經進行了升級，確實有點費力。現在讓我們來談談升級后要做的一些事情。我們可以充分利用5.0的潛力，升級之后，我們就可以利用一些優化的點，我們得到了視覺上更讓人舒服的UI，我們擁有了新的功能集，但我們也需要應用這些優勢，不是嗎？我們需要驗證我們的實例完整性，升級后一切都在運行，并使用最新和最好的功能和要求，我們需要檢查其性能，也許還需要對其進行進一步的優化，現在我們有了執行此操作的工具，還可以啟用一些新功能。

當然，升級之后，你要做的第一件事就是在當天，或者當天晚上檢查錯誤消息和日志。如果你在升級過程中遇到一些錯誤消息，你需要及時修復這些問題，特別是如果你自定義了一些數據庫表，或者添加了一些額外的索引，或者執行了類似的操作，則需要對這些充分進行刪除。將數據庫恢復到其原始狀態，然后繼續進行升級。然后，你需要注意到的另一件事是，你將收到一條錯誤消息或更多關于排序規則的警告。因此你可以參考這個ZBX-17357，它將包含更改數據庫排序規則和列排序規則的查詢，然后你可以執行并修復這些問題。但是，需要說明的是，對你來說這不一定是一個關鍵的問題，也許這個問題在你這里已經存在了好幾年。但需要記住的是，在我們所有的培訓中，在我們與客戶和所有論壇溝通中，在與你們的面對面交流中，我們一直強調排序規則是一個十分重要的環節。它確保你的實體和元素對大小寫敏感。Zabbix支持大小寫敏感元素。例如，你有一個全小寫的主機abc和全大寫的主機ABC，Zabbix應該能夠區分這兩個主機，這就是正確排序規則真正的意義所在。

使用補丁進行升級Float64

接下來，我們還啟用了Float64支持，目前是通過自定義補丁實現。可以通過鏈接獲得。只需打開它，如果你需要Float64值更高的未來校樣，請使用補丁進行升級。你可以繼續使用Float64的值，如果你不需要，現在你想稍后升級，就像我說的，你現在很累，你可以后面再做。

查看前端

好，接下來我們來看一下我們的前端。如果我們有錯誤的排序規則或錯誤的字符集，我們的前端也會給我們一條警告消息。所以我們需要修復。這里我再次提供了ZBX-17357鏈接和ZBXNEXT-5691鏈接，是和排序規則、Float64有關的告警信息。因此，你不僅可以在日志文件中看到，還可以在系統信息部分的前端中看到它。

對腳本和自定義媒體類型的集成執行測試

接下來，對你的腳本和自定義媒體類型的集成執行測試。如果它們正常工作，并且你可以獲得預期的數據，那么很好，我們可以繼續。注意小的測試按鈕，可以直接點擊來測試的，對吧。接下來，確保你基于腳本的監控項在正常接收數據。現在這里也有測試按鈕，你也可以使用，來測試你是否獲得了正確的值。如果沒問題的話，很好，我們就可以繼續了。如果有問題，修復腳本，然后繼續。當然，在升級之后，請驗證性能和配置，確認在升級了proxies之后隊列沒有大幅的增加。因為proxies需要升級到與后端相同的主要版本。然后我們可以繼續了。

確認Zabbix server和proxy的性能圖表

接下來，確認一下Zabbix server和proxy的性能圖表，如果有任何大的變動，我們需要找出問題所在。還要看看Zabbix server或proxy的日志文件中比較慢的查詢隊列，如果有比較慢的隊列，我們需要找出這些性能問題來自哪里。是不是數據庫出現了問題？還是Zabbix server性能出現問題？我們需要找出是什么原因造成的，并修復。

優化數據采集邏輯

接下來，我們可以通過使用新功能、新預處理規則來優化數據采集邏輯。例如，節流對于優化非常有用，既然你已經升級到5.0，那么就可以使用這些新功能，使用節流，丟棄不必要的數據。我們還可以使用預處理的數據驗證規則來驗證和獲取數據，并檢查它是否遵守我們的數據收集規則。修改現有監控項以使用新功能而不是DSN。也許你現在想要使用ODBC連接字符串，因為它在新版本里是完全受支持的。仔細檢查你的API腳本，我們做了一些更新，進行了改進，例如，SNMP接口類型現在需要details屬性，這可能會破壞你的遺留主機創建的腳本。你需要遵守這條規則，所以你需要稍微更改一下API腳本，添加以前可能缺少details屬性，因為這個之前不是必需的。

從腳本切換到WEBHOOKS，這是4.2中增加的一個很大的功能，用WEBHOOK來集成，而不是使用你自己編寫的腳本，你可能花了幾個小時來編寫，現在還要花時間維護，必須維護。切換到官方支持的WEBHOOK吧，我們現在提供WEBHOOK，可以用于集成，我們會維護，我們會更新、改進。這會讓你的工作輕松很多。既然你已經升級到5.0，你完全可以使用這個。使用升級了的安全功能，數據庫和后端之間的加密通信，前端和數據庫之間的加密通信，你還可以對其進一步加密，屏蔽宏，是的，如果你現在將密碼存儲在宏中，你現在可以屏蔽。所以沒有人能夠看到你輸入的內容。遷移到開箱即用的單點登錄支持，不需要在web部件、web組件上使用，你可以在Zabbix中本地使用這個功能了。

我的演講接近尾聲，通過演講帶著大家過一下升級時準備階段、升級階段和升級后階段需要做的工作。希望我的演講給了你們一些啟示和幫助，祝大家順利升級到5.0，謝謝！

“分享升級5.0常見的問題和最佳解決方案，方便大家能夠在自己的環境中順利升級Zabbix。”

——Arturs Lontons，高級技術支持工程師，Zabbix SIA

本文整理自Arturs 在2020Zabbix中國峰會的演講，更多演講視頻可關注官方Bilibili賬號主頁（ID：Zabbix中國）。

01 - 升級準備

首先，在升級之前需要做一些準備，所以我想跟先大家講一下升級的一些新要求、備份和可能的停機等相關內容。我將分別說明新版本對php和數據庫后端的要求更新、備份Zabbix實例以及如何預估需要的停機時間，這些點對于更新而言非常重要，你肯定想要確定大概有多長的時間監控系統不能運行。首先我們來看一下新版本的基本要求更新，正如你所看到的，我們已經對php支持的最低版本進行了更新，之前是5.4，而現在則是7.2。我們不再支持embedTLS，因為它已經被棄用，安全性是我們最為注重的一個方面，而支持不受支持的加密庫（特別是不推薦使用的加密庫）的潛在風險和潛在成本太大。我們在較新的平臺比如RHEL8上添加了對LIBSSH的支持。MySQL也從5.0.3版升級到5.5.62至8.0.x。Oracle支持的版本也有更改，還有PostgreSQL，如果你使用的是Timescale，那么這正是我們的新功能之一，目前我們支持Timescale 1.0或更高版本。我們沒有找到關于IBM DB2的可行用例，我們確實有盡力的找，所以在新版本中，IBM DB2支持已被取消，因為這是一個非常小眾的數據庫后端，盡管我們在測試實驗室中使用這一數據庫后端，但似乎沒有其他人在使用。因此，我們決定放棄這項的維護，讓開發團隊集中于更有意義的任務。現在我們知道了新的最低要求，讓我們在考慮到這些要求的情況下開始做準備吧。

02 - 對所有的OS更新進行檢測

首先，我們需要對所有的OS更新進行檢測，如果我們有一些占存非常大的OS正在等待更新，那么我們就需要決定是否對它們執行更新，我們需要做一些規劃：我們需要做這件事嗎？會導致多久的停機時間？我們需要這樣做嗎？如果確實需要對它們進行更新的話，那么什么時候最為合適？如果我們決定更新，那么就讓我們來執行。在完成OS更新之后，需要記住的是，在進行下一步之前，我們需要在環境中運行幾天的時間，以便于對任何新出現的潛在問題進行詳細的盤查，因此，這里我們的基本思路是，一次只更新一部分，首先執行OS更新，然后掃描問題，然后檢查數據庫后端，必要時執行數據庫后端更新，然后查找和排除可能發生的任何問題、錯誤和性能故障，這樣我們可以根除這些潛在的問題，然后一旦所有這些都完成了，我們就已經準備好了基礎架構，準備好了運行環境，然后我們就可以繼續進行Zabbix本身的升級了。否則，如果我們同時進行所有的更新，那么在出現問題時，我們就真的很難找出問題的根源。就無法確定問題是不是來自Zabbix？還是來自OS？還是來自數據庫？因為我們在很短的時間里做了太多改動，這就是為什么需要一步一步來更新的原因。

03 - 為備份工作做好準備

接下來，為備份工作做好準備，這是在將Zabbix升級到5.0之前需要進行的一項大型工作。首先，確認下Zabbix監控實例中是否使用到了任何自定義解決方案。如果是，請備份，當然還要進行測試。這個非常重要。如果這些是專門為現有的舊版本定制的解決方案，那么就需要在新版本上首先進行測試，然后才能將其用于生產環境中。例如你采用的可能是某個社區開發的模板，它使用自定義腳本或一些前端修改、數據庫修改，雖然不是必然，但是在升級的過程中這些自定義很可能會導致一些問題。例如，如果你正在使用分區，要從版本等于或早于3.0的版本升級到5.0，則在繼續升級之前必須關閉這些分區。不過，對于較新的版本而言并不是一個問題，因為歷史表在升級過程中不會受到干擾。但是對于舊版本，我們需要在升級時禁用該分區，然后重新創建。就像我說的，自定義模塊和補丁，你是否有在使用？如果是，那么就需要首先對其兼容性進行測試，然后進行備份。另外一件事情，非常非常簡單，也非常基礎，但是大家總是忘記。我們的軟件包也可以在底層操作系統上運行。系統策略會允許下載這些軟件包嗎？網絡團隊允許你下載嗎？安全團隊允許下載嗎？如果不允許，那么我能否從源代碼編譯Zabbix或Zabbix軟件包將取決于這些前提條件，不同的情況下需要以不同的方式進行升級。如果你可以直接安裝新的軟件包，那就可以繼續。如果不可以，那么必須選擇其他的辦法，例如從源代碼編譯。這些都準備完成之后，就可以考慮對基礎架構進行備份。除此之外，我們還需要執行數據庫、后端、前端文件和備份，就像我說的那樣，不要忘記對你的自定義設置、自定義腳本（例如自定義配置文件、模塊等）進行備份。而且不僅要備份自定義配置文件，還要對常規配置文件進行備份，如果有些內容損壞了，只要有備份，我們可以完整的恢復過來。在屏幕上是一些關于如何備份Zabbix配置的示例。可以看到，我們正在執行外部腳本、Zabbix config目錄、Apache配置目錄（用于使用Apache）、我們的Web前端本身和doc目錄（可以包含基礎架構和其他一些內容）的副本。

然后，我們就需要執行非常重要的一步，那就是對環境配置進行備份。用戶需要明白的是，備份配置的重要性在很多時候都要大于歷史記錄的備份。因為如果我們丟失了所有的配置文件，那么我們就會遇到非常非常棘手的麻煩。歷史數據通常會自己備份，可能是通過分區進行備份，或者如果可以做到，我們可以單獨備份歷史數據，但配置可能是我們多年以來一直都在做的、修改和調整的。因此，我們肯定不想丟失配置。所以在這里我們有MySQL dump命令可用，這一命令會忽略我們的歷史和趨勢表。并能夠將其余內容轉儲到存檔之中，然后你就可以對其進行備份。

04 - 如何估計停機時間

那么我們如何估計停機時間呢？這非常重要，你的管理層會經常問你，這需要多長時間？一個小時？一天？還是更長時間？所以我們可以做一個非常粗略的估計，通過執行查詢，在這里查詢table_schema表，其中有幾個參數可以給我們提供數據庫的大小。這可以為我們提供一個粗略的估計，幾GB？幾百GB？還是超過1TB？通過這一信息，我們就可以估計出這個過程需要多長時間，是幾個小時，還是幾天還是更長。然后，在更細粒度的級別上，我們還可以查看數據庫表。這里有一個select語句，可以顯示前20個表。在此基礎上，了解不同版本之間的變化，通過查看“版本說明”，我們可以確定哪些表將進行升級。正如我們所看到的，我現在的屏幕上有一個配置表，非常簡單明了。可以看出，alerts是最上面的配置表，items甚至不是真正的配置表，只是包含alerts，但我選擇了除事件歷史趨勢之外的所有內容，所以alerts也會顯示出來，但這個表占用存儲空間也很小，只有1.64GB。items配置表大小為1.46GB，triggers配置表的大小也僅僅為0.4GB，真的很小。另一方面，在同一實例上，讓我們來看一下歷史事件和趨勢，你可以看到歷史表的大小為220GB，所以history表比alerts表大100多倍，events是156，trends是126，這是一個很小的示例。小型到中型實例，對于較大的實例，這些表就是變得很大（非常大）。因此，查看這些表的大小可以幫助我們估計停機時間，特別是從舊版本升級時，例如歷史表和事件表要升級。我們如何清理其中的一些呢？例如，對于事件，我們需要查看housekeeping設置，我經常看到客戶、社區成員、我的朋友，甚至是同事會使用非常長的數據存儲期，例如，存儲觸發數據的數據存儲期為一年，存儲內部數據的數據存儲期一年。而大多數時候并不需要如此長的儲存期，那么我們需要怎么做呢？我們可以將事件存儲期設置為一天，然后從命令行手動執行housekeeper進程，你的屏幕上會顯示該命令，你可以看到所有舊事件正在被刪除，表正在清理，完成此操作后備份的速度會快得多。也許我們在這里刪除了好幾GB的數據。升級時的停機時間時也會減少很多。

還有另一種方式，有時我們會這樣做，但對于一般的客戶或社區成員，或朋友們，如果你不知道自己在做什么，我不建議這樣做。這里有一個循環，可以手動清理事件表，如果housekeeper不夠用，或者有一些限制，我們可以使用我現在屏幕上的這個循環，50次迭代，在每次迭代中刪除大約100000個項。根據你所需的性能，你可以增加或減少該限制。所以，就像我說的，這是一種變通辦法，如果housekeeper不夠用，比如在非常大的情況下。但是要小心，你要知道你在做什么。我們在支持團隊中，在出現問題之前，我們可以互相咨詢，我們不會破壞一個實例。但在實際環境中，你必須小心，當然理想情況下，首先要在測試環境中執行此操作。另外一種情況下，如果連這個for loop循環都不夠用，我會怎么做呢？我將源為0的事件觸發，復制到新表中。因此，新的事件表僅包含源為0的事件，這里的問題是你必須刪除并重新創建所有約束，引用其他表上的事件。由于只是復制并重命名時間表，因此創建新的表事件（如Events），然后給它重命名，不能滿足引用的要求，約束仍然停留在包含所有舊事件的舊表上。所以我們需要在新表上重新創建約束，這里有一些示例查詢，我是如何重新創建它們的一些示例語句。請注意，事件表沒有任何更改，如果你是從4.0升級到5.0，那么根本不需要擔心這一點。還有一個相當普遍的做法，就是創建臨時歷史表。本質上是創建空的歷史表，對這些空表執行升級，它們的pattern會稍有改變。然后重新插入舊數據。這樣，你可以盡快啟動并運行Zabbix實例。空表上的升級將比滿表上的升級快得多，特別是因為pattern有一點變化。同樣，如果你要從4.0升級到5.0，表結構不會改變，因此你不必擔心這一點，你的歷史表將完全不受影響。

接下來，讓我們來看看這些逐步升級的示例。這里有兩個用例，首先是配置有Zabbix 3.0 server的CentOS 7，前端以及三個proxies，其中一個proxies使用的是Amazon Linux AMI OS，這可能會出現比較大的問題，正如我們看到的那樣，Zabbix server所使用的是MariaDB10.2作為后臺數據庫，而proxy使用MariaDB5.5和SQLite的組合。所以，我們這里該怎么做？首先需要創建臨時歷史表，安裝更新包，清理存儲庫緩存，執行升級，并對命令進行檢查，完成，希望成功。我們可以看到這一提示，是的，從數據包的角度來看，這是一個相當簡單的實例，我們可以在線下載軟件包，再安裝，我們不需要從源代碼編譯任何東西，一切都非常簡單和順利。然后安裝Zabbix 5.0存儲庫和CentOS SCL repo，這是基于我們使用的CentOS 7的操作系統的要求。讓我提醒你，在這一用例下，我們是在CentOS 7上執行運行，并從3.0升級到5.0。這就是為什么我們需要SCL repo，添加，然后安裝，啟用，除此之外，我們還需要在我們的Zabbix用戶配置中啟用前端存儲庫。然后，使用Apache配置重新安裝前端，我們需要專門重新安裝它，因為這里我們在使用一些新的軟件包，所以我們需要刪除舊的前端并安裝新的前端。安裝Zabbix web，MySQL，這就是MySQL前端，支持你MySQL查詢的前端，MySQL數據庫后端，我們正在從SCL存儲庫中安裝Apache配置。然后，更改默認的php配置，內存限制是你可能希望在較大實例上更改的內容。你可以根據實例所在的位置更改日期和時區，在我的情況下，是“Europe/Riga”。然后我導入回舊的歷史數據，所以我使用帶有空歷史表的臨時表進行了升級，我是從3.0升級的。然后，我將數據從舊的表導回到新的表中，好的一點是，這步可以在服務器運行的同時完成，這個非常好！因為它還在收集新的數據，而整個數據都很重要。所以在這種情況下沒有發生停機。在升級過程中有短暫的停機時間，但數據導入階段沒有停機時間。

05 - 繼續升級proxy

然后繼續升級proxies，在這里，我們使用兩種不同的方法。其中第一個非常順利，升級proxies，添加存儲庫，yum clean all, 升級proxies，使用MariaDB，一切都很順利。proxies啟動一切都很好，很簡單。我們甚至有一些使用SQLite3的proxy，這個可能就沒有那么簡單，因為我們必須刪除單個文件，雖然這有點耗時，但仍然不算復雜。我們刪除SQLite的數據庫文件，重新啟動proxies，一切都正常。然后我們使用另一種方法，發生了什么，這種單一用例為什么如此獨特可以被分成兩部分。如果有Proxy會怎么樣,在本例中運行的是Amazon Linux AMI，使用CentOS 6軟件包，在這種情況下，我們沒有事先檢查是否有適用于CentOS 6的軟件包。在CentOS 6上沒有5.0的server或proxy軟件包可用，那么我們此時能做什么？這里我們需要停下來，喝杯咖啡或茶或別的什么，然后我們決定如何繼續，我們是否需要從源代碼編譯proxy？在這種情況下，我們將來升級時，比如升級到5.2或6.0時，我們將需要重新編譯這個proxy，從頭開始，取決于你是否能接受這個，或者你的管理員或者其他執行人員是否同意。也許更好的做法是為整個環境做好未來的準備，并創建一個新的虛擬機，使用最新的操作系統。我們現在和將來都可以從包中安裝proxy，所以這實際上就是我們所做的。在實際環境中，這是一個真實的用例。這里，我們決定啟用一個帶有CentOS 8的新虛擬機，并安裝軟件包中的所有內容，實際上速度相當快。我認為這比錄制整個編譯過程、將來校對、提供客戶的文檔都要快得多。客戶熟悉從軟件包開始的升級，從軟件包開始安裝，所以這是最好的解決方案。你得做個決定。

接下來，安裝agent，要么是C agent，要么是GO agent，記住新的版本中已經有GO agent了，還提供很多新的插件可以使用，真的很不錯。再次由你來決定，是否要執行升級，然后你需要在C agent 和GO agent 之間做出選擇，但是由于它們可以后端可兼容，因此如果你非常疲憊，也可以推遲決定這個選擇，比如目前你已經升級了三個proxies，其中一個運行在不受支持的操作系統上，你可以稍后、明天、一個月后確認，視情況而定，或者如果你現在需要新功能，那么你現在就可以執行此操作。

06 - 升級之后要做的事

檢查錯誤消息和日志

好的，我們已經進行了升級，確實有點費力。現在讓我們來談談升級后要做的一些事情。我們可以充分利用5.0的潛力，升級之后，我們就可以利用一些優化的點，我們得到了視覺上更讓人舒服的UI，我們擁有了新的功能集，但我們也需要應用這些優勢，不是嗎？我們需要驗證我們的實例完整性，升級后一切都在運行，并使用最新和最好的功能和要求，我們需要檢查其性能，也許還需要對其進行進一步的優化，現在我們有了執行此操作的工具，還可以啟用一些新功能。

當然，升級之后，你要做的第一件事就是在當天，或者當天晚上檢查錯誤消息和日志。如果你在升級過程中遇到一些錯誤消息，你需要及時修復這些問題，特別是如果你自定義了一些數據庫表，或者添加了一些額外的索引，或者執行了類似的操作，則需要對這些充分進行刪除。將數據庫恢復到其原始狀態，然后繼續進行升級。然后，你需要注意到的另一件事是，你將收到一條錯誤消息或更多關于排序規則的警告。因此你可以參考這個ZBX-17357，它將包含更改數據庫排序規則和列排序規則的查詢，然后你可以執行并修復這些問題。但是，需要說明的是，對你來說這不一定是一個關鍵的問題，也許這個問題在你這里已經存在了好幾年。但需要記住的是，在我們所有的培訓中，在我們與客戶和所有論壇溝通中，在與你們的面對面交流中，我們一直強調排序規則是一個十分重要的環節。它確保你的實體和元素對大小寫敏感。Zabbix支持大小寫敏感元素。例如，你有一個全小寫的主機abc和全大寫的主機ABC，Zabbix應該能夠區分這兩個主機，這就是正確排序規則真正的意義所在。

使用補丁進行升級Float64

接下來，我們還啟用了Float64支持，目前是通過自定義補丁實現。可以通過鏈接獲得。只需打開它，如果你需要Float64值更高的未來校樣，請使用補丁進行升級。你可以繼續使用Float64的值，如果你不需要，現在你想稍后升級，就像我說的，你現在很累，你可以后面再做。

查看前端

好，接下來我們來看一下我們的前端。如果我們有錯誤的排序規則或錯誤的字符集，我們的前端也會給我們一條警告消息。所以我們需要修復。這里我再次提供了ZBX-17357鏈接和ZBXNEXT-5691鏈接，是和排序規則、Float64有關的告警信息。因此，你不僅可以在日志文件中看到，還可以在系統信息部分的前端中看到它。

對腳本和自定義媒體類型的集成執行測試

接下來，對你的腳本和自定義媒體類型的集成執行測試。如果它們正常工作，并且你可以獲得預期的數據，那么很好，我們可以繼續。注意小的測試按鈕，可以直接點擊來測試的，對吧。接下來，確保你基于腳本的監控項在正常接收數據。現在這里也有測試按鈕，你也可以使用，來測試你是否獲得了正確的值。如果沒問題的話，很好，我們就可以繼續了。如果有問題，修復腳本，然后繼續。當然，在升級之后，請驗證性能和配置，確認在升級了proxies之后隊列沒有大幅的增加。因為proxies需要升級到與后端相同的主要版本。然后我們可以繼續了。

確認Zabbix server和proxy的性能圖表

接下來，確認一下Zabbix server和proxy的性能圖表，如果有任何大的變動，我們需要找出問題所在。還要看看Zabbix server或proxy的日志文件中比較慢的查詢隊列，如果有比較慢的隊列，我們需要找出這些性能問題來自哪里。是不是數據庫出現了問題？還是Zabbix server性能出現問題？我們需要找出是什么原因造成的，并修復。

優化數據采集邏輯

接下來，我們可以通過使用新功能、新預處理規則來優化數據采集邏輯。例如，節流對于優化非常有用，既然你已經升級到5.0，那么就可以使用這些新功能，使用節流，丟棄不必要的數據。我們還可以使用預處理的數據驗證規則來驗證和獲取數據，并檢查它是否遵守我們的數據收集規則。修改現有監控項以使用新功能而不是DSN。也許你現在想要使用ODBC連接字符串，因為它在新版本里是完全受支持的。仔細檢查你的API腳本，我們做了一些更新，進行了改進，例如，SNMP接口類型現在需要details屬性，這可能會破壞你的遺留主機創建的腳本。你需要遵守這條規則，所以你需要稍微更改一下API腳本，添加以前可能缺少details屬性，因為這個之前不是必需的。

從腳本切換到WEBHOOKS，這是4.2中增加的一個很大的功能，用WEBHOOK來集成，而不是使用你自己編寫的腳本，你可能花了幾個小時來編寫，現在還要花時間維護，必須維護。切換到官方支持的WEBHOOK吧，我們現在提供WEBHOOK，可以用于集成，我們會維護，我們會更新、改進。這會讓你的工作輕松很多。既然你已經升級到5.0，你完全可以使用這個。使用升級了的安全功能，數據庫和后端之間的加密通信，前端和數據庫之間的加密通信，你還可以對其進一步加密，屏蔽宏，是的，如果你現在將密碼存儲在宏中，你現在可以屏蔽。所以沒有人能夠看到你輸入的內容。遷移到開箱即用的單點登錄支持，不需要在web部件、web組件上使用，你可以在Zabbix中本地使用這個功能了。

我的演講接近尾聲，通過演講帶著大家過一下升級時準備階段、升級階段和升級后階段需要做的工作。希望我的演講給了你們一些啟示和幫助，祝大家順利升級到5.0，謝謝！

Zabbix 運維

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。