主持人 > 博客 > 管理 > 指標儲存：我們如何從 Graphite+Whisper 切換到 Graphite+ClickHouse

指標儲存：我們如何從 Graphite+Whisper 切換到 Graphite+ClickHouse

大家好！ 在他的 上一篇文章 我寫了一篇關於為微服務架構組織模組化監控系統的文章。 沒有什麼是靜止的，我們的專案不斷增長，儲存的指標數量也在不斷增長。 我們如何在高負載條件下組織從 Graphite+Whisper 到 Graphite+ClickHouse 的過渡，了解其期望以及削減後的遷移結果。

指標儲存：我們如何從 Graphite+Whisper 切換到 Graphite+ClickHouse

在我告訴您我們如何組織從在 Graphite+Whisper 中存儲指標到 Graphite+ClickHouse 的過渡之前，我想先介紹一下做出這樣的決定的原因以及我們長期以來一直忍受的 Whisper 的缺點。

石墨+耳語問題

1. 磁碟子系統負載過高

在過渡時，每分鐘大約有 1.5 萬個指標到達我們。 在這樣的流程下，伺服器上的磁碟利用率約為 30%。 總的來說，這是完全可以接受的- 一切都運行穩定，寫入速度快，讀取速度快......直到其中一個開發團隊推出了一項新功能並開始每分鐘向我們發送10 萬個指標。 就在那時，磁碟子系統收緊了，我們看到了 100% 的利用率。 問題很快就解決了解決，但仍有殘留。

2. 缺乏複製性和一致性

最有可能的是，就像每個使用 Graphite+Whisper 的人一樣，我們將相同的指標流同時倒入多個 Graphite 伺服器上，以建立容錯能力。 這並沒有什麼特別的問題 - 直到其中一台伺服器因某種原因崩潰的那一刻。 有時我們設法足夠快地恢復掉下的伺服器，並且carbon-c-relay設法將其快取中的指標加載到其中，但有時卻不能。 然後指標中出現了一個漏洞，我們用 rsync 填補了這個漏洞。 整個過程相當漫長。 唯一可取之處是這種情況很少發生。 我們還定期獲取一組隨機指標，並將它們與集群相鄰節點上相同類型的其他指標進行比較。 在大約 5% 的情況下，幾個值是不同的，我們對此不太滿意。

3、佔地面積大

由於我們不僅用Graphite 編寫基礎設施，還用Graphite 編寫業務指標（現在還包括來自Kubernetes 的指標），因此我們經常會遇到這樣的情況：指標僅包含幾個值，而創建.wsp 文件時考慮了所有保留期間，並佔用預先分配的空間量，對我們來說約為 2MB。 隨著時間的推移，出現大量類似的文件，並且在基於這些文件建立報告時，讀取空點需要花費大量時間和資源，這一事實進一步加劇了問題。

我想立即指出，上述問題可以使用各種方法來處理，並具有不同程度的有效性，但是您開始收到的數據越多，問題就越嚴重。

具備上述所有條件（考慮到先前的 文章），以及接收到的指標數量不斷增加，希望將所有指標傳輸到 30 秒的儲存間隔。 （如有必要，最多 10 秒），我們決定嘗試 Graphite+ClickHouse 作為 Whisper 的有前途的替代方案。

石墨+ClickHouse。 期望

參觀過 Yandex 人員的幾次聚會，閱讀過 幾篇關於哈布雷的文章，在瀏覽了文件並找到了在 Graphite 下綁定 ClickHouse 的合理元件後，我們決定採取行動！

我希望收到以下訊息：

  • 將磁碟子系統利用率從 30% 降低至 5%；
  • 將佔用空間從 1TB 減少到 100GB；
  • 能夠每分鐘將 100 億個指標接收到伺服器中；
  • 開箱即用的資料複製和容錯；
  • 不要在這個項目上等待一年，並在合理的時間範圍內進行過渡；
  • 無需停機即可切換。

相當雄心勃勃，對吧？

石墨+ClickHouse。 成分

為了透過 Graphite 協定接收資料並隨後記錄在 ClickHouse 中，我選擇了 碳點擊屋 （戈蘭）。

選擇ClickHouse的最新版本，穩定版本1.1.54253作為儲存時間序列的資料庫。 使用它時遇到了問題：大量錯誤湧入日誌中，並且不完全清楚如何處理它們。 正在討論中 羅蒙諾索夫 （carbon-clickhouse、graphite-clickhouse 等等的作者）選擇了較舊的 發布1.1.54236。 錯誤消失了——一切都開始順利進行。

選擇從ClickHouse讀取數據 石墨-Clickhouse （戈蘭）。 作為 Graphite 的 API - 碳API （戈蘭）。 ClickHouse用於組織表之間的複製 動物園管理員。 對於路由指標，我們留下了我們心愛的人 碳-C-繼電器 （和） （見上一篇文章）.

石墨+ClickHouse。 表結構

「graphite」是我們為監控表所建立的資料庫。

“graphite.metrics” - 具有 ReplicatedReplacingMergeTree 引擎的表（複製 替換MergeTree）。 此表儲存指標的名稱及其路徑。

CREATE TABLE graphite.metrics ( Date Date, Level UInt32, Path String, Deleted UInt8, Version UInt32 ) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/replicator/graphite.metrics', ‘r1’, Date, (Level, Path), 8192, Version);

“graphite.data” - 具有 ReplicatedGraphiteMergeTree 引擎的表格（複製 石墨合併樹）。 該表儲存度量值。

