OpenStack/Gnocchi簡介——時間序列資料彙總操作提前計算並儲存起來，先算後取的理念

標籤：目前時間   帶來   不能   ceph   多個   檔案   one   接受   back   

先看下 http://www.cnblogs.com/bonelee/p/6236962.html 這裡對於環形資料庫的介紹，便於理解歸檔這個操作！

轉自：http://blog.sina.com.cn/s/blog_6de3aa8a0102wk0y.html

早期的OpenStack監控（遙測）項目ceilometer被一分為四（Ceilometer、Gnocchi、Aodh、Panko），各司其職！其中Ceilometer負責採集計量資料並加工預先處理；Gnocchi主要用來提供資源索引和儲存時序計量資料；Aodh主要提供預警和計量通知服務；Panko主要提供事件儲存服務。促成Ceilometer分裂的主要原因是：早期各類資源的計量資料（即是時間序列資料）（measurement，核心欄位是<</span>時間，值>）儲存在SQL資料庫中的sample表中；隨著雲環境中需要被監控的資源增多和時間的推移，計量資料的增長變得難以預測；計量資料的使用方面，查詢操作首先要從巨大的sample單表中過濾所需條目，然後還會涉及到相關的彙總計算；可想而知，由此帶來的效能開銷絕對是無法忍受的，並且隨著時間的推移這個瓶頸會愈加明顯直至奔潰。要解決上述問題方法有很多，比如分表：每個監控指標（Metirc）一張表，那麼一個資源可能會有多張表（比如一個instance至少會有cpu，cpu.util，memory，memory.usage，disk.* 等監控指標metrics）；這似乎有點誇張，即使這樣都可以接受的話，那麼查詢時對計量資料的彙總操作也還是個問題。

類似的思想，紅帽的Julien Danjou（blog：https://julien.danjou.info/blog/）發起了Gnocchi項目來解決這類問題。其總體思路是：把各個計量指標Metric的計量資料measurement直接寫入後端儲存中；並在measurement寫入之前根據預先設定的歸檔策略進行彙總操作；查詢時直接讀取對應的檔案即可獲得彙總後的監控資訊點，顯然時間複雜度變為O(1)了；並且提供資源索引，這樣能更快的找到每個資源的基礎資訊metadata和其相關的metrics資訊。

OpenStack/Gnocchi簡介和架構[附文檔翻譯]

文檔翻譯（歡迎雅正）：http://gnocchi.xyz

第一部分：Gnocchi簡介 http://gnocchi.xyz/index.html

Gnocchi – Metric as a Service，Gnocchi計量作為一種服務
Gnocchi是一個多租戶時間序列，計量和資源資料庫。提供了HTTP REST介面來建立和操作資料。Gnocchi設計用於超大規模計量資料的儲存，同時向操作者和使用者提供對度量和資源資訊的訪問。
Gnocchi是OpenStack項目的一部分。因此它支援OpenStack，但也能完全獨立的工作。
您可以在 http://gnocchi.xyz上閱讀完整的線上文檔。

Why Gnocchi?為什麼使用Gnocchi？
Gnocchi已被建立滿足在雲端運算環境中可用的時間序列資料庫的需要：提供儲存大量度量資料並且易於擴充的能力。
Gnocchi項目於2014年開始，作為OpenStack Ceilometer項目的分支，以解決Ceilometer在將標準資料庫用作計量資料的儲存後端時遇到的效能問題。更多資訊，請參見Julien的部落格Gnocchi。

Use cases，使用案例
Gnocchi旨在用於儲存時間序列及其相關聯的資源中繼資料。因此，它有用的例子如：
（1）計費系統的儲存；（2）警示觸發或監控系統；（3）資料的統計使用。

Key Features，關鍵特性
HTTP REST介面 水平可擴充性 度量彙總 測量批處理支援 存檔策略 計量值搜尋
結構化資源 資源曆史 可查詢資源索引器 多租戶支援 Grafana支援 Statsd協議支援


第二部分：Gnocchi的架構 http://gnocchi.xyz/architecture.html

Project Architecture，項目架構
Gnocchi由幾個服務組成：一個HTTP REST API（請參閱REST API Usage），可選的statsd相容精靈（請參閱Statsd精靈使用）和非同步處理精靈。 通過HTTP REST API和statsd精靈接收資料。非同步處理精靈（稱為gnocchi-metricd）在後台對接收到的資料執行統計計算，度量標準清除等操作。
HTTP REST API和非同步處理精靈都是無狀態的，並且是可擴充的。可以根據負載添加其它workers。

