我們將了解 Zabbix 如何使用 TimescaleDB 資料庫作為後端。 我們將向您展示如何從頭開始以及如何從 PostgreSQL 遷移。 我們還將提供兩種配置的性能對比測試。
HighLoad++ 西伯利亞 2019。托木斯克大廳。 24 月 16 日 00:XNUMX。 論文和 。 下一次 HighLoad++ 會議將於 6 年 7 月 2020 日至 XNUMX 日在聖彼得堡舉行。 詳情及門票 .
安德烈·古希欽（Andrey Gushchin，以下簡稱“AG”）： – 我是Zabbix技術支援工程師（以下簡稱「Zabbix」），訓練師。 我從事技術支援工作超過 6 年，對性能有直接的經驗。 今天我將討論 TimescaleDB 與常規 PostgreSQL 10 相比可以提供的效能。此外，還有一些關於它的一般工作原理的介紹部分。
生產力面臨的首要挑戰：從資料收集到資料清理
首先，每個監控系統都面臨某些效能挑戰。 第一個生產力挑戰是快速收集和處理數據。
一個好的監控系統應該能夠快速、及時地接收到所有的數據，並根據觸發表達式進行處理，即按照某種標準進行處理（這個在不同的系統中是不同的），並保存到資料庫中，以便在系統中使用這些數據。未來。
第二個性能挑戰是歷史儲存。 經常儲存在資料庫中，並且可以快速方便地存取一段時間內收集的這些指標。 最重要的是，這些數據很容易獲取，可以在報告、圖表、觸發器、某些閾值、警報等中使用它。
第三個效能挑戰是歷史清除，也就是說，當您達到不需要儲存 5 年（甚至幾個月或兩個月）收集的任何詳細指標的程度時。 某些網路節點被刪除，或某些主機不再需要這些指標，因為它們已經過時並且不再收集。 所有這些都需要清除，以便您的資料庫不會變得太大。 一般來說，清除歷史記錄通常是對儲存的嚴峻考驗 - 它通常會對效能產生非常大的影響。
如何解決快取問題？
我現在具體講一下Zabbix。 在Zabbix中，第一次和第二次呼叫是使用快取解決的。
資料收集和處理 - 我們使用 RAM 來儲存所有這些資料。 現在將更詳細地討論這些數據。
此外，在資料庫方面，還有一些主要選擇的快取 - 用於圖形和其他內容。
Zabbix 伺服器本身的快取：我們有 ConfigurationCache、ValueCache、HistoryCache、TrendsCache。 這是什麼？
ConfigurationCache是主要的緩存，我們在其中儲存指標、主機、資料項目、觸發器； 處理預處理、收集資料、從哪些主機收集、以何種頻率收集所需的一切。 所有這些都儲存在 ConfigurationCache 中，以免存取資料庫並建立不必要的查詢。 伺服器啟動後，我們更新此快取（創建它）並定期更新（取決於配置設定）。
在 Zabbix 中快取。 數據採集
這裡的圖相當大：
該計劃中的主要收集者是這些收集者：
這些是組裝過程本身，負責不同類型組裝的各種「輪詢器」。 他們透過 icmp、ipmi 和各種協定收集資料並將其全部傳輸到預處理。
預處理歷史緩存
另外，如果我們有計算資料元素（熟悉Zabbix的都知道），也就是計算、聚合資料元素，我們直接從ValueCache中取出。 稍後我會告訴你如何填充。 所有這些收集器都使用 ConfigurationCache 來接收其作業，然後將其傳遞給預處理。
預處理也會使用 ConfigurationCache 來取得預處理步驟並以各種方式處理此資料。 從 4.2 版本開始，我們已將其移至代理。 這非常方便，因為預處理本身就是一個相當困難的操作。 而如果你有一個非常大的Zabbix，有大量的數據元素和很高的收集頻率，那麼這會大大簡化工作。
因此，在我們使用預處理以某種方式處理這些資料後，我們將其保存在 HistoryCache 中，以便進一步處理。 數據收集到此結束。 我們繼續進行主要流程。
歷史同步器的工作
Zabbix 中的主要流程（因為它是整體架構）是歷史同步器。 這是專門處理每個資料元素（即每個值）的原子處理的主流程：
- 值來了（它從 HistoryCache 中獲取）；
- 檢查配置同步器：是否有任何計算觸發器 - 計算它們；
如果有 - 建立事件，建立昇級以建立警報（如有必要）根據配置； - 記錄觸發器以供後續處理、聚合； 如果您在過去一小時等時間內進行聚合，則 ValueCache 會記住該值，以免進入歷史表； 因此，ValueCache填充了計算觸發器、計算元素等所需的必要資料；
- 然後歷史同步器將所有資料寫入資料庫；
- 資料庫將它們寫入磁碟 - 這是處理過程結束的地方。
資料庫. 快取
在資料庫方面，當您想要查看圖表或一些事件報告時，有各種快取。 但在這篇報告中我不會談論它們。
對於 MySQL，有 Innodb_buffer_pool，以及一堆可以配置的不同快取。
但這些是主要的：
- 共享緩衝區；
- 有效快取大小；
- 共享池。
對於所有資料庫，我說過都有某些快取允許您將查詢經常需要的資料儲存在 RAM 中。 他們有自己的技術。
關於資料庫效能
相應地，存在一個競爭環境，即Zabbix伺服器收集資料並記錄它。 重新啟動時，它也會從歷史記錄中讀取資料以填入 ValueCache 等。 在這裡，您可以擁有使用 Zabbix API 的腳本和報告，該 API 建置在 Web 介面上。 Zabbix API 進入資料庫並接收必要的資料以取得圖表、報告或某種事件清單、最近的問題。
Grafana 也是一個非常受歡迎的視覺化解決方案，我們的用戶也使用它。 能夠透過Zabbix API和資料庫直接登入。 它也為獲取數據帶來了一定的競爭：需要對資料庫進行更精細、更好的調整，以滿足結果和測試的快速交付。
清除歷史記錄。 Zabbix 有管家
Zabbix 中使用的第三個呼叫是使用 Housekeeper 清除歷史記錄。 管家遵循所有設置，即我們的資料元素表示儲存多長時間（以天為單位）、儲存趨勢多長時間以及變化的動態。
我沒有談論 TrendCache，它是我們即時計算的：數據到達後，我們將其聚合一小時（大部分是最後一小時的數字），數量是平均值/最小值，我們每小時將其記錄一次變化動態表（“趨勢”）。 「管家」使用常規選擇來啟動和刪除資料庫中的數據，但這並不總是有效。
怎麼理解是無效呢？ 內部流程的效能圖可以看到下圖：
您的歷史記錄同步器一直很忙（紅色圖）。 以及頂部的“紅色”圖表。 這是一個“管家”，它啟動並等待資料庫刪除它指定的所有行。
讓我們來看看 Item ID：您需要刪除最後 5 個； 當然是透過索引。 但通常資料集相當大——資料庫仍然從磁碟讀取它並將其放入快取中，這對於資料庫來說是一個非常昂貴的操作。 根據其大小，這可能會導致某些效能問題。
您可以透過簡單的方式停用 Housekeeper - 我們有一個熟悉的 Web 介面。 在管理常規設定（「管家」設定）中，我們停用內部歷史記錄和趨勢的內部管理。 因此，管家不再控制這一點：
接下來你可以做什麼？ 您將其關閉，您的圖表已趨於平穩...在這種情況下可能會出現哪些進一步的問題？ 有什麼可以幫忙的？
分區（分段）
通常，這在我列出的每個關係資料庫上以不同的方式配置。 MySQL有自己的技術。 但總的來說，PostgreSQL 10 和 MySQL 非常相似。 當然，在如何實現以及如何影響效能方面存在許多內部差異。 但一般來說，建立新分區往往也會導致某些問題。
根據您的設定（一天創建多少數據），他們通常會設定最小值 - 這是 1 天/批次，對於“趨勢”，變化的動態 - 1 個月/新批次。 如果您的設定非常大，這可能會改變。
讓我們立即說說設定的大小：每秒最多 5 個新值（所謂的 nvps）——這將被視為一個小型「設定」。 平均 – 每秒 5 到 25 個值。 以上所有內容都已經是大型且非常大型的安裝，需要非常仔細地配置資料庫。
對於非常大的安裝，1 天可能不是最佳選擇。 我個人看過 MySQL 上每天 40 GB 的分割區（可能還有更多）。 這是一個非常大量的數據，可能會導致一些問題。 它需要減少。
為什麼需要分區？
我想大家都知道，分割區提供的是表格分割區。 通常，這些是磁碟上的單獨檔案和跨度請求。 如果它是正常分割區的一部分，它會更最佳化地選擇一個分割區。
對於Zabbix來說，特別是，它是按範圍使用的，按範圍，即我們使用時間戳（一個常規數字，自紀元開始以來的時間）。 您指定一天的開始/一天的結束，這就是分區。 因此，如果您要求兩天前的數據，則可以更快地從資料庫中檢索所有內容，因為您只需將一個文件加載到快取中並返回它（而不是一張大表）。
許多資料庫也加速插入（插入到一個子表中）。 我現在只是抽像地說，但這也是可能的。 分區通常會有所幫助。
適用於 NoSQL 的 Elasticsearch
最近，在 3.4 中，我們實作了 NoSQL 解決方案。 新增了在 Elasticsearch 中寫入的功能。 您可以寫某些類型：您選擇 - 寫數字或一些符號； 我們有字串文本，您可以將日誌寫入Elasticsearch...相應地，Web介面也會存取Elasticsearch。 這在某些情況下效果很好，但目前可以使用。
時間刻度資料庫。 超級表
對於 4.4.2，我們關注了 TimescaleDB 這樣的一件事。 這是什麼？ 這是 PostgreSQL 的擴展，也就是說，它有一個原生的 PostgreSQL 介面。 另外，此擴充功能可讓您更有效地處理時間序列資料並具有自動分割區。 它看起來像什麼：
這是hypertable——Timescale中有這樣一個概念。 這是您創建的超表，它包含區塊。 如果我沒記錯的話，區塊是分區，這些是子表。 真的很有效。
TimescaleDB 和 PostgreSQL
正如 TimescaleDB 製造商所保證的那樣，他們使用更正確的演算法來處理查詢，特別是插入，這使得他們能夠隨著資料集插入大小的增加而獲得大致恆定的效能。 也就是說，在 Postgres 的 200 億行之後，通常的行開始大幅下降，效能幾乎為零，而 Timescale 允許您以任意數量的資料盡可能有效地插入插入內容。
如何安裝TimescaleDB？ 這很簡單！
它在文件中進行了描述 - 您可以從任何包中安裝它...這取決於官方 Postgres 包。 可以手動編譯。 碰巧我必須為資料庫進行編譯。
在 Zabbix 上，我們只需啟動擴充功能即可。 我認為那些在 Postgres 中使用 Extention 的人...您只需啟動 Extention，為您正在使用的 Zabbix 資料庫建立它即可。
還有最後一步...
時間刻度資料庫。 歷史表遷移
您需要建立一個超級表。 為此有一個特殊的函數——創建超級表。 其中，第一個參數是該資料庫中所需的表（您需要為其建立超表）。
創建的字段，chunk_time_interval（這是chunk（需要使用的分區）的時間間隔。86是一天。
Migrate_data 參數：如果插入為 true，則這會將所有目前資料遷移到預先建立的區塊中。
我自己使用過 migrate_data - 它需要相當長的時間，這取決於您的資料庫有多大。 我有超過 XNUMX TB 的數據 - 創建它花了一個多小時。 在某些情況下，在測試過程中，我刪除了文字（history_text）和字串（history_str）的歷史數據，以免傳輸它們 - 它們對我來說並不真正有趣。
我們在 db_extention 中進行最後一次更新：我們安裝 timescaledb，以便資料庫，特別是我們的 Zabbix 知道有 db_extention。 他啟動它並使用正確的語法和資料庫查詢，使用 TimescaleDB 所需的「功能」。
伺服器配置
我用了兩台伺服器。 第一台伺服器是一個相當小的虛擬機，有 20 個處理器、16 GB RAM。 我在上面配置了 Postgres 10.8：
作業系統是Debian，檔案系統是xfs。 我做了最少的設定來使用這個特定的資料庫，減去 Zabbix 本身將使用的設定。 在同一台機器上有 Zabbix 伺服器、PostgreSQL 和負載代理程式。
我使用了 50 個使用 LoadableModule 的活動代理來快速產生不同的結果。 他們是生成字串、數字等的人。 我用大量數據填充了資料庫。 最初，每個主機的配置包含 5 個資料元素，並且大約每個資料元素都包含一個觸發器 - 以便這是一個真正的設定。 有時您甚至需要使用多個觸發器。
我不僅使用 50 個代理程式（添加更多），而且還使用動態資料元素並將更新間隔減少到 4 秒，從而調節了更新間隔和負載本身。
性能測試。 PostgreSQL：36 個 NVP
第一次啟動，我的第一個設定是在這個硬體上的純 PostreSQL 10 上（每秒 35 個值）。 一般來說，正如您在螢幕上看到的那樣，插入資料只需幾分之一秒的時間 - 一切都很好而且很快，SSD 驅動器（200 GB）。 唯一的問題是 20GB 很快就被佔滿了。
未來這樣的圖表還會有很多。 這是一個標準的 Zabbix 伺服器效能儀表板。
第一張圖是每秒的數值數量（藍色，左上），在本例中為 35 個數值。 這個（頂部中心）是構建進程的加載，這個（右上角）是內部進程的加載：歷史同步器和管家，這裡（底部中心）已經運行了相當長一段時間。
此圖（底部中央）顯示 ValueCache 使用情況 - 觸發器的 ValueCache 命中次數（每秒數千個值）。 另一個重要的圖是第四個圖（左下），它顯示了我談到的HistoryCache的使用，它是插入資料庫之前的緩衝區。
性能測試。 PostgreSQL：50 個 NVP
接下來，我在同一硬體上將負載增加到每秒 50 個值。 當管家加載時，透過計算在10-2秒內記錄了3個值。 事實上，如下截圖所示：
「管家」已經開始乾擾工作，但總體而言，歷史沉降陷阱者的負荷仍處於 60% 的水平（第三張圖，右上）。 當 Housekeeper 運行時，HistoryCache 已經開始主動填充（左下角）。 約有 20 GB，已滿 XNUMX%。
性能測試。 PostgreSQL：80 個 NVP
然後我將其增加到每秒 80 個值：
大約有 400 萬個資料元素，280 萬個觸發器。 正如您所看到的，就歷史沉澱片的負載而言，插入件（共有 30 個）已經相當高了。 然後我增加了各種參數：歷史記錄器、快取......在這個硬體上，歷史記錄器的負載開始增加到最大值，幾乎「上架」 - 相應地，歷史記錄器進入了非常高的負載：
一直以來，我監控所有系統參數（處理器的使用方式、RAM），並發現磁碟利用率達到最大 - 我在該硬體、該虛擬機器上實現了該磁碟的最大容量。 「Postgres」開始以如此強度相當積極地轉儲數據，磁碟不再有時間寫入、讀取...
我使用另一台已經擁有 48 個處理器和 128 GB RAM 的伺服器：
我還“調整”了它 - 安裝了歷史同步器（60 件）並達到了可接受的性能。 事實上，我們並沒有“束手無策”，但這可能是生產力的極限，我們已經有必要對此採取一些措施了。
性能測試。 TimescaleDB：80 個 NVP
我的主要任務是使用 TimescaleDB。 每張圖都顯示出下降：
這些失敗恰恰就是資料遷移。 之後，在Zabbix伺服器中，歷史沉降器的載入設定文件，如您所見，發生了很大變化。 它允許您插入資料的速度提高近 3 倍，並且使用更少的 HistoryCache - 因此，您將按時交付資料。 同樣，每秒 80 個值是一個相當高的速率（當然，對於 Yandex 來說不是）。 總的來說，這是一個相當大的設置，只有一台伺服器。
PostgreSQL 效能測試：120 萬個 NVP
接下來，我將資料元素數量的值增加到 125 萬，並收到每秒 XNUMX 個的計算值：
我得到了這些圖表：
原則上，這是一個工作設置，它可以工作相當長的時間。 但由於我只有 1,5 TB 的磁碟，幾天後就用完了。 最重要的是，同時在 TimescaleDB 上建立了新分割區，而這對於效能來說完全沒有被注意到，而 MySQL 就不能這樣說。
通常，分區是在晚上創建的，因為這通常會阻止插入和使用表，並可能導致服務降級。 在這種情況下，情況並非如此！ 主要任務是測試TimescaleDB的功能。 結果如下圖：每秒120萬個數值。
社區裡也有這樣的例子：
該人還打開了 TimescaleDB，並且使用 io.weight 的負載下降到了處理器上； 由於包含了 TimescaleDB，內部流程元素的使用也減少了。 而且，這些都是普通的煎餅盤，也就是普通磁碟（不是SSD）上的普通虛擬機器！
對於一些受磁碟效能限制的小型設置，在我看來，TimescaleDB 是一個非常好的解決方案。 它將允許您在遷移到更快的資料庫硬體之前繼續工作。
我邀請大家參加我們的活動：莫斯科會議、裡加峰會。 使用我們的頻道 - Telegram、論壇、IRC。 如果您有任何疑問，請來到我們的辦公桌，我們可以討論一切。
觀眾提問
觀眾提出的問題（下文 - A）： - 如果 TimescaleDB 如此易於配置，並且它提供瞭如此大的性能提升，那麼也許這應該用作使用 Postgres 配置 Zabbix 的最佳實踐？ 這個解決方案有什麼陷阱和缺點嗎？或者畢竟，如果我決定自己製作 Zabbix，我可以輕鬆地使用 Postgres，立即在那裡安裝 Timescale，使用它而不用考慮任何問題？
股份公司： – 是的，我想說這是一個很好的建議：立即使用 Postgres 和 TimescaleDB 擴充功能。 正如我已經說過的，儘管這個「功能」是實驗性的，但還是有很多好評。 但實際測試表明，這是一個很棒的解決方案（使用 TimescaleDB），我認為它會繼續發展！ 我們正在監控此擴充功能的發展情況，並將根據需要進行更改。
即使在開發過程中，我們也依賴它們眾所周知的「功能」之一：可以以稍微不同的方式處理區塊。 但後來他們在下一個版本中刪除了它，我們只好停止依賴這段程式碼。 我建議在許多設定中使用此解決方案。 如果您使用 MySQL...對於一般設置，任何解決方案都可以正常運作。
但： – 在社區的最後一張圖表中，有一張帶有「管家」的圖表：
他繼續工作。 Housekeeper 使用 TimescaleDB 做什麼？
股份公司： – 現在我不能肯定地說 – 我會查看程式碼並更詳細地告訴你。 它使用 TimescaleDB 查詢不是為了刪除區塊，而是以某種方式聚合它們。 我還沒準備好回答這個技術問題。 我們將在今天或明天的展位上了解更多。
但： – 我有一個類似的問題 – 關於 Timescale 中刪除操作的效能。
A（觀眾回答）： – 當您從表中刪除資料時，如果您透過刪除來執行此操作，那麼您需要遍歷該表 - 刪除、清理、標記所有內容以供將來清理。 在 Timescale 中，由於您有區塊，因此可以刪除。 粗略地說，你只需告訴大數據中的文件：“刪除！”
Timescale 簡單地理解這樣的區塊不再存在。 由於它集成到查詢規劃器中，因此它使用鉤子來捕獲 select 或其他操作中的條件，並立即了解該塊不再存在 - “我不會再去那裡了！” （數據不可用）。 就這樣！ 也就是說，表掃描被二進位檔案刪除取代，所以速度很快。
但： – 我們已經談到了非 SQL 的主題。 據我了解，Zabbix實際上並不需要修改數據，所有這些都是類似日誌的東西。 是否可以使用無法更改資料的專用資料庫，但同時可以更快地保存、累積和分發 - 例如 Clickhouse，類似於 Kafka 的東西？...Kafka 也是日誌！ 是否有可能以某種方式整合它們？
股份公司： - 可以卸貨。 從 3.4 版本開始，我們有一個特定的「功能」：你可以將所有歷史文件、事件、其他所有內容寫入檔案； 然後使用一些處理程序將其發送到任何其他資料庫。 事實上，很多人返工後直接寫入資料庫。 即時歷史沉降器將所有這些寫入文件，輪換這些文件等等，您可以將其傳輸到 Clickhouse。 我不能透露具體計劃，但也許會繼續對 NoSQL 解決方案（例如 Clickhouse）提供進一步支援。
但： – 總的來說，事實證明你可以完全擺脫postgres？
股份公司： – 當然，Zabbix中最困難的部分是歷史表，它產生最多的問題和事件。 在這種情況下，如果您不長期儲存事件並將歷史記錄和趨勢儲存在其他一些快速儲存中，那麼一般來說，我認為不會有任何問題。
但： – 例如，如果您切換到 Clickhouse，您能估計一切運行速度會快多少嗎？
股份公司： – 我還沒測試過。 我認為至少可以很簡單地實現相同的數字，因為 Clickhouse 有自己的介面，但我不能肯定地說。 最好測試一下。 這一切都取決於配置：您有多少主機，等等。 插入是一回事，但您還需要檢索此資料 - Grafana 或其他東西。
但： – 所以我們正在談論一場平等的戰鬥，而不是這些快速資料庫的巨大優勢？
股份公司： – 我認為當我們整合時，會有更準確的測試。
但： – 原來的 RRD 去哪了？ 是什麼讓您轉向 SQL 資料庫？ 最初，所有指標都是在 RRD 上收集的。
股份公司： – Zabbix 有 RRD，也許是一個非常古老的版本。 SQL 資料庫一直存在——這是一種經典的方法。 經典的方法是 MySQL、PostgreSQL（它們已經存在很久了）。 我們幾乎從未使用過 SQL 和 RRD 資料庫的通用介面。
一些廣告🙂
感謝您與我們在一起。 你喜歡我們的文章嗎？ 想看更多有趣的內容？ 通過下訂單或推薦給朋友來支持我們， , 我們為您發明的入門級服務器的獨特模擬： （適用於 RAID1 和 RAID10，最多 24 個內核和最多 40GB DDR4）。
Dell R730xd 在阿姆斯特丹的 Equinix Tier IV 數據中心便宜 2 倍？ 只有這裡 在荷蘭！ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 美元起！ 閱讀
來源： www.habr.com