VictoriaMetrics是一個快速且可擴展的DBMS，用於以時間序列的形式儲存和處理資料（一筆記錄由時間和與該時間對應的一組值組成，例如透過定期輪詢感測器或感測器的狀態取得）指標的集合）。
我叫科洛巴耶夫·帕維爾。 DevOps、SRE、LeroyMerlin，一切都像代碼 - 一切都與我們有關：關於我和其他 LeroyMerlin 員工。
有一個基於OpenStack的雲端。 有一個與技術雷達的小連結。
它建構在 Kubernetes 硬體以及 OpenStack 和日誌記錄的所有相關服務上。
這是我們正在開發的計劃。 當我們開發這一切時，我們有一個 Prometheus Operator，它將資料儲存在 K8s 叢集本身內。 粗略地說，他會自動找到需要擦洗的東西並將其放在腳下。
我們需要將所有資料移到 Kubernetes 叢集之外，因為如果發生什麼事情，我們需要了解發生了什麼以及發生在哪裡。
第一個解決方案是，當我們有第三方Prometheus的時候，我們透過聯邦機制去Kubernetes集群的時候，就使用聯邦。
但這裡有一些小問題。 在我們的例子中，當我們有 250 個指標時，問題就開始了，而當有 000 個指標時，我們意識到我們不能那樣工作。 我們將 scrape_timeout 增加到 400 秒。
為什麼我們必須這樣做？ Prometheus 從柵欄的起點開始計算超時時間。 數據仍在流動並不重要。 如果在這段指定的時間內沒有合併資料且沒有透過http關閉會話，則認為會話失敗且資料不會進入Prometheus本身。
每個人都熟悉當某些資料遺失時我們得到的圖表。 日程安排被破壞了，我們對此並不滿意。
下一個選項是透過相同的聯邦機制基於兩個不同的 Prometheus 進行分片。
例如，只需將它們按名稱分片即可。 這也可以使用，但我們決定繼續前進。
我們現在必須以某種方式處理這些碎片。 您可以使用 promxy，它會進入分片區域並乘以資料。 它使用兩個分片作為單一入口點。 這個可以透過promxy來實現，但還是太難了。
第一個選擇是我們要放棄聯邦機制，因為它非常慢。
Prometheus 開發人員明確表示：“夥計們，請使用不同的 TimescaleDB，因為我們不支持指標的長期存儲。” 這不是他們的任務。
我們在一張紙上寫下我們仍然需要卸到外面，以免所有東西都存放在一個地方。
第二個缺點是記憶體消耗。 是的，我知道很多人會說，到 2020 年，幾 GB 的記憶體只需要一分錢，但仍然如此。
現在我們有了開發和生產環境。 在開發中，9 萬個指標大約需要 350 GB。 在產品中，它有 000 GB 和略多於 14 個指標。 同時，我們的保留時間只有780分鐘。 這不好。 現在我將解釋原因。
我們做了一個計算，即有35萬個指標，我們已經接近它們，在設計階段我們獲得37-4GB的記憶體。 但已經有 90 萬個指標需要大約 XNUMX GB 的記憶體。 也就是說，它是使用Prometheus開發人員提供的公式計算的。 我們查看了相關性，並意識到我們不想為僅用於監控的伺服器支付幾百萬美元。
我們不僅會增加機器的數量，還會監控虛擬機器本身。 因此，虛擬機器越多，各種指標就越多，等等。我們的叢集在指標方面會有一個特殊的成長。
對於磁碟空間來說，並不是一切都那麼糟糕，但我想改進它。 我們在 15 天內總共收到了 120 GB，其中 100 個是壓縮數據，20 個是未壓縮數據，但我們總是想要更少。
因此，我們再記下一點——這是一個很大的資源消耗，我們仍然想節省這一點，因為我們不希望我們的監控叢集比我們管理OpenStack的叢集消耗更多的資源。
Prometheus 還有一個缺點，我們已經為自己確定了這一點，這至少是某種記憶體限制。 對普羅米修斯來說，這裡的一切都更糟糕，因為它根本沒有這樣的曲折。 在 docker 中使用限制也不是一個選擇。 如果你的 RAF 突然下降，而有 20-30 GB，那麼需要很長時間才能上升。
這也是Prometheus不適合我們的另一個原因，即我們無法限制記憶體消耗。
提出這樣的方案是可能的。 我們需要這個方案來組織 HA 叢集。 我們希望我們的指標隨時隨地可用，即使儲存這些指標的伺服器崩潰了。 因此我們必須建立這樣一個計劃。
此方案表示，我們將出現分片的重複，相應地，消耗資源的成本也會重複。 它幾乎可以水平擴展，但資源消耗將是地獄般的。
缺點按照我們自己寫下來的形式排列：
- 需要從外部上傳指標。
- 資源消耗高。
- 沒有辦法限制記憶體消耗。
- HA 的實施複雜且資源密集。
對於我們自己來說，我們決定放棄 Prometheus 作為儲存設施。
我們已經為自己確定了我們需要的額外要求。 這：
- 這是 promql 支持，因為很多東西已經為 Prometheus 編寫了：查詢、警報。
- 然後我們有 Grafana，它已經以與 Prometheus 後端完全相同的方式編寫。 我不想重寫儀表板。
- 我們要建構一個正常的HA架構。
- 我們希望減少任何資源的消耗。
- 還有另一個細微差別。 我們不能使用各種類型的雲端指標收集系統。 我們還不知道這些指標會包含哪些內容。 由於任何東西都可以飛到那裡，我們必須將自己限制在本地放置。
幾乎沒有選擇。 我們收集了我們所經歷過的一切。 我們查看了整合部分中的 Prometheus 頁面，閱讀了很多文章，並了解了其中的內容。 對於我們自己來說，我們選擇了 VictoriaMetrics 作為 Prometheus 的替代品。
為什麼？ 因為：
- 懂promql。
- 有一個模組化架構。
- 不需要更改 Grafana。
- 最重要的是，我們可能會在公司內部提供指標儲存作為服務，因此我們正在提前尋求各種限制，以便用戶可以以某種有限的方式使用叢集的所有資源，因為有機會它將實現多租戶。
我們先來做個比較。 我們在群集內部使用相同的 Prometheus，外部 Prometheus 則使用它。 透過remoteWrite VictoriaMetrics 新增。
我會立即保留意見，我們從 VictoriaMetrics 發現 CPU 消耗略有增加。 VictoriaMetrics wiki 告訴您哪些參數最好。 我們檢查了他們。 他們很好地降低了 CPU 消耗。
在我們的例子中，位於 Kubernetes 叢集中的 Prometheus 的記憶體消耗並沒有顯著增加。
我們比較相同資料的兩個資料來源。 在普羅米修斯中我們看到同樣的缺失資料。 VictoriaMetrics 一切都很好。
磁碟空間測試結果。 我們 Prometheus 總共收到了 120 GB。 在 VictoriaMetrics，我們每天已經收到 4 GB 的資料。 它的機制與我們在普羅米修斯中看到的機制略有不同。 也就是說，數據在一天、半小時內就已經壓縮得很好了。 一天、半小時就已經收穫頗豐了，儘管稍後數據還是會遺失。 結果，我們節省了磁碟空間。
我們也節省了記憶體資源消耗。 測試時，我們將 Prometheus 部署在虛擬機器上 - 8 核心、24 GB。 普羅米修斯幾乎吃掉一切。 他摔倒在 OOM Killer 上。 同時，只有 900 萬個活躍指標被注入其中。 這大約是每秒 000-25 個指標。
我們在具有 8 GB RAM 的雙核心虛擬機器上運行 VictoriaMetrics。 我們透過在 8GB 機器上擺弄一些東西，成功地讓 VictoriaMetrics 正常工作。 最終，我們將其保持在 7 GB。 同時，內容即指標的傳遞速度甚至比Prometheus還要快。
CPU相比Prometheus已經變得好很多了。 這裡Prometheus消耗了2,5個核心，而VictoriaMetrics只消耗了0,25個核心。 開始時 - 0,5 個核心。 當它融合時，它會到達一個核心，但這非常非常罕見。
就我們而言，選擇落在了 VictoriaMetrics 身上，原因顯而易見；我們想省錢，我們也這麼做了。
我們先劃掉兩點──指標上傳和資源消耗大。 我們只需要決定剩下的兩點。
這裡我馬上預約一下，我們把VictoriaMetrics看作是指標的儲存。 但由於我們很可能會為所有 Leroy 提供 VictoriaMetrics 作為存儲，因此我們需要限制使用該叢集的人，以免他們將其提供給我們。
有一個很棒的參數，可讓您按時間、資料量和執行時間進行限制。
還有一個很好的選項可以讓我們限制記憶體消耗，從而找到一個平衡點，讓我們獲得正常的運行速度和足夠的資源消耗。
再減去一點，即劃掉這一點——你無法限制記憶體消耗。
在第一次迭代中，我們測試了 VictoriaMetrics 單節點。 接下來我們轉向 VictoriaMetrics 叢集版本。
在這裡，我們可以自由地在 VictoriaMetrics 中分離不同的服務，這取決於它們將運行的內容以及它們將消耗的資源。 這是一個非常靈活、方便的解決方案。 我們自己也用過這個。
VictoriaMetrics Cluster Version的主要元件是vmstsorage。 它們可以有N個。 在我們的例子中，到目前為止有 2 個。
還有 vminsert。 這是一個代理伺服器，它允許我們：在我們告訴它的所有儲存之間安排分片，並且它還允許副本，即您將同時擁有分片和副本。
Vminsert 支援來自 Prometheus 的 OpenTSDB、Graphite、InfluxDB 和 RemoteWrite 協定。
還有vmselect。 它的主要任務是去vmstorage，從其中接收數據，對這些數據進行重複數據刪除並將其提供給客戶端。
有一個奇妙的東西叫做 vmagent。 我們真的很喜歡她。 它允許您像 Prometheus 一樣進行配置，並且仍然像 Prometheus 一樣做所有事情。 也就是說，它從不同的實體和服務收集指標並將其發送到 vminsert。 那麼一切都取決於你。
另一個很棒的服務是 vmalert，它允許您使用 VictoriaMetrics 作為後端，從 vminsert 接收處理後的資料並將其發送到 vmselect。 它本身處理警報以及規則。 對於警報，我們透過 Alertmanager 接收警報。
有一個 wmauth 組件。 我們可能會也可能不會（我們還沒有決定）將其用作多租戶版本集群的授權系統。 它支援Prometheus的remoteWrite，並且可以根據url（或更確切地說是它的第二部分）進行授權，您可以在其中寫入或不能寫入。
還有vmbackup、vmrestore。 這本質上就是所有資料的恢復和備份。 可以做S3、GCS、文件。
我們集群的第一次迭代是在隔離期間進行的。 當時沒有副本，因此我們的迭代由兩個不同且獨立的集群組成，我們透過 RemoteWrite 將資料接收到其中。
這裡我要保留的是，當我們從VictoriaMetrics單節點切換到VictoriaMetrics叢集版本時，我們仍然保持相同的消耗資源，即主要是記憶體。 這大約就是我們的資料（即資源消耗）的分佈方式。
此處已新增副本。 我們將所有這些組合成一個相對較大的群集。 我們所有的資料都被分片和複製。
整個集群有N個入口點，這意味著Prometheus可以透過HAPROXY添加資料。 這裡我們有這個入口點。 透過這個入口點您可以從 Grafana 登入。
在我們的例子中，HAPROXY 是代理此叢集內的選擇、插入和其他服務的唯一連接埠。 在我們的例子中，不可能建立一個位址；我們必須建立多個入口點，因為執行 VictoriaMetrics 叢集的虛擬機器本身位於同一雲端提供者的不同區域，即不在我們的雲端內部，而是在外部。
我們有警報。 我們用它。 我們使用 Prometheus 中的警報管理器。 我們使用 Opsgenie 和 Telegram 作為警報傳遞管道。 在 Telegram 中，他們從開發人員湧入，也許有來自產品的東西，但主要是工程師需要的統計數據。 Opsgenie 至關重要。 這些是呼叫、事件管理。
永恆的問題：“誰來監控監控？” 在我們的例子中，監控監控監控本身，因為我們在每個節點上使用 vmagent。 而且由於我們的節點分佈在同一提供者的不同資料中心，每個資料中心都有自己的通道，它們是獨立的，即使腦裂到來，我們仍然會收到警報。 是的，會有更多警報，但收到更多警報總比沒有警報好。
我們以 HA 實施結束我們的清單。
此外，我想談談與 VictoriaMetrics 社群溝通的經驗。 結果非常積極。 小伙子們反應敏捷。 他們試圖深入研究所提供的每一個案例。
我在 GitHub 上發起了問題。 他們很快就得到了解決。 還有一些問題尚未完全解決，但我已經從程式碼中看到朝這個方向工作的工作正在進行中。
在迭代期間對我來說主要的痛苦是，如果我關閉一個節點，那麼在前 30 秒內 vminsert 無法理解沒有後端。 現在這已經決定了。 從字面上看，在一兩秒內，資料就會從所有剩餘的節點中獲取，並且請求將停止等待遺失的節點。
在某個時候，我們希望 VictoriaMetrics 成為 VictoriaMetrics 運營商。 我們等他。 我們現在正在積極建立一個框架，讓VictoriaMetrics算子將所有的預計算規則等Prometheus拿走，因為我們相當積極地使用Prometheus算子自帶的規則。
有人提出了改進集群實施的建議。 我在上面概述了它們。
我真的很想縮減採樣。 在我們的例子中，只有在查看趨勢時才需要下採樣。 粗略地說，白天有一個指標對我來說就夠了。 這些趨勢需要一年、三年、五年、十年。 一個指標值就夠了。
- 我們和我們的一些同事一樣，都體驗過使用 Prometheus 時的痛苦。
- 我們為自己選擇了VictoriaMetrics。
- 它在垂直和水平方向上都可以很好地縮放。
- 我們可以將不同的元件分佈到集群中不同數量的節點上，透過記憶體限制、添加記憶體等。
我們將在家裡使用 VictoriaMetrics，因為我們真的很喜歡它。 這就是過去和現在的情況。
幾個用於 VictoriaMetrics 聊天、我的聯絡人、LeroyMerlin 技術雷達的二維碼。
來源： www.habr.com