對于互聯(lián)網(wǎng)業(yè)務(wù)而言，為保證服務(wù)的穩(wěn)定運(yùn)行，就要時刻關(guān)注服務(wù)器、服務(wù)調(diào)用、網(wǎng)絡(luò)狀況等各項指標(biāo)，單是監(jiān)控數(shù)據(jù)就存在非常大的量級。為了應(yīng)對這種挑戰(zhàn)，結(jié)合監(jiān)控數(shù)據(jù)的特點(diǎn)，許多企業(yè)開始選擇符合業(yè)務(wù)需求的時序數(shù)據(jù)庫（Time Series Database），以便更好地支持運(yùn)維監(jiān)控。

轉(zhuǎn)轉(zhuǎn) x TDengine

“使用 TDengine 完成改造后，線上的監(jiān)控狀態(tài)達(dá)到預(yù)期，滿足當(dāng)前業(yè)務(wù)需求，目前運(yùn)行非常穩(wěn)定。且配合 Grafana后，每個域名的流量、連接數(shù)、響應(yīng)時間等信息都能夠?qū)崟r監(jiān)控到。無論是在成本、性能層面，還是在使用的便利性上，TDengine 都具有非常大的優(yōu)勢，在我們的實踐中也得到了證明，尤其是成本管控上效果非常顯著?！?/p>

業(yè)務(wù)背景

轉(zhuǎn)轉(zhuǎn)的業(yè)務(wù)使用了 Nginx 作為反向代理，為保證代理層可用性，需要對 Nginx 進(jìn)行實時狀態(tài)監(jiān)控。在服務(wù)器的基礎(chǔ)監(jiān)控的選擇上，其將 OpenFalcon 逐步替換為夜鶯，對 Nginx 的 reqstat 監(jiān)控最初也使用了這兩種。但是這兩大監(jiān)控都有一個共同缺點(diǎn)，即在展示時有條數(shù)限制，導(dǎo)致域名數(shù)量和機(jī)器數(shù)量相乘后數(shù)據(jù)量增多的情況下，無法滿足需求。這種情況下，轉(zhuǎn)轉(zhuǎn)考慮對現(xiàn)有監(jiān)控模塊進(jìn)行升級改造，重新進(jìn)行數(shù)據(jù)庫選型，最終在對比 InfluxDB 及 TDengine 之后做出了選擇。

架構(gòu)圖

點(diǎn)擊案例查看更多技術(shù)細(xì)節(jié)

同程旅行 x TDengine

“聚焦到實際效果上，TDengine 數(shù)據(jù)寫入性能很強(qiáng)。原本我們的單套存儲系統(tǒng)需要 10 多臺高配機(jī)器，IO 平均 30% 最高 100% 的情況下才能寫完數(shù)據(jù)；現(xiàn)在只需要 7 臺機(jī)器，并且 CPU 消耗在 10% 左右、磁盤 IO 消耗在 1% 左右，這點(diǎn)非常的棒。同時，其數(shù)據(jù)讀取接入過程也很順利。使用 RESTful 接口后，結(jié)合 TDengine 自帶的強(qiáng)大聚合函數(shù)功能，很容易就能計算出想要的結(jié)果?！?/p>

業(yè)務(wù)背景

同程旅行有一套自研的基礎(chǔ)監(jiān)控系統(tǒng)“夜鷹監(jiān)控”。目前夜鷹監(jiān)控使用情況為百萬級別 endpoint、億級 metric、每秒 200 萬并發(fā)寫入以及 2 萬并發(fā)查詢。其存儲組件基于 RRD 存儲，RRD 存儲雖然擁有很好的性能，卻也存在著一些問題——基于內(nèi)存緩存定期寫入 RRD，在機(jī)器重啟后會丟失部分?jǐn)?shù)據(jù)。針對此問題，夜鷹監(jiān)控做了很多高可用設(shè)計，但還是很難滿足業(yè)務(wù)需求。

隨著基礎(chǔ)監(jiān)控系統(tǒng)接入指標(biāo)的增長，目前 2 套存儲系統(tǒng)在資源消耗方面一直在增長，同時業(yè)務(wù)對監(jiān)控也提出了更多的聚合計算功能要求?；诖耍搪眯行枰獜?InfluxDB、TDengine、Prometheus 等多款時序數(shù)據(jù)庫中尋找一個新的來代替現(xiàn)有的存儲系統(tǒng)，以減少運(yùn)維成本。