CREATE TABLE graphite.data ( Path String, Value Float64, Time UInt32, Date Date, Timestamp UInt32 ) ENGINE = ReplicatedGraphiteMergeTree('/clickhouse/tables/replicator/graphite.data', 'r1', Date, (Path, Time), 8192, 'graphite_rollup')

「graphite.date_metrics」是一個使用 ReplicatedReplacingMergeTree 引擎進行條件填充的表。 表格記錄了當天遇到的所有指標的名稱。 創建它的原因在章節中描述 “問題” 在本文的最後。

CREATE MATERIALIZED VIEW graphite.date_metrics ( Path String,  Level UInt32,  Date Date) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/replicator/graphite.date_metrics', 'r1', Date, (Level, Path, Date), 8192) AS SELECT toUInt32(length(splitByChar('.', Path))) AS Level, Date, Path FROM graphite.data

“graphite.data_stat” - 根據條件填滿的表，使用 ReplicatedAggregatingMergeTree 引擎（複製 聚合合併樹）。 此表記錄傳入指標的數量，分為 4 個巢狀層級。

CREATE MATERIALIZED VIEW graphite.data_stat ( Date Date,  Prefix String,  Timestamp UInt32,  Count AggregateFunction(count)) ENGINE = ReplicatedAggregatingMergeTree('/clickhouse/tables/replicator/graphite.data_stat', 'r1', Date, (Timestamp, Prefix), 8192) AS SELECT toStartOfMonth(now()) AS Date, replaceRegexpOne(Path, '^([^.]+.[^.]+.[^.]+).*$', '1') AS Prefix, toUInt32(toStartOfMinute(toDateTime(Timestamp))) AS Timestamp, countState() AS Count FROM graphite.data  GROUP BY Timestamp, Prefix

石墨+ClickHouse。 組件互動圖

指標儲存：我們如何從 Graphite+Whisper 切換到 Graphite+ClickHouse

石墨+ClickHouse。 資料遷移

正如我們對這個專案的期望所記得的那樣，向 ClickHouse 的過渡應該不會造成停機；因此，我們必須以某種方式對用戶盡可能透明地將整個監控系統切換到新儲存。
我們就是這樣做的。

  • Carbon-c-relay 中新增了一條規則，用於將額外的指標流傳送到參與 ClickHouse 表複製的其中一台伺服器的 Carbon-Clickhouse。

  • 我們用 python 編寫了一個小腳本，它使用 Whisper-dump 庫從我們的存儲中讀取所有 .wsp 文件，並通過 24 個線程將該數據發送到上述的carbon-clickhouse。 Carbon-Clickhouse 中接受的指標值數量達到了 125 億/分鐘，ClickHouse 甚至不費吹灰之力。

  • 我們在 Grafana 中建立了一個單獨的資料來源來調試現有儀表板中使用的功能。 我們確定了我們使用的函數列表，但它們並未在carbonapi中實現。 我們添加了這些功能並向carbonapi的作者發送了PR（特別感謝他們）。

  • 為了切換平衡器設定中的讀取負載，我們將端點從graphite-api（Graphite+Whisper的API介面）變更為carbonapi。

石墨+ClickHouse。 結果

  • 將磁碟子系統利用率從 30% 降低至 1%；

    指標儲存：我們如何從 Graphite+Whisper 切換到 Graphite+ClickHouse

  • 將佔用空間從 1 TB 減少到 300 GB；
  • 我們有能力每分鐘將 125 億個指標接收到伺服器中（遷移時的峰值）；
  • 將所有指標轉移到三十秒的儲存間隔；
  • 接收資料的複製和容錯；
  • 無需停機即可切換；
  • 完成所有工作大約需要 7 週。

石墨+ClickHouse。 問題

在我們的例子中，存在一些陷阱。 這是我們轉型後遇到的情況。

  1. ClickHouse 並不總是即時重新讀取配置；有時需要重新啟動。 例如，對於 ClickHouse 配置中的 Zookeeper 叢集的描述，直到 clickhouse-server 重新啟動後才使用它。
  2. 大型 ClickHouse 請求沒有通過，因此在石墨-clickhouse 中，我們的 ClickHouse 連接字串如下所示： 
    url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"
  3. ClickHouse 經常發布穩定版本的新版本；它們可能包含驚喜：要小心。
  4. kubernetes 中動態建立的容器會傳送大量生命週期短且隨機的指標。 這樣的指標點數不多，空間也不存在問題。 但是在建立查詢時，ClickHouse 會從「指標」表中取得大量相同的指標。 在 90% 的情況下，在視窗（24 小時）之外沒有關於它們的數據。 但是時間花在了在「數據」表中搜尋這些數據，最終會遇到超時。 為了解決這個問題，我們開始維護一個單獨的視圖，其中包含當天遇到的指標資訊。 因此，在動態建立的容器上建立報告（圖表）時，我們僅查詢給定視窗內遇到的指標，而不是整個時間，這顯著加快了報告的建置速度。 對於上述解決方案，我收集了 石墨-clickhouse（叉子），其中包括使用 date_metrics 表的實作。

石墨+ClickHouse。 標籤

隨著版本 1.1.0 Graphite 正式上線 支援標籤。 我們正在積極思考如何以及如何支援石墨+clickhouse 堆疊中的這項舉措。

石墨+ClickHouse。 異常檢測器

基於上述基礎設施，我們實現了異​​常檢測器的原型，並且它可以工作！ 但下一篇文章將詳細介紹他。

訂閱，按向上箭頭並快樂！

來源： www.habr.com

添加評論