Zabbix是一個監控系統。 與其他系統一樣，它面臨著所有監控系統的三個主要問題：收集和處理資料、儲存歷史記錄以及清理資料。
接收、處理和記錄資料的階段需要時間。 雖然不多，但對於大型系統來說，這可能會導致較大的延遲。 儲存問題是資料存取問題。 它們用於報告、檢查和觸發器。 資料存取的延遲也會影響效能。 當資料庫成長時，必須刪除不相關的資料。 刪除是一項困難的操作，也會消耗一些資源。
Zabbix中收集和預存程序中的延遲問題透過快取來解決：幾種類型的緩存，資料庫中的快取。 為了解決第三個問題，快取不適合，所以Zabbix使用了TimescaleDB。 他會告訴你這件事 安德烈·古欣 - 技術支援工程師 。 Andrey 已經支援 Zabbix 超過 6 年，並且在性能方面擁有直接的經驗。
TimescaleDB 是如何運作的，與常規 PostgreSQL 相比，它能提供什麼效能？ Zabbix對於TimescaleDB資料庫扮演什麼角色？ 如何從頭開始以及如何從 PostgreSQL 遷移以及哪種配置具有更好的效能？ 關於這一切都在削減之下。
生產力挑戰
每個監控系統都面臨特定的效能挑戰。 我會講其中三個：資料收集和處理、儲存和歷史清除。
快速資料收集和處理。 一個好的監控系統應該快速接收所有資料並根據觸發表達式進行處理 - 根據其標準。 處理完成後，系統還必須快速將這些資料保存到資料庫中以供以後使用。
歷史儲存。 一個好的監控系統應該將歷史記錄儲存在資料庫中並提供對指標的輕鬆存取。 報告、圖表、觸發器、閾值和計算的警報資料項目需要使用歷史記錄。
清除歷史記錄。 有時有一天您不需要儲存指標。 為什麼需要 5 年前、一兩個月收集的資料：有些節點已被刪除，有些主機或指標不再需要，因為它們已經過時且不再收集。 一個好的監控系統應該儲存歷史資料並且時常刪除，這樣資料庫就不會成長。
清理陳舊資料是一個極大影響資料庫效能的關鍵問題。
Zabbix 中的緩存
在Zabbix中，第一次和第二次呼叫是使用快取解決的。 RAM用於收集和處理資料。 用於儲存 - 觸發器、圖表和計算資料元素中的歷史記錄。 在資料庫方面，有一些基本選擇的緩存，例如圖形。
Zabbix 伺服器本身的快取是：
- 配置緩存；
- 值緩存；
- 歷史緩存；
- 趨勢緩存。
更詳細地考慮它們。
配置快取
這是我們儲存指標、主機、資料項目、觸發器的主要快取 - 預處理和資料收集所需的一切。
所有這些都儲存在 ConfigurationCache 中，以免在資料庫中建立不必要的查詢。 伺服器啟動後，我們更新此緩存，建立並定期更新配置。
資料收集
這張圖很大，但主要是 採摘者。 這些是各種“輪詢器”——組裝過程。 它們負責不同類型的組裝：它們透過 SNMP、IPMI 收集數據，並將其全部傳輸到預處理。
收集器的輪廓為橙色。
Zabbix 已計算出聚合檢查所需的聚合項。 如果我們有它們，我們會直接從 ValueCache 取得它們的資料。
預處理歷史緩存
所有收集器都使用 ConfigurationCache 來接收作業。 然後他們將它們轉移到預處理。
預處理使用 ConfigurationCache 來接收預處理步驟。 它以各種方式處理這些數據。
使用 PreProcessing 處理資料後，我們將其保存在 HistoryCache 中進行處理。 資料收集到此結束，我們繼續進行 Zabbix 中的主要流程 - 歷史同步器，因為它是一個整體架構。
注意：預處理是一個相當困難的操作。 在 v 4.2 中，它已移至代理。 如果您有一個非常大的 Zabbix，具有大量數據元素和收集頻率，那麼這會使工作變得更加容易。
ValueCache、歷史與趨勢緩存
歷史同步器是原子地處理每個資料元素（即每個值）的主程序。
歷史同步器從 HistoryCache 中取得值並檢查配置是否存在計算觸發器。 如果它們存在，它就會進行計算。
歷史記錄同步器建立事件、升級以根據配置和記錄建立警報（如果需要）。 如果有後續處理的觸發器，那麼它會將這個值儲存在ValueCache中，以免存取歷史表。 這就是 ValueCache 填充計算觸發器和計算元素所需的資料的方式。
歷史同步器將所有資料寫入資料庫，然後寫入磁碟。 處理過程到此結束。
緩存在資料庫中
當您想要查看事件的圖表或報告時，資料庫端有各種快取：
Innodb_buffer_pool在 MySQL 方面；shared_buffers在 PostgreSQL 方面；effective_cache_size在 Oracle 方面；shared_pool在 DB2 端。
還有許多其他緩存，但這些是所有資料庫的主要緩存。 它們允許您將查詢經常需要的資料儲存在 RAM 中。 他們有自己的技術。
資料庫效能至關重要
Zabbix伺服器不斷收集資料並寫入。 重新啟動時，它也會從歷史記錄中讀取資料以填入 ValueCache。 使用腳本和報告 扎比克斯API，它建構在 Web 介面上。 Zabbix API 存取資料庫並檢索圖表、報告、事件清單和最新問題所需的資料。
為了可視化 - 格拉法納。 這是我們用戶中流行的解決方案。 它可以直接透過Zabbix API發送請求並發送到資料庫，並為接收資料創建一定的競爭。 因此，需要對資料庫進行更精細、更好的調整，以匹配結果和測試的快速交付。
管家
Zabbix中的第三個性能挑戰是使用Housekeeper清除歷史記錄。 它遵循所有設定 - 資料元素指示儲存動態變化（趨勢）的時間（以天為單位）。
我們即時計算 TrendsCache。 當資料到達時，我們將其聚合一小時並將其記錄在表格中以了解趨勢變化的動態。
Housekeeper 使用通常的「選擇」啟動資料庫並刪除資訊。 這並不總是有效，從內部流程的效能圖表可以看出。
紅色圖顯示歷史記錄同步器一直處於繁忙狀態。 頂部的橙色圖是不斷運行的 Housekeeper。 他等待資料庫刪除他指定的所有行。
什麼時候該禁用管家？ 例如，有一個“Item ID”，需要在一定時間內刪除最後5行。 當然，這是透過索引發生的。 但通常資料集非常大，資料庫仍然從磁碟讀取並放入快取。 對於資料庫來說，這始終是一項非常昂貴的操作，並且根據資料庫的大小，可能會導致效能問題。
管家很容易被禁用。 在Web介面中，有一個針對管家的「常規管理」設定。 我們禁用內部趨勢歷史記錄的內部管理，它不再管理它。
Housekeeper 被關閉，圖表趨於平穩 - 在這種情況下可能存在哪些問題以及什麼可以幫助解決第三個效能挑戰？
分區－分區或分區
通常，在我列出的每個關係資料庫上以不同的方式配置分割區。 每個都有自己的技術，但總體上是相似的。 建立新分區通常會導致某些問題。
通常，分區的配置取決於「設定」—一天內建立的資料量。 一般來說，分區會在一天內發出，這是最少的。 對於新批次的趨勢 - 1 個月。
如果「設定」非常大，這些值可能會改變。 如果小型「設定」高達 5 nvps（每秒新值），中型「設定」為 000 到 5，那麼大型「設定」則高於 000 nvps。 這些是大型和超大型安裝，需要仔細配置資料庫。
對於非常大的安裝，一天的時間可能不是最佳的。 我見過每天 40 GB 或更多的 MySQL 分割區。 這是一個非常大量的數據，可能會導致問題，需要減少。
分區能帶來什麼？
分區表。 通常這些是磁碟上的單獨檔案。 查詢計劃會更最佳化地選擇一個分區。 通常分區是按範圍使用的——對於 Zabbix 來說也是如此。 我們在那裡使用「時間戳」——自時代開始以來的時間。 這些對我們來說都是普通的數字。 您可以設定一天的開始和結束 - 這是一個分割區。
快速移除 - DELETE。 選擇一個檔案/子表，而不是選擇要刪除的行。
顯著加快資料檢索速度 SELECT - 使用一個或多個分區，而不是整個表。 如果您正在存取兩天前的數據，則從資料庫中檢索資料的速度會更快，因為您只需將一個檔案載入到快取中並返回它，而不是一張大表。
通常許多資料庫也會加速 INSERT — 插入到子表中。
時標數據庫
對於 v 4.2，我們將注意力轉向了 TimescaleDB。 這是具有本機介面的 PostgreSQL 擴充。 此擴展可以有效地處理時間序列數據，而不會失去關係資料庫的優勢。 TimescaleDB 也會自動分割。
TimescaleDB有一個概念 超穩定 您建立的（超表）。 它包含 區塊 - 分區。 區塊是自動管理的超表片段，不會影響其他片段。 每個區塊都有自己的時間範圍。
TimescaleDB 與 PostgreSQL
TimescaleDB 的工作效率非常高。 該擴充功能的製造商聲稱他們使用了更正確的查詢處理演算法，特別是inserts 。 隨著資料集插入大小的成長，演算法保持恆定的效能。
在 200 億行之後，PostgreSQL 通常開始顯著下降，效能下降至 0。TimescaleDB 可讓您有效率地插入任意數量的資料的「插入」。
安裝
對於任何軟體包來說，安裝 TimescaleDB 都相當容易。 在 一切都有詳細描述 - 這取決於官方 PostgreSQL 包。 TimescaleDB 也可以手動建置和編譯。
對於 Zabbix 資料庫，我們只需啟動擴充功能即可：
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
你啟用設定 extension 並為 Zabbix 資料庫創建它。 最後一步是建立一個超級表。
將歷史表遷移到 TimescaleDB
有一個專門的函數可以實現這個功能 create_hypertable:
SELECT create_hypertable(‘history’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_log’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_text’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_str’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
UPDATE config SET db_extension=’timescaledb’, hk_history_global=1, hk_trends_global=1
此函數有三個參數。 第一的 - 資料庫中的表，您需要為其建立一個超級表。 第二 - 場，根據您需要創建 chunk_time_interval — 要使用的分區塊的間隔。 就我而言，間隔是一天 - 86。
第三個參數 - migrate_data。 如果你設定 true，然後所有當前資料都會轉移到預先建立的區塊中。 我自己用過 migrate_data。 我有大約 1 TB，花了一個多小時。 甚至在某些情況下，在測試過程中，我刪除了不需要儲存的字元類型的歷史數據，以免傳輸它們。
最後一步 - UPDATE：在 db_extension 放 timescaledb以便資料庫了解此擴展名的存在。 Zabbix 會啟動它並正確使用資料庫的語法和查詢 - 這些功能是 TimescaleDB 所必需的。
硬體配置
我用了兩台伺服器。 第一的 - 虛擬機。 它非常小：20 個 Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz 處理器、16 GB RAM 和 200 GB SSD。
我在上面安裝了 PostgreSQL 10.8、Debian 10.8-1.pgdg90+1 作業系統和 xfs 檔案系統。 我對所有內容進行了最低程度的配置以使用這個特定的資料庫，減去 Zabbix 本身將使用的資料庫。
在同一台機器上有一個 Zabbix 伺服器、PostgreSQL 和 負載代理。 我有 50 個正在使用的活躍代理 LoadableModule非常快速地產生不同的結果：數字、字串。 我用大量數據填充了資料庫。
最初的配置包含 5 個元素 每個主機的資料。 幾乎每個元素都包含一個觸發器，使其類似於真實的安裝。 在某些情況下，有不只一個觸發因素。 對於一個網路節點有 3-000 個觸發器.
資料項更新間隔 - 4-7秒。 我不僅使用 50 個代理，還添加了更多代理來調節負載本身。 此外，使用資料元素，我動態調整負載並將更新間隔減少到 4 秒。
PostgreSQL。 35 次 nvps
我在這個硬體上的第一次運行是在純 PostgreSQL 上——每秒 35 個值。 正如您所看到的，插入資料只需幾分之一秒的時間 - 一切都很好而且很快。 唯一的問題是 200 GB SSD 磁碟很快就會被填滿。
這是一個標準的 Zabbix 伺服器效能儀表板。
第一個藍色圖是每秒的數值數量。 右側第二張圖是建置過程的載入。 第三個是載入內部建置進程：歷史同步器和 Housekeeper，它們已經在這裡運行了相當長的一段時間。
第四張圖顯示了 HistoryCache 的使用情況。 這是插入資料庫之前的一種緩衝區。 綠色的第五張圖顯示了 ValueCache 的使用情況，即觸發器命中了多少 ValueCache - 這是每秒數千個值。
PostgreSQL。 50 次 nvps
然後我在相同的硬體上將負載增加到每秒 50 個值。
從Housekeeper載入時，插入10萬個值需要2-3秒。
管家已經開始乾涉工作了。
第三張圖顯示，整體而言，捕獲器和歷史同步器的負載仍為 60%。 在第四張圖中，HistoryCache 在 Housekeeper 作業期間已經開始相當活躍地填滿。 已滿 20%，約 0,5 GB。
PostgreSQL。 80 次 nvps
然後我將負載增加到每秒 80 個值。 這大約有 400 萬個資料元素和 280 萬個觸發器。
三十個歷史同步器的載入成本已經相當高了。
我還增加了各種參數：歷史同步器、快取。
在我的硬體上，歷史同步器的負載增加到最大。 HistoryCache 很快就填滿了資料——用於處理的資料已經累積在緩衝區中。
這段時間我觀察了處理器、RAM和其他系統參數的使用情況，發現磁碟利用率達到了最大。
我已經實現了使用 最大磁碟容量 在此硬體和此虛擬機器上。 在這樣的強度下，PostgreSQL開始相當積極地刷新數據，磁碟不再有時間寫入和讀取。
第二台伺服器
我選擇了另一台伺服器，它已經有 48 個處理器和 128 GB RAM。 我對其進行了調整 - 將其設置為 60 個歷史記錄同步器，並獲得了可接受的性能。
事實上，這已經是生產力的極限了，需要做些什麼。
時間刻度資料庫。 80 次 nvps
我的主要任務是測試 TimescaleDB 針對 Zabbix 負載的功能。 每秒 80 萬個值很多，收集指標的頻率（當然 Yandex 除外）和相當大的「設定」。
每張圖中都有一個下降——這正是資料遷移。 Zabbix 伺服器發生故障後，歷史同步器的載入設定檔發生了很大變化 - 下降了 XNUMX 次。
TimescaleDB 讓您可以將資料插入速度提高近 3 倍，並且使用更少的 HistoryCache。
因此，您將及時收到數據。
時間刻度資料庫。 120 次 nvps
然後我將資料元素的數量增加到500萬個，主要任務是測試TimescaleDB的能力——我收到每秒125萬個值的計算值。
這是一個可以長期有效的有效「設定」。 但由於我的磁碟只有 1,5 TB，所以幾天之內就填滿了。
最重要的是，同時建立了新的 TimescaleDB 分割區。
這對於性能來說是完全察覺不到的。 例如，當在 MySQL 中建立分割區時，一切都不同了。 這通常發生在晚上，因為它會阻止一般插入、處理表並可能導致服務降級。 TimescaleDB 的情況並非如此。
作為範例，我將展示社區中許多圖表的一張圖表。 圖中，TimescaleDB 已啟用，因此處理器上使用 io.weight 的負載下降了。 內部流程元素的使用也減少了。 而且，這是普通煎餅盤上的普通虛擬機，而不是SSD。
發現
TimescaleDB 是小型「設定」的良好解決方案，這會影響磁碟效能。 它將允許您繼續良好地工作，直到資料庫盡快遷移到硬體。
TimescaleDB 易於配置，可提高效能，與 Zabbix 配合良好， 與 PostgreSQL 相比有優勢.
如果您使用 PostgreSQL 並且不打算更改它，我建議 將 PostgreSQL 與 TimescaleDB 擴充功能結合使用 Zabbix。 該解決方案在中等“設定”下也能有效運作。
當我們說「高性能」時，我們的意思是 。 您很快就能了解使服務能夠為數百萬用戶提供服務的技術和實踐。 清單 7 月 8 日和 XNUMX 日我們已經編譯好了，但在這裡 還可以提出更多建議。
訂閱我們的 и ，其中我們揭示了即將舉行的會議的特點，並了解如何充分利用它。
來源： www.habr.com