以下是使用示例數據集合的查詢示例列表。我們將說明可能遇到的一些常見查詢類型，以便了解查詢系統的工作原理。示例集合中的每個時間序列都只存儲一個數據點，並且UID已被截斷爲單個字節，以便於閱讀。示例查詢都是來自HTTP API的指標查詢，並且僅顯示m=組件。有關詳細信息，請參閱/api/query。如果使用的是CLI工具，查詢格式會略有不同，請閱讀特定命令的文檔。
| 時間序列 | 指標 | 標籤 | TSUID |
|---|---|---|---|
| 1 | sys.cpu.system | dc=dal host=web01 | 0102040101 |
| 2 | sys.cpu.system | dc=dal host=web02 | 0102040102 |
| 3 | sys.cpu.system | dc=dal host=web03 | 0102040103 |
| 4 | sys.cpu.system | host=web01 | 010101 |
| 5 | sys.cpu.system | host=web01 owner=jdoe | 0101010306 |
| 6 | sys.cpu.system | dc=lax host=web01 | 010102050101 |
| 7 | sys.cpu.system | dc=lax host=web02 | 010102050102 |
| 8 | sys.cpu.system | dc=dal host=web01 | 020202040101 |
| 9 | sys.cpu.system | dc=dal host=web02 | 020202040102 |
UIDS
| Name | UID |
|---|---|
| Metrics | |
| cpu.system | 01 |
| cpu.user | 02 |
| Tagks | |
| host | 01 |
| dc | 02 |
| owner | 03 |
| Tagvs | |
| web01 | 01 |
| web02 | 02 |
| web03 | 03 |
| dal | 04 |
| lax | 05 |
| jdoe | 06 |
警告：
這並不是設置指標和標籤的最佳方式，而是爲了說明查詢系統的工作原理。特別是，TS＃4和5，雖然是合法的時間序列，但可能會搞砸你的查詢，除非你知道它們是如何工作的。一般來說，儘量爲每個時間序列保留相同數量和類型的標籤。
Under the hood
您可能想了解OpenTSDB如何在這裏存儲時間序列數據：存儲。否則，請記住存儲器中的每一行都有一個唯一的格式化的鍵：
<metricID> <normalized_timestamp> <tagkID1> <tagvID1> [... <tagkIDN> <tagvIDN>]上面的數據表將被存儲爲
01 < TS > 0101
01 < TS > 01010306
01 < TS > 02040101
01 < TS > 02040102
01 < TS > 02040103
01 < TS > 02050101
01 < TS > 02050102
02 < TS > 02040101
02 < TS > 02040102當你查詢OpenTSDB時：
- 查詢將被解析並進行驗證，以確保格式正確，並且存在指標，標籤名稱和標籤值。如果系統中不存在單個指標，標籤名稱或值，則會返回錯誤。
- 然後它爲底層存儲系統設置掃描程序。
- 如果查詢沒有任何標籤或標籤值，那麼它將抓取任何匹配的數據行<metricID><timestamp>，因此如果您有特定度量標準的大量時間序列，則這可能是許多行。
- 如果查詢確實定義了一個或多個標記，則它仍將掃描匹配的所有行<metricID><timestamp>，但也會執行正則表達式以僅返回包含所請求標記的行。
- 一旦所有數據都被返回，OpenTSDB將其組織成組，如果需要的話
- 如果要求下采樣，則使用適當的聚合器將每個單獨的時間序列下采樣到更小的時間跨度中
- 然後使用特定的聚合函數聚合每組數據
- 如果rate檢測到該標誌，則會調整每個彙總以獲得匯率。
- 結果返回給調用者