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

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

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

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

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

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

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

作為一款結(jié)構(gòu)化的時(shí)序數(shù)據(jù)庫(kù)，為了能夠達(dá)到最優(yōu)的性能表現(xiàn)，TDengine在接入數(shù)據(jù)前需要根據(jù)數(shù)據(jù)的特性設(shè)計(jì)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ù)訪問(wèn)的事實(shí)數(shù)據(jù)，只要不是臟數(shù)據(jù)，就不會(huì)刪除
• 需要采集的數(shù)據(jù)標(biāo)簽不多，而且固定
• 單條數(shù)據(jù)量約在1KB
• 保存6個(gè)月以上

此外，TDengine的文檔顯示：

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

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

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

具體示例如下：

落地實(shí)施和最終效果展示

因?yàn)槭侨诤弦粋€(gè)全新的數(shù)據(jù)庫(kù)，在真正的落地實(shí)施時(shí)不可避免會(huì)遇到一些問(wèn)題點(diǎn)，以下三點(diǎn)是我們匯總的實(shí)施經(jīng)驗(yàn)，放在本篇文章中給大家做參考：

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

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

• 查詢(xún)問(wèn)題

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

• 容量規(guī)劃

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

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

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

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

寫(xiě)在最后

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

此外，從自身項(xiàng)目和實(shí)踐出發(fā)，我們也有一些針對(duì)于TDengine Database期盼改進(jìn)的功能點(diǎn)：

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

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

最后，衷心祝愿TDengine越來(lái)越好！