對于互聯網業務而言，為保證服務的穩定運行，就要時刻關注服務器、服務調用、網絡狀況等各項指標，單是監控數據就存在非常大的量級。為了應對這種挑戰，結合監控數據的特點，許多企業開始選擇符合業務需求的時序數據庫（Time Series Database），以便更好(hao)地支持運維監(jian)控。
轉轉 x TDengine
“使(shi)(shi)用(yong) TDengine 完成(cheng)(cheng)改造后，線上(shang)(shang)的(de)監控狀(zhuang)態達到(dao)(dao)預期，滿(man)足當前業務需(xu)求(qiu)，目前運行非(fei)(fei)(fei)常(chang)穩定。且配合 Grafana后，每個域(yu)名的(de)流量、連接數(shu)、響(xiang)應時(shi)間等信息都能(neng)夠實時(shi)監控到(dao)(dao)。無論是在成(cheng)(cheng)本(ben)、性能(neng)層面(mian)，還是在使(shi)(shi)用(yong)的(de)便利性上(shang)(shang)，TDengine 都具有非(fei)(fei)(fei)常(chang)大的(de)優勢，在我們的(de)實踐中也得到(dao)(dao)了證明，尤其是成(cheng)(cheng)本(ben)管控上(shang)(shang)效果非(fei)(fei)(fei)常(chang)顯(xian)著。”
業務背景
轉轉的(de)(de)(de)業(ye)務(wu)使用(yong)了(le) Nginx 作為(wei)反(fan)向代理，為(wei)保(bao)證代理層可用(yong)性，需要對(dui)(dui) Nginx 進行實時狀(zhuang)態監控(kong)。在(zai)服務(wu)器的(de)(de)(de)基礎監控(kong)的(de)(de)(de)選(xuan)擇(ze)上，其將 OpenFalcon 逐步替換為(wei)夜鶯，對(dui)(dui) Nginx 的(de)(de)(de) reqstat 監控(kong)最初也使用(yong)了(le)這兩(liang)種。但(dan)是這兩(liang)大監控(kong)都有一個(ge)共(gong)同缺點，即在(zai)展示(shi)時有條數限(xian)制，導致域名數量(liang)(liang)和機器數量(liang)(liang)相乘(cheng)后數據量(liang)(liang)增多的(de)(de)(de)情(qing)(qing)況(kuang)(kuang)下，無法滿足需求。這種情(qing)(qing)況(kuang)(kuang)下，轉轉考慮對(dui)(dui)現有監控(kong)模塊進行升級改造，重(zhong)新進行數據庫選(xuan)型，最終在(zai)對(dui)(dui)比 InfluxDB 及 TDengine 之后做出了(le)選(xuan)擇(ze)。
架構圖
同程旅行 x TDengine
“聚焦到實際(ji)效果(guo)上，TDengine 數據(ju)寫入性能(neng)很強。原(yuan)本我們的單(dan)套存儲系統需(xu)要(yao)(yao) 10 多(duo)臺高配機器，IO 平均(jun) 30% 最高 100% 的情(qing)況下(xia)才能(neng)寫完數據(ju)；現在(zai)只需(xu)要(yao)(yao) 7 臺機器，并且 CPU 消(xiao)耗在(zai) 10% 左右、磁(ci)盤 IO 消(xiao)耗在(zai) 1% 左右，這點非常的棒。同時(shi)，其(qi)數據(ju)讀取接(jie)入過程也很順利。使用 RESTful 接(jie)口后，結(jie)合 TDengine 自帶的強大(da)聚合函數功能(neng)，很容易就能(neng)計算出想要(yao)(yao)的結(jie)果(guo)。”
業務背景
同(tong)程旅行有一套自研的基礎監(jian)(jian)控系統“夜鷹(ying)(ying)監(jian)(jian)控”。目前(qian)夜鷹(ying)(ying)監(jian)(jian)控使用情況(kuang)為(wei)百(bai)萬級(ji)(ji)別 endpoint、億級(ji)(ji) metric、每秒 200 萬并發寫入以及 2 萬并發查詢。其(qi)存(cun)儲(chu)(chu)組件(jian)基于(yu) RRD 存(cun)儲(chu)(chu)，RRD 存(cun)儲(chu)(chu)雖然擁有很(hen)好的性(xing)能，卻也存(cun)在著一些問(wen)題——基于(yu)內存(cun)緩存(cun)定期寫入 RRD，在機(ji)器重啟(qi)后會丟失部分數據(ju)。針對此問(wen)題，夜鷹(ying)(ying)監(jian)(jian)控做了(le)很(hen)多高(gao)可用設計，但還是很(hen)難(nan)滿足業務需(xu)求。
隨著基(ji)礎(chu)監(jian)控(kong)系(xi)統(tong)接(jie)入(ru)指標(biao)的增長(chang)(chang)，目(mu)前 2 套存(cun)儲系(xi)統(tong)在(zai)(zai)資源消耗方面一(yi)直在(zai)(zai)增長(chang)(chang)，同時業(ye)務對監(jian)控(kong)也(ye)提出(chu)了更多(duo)的聚合計算功能要求。基(ji)于此(ci)，同程旅行需要從 InfluxDB、TDengine、Prometheus 等多(duo)款(kuan)時序數據庫中尋找一(yi)個(ge)新的來代替現有的存(cun)儲系(xi)統(tong)，以減少運維成本。
架構圖
得物 x TDengine
“目前 TDengine 承(cheng)載了數百(bai)億(yi)數據(ju)(ju)(ju)(ju)(ju)，在(zai)生產(chan)環(huan)境運行(xing)平(ping)穩(wen)， CPU 使用率日常(chang)不(bu)到 1 % ，內存(cun)使用率穩(wen)定在(zai) 25 % 以下(xia)。大批量(liang)(liang)的(de)(de)(de)寫入(ru)，耗時基(ji)本(ben)也(ye)能保持在(zai) 10 ms，屬(shu)于(yu)比(bi)較(jiao)理想的(de)(de)(de)范圍；不(bu)管是(shi)大數據(ju)(ju)(ju)(ju)(ju)量(liang)(liang)范圍的(de)(de)(de)聚合查(cha)詢(xun)，還是(shi)指定查(cha)詢(xun)某一小區間內的(de)(de)(de)全部數據(ju)(ju)(ju)(ju)(ju)，查(cha)詢(xun)效率都非常(chang)優異；在(zai)存(cun)儲上，我們的(de)(de)(de)全量(liang)(liang)數據(ju)(ju)(ju)(ju)(ju)分散在(zai)三(san)臺機器中，根(gen)據(ju)(ju)(ju)(ju)(ju)計算得知(zhi) TDengine 對于(yu)監(jian)控數據(ju)(ju)(ju)(ju)(ju)的(de)(de)(de)壓縮率達 10 %，相當可觀。”
業務背景
作為一(yi)家互聯網電商公司，得物有許(xu)多(duo)系統和(he)場景都需(xu)要(yao)做流量(liang)的(de)監(jian)控和(he)防護，一(yi)天就能(neng)夠產(chan)生數(shu)(shu)億數(shu)(shu)據(ju)(ju)，寫入速度達到萬 TPS ，該數(shu)(shu)據(ju)(ju)量(liang)級(ji)無法用傳統的(de)關(guan)系型數(shu)(shu)據(ju)(ju)庫處理，亟需(xu)一(yi)款能(neng)夠承(cheng)載大量(liang)的(de)流量(liang)監(jian)控數(shu)(shu)據(ju)(ju)、并能(neng)對數(shu)(shu)據(ju)(ju)進(jin)行存(cun)儲(chu)和(he)高效(xiao)查詢(xun)的(de)數(shu)(shu)據(ju)(ju)庫。在對比了 InfluxDB 、OpenTSDB 、Cassandra 等時序(xu)數(shu)(shu)據(ju)(ju)庫的(de)性能(neng)后(hou)，其最終選擇 TDengine 。
架構圖
浙商銀行 x TDengine
“我們存儲(chu)于 TDengine 中(zhong)的數據(ju)主要為時(shi)序類數據(ju)，如CPU、內(nei)存使用率等(deng)(deng)系統運(yun)行數據(ju)，微服務調用、分布式鎖、數據(ju)庫操(cao)作處理時(shi)間，業務線(xian)程池、連接池等(deng)(deng)各類指(zhi)標數據(ju)。目前微服務可(ke)視化服務治(zhi)理平(ping)(ping)臺對(dui)并(bing)發要求(qiu)較高，但是 TDengine 可(ke)以(yi)很好地滿足需求(qiu)，插入/查(cha)詢平(ping)(ping)均耗時(shi)均在(zai) 10ms 以(yi)內(nei)。”
業務背景
浙商銀行微服務可視化治理平臺是基于 Java 體系自研的微服務治理監控平臺，為行內基于統一的微服務框架開發的應用提供全面、實時的微服務治理監控功能。在這樣的業務場景中，數據量大、監控指標繁雜成了主要挑戰，浙商銀行需要一款能高效處理時序數據的工具。在明確了核心訴求之后，其調研了包括 Apache Druid、InfluxDB 和 TDengine 在內的幾款典型時序數據庫，在對比后(hou)決定嘗試 TDengine。
架構圖
結語
從上述企業的具體數據架構改造實踐中我們能夠看到，在應對海量時序數據的 IT 運維監控需求時，時序數據庫明顯要更加專業，在性能和成本管控上都上升了一個維度。而這些行業的頭部企業在眾多時序數據庫產品中都選擇了 TDengine，個中原因從改造效果中也可見一斑，有同樣需求的小伙伴也可以通過閱讀具體的案例細節了解更多。TDengine 目前已經運營了幾十個用戶交流群，如果你有要進群溝通了解的需求，可以添加小T微信：tdengine1 。
