趙運周 / 轉轉

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

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

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

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

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

使用TDengine進行數據庫建模

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

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

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

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

此外，TDengine的文檔顯示：

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

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

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

具體示例如下：

落地實施和最終效果展示

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

• 數據寫入

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

• 查詢問題

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

• 容量規(guī)劃

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

1. 表數量
2. 數據長度
3. 副本數
4. 表活躍度等

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

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

寫在最后

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

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

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

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

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