雖然TSDB被設(shè)計為只要有空間就可以存儲原始全分辨率(resolution)的數(shù)據(jù)，但是對于廣泛的時間范圍或在許多標簽組合之上的查詢可能是相當痛苦的。這樣的查詢可能需要很長時間才能完成，或者在最糟糕的情況下，可能會導(dǎo)致內(nèi)存不足的異常。從OpenTSDB 2.4開始，一組新的API允許存儲和查詢較低分辨率的數(shù)據(jù)以更快地回答這樣的查詢。本頁將概述上卷和預(yù)聚合是什么，它們?nèi)绾卧赥SDB中工作以及如何最好地使用它們。查看API部分的具體實現(xiàn)細節(jié)。
注意：
OpenTSDB本身不計算和存儲上卷或預(yù)聚合數(shù)據(jù)。有多種計算結(jié)果的方法，但是根據(jù)規(guī)模和精度要求，它們都有好處和缺點。請參閱生成上卷和預(yù)聚合部分，討論如何創(chuàng)建此數(shù)據(jù)。
為了幫助描述較低分辨率的數(shù)據(jù)，我們來看一些完整的分辨率（也稱為原始數(shù)據(jù)）的示例數(shù)據(jù)。第一個表格用快捷標識符定義時間序列。
| 序列ID | Metric | Tag1 | Tag2 | Tag3 |
|---|---|---|---|---|
| ts1 | system.if.bytes.out | host=web01 | colo=lga | interface=eth0 |
| ts2 | system.if.bytes.out | host=web02 | colo=lga | interface=eth0 |
| ts3 | system.if.bytes.out | host=web03 | colo=sjc | interface=eth0 |
| ts4 | system.if.bytes.out | host=web04 | colo=sjc | interface=eth0 |
請注意，它們都具有相同metric和interface標記，但不同host和colo標簽。
接下來以15分鐘的時間間隔寫出一些數(shù)據(jù)：
| 序列ID | 12:00 | 12:15 | 12:30 | 12:45 | 13:00 | 13:15 | 13:30 | 13: 45 |
|---|---|---|---|---|---|---|---|---|
| ts1 | 1 | 4 | -3 | 8 | 2 | -4 | 5 | 2 |
| ts2 | 7 | 2 | 8 | -9 | 4 | 1 | 1 | |
| ts3 | 9 | 3 | -2 | -1 | 6 | 3 | 8 | 2 |
| ts4 | 2 | 5 | 2 | 8 | 5 | -4 | 7 |
請注意，有些數(shù)據(jù)點丟失。有了這些數(shù)據(jù)集，我們先看看上卷。
在OpenTSDB中，“上卷”被定義為隨著時間的推移聚合匯總的單個時間序列。它也可以被稱為“基于時間的聚合”。上卷幫助解決在廣泛的時間跨度的問題。例如，如果每60秒寫入一個數(shù)據(jù)點并查詢一年的數(shù)據(jù)，則時間序列將返回超過525,000個單獨的數(shù)據(jù)點。圖表會有很多點并且很可能會相當凌亂。相反，可能需要查看較低分辨率的數(shù)據(jù)，例如，只需要8k左右1小時數(shù)據(jù)進行繪圖。然后，可以識別異常并向下鉆取更精細的分辨率數(shù)據(jù)。
如果您已經(jīng)使用OpenTSDB查詢數(shù)據(jù)，則您可能熟悉將每個時間序列聚合為更小或更低分辨率值的降采樣器。上卷實質(zhì)上是系統(tǒng)中存儲的降采樣的結(jié)果，并隨意調(diào)用。每個上卷（或降采樣器）需要兩條信息：
警告
存儲上卷時，最好避免平均值，中值或偏差等函數(shù)(average, median or deviation)。在進一步降采樣或分組聚合時，這些值變得毫無意義。相反，總是存儲總和(sum)和計數(shù)(count)要好得多，至少可以在查詢時計算平均值。有關(guān)更多信息，請參閱下面的部分。
上卷數(shù)據(jù)點的時間戳應(yīng)該捕捉到(snap to)上卷間隔的頂部。例如，如果匯總間隔是1h那么它包含1小時的數(shù)據(jù)，并應(yīng)該快速(snap to)到小時的頂部。（因為所有的時間戳都是用Unix Epoch格式編寫的，定義為UTC時區(qū)，所以這將是一個小時UTC時間的開始）。
對于前述給定的數(shù)據(jù)，使用1h的間隔存儲sum和count。
| 序列ID | 12:00 | 13:00 |
|---|---|---|
| ts1 SUM | 10 | 5 |
| ts1 COUNT | 4 | 4 |
| ts2 SUM | 8 | 6 |
| ts2 COUNT | 4 | 3 |
| ts3 SUM | 9 | 19 |
| ts3 COUNT | 4 | 4 |
| ts4 SUM | 9 | 16 |
| ts4 COUNT | 3 | 4 |
請注意，無論間隔“bucket”中的第一個數(shù)據(jù)點何時出現(xiàn)，所有時間戳都對齊到小時的頂部。另請注意，如果一個數(shù)據(jù)點在一段時間內(nèi)不存在，則計數(shù)較低。
在一般情況下，在每個時間序列存儲上卷時，目標應(yīng)該是計算和存儲MAX，MIN，SUM和COUNT。
當啟用上卷并且請求使用OpenTSDB 的avg函數(shù)的降采樣器時，TSD將掃描存儲中SUM和COUNT值。然后在迭代數(shù)據(jù)的時候，它會精確地計算平均值。
COUNT和SUM值的時間戳必須匹配。但是，如果一個SUM的預(yù)期計數(shù)COUNT值缺失，則SUM將會被踢出結(jié)果。從上面的例子中，現(xiàn)在我們丟失了一個計數(shù)數(shù)據(jù)點ts2。
| 序列ID | 12:00 | 13:00 |
|---|---|---|
| ts1 SUM | 10 | 5 |
| ts1 COUNT | 4 | 4 |
| ts2 SUM | 8 | 6 |
| ts2 COUNT | 4 |
所得到的一個2h降采樣的avg查詢應(yīng)該是這樣的：
| 序列ID | 12:00 |
|---|---|
| ts1 AVG | 1.875 |
| ts2 AVG | 2 |
重慶分公司
重慶分公司
ts1: (10+5)/8=1.875
ts2: 8/4=2雖然上卷可以幫助處理較長時間的查詢，但是如果度量具有較高的基數(shù)（即給定度量的唯一時間序列數(shù)量），仍然可能遇到小范圍查詢性能問題。在上面的例子中，我們有4臺Web服務(wù)器。即使我們有10,000臺服務(wù)器。獲取網(wǎng)絡(luò)流量(interface traffic)的總和或平均值可能會相當慢。如果用戶經(jīng)常拉取大量分組集合（或一些將它作為空間集合）的話，存儲聚合和查詢替代很有意義，這樣會獲取更少的數(shù)據(jù)。
與上卷不同，預(yù)聚合只需要一條額外的信息：
在OpenTSDB中，預(yù)聚合與其他帶有特殊標簽的時間序列不同。默認標簽key是_aggregate（可通過tsd.rollups.agg_tag_key配置）。然后用于生成數(shù)據(jù)的聚合函數(shù)以大寫形式存儲在標簽值中。讓我們看一個例子：
考慮到頂部的示例，我們可能想要查看colo（數(shù)據(jù)中心）的總網(wǎng)絡(luò)流量。在這種情況下，我們可以通過SUM和COUNT聚合，類似于上卷。結(jié)果將是四個伴隨元數(shù)據(jù)的新的時間序列，如：
| 序列ID | Metric | Tag1 | Tag2 |
|---|---|---|---|
| ts1’ | system.if.bytes.out | colo=lga | _aggregate=SUM |
| ts2’ | system.if.bytes.out | colo=lga | _aggregate=COUNT |
| ts3’ | system.if.bytes.out | colo=sjc | _aggregate=SUM |
| ts4’ | system.if.bytes.out | colo=sjc | _aggregate=COUNT |
請注意，這些時間序列已經(jīng)丟棄了host和interface標簽。這是因為，聚合過程中，取了host和interface的多個不同的值，已經(jīng)包裝到這個新的序列，如果再讓他們作為標簽，不會再有意義。另外請注意，我們在存儲的數(shù)據(jù)中注入了新的標簽_aggregate?，F(xiàn)在查詢可以通過指定一個_aggregate值來訪問這些數(shù)據(jù)。
注意：
啟用了上卷后，如果您計劃使用預(yù)聚合，則可能需要通過讓TSDB自動注入_aggregate=RAW來幫助區(qū)分預(yù)聚合中的原始數(shù)據(jù)。只需將tsd.rollups.tag_raw屬性設(shè)置為true。
現(xiàn)在結(jié)果數(shù)據(jù)如下：
| 序列ID | 12:00 | 12:15 | 12:30 | 12:45 | 13:00 | 13:15 | 13:30 | 13:45 |
|---|---|---|---|---|---|---|---|---|
| ts1’ | 8 | 6 | 5 | -1 | 6 | -4 | 6 | 3 |
| ts2’ | 2 | 2 | 2 | 2 | 2 | 1 | 2 | 2 |
| ts3’ | 9 | 5 | 3 | 1 | 14 | 8 | 4 | 9 |
| ts4’ | 1 | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
由于我們正在通過聚合（通過colo分組）來執(zhí)行分組，所以我們?yōu)槊總€時間戳從原始數(shù)據(jù)集中獲取一個值。在這種情況下，我們不采用降采樣或者上卷。
聚合算法：
根據(jù)colo分組，因此ts1與ts2一組，ts3與ts4一組。
ts1’ => SUM: 1+7=8 4+2=6 …
ts2’ => COUNT: 2 2 …
ts3’ => SUM: 9 3+2=5 …
ts4’ => COUNT: 1 2 …警告
和上卷一樣，在編寫預(yù)聚合時，最好避免平均值，中值或偏差等函數(shù)。只是存儲總和和計數(shù)。
雖然預(yù)聚合肯定有助于高基數(shù)的指標，但用戶可能仍然希望查詢訪問廣泛的時間跨度，但遇到緩慢的查詢。謝天謝地，可以像原始數(shù)據(jù)一樣進行上卷預(yù)聚合。只要生成預(yù)聚合，然后使用上面的信息將其上卷起來。
目前，TSD不會為您生成上卷數(shù)據(jù)或預(yù)聚合數(shù)據(jù)。主要原因是意味著OpenTSDB處理大量的時間序列數(shù)據(jù)，所以單個TSD專注于盡可能快地將數(shù)據(jù)存儲到存儲中。
由于TSD的（基本上）無狀態(tài)特性，它們可能不具備用于執(zhí)行預(yù)聚合的全套數(shù)據(jù)。例如，我們的樣本ts1數(shù)據(jù)可能在寫入TSD_A的同時ts2被寫入TSD_B。不從存儲中讀取數(shù)據(jù)，也不能執(zhí)行正確的分組。我們也不知道我們應(yīng)該在什么時候進行預(yù)聚合。我們可以等待1分鐘，然后預(yù)先聚合數(shù)據(jù)，但會錯過那一分鐘后發(fā)生的任何事情?；蛘呶覀兛梢缘却粋€小時，預(yù)先聚合的查詢將不會有最后一個小時的數(shù)據(jù)。如果數(shù)據(jù)來得太晚，會發(fā)生什么？
此外，對于上卷，根據(jù)用戶向TSD寫入數(shù)據(jù)的方式，對于ts1來說，我們可能會收到TSD_A上12:15的數(shù)據(jù)點，但是數(shù)據(jù)在12:30到達了TSD_B，因此整個小時都不需要數(shù)據(jù)(neither has the data required for the full hour)。時間窗口限制也適用于上卷。
使用上卷和預(yù)聚合需要一些分析和各種權(quán)衡之間的選擇。由于一些OpenTSDB用戶已經(jīng)具備了計算這類數(shù)據(jù)的方式和手段，我們只需提供API來存儲和查詢。但是，這里有一些關(guān)于如何自己計算這些的提示。
其他時間序列數(shù)據(jù)庫常用的一種方法是在延遲一段時間后從數(shù)據(jù)庫中讀取數(shù)據(jù)，計算出預(yù)聚合和上卷，然后寫入數(shù)據(jù)。這是解決這個問題的最簡單的方法，在小規(guī)模下運作良好。但是仍然有一些問題：
改進批處理的一些方法包括：
某些數(shù)據(jù)庫使用的另一個選項是將所有數(shù)據(jù)排列在進程中的內(nèi)存中，并在經(jīng)過配置的時間窗口后寫入結(jié)果。但是由于TSD是無狀態(tài)的，通常用戶在其TSD之前放置一個負載均衡器，所以單個TSD可能無法得到整個上卷或預(yù)聚合的所有數(shù)據(jù)進行計算（如上所述）。為了使這種方法起作用，上游收集器必須將計算所需的所有數(shù)據(jù)發(fā)送到特定的TSD。這不是一個困難的任務(wù)，但面臨的問題包括：
一般來說，在Writer上排隊是一個壞主意。避免痛苦。
處理上卷和預(yù)聚合的一種更好的方法是將數(shù)據(jù)發(fā)送到流處理系統(tǒng)，在那里它可以被近乎實時地處理并寫入到TSD中。它類似于TSD上的排隊選項，但使用無數(shù)的流處理框架之一（Storm，F(xiàn)link，Spark等）來處理消息路由和內(nèi)存中的存儲。然后，您只需編寫一些代碼來計算聚合，并在窗口過去后將數(shù)據(jù)吐出。
這是許多下一代監(jiān)控解決方案所使用的解決方案，例如雅虎！雅虎正在努力為需要大規(guī)模監(jiān)控的其他人開放流處理系統(tǒng)，并將其整齊地插入到TSDB中。
雖然流處理更好，但您仍然遇到以下問題：
如果您有計算聚合的工作代碼，請與OpenTSDB組共享。如果您的解決方案是開源的，我們可能會將其納入OpenTSDB生態(tài)系統(tǒng)。
對于Opentsdb 2.4，上卷配置由opentsdb.conf中的Key tsd.rollups.config引用。此鍵的值必須是引號轉(zhuǎn)義的JSON字符串，不帶換行符，或者最好是包含配置的JSON文件的路徑。文件名必須如rollup_config.json一樣以.json 結(jié)尾。
JSON配置應(yīng)該如下所示：
{
"aggregationIds": {
"sum": 0,
"count": 1,
"min": 2,
"max": 3
},
"intervals": [{
"table": "tsdb",
"preAggregationTable": "tsdb-preagg",
"interval": "1m",
"rowSpan": "1h",
"defaultInterval": true
}, {
"table": "tsdb-rollup-1h",
"preAggregationTable": "tsdb-rollup-preagg-1h",
"interval": "1h",
"rowSpan": "1d"
}]
}兩個頂級的字段包括：
aggregationIds: 將OpenTSDB聚合函數(shù)名稱映射到用于壓縮存儲的數(shù)字標識符的映射。
intervals: 包含表名和間隔定義的一個或多個間隔定義的列表。
aggregation ids映射用于通過將每種類型的上卷數(shù)據(jù)預(yù)先加上數(shù)字ID來減少存儲量，而不是拼出完整的匯總函數(shù)。例如，如果我們COUNT:為每個值的每個列（或壓縮列）添加6個字節(jié)，我們可以使用一個ID保存。
ID必須是從0到127的整數(shù)。這意味著我們可以在每個間隔中存儲多達128個不同的上卷。在map中只能為每個數(shù)值提供一個ID，并且只能為每個類型給定一個聚合函數(shù)。如果函數(shù)名稱沒有映射到OpenTSDB支持的聚合函數(shù)，則會在啟動時引發(fā)異常。同樣，至少要給定一個聚合，才能啟動TSD。
警告
一旦開始寫入數(shù)據(jù)，聚合ID將無法更改。如果更改映射，則可能會返回不正確的數(shù)據(jù)，或者查詢和寫入操作可能會失敗。您可以隨時添加函數(shù)，但不能改變映射。
每個間隔對象都定義了表格路由，以便上卷和預(yù)先聚合的數(shù)據(jù)寫入并查詢。有兩種類型的間隔：
應(yīng)該定義下列字段：
| 名稱 | 數(shù)據(jù)類型 | Required | 描述 | 示例 |
|---|---|---|---|---|
| table | String | Required | 非預(yù)先匯總的數(shù)據(jù)的基礎(chǔ)或上卷表。對于默認表，應(yīng)該是tsdb或現(xiàn)有的原始數(shù)據(jù)被寫入的表。對于上卷的數(shù)據(jù)，它必須與原始數(shù)據(jù)不同表。 | tsdb-rollup-1h |
| preAggregationTable | String | Required | 應(yīng)該寫入預(yù)先聚合的數(shù)據(jù)和（可選）上卷數(shù)據(jù)的表。它可能與table值相同，為同一張表。 | tsdb-rollup-preagg-1h |
| interval | String | Required | 格式為“ | 1h |
| rowSpan | String | Required | 存儲中每行的寬度。此值必須大于interval和interval中定義的數(shù)字。 例如，如果interval是1h,rowSpan是1天，則每行會有24個值。 | 1d |
| defaultInterval | Boolean | Optional | 是否將配置的時間間隔作為原始未滾動數(shù)據(jù)的默認值。 | true |
在存儲中，上卷的編寫類似于原始數(shù)據(jù)，每行都有一個基準時間戳，每個數(shù)據(jù)點是相對于基準時間的偏移量。每個偏移量都是基準時間以外的增量，而不是實際的偏移量。例如，如果一行存儲1天of 1小時的數(shù)據(jù)，則會有多達24個偏移量。偏移0將映射到午夜的行，偏移量5將映射到上午6點。因為上卷偏移量是以14位編碼的，所以如果一行中存儲的間隔太多以便適應(yīng)14位，TSD啟動時會引發(fā)錯誤。
警告
將數(shù)據(jù)寫入TSD之后，不要更改上卷間隔的間隔寬度或行跨度。這將導(dǎo)致垃圾數(shù)據(jù)和可能失敗的查詢。
另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機、免備案服務(wù)器”等云主機租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。