架構(gòu)圖

點(diǎn)擊案例查看更多技術(shù)細(xì)節(jié)

得物 x TDengine

“目前 TDengine 承載了數(shù)百億數(shù)據(jù)，在生產(chǎn)環(huán)境運(yùn)行平穩(wěn)， CPU 使用率日常不到 1 % ，內(nèi)存使用率穩(wěn)定在 25 % 以下。大批量的寫入，耗時基本也能保持在 10 ms，屬于比較理想的范圍；不管是大數(shù)據(jù)量范圍的聚合查詢，還是指定查詢某一小區(qū)間內(nèi)的全部數(shù)據(jù)，查詢效率都非常優(yōu)異；在存儲上，我們的全量數(shù)據(jù)分散在三臺機(jī)器中，根據(jù)計算得知 TDengine 對于監(jiān)控數(shù)據(jù)的壓縮率達(dá) 10 %，相當(dāng)可觀?！?/p>

業(yè)務(wù)背景

作為一家互聯(lián)網(wǎng)電商公司，得物有許多系統(tǒng)和場景都需要做流量的監(jiān)控和防護(hù)，一天就能夠產(chǎn)生數(shù)億數(shù)據(jù)，寫入速度達(dá)到萬 TPS ，該數(shù)據(jù)量級無法用傳統(tǒng)的關(guān)系型數(shù)據(jù)庫處理，亟需一款能夠承載大量的流量監(jiān)控數(shù)據(jù)、并能對數(shù)據(jù)進(jìn)行存儲和高效查詢的數(shù)據(jù)庫。在對比了 InfluxDB 、OpenTSDB 、Cassandra 等時序數(shù)據(jù)庫的性能后，其最終選擇 TDengine 。

架構(gòu)圖

點(diǎn)擊案例查看更多技術(shù)細(xì)節(jié)

浙商銀行 x TDengine

“我們存儲于 TDengine 中的數(shù)據(jù)主要為時序類數(shù)據(jù)，如CPU、內(nèi)存使用率等系統(tǒng)運(yùn)行數(shù)據(jù)，微服務(wù)調(diào)用、分布式鎖、數(shù)據(jù)庫操作處理時間，業(yè)務(wù)線程池、連接池等各類指標(biāo)數(shù)據(jù)。目前微服務(wù)可視化服務(wù)治理平臺對并發(fā)要求較高，但是 TDengine 可以很好地滿足需求，插入/查詢平均耗時均在 10ms 以內(nèi)?！?/p>

業(yè)務(wù)背景

浙商銀行微服務(wù)可視化治理平臺是基于 Java 體系自研的微服務(wù)治理監(jiān)控平臺，為行內(nèi)基于統(tǒng)一的微服務(wù)框架開發(fā)的應(yīng)用提供全面、實時的微服務(wù)治理監(jiān)控功能。在這樣的業(yè)務(wù)場景中，數(shù)據(jù)量大、監(jiān)控指標(biāo)繁雜成了主要挑戰(zhàn)，浙商銀行需要一款能高效處理時序數(shù)據(jù)的工具。在明確了核心訴求之后，其調(diào)研了包括 Apache Druid、InfluxDB 和 TDengine 在內(nèi)的幾款典型時序數(shù)據(jù)庫，在對比后決定嘗試 TDengine。

架構(gòu)圖

點(diǎn)擊案例查看更多技術(shù)細(xì)節(jié)

結(jié)語

從上述企業(yè)的具體數(shù)據(jù)架構(gòu)改造實踐中我們能夠看到，在應(yīng)對海量時序數(shù)據(jù)的 IT 運(yùn)維監(jiān)控需求時，時序數(shù)據(jù)庫明顯要更加專業(yè)，在性能和成本管控上都上升了一個維度。而這些行業(yè)的頭部企業(yè)在眾多時序數(shù)據(jù)庫產(chǎn)品中都選擇了 TDengine，個中原因從改造效果中也可見一斑，有同樣需求的小伙伴也可以通過閱讀具體的案例細(xì)節(jié)了解更多。TDengine 目前已經(jīng)運(yùn)營了幾十個用戶交流群，如果你有要進(jìn)群溝通了解的需求，可以添加小T微信：tdengine1 。