Back-ends，後端
Gnocchi使用了兩個不同的後端儲存資料：一個用於儲存時間序列（儲存區驅動程式），另一個用於索引資料（索引驅動程式）。
儲存空間負責儲存所建立的度量的計量值measurement。它接收時間戳記和值，並根據定義的歸檔策略預先計算彙總。
索引器負責儲存所有資源的索引，以及它們的類型和屬性。Gnocchi不僅瞭解來自OpenStack項目的資源類型，也提供了一個通用類型，因此您可以建立基本資源並自己處理資源屬性。 索引器還負責將資源與度量指標metric相關聯。

How to choose back-ends，如何選擇後端
Gnocchi目前提供了集中不同的儲存引擎：File，Swift，S3，Ceph（首選）。
Storage的驅動程式基於一個名為Carbonara的中間庫，由該中間庫處理時間序列操作，因為這些儲存技術本身都不能處理時間序列。
四個基於Carbonara的驅動程式運行良好，並且後端技術保證可擴充性。 Ceph和Swift本身就比檔案磁碟機更具可擴充性。
根據您的體繫結構的大小，使用檔案驅動程式並將資料存放區在磁碟上可能就足夠了。 如果需要使用檔案驅動程式擴充伺服器數量，則可以通過NFS在所有Gnocchi進程中匯出和共用資料。在任何情況下，顯然S3，Ceph和Swift驅動程式在很大程度上更具延展性。Ceph還提供了更好的一致性，因此是推薦的驅動程式。

How to plan for Gnocchi’s storage，如何規劃Gnocchi的儲存
Gnocchi使用基於Carbonara庫的自訂檔案格式。在Gnocchi中，時間序列是點的集合，其中點是在時間序列的壽命中的給定測量或樣本。使用各種技術壓縮儲存格式，因此可以基於其最壞情況情況使用以下公式來估計時間序列大小的計算： 點數×8位元組=以位元組為單位的大小
您要保留的點數通常由以下公式確定： 點數=時間跨度÷粒度
例如，如果您想保留一年的資料，一分鐘的解析度： 點數=（365天×24小時×60分鐘）÷1分鐘 = 525 600。然後：位元組大小= 525 600位元組×6 = 3 159 600位元組= 3 085 KiB
這隻是一個彙總時間序列。如果歸檔策略使用具有相同“一年，一分鐘彙總”解析度的6個預設彙總方法（mean，min，max，sum，std，count），則使用的空間將最多增加到6×4.1 MiB = 24.6 MiB。

How to set the archive policy and granularity，如何設定歸檔策略和計量粒度
在Gnocchi中，歸檔策略以點數表示。如果歸檔策略定義了10點的策略，粒度為1秒，則時間序列歸檔將保持長達10秒，每個代表1秒鐘的彙總。這意味著時間序列將最多保留最近點和最舊點之間的10秒資料（有時多一點）。這並不意味著它將是10個連續的秒：如果資料被不規則地時間間隔送達，可能存在間隙。
相對於目前時間戳沒有資料到期。此外，您不能刪除舊的資料點（至少現在）。
因此，存檔策略和粒度完全取決於您的用例。根據資料的使用方式，可以定義多個歸檔策略。典型的低粒度用例可能是：
3600點，粒度為1秒= 1小時
1440點，粒度為1分鐘= 24小時
720點，粒度為1小時= 30天
365分，粒度為1天= 1年
這將表示每種聚集方法6125點×9 = 54 KiB。如果使用8標準彙總方法，您的指標將佔用8×54 KiB = 432 KiB的磁碟空間。

Default archive policies，預設的歸檔策略
預設情況下，使用預設存檔策略（在default_aggregation_methods中列出，即平均值，最小值，最大值，總和，標準值，計數）建立3個歸檔策略：
low（每個metric的最大估計大小：5 KiB）
5分鐘粒度1小時；1小時粒度1天；1天粒度超過1個月
medium（每個metric的最大估計大小：139 KiB）
1分鐘粒度1天；1小時粒度超過1周；1天的粒度超過1年
high（每個metric的最大估計大小：1 578 KiB）
1秒粒度；1分鐘粒度1周；1小時粒度超過1年

OpenStack/Gnocchi簡介——時間序列資料彙總操作提前計算並儲存起來，先算後取的理念