趙運周 / 轉(zhuǎn)轉(zhuǎn)

在轉(zhuǎn)轉(zhuǎn)的業(yè)務(wù)中，我們使用了Nginx作為我們的反向代理，為保證代理層可用性，需要對Nginx進行實時狀態(tài)監(jiān)控。在服務(wù)器的基礎(chǔ)監(jiān)控的選擇上，我們將OpenFalcon逐步替換為夜鶯，對Nginx 的reqstat監(jiān)控最初也使用了這兩種。但是這兩大監(jiān)控都有一個共同缺點，即在展示時有條數(shù)限制，導(dǎo)致域名數(shù)量和機器數(shù)量相乘后數(shù)據(jù)量增多的情況下，無法滿足需求。

為了解決這個問題，我們考慮對現(xiàn)有監(jiān)控模塊進行升級改造，重新進行數(shù)據(jù)庫選型，在預(yù)研和分析階段，根據(jù)當(dāng)前的業(yè)務(wù)需求我們從開源的數(shù)據(jù)庫中選擇了兩款時序數(shù)據(jù)庫（Time-Series Database），分別是InfluxDB和TDengine，這兩款都可以實現(xiàn)高性能地查詢與存儲時序性數(shù)據(jù)，但TDengine相比于InfluxDB還存在三點優(yōu)勢：

• 集群功能已經(jīng)開源，支持橫向擴展以及高可用
• 性能和成本之間的平衡達到最優(yōu)化，運維難度顯著降低
• 其超級表特別適合我們這個以域名為維度的監(jiān)控方案

通過綜合對比，我們初步選定TDengine作為監(jiān)控模塊的數(shù)據(jù)庫。此外，濤思官方的測試結(jié)果顯示，TDengine的寫入速度高于InfluxDB，這一點也更加堅定了我們選擇TDengine的決定。

而且TDengine支持多種數(shù)據(jù)接口，包含C/C++、Java、Python、Go和RESTful等。轉(zhuǎn)轉(zhuǎn)之前的服務(wù)用的是Python，所以這也方便我們依舊延續(xù)使用Python connector。

使用TDengine進行數(shù)據(jù)庫建模

作為一款結(jié)構(gòu)化的時序數(shù)據(jù)庫，為了能夠達到最優(yōu)的性能表現(xiàn)，TDengine在接入數(shù)據(jù)前需要根據(jù)數(shù)據(jù)的特性設(shè)計schema。 Nginx監(jiān)控功能數(shù)據(jù)特性如下：

• 數(shù)據(jù)格式固定：配置好req_status_zone之后，日志文件就固定住了，但總的字段數(shù)是有限的，樣例如下：

zone_name   key max_active  max_bw  traffic requests    active  bandwidth
server_addr 192.168.187.164 2    432    17K 18  1    0
server_name 192.168.187.164 2    432    17K 18  1    0
server_url  192.168.187.164/    1    0   0  8   0    0
server_url  192.168.187.164/index.html  1    0  11K 8   0    0
server_url  192.168.187.164/req-status  1    0   0  1   1    0
server_url  192.168.187.164/req_status  1    0   5680   1   0    0

• 數(shù)據(jù)極少需要更新或刪除
  • 屬于服務(wù)訪問的事實數(shù)據(jù)，只要不是臟數(shù)據(jù)，就不會刪除
• 需要采集的數(shù)據(jù)標(biāo)簽不多，而且固定
• 單條數(shù)據(jù)量約在1KB
• 保存6個月以上

此外，TDengine的文檔顯示：

TDengine 對每個數(shù)據(jù)采集點單獨建表，但在實際應(yīng)用中經(jīng)常需要對不同的采集點數(shù)據(jù)進行聚合。為高效的進行聚合操作，TDengine 引入超級表（STable）的概念。超級表用來代表一特定類型的數(shù)據(jù)采集點，它是包含多張表的表集合，集合里每張表的模式（schema）完全一致，但每張表都帶有自己的靜態(tài)標(biāo)簽，標(biāo)簽可以有多個，可以隨時增加、刪除和修改。

按照其建議的數(shù)據(jù)模型，我們需要建立一個超級表。結(jié)合我們的數(shù)據(jù)特點和使用場景，創(chuàng)建數(shù)據(jù)模型如下：

• 超級表：以指標(biāo)作為超級表
• 子表：每個域名做一個子表
  • 標(biāo)簽tag：直接將標(biāo)簽信息作為超級表的標(biāo)簽列
