16 個數據機、4 個蜂窩運營商 = 傳出速度 933.45 Mbit/s
介紹
你好！ 這篇文章是關於我們如何為自己寫一個新的監控系統的。 它與現有的不同之處在於它能夠獲取高頻同步指標並且資源消耗非常低。 輪詢速率可達0.1毫秒，指標間的同步精度為10奈秒。 所有二進位檔案佔用 6 MB。
關於
我們有一個相當具體的產品。 我們提供了一個全面的解決方案來總結資料傳輸通道的吞吐量和容錯能力。 這是當有多個通道時，比方說 Operator1 (40Mbit/s) + Operator2 (30Mbit/s)+ Something else (5 Mbit/s)，結果是一個穩定且快速的通道，其速度將類似於這個： (40+30+5)x0.92=75×0.92=69Mbit/s。
當任何一個通道的容量不足時，就需要這樣的解決方案。 例如，交通、視訊監控系統和即時視訊串流、直播電視和廣播廣播、電信營運商中只有四大代表且一個調製解調器/通道的速度不夠的任何郊區設施。
對於每個領域，我們都生產單獨的設備系列，但它們的軟體部分幾乎相同，高品質的監控系統是其主要模組之一，如果沒有正確的實施，該產品就不可能實現。
經過幾年的時間，我們成功創造了一個多層次、快速、跨平台、輕量級的監控系統。 這就是我們想要與我們尊敬的社群分享的內容。
制定問題
監控系統提供兩個根本不同類別的指標：即時指標和所有其他指標。 監控系統僅有以下要求：
- 高頻同步擷取即時指標並無延遲傳輸至通訊管理系統。
不同指標的高頻和同步不僅重要，對於分析資料傳輸通道的熵也至關重要。 如果在一個資料傳輸通道中平均延遲為 30 毫秒，則其餘度量之間僅 5 毫秒的同步誤差將導致最終通道的速度下降約 1%。 如果我們在 4 個通道上錯時 30 毫秒，速度下降很容易下降到 0.5%。 此外，通道中的熵變化非常快，因此如果我們測量它的頻率少於每 500 毫秒一次，那麼在延遲較小的快速通道上，我們將得到高速退化。 當然，並非所有指標和所有條件都需要這樣的準確性。 當通道中的延遲為 1 毫秒時，並且我們使用這樣的延遲，那麼 2 毫秒的誤差幾乎不會被注意到。 另外，對於維生系統指標，我們有足夠的XNUMX秒輪詢和同步速率，但監控系統本身必須能夠支援超高輪詢速率和超精確的指標同步。 - 最少的資源消耗和單一堆疊。
終端設備可以是功能強大的車載綜合體，可以分析道路情況或對人員進行生物識別記錄，也可以是手掌大小的單板計算機，特種部隊士兵佩戴在防彈衣下，用於傳輸視頻在通信條件較差的情況下實現即時。 儘管架構和運算能力多種多樣，但我們希望擁有相同的軟體堆疊。 - 傘式架構
指標必須在終端設備上收集和聚合、本地存儲，並即時和回顧性地可視化。 如果有連接，則將資料傳輸到中央監控系統。 當沒有連線時，發送佇列應該累積並且不消耗RAM。 - 用於整合到客戶監控系統中的API，因為沒有人需要許多監控系統。 客戶必須將來自任何裝置和網路的資料收集到單一監控中。
發生了什麼事
為了不給已經令人印象深刻的長讀帶來負擔，我不會給出所有監控系統的範例和測量結果。 這將導致另一篇文章。 我只想說，我們無法找到一個能夠同時獲取兩個指標且誤差小於 1 毫秒的監控系統，並且在具有 64 MB RAM 的 ARM 架構和具有 86 MB RAM 的 x64_32 架構上同樣有效地工作。GB 內存。 因此，我們決定自己寫，它可以完成這一切。 這是我們得到的：
總結不同網路拓撲的三個通道的吞吐量
一些關鍵指標的可視化
架構
我們在設備和資料中心都使用 Golang 作為主要程式語言。 它透過實現多任務處理以及為每項服務獲取靜態連結的可執行二進位檔案的能力，極大地簡化了生活。 因此，我們顯著節省了將服務部署到終端設備的資源、方法和流量、開發時間和程式碼偵錯。
該系統按照經典的模組化原理實現，包含多個子系統：
- 指標註冊。
每個指標都由其自己的線程提供服務並跨通道同步。 我們能夠實現高達 10 奈秒的同步精度。 - 指標存儲
我們正在選擇編寫自己的時間序列儲存或使用已經可用的東西。 此資料庫需要用於後續可視化的回顧性數據，即不包含通道中每0.5毫秒的延遲數據或傳輸網路中的錯誤讀數，但包含每個介面每500毫秒的速度。 除了跨平台要求高、資源消耗低之外，處理能力對我們來說也是極為重要的。 資料是它儲存的地方。 這節省了大量的運算資源。 自 2016 年以來，我們一直在這個專案中使用 Tarantool DBMS，到目前為止，我們還沒有看到它的替代品。 靈活，具有最佳的資源消耗，充足的技術支援。 Tarantool 也實作了 GIS 模組。 當然，它不如 PostGIS 那麼強大，但對於我們儲存一些與位置相關的指標（與交通相關）的任務來說已經足夠了。 - 指標視覺化
這裡一切都比較簡單。 我們從倉庫獲取資料並即時或回顧性地顯示它。 - 與中央監控系統資料同步。
中央監控系統接收來自所有設備的數據，將其儲存在指定的歷史記錄中，並透過 API 將其發送到客戶的監控系統。 與「頭部」四處走動並收集數據的經典監控系統不同，我們有相反的方案。 當存在連接時，設備本身會發送資料。 這是非常重要的一點，因為它允許您在設備不可用的時間段內從設備接收數據，並且在設備不可用時不載入通道和資源。 我們使用Influx監控伺服器作為中央監控系統。 與它的類似物不同，它可以導入回顧性資料（即，具有與接收指標時不同的時間戳記）。收集的指標由 Grafana 視覺化，並使用文件進行修改。 選擇此標準堆疊的另一個原因是它具有與幾乎所有客戶監控系統的現成 API 整合。 - 與中央設備管理系統的資料同步。
設備管理系統實現零接觸配置（更新韌體、配置等），並且與監控系統不同，它僅接收每個設備的問題。 這些是板載硬體看門狗服務操作和生命維持系統所有指標的觸發器：CPU 和 SSD 溫度、CPU 負載、可用空間和磁碟上的 SMART 運作狀況。 子系統儲存也是基於 Tarantool 建構的。 這使我們能夠以顯著的速度聚合數千個設備上的時間序列，並且還徹底解決了與這些設備同步資料的問題。 Tarantool 擁有出色的排隊和有保障的交付系統。 我們開箱即用了這個重要的功能，太棒了！
網路管理系統
下一步是什麼
到目前為止，我們最薄弱的環節是中央監控系統。 它在標準堆疊上實現了 99.9%，但有許多缺點：
- 斷電時，InfluxDB 會遺失資料。 通常，客戶會立即收集來自設備的所有內容，並且資料庫本身不包含超過 5 分鐘的數據，但將來這可能會變得很痛苦。
- Grafana 在資料聚合和顯示同步方面存在許多問題。 最常見的問題是，當資料庫包含從 2:00:00 開始、間隔為 00 秒的時間序列時，Grafana 從 +1 秒開始顯示聚合資料。 結果，用戶看到了跳舞的圖表。
- 與第三方監控系統的API整合程式碼量過多。 它可以變得更加緊湊，當然可以用 Go 重寫）
我想你們都已經清楚地看到了 Grafana 的樣子，並且即使沒有我也知道它的問題，所以我不會在帖子中放太多圖片。
結論
我故意不描述技術細節，只描述這個系統的基本設計。 首先，為了從技術上全面描述該系統，需要另一篇文章。 其次，並不是所有人都會對此感興趣。 在評論中寫下您想了解的技術細節。
如果有人有超出本文範圍的問題，可以寫信給我：[email protected]
來源： www.habr.com