• 列column：監(jiān)控數(shù)據(jù)本身除去標(biāo)簽部分

具體示例如下：

落地實施和最終效果展示

因為是融合一個全新的數(shù)據(jù)庫，在真正的落地實施時不可避免會遇到一些問題點，以下三點是我們匯總的實施經(jīng)驗，放在本篇文章中給大家做參考：

• 數(shù)據(jù)寫入

在數(shù)據(jù)寫入的階段，我們開始設(shè)計的是一個域名一個子表，但是直接使用域名做表名不符合保留字符的規(guī)范，所以需要將域名轉(zhuǎn)換一下。

• 查詢問題

由于寫入的數(shù)據(jù)是實時的值，而監(jiān)控業(yè)務(wù)更多地是需要獲取前后差值，因此需要用上TDengine自帶的函數(shù)DIFF。官方從2.1.3.0 版本開始，DIFF 函數(shù)可以由GROUP BY 劃分出單獨時間線的情況下用于超級表（也即 GROUP BY TBNAME）。而且TDengine的超級表極大程度上簡化了查詢代碼，其分片特性也保證了同時查詢多個域名能夠做到充分地多核并發(fā)。

• 容量規(guī)劃

在落地過程中，我們發(fā)現(xiàn)數(shù)據(jù)類型、數(shù)據(jù)規(guī)模對TDengine的性能影響比較大，最好根據(jù)每個場景的特性進行容量規(guī)劃，影響因素包括：

1. 表數(shù)量
2. 數(shù)據(jù)長度
3. 副本數(shù)
4. 表活躍度等

從這些因素出發(fā)調(diào)整配置參數(shù)能夠確保最佳性能，在與濤思數(shù)據(jù)工程師溝通后，我們確定了現(xiàn)在的容量規(guī)劃計算模型。值得注意的是，TDengine容量規(guī)劃的難點在于內(nèi)存的規(guī)劃，需要在內(nèi)存的使用和讀寫性能之間進行平衡。 連接TDengine后，我們目前系統(tǒng)的拓撲結(jié)構(gòu)如下：

使用TDengine完成改造后，線上的監(jiān)控狀態(tài)達到預(yù)期，滿足當(dāng)前業(yè)務(wù)需求，目前運行非常穩(wěn)定。且配合Grafana后，每個域名的流量、連接數(shù)、響應(yīng)時間等信息都能夠?qū)崟r監(jiān)控到。

寫在最后

總而言之，無論是在成本和性能層面，還是在使用的便利性方面，TDengine Database都具有非常大的優(yōu)勢，在我們的實踐中也得到了證明，尤其是成本管控上效果非常顯著。同時，也非常感謝濤思數(shù)據(jù)的小伙伴們提供的專業(yè)、及時的幫助，我們也希望未來TDengine Database能夠開拓出更多更加優(yōu)秀的新特性。當(dāng)然，作為TDengine的使用者，我們也會在GitHub上為TDengine做代碼貢獻。

此外，從自身項目和實踐出發(fā)，我們也有一些針對于TDengine Database期盼改進的功能點：

• 對表名支持更友好：能夠減少對特殊字符的屏蔽（據(jù)說在后續(xù)版本中會實現(xiàn)，這樣就更貼近場景，省去了應(yīng)用端的特殊處理）
• 支持更加豐富的SQL語句：能夠針對少有的場景，提供更加靈活的SQL語句，便于做更加復(fù)雜的計算分析，這也是AIOps的進階部分
• 灰度平滑升級：目前TDengine保持著2周一次的發(fā)版節(jié)奏，還是期望能夠快速用上新的特性。但是每次停機升級又會是一個麻煩的事情，期待官方早日支持滾動升級
• 可實現(xiàn)自定義聚合方法：由于時間問題，沒趕上官方的UDF特性。期望官方的UDF能夠早日發(fā)布，好實現(xiàn)更加復(fù)雜的聚合計算
• 子表自動清理功能：由于域名會存在下線問題，目前的TTL策略只是針對數(shù)據(jù)而不是Table本身，淘汰子表還需要人工運維介入

盡管還存在不足，但作為首次嘗試，TDengine的表現(xiàn)可以說是相當(dāng)不錯了，我們也很期待未來能夠在更多場景中和TDengine展開合作，包括更多監(jiān)控項以及業(yè)務(wù)時序數(shù)據(jù)庫需求的接入嘗試。

最后，衷心祝愿TDengine越來越好！