作者：呂越
TDSQL作為金融級資料庫，目前已大量應用部署在計平内部，業務夥伴，公有雲以及私有雲。随着業務增長，線上單一TDSQL叢集的執行個體數最大可到1200+ SET，近3600+ MySQL instance，當初為快速實作監控覆寫的老TDSQL監控面臨挑戰，運作狀況急需改善；同時為提升監控的有效發現能力，引入更适合的監控方法，對TDSQL的擴大應用也具有促進意義。
為此我們從兩個階段分别着手對TDSQL監控進行整合優化，階段一：對現有的監控邏輯進行梳理，整了解決現有痛點。階段二：引入新的監控算法，如趨勢性算法、突變算法、推理算法等。本文主要對階段一主要工作進行介紹。
現有監控主要分3部分。工作圖如下：
資料采集目前包含有多個資料源，如zk、mysql、hdfs、oss server等。資料目前為1min采集粒度，采集回來之後寫入存儲。資料存儲鑒于減少維護成本和取得收益的均衡性，仍采用MYSQL或TDSQL。目前資料采集的主要問題為：
1、采集并發度不高。資料量大時，部分資料源資料串行拉取，采集不過來，導緻曲線掉點毛刺；
2、采集會有多個資料源和多個資料流向，互相之間會有影響。如入庫監控存儲和外部存儲時，為同一線程,監控線程入庫失敗或延時，導緻外部存儲也掉點毛刺；
3、采集同多個資料源和存儲之間連結多為短連結，無法複用性能不高；
4、資料入庫io頻度高，導緻入庫慢。
資料存儲面臨的問題，更為迫切，由于是1min粒度，且業務增長塊，采集的名額1min 有30W + 名額入庫，老的表結構設計不滿足現有監控存儲的要求。主要面臨問題如下：
1、存儲占用空間大，有備援字段。叢集平均天20G+的存儲消耗，目前容量下最大存儲時長隻能到1個月，即700G+。
2、資料查詢慢。由于是月表設計量大索引大資料曲線展示時耗長，分析查詢資料也受到影響。
3、不便管理。資料隻能整月删除，或者按時間删除時需要掃描全表，影響監控。
分析告警也為1min 周期進行分析，拉取監控的資料，根據響應的監控政策進行分析，産生告警并發送。在現階段分析告警機制相對簡單，主要依賴采集和存儲穩定性，避免誤告。
針對以上問題，我們針對向的對采集進行了重寫，對存儲進行了重新設計，對分析&告警也配合存儲做了重寫。具體方案如下：
在采集優化上主要着重解決已存在的問題，如并發能力，持久化連結，入庫瓶頸等。
1、提高并發度，将并發能力由之前執行個體級(執行個體資料拉取會有多次io串行拉取)，分解到io級别，提高并行能力；
2、多個資料源獨立線程和任務。減少資料源及資料入庫之間的互相幹擾；
3、資料源和資料入庫采用隊列形式，并獨立隊列，避免互相影響；
4、資料入庫優化為批量入庫，減少io頻率；
5、資料索引進行cache，減少io查詢(索引部分見存儲優化部分解釋)；
6、連接配接複用。尤其是zk、http、mysql的連結複用。
優化效果如下，有效解決了資料采集掉點，曲線毛刺，以及CPU消耗高問題，新老對比如下圖。
1、掉點優化新老對比
2、掉點優化後
3、曲線毛刺新老對比
4、毛刺優化後
5、CPU優化新老對比
6、優化後新采集
為解決現存問題，在存儲上我們也進行重新設計。鑒于維護成本，以及對相關TSDB的比較，我們仍選用TDSQL或MYSQL作為存儲方案，并進行插件化替換，目前使用TDSQL GroupSharding的二級分區版本，分區規則為Hash+按日期分區。考慮到後續監控算法引入，會增加對資料查詢壓力。相關tsdb中主要比較了influxdb和opentsdb。influxdb寫入性能優良，也足夠的輕量，且有一定的高可用，但查詢性能有瓶頸，opentsdb較重量，維護成本高。沿用TDSQL或MYSQL作為解決方案，我們主要做了如下優化：
1、引入索引表。将備援字段進行了剝離，減少存儲消耗；
2、時間序列分鐘級轉到小時級的60列。時序資料為相同的名額在不同時間的取值序列。這種方式一方面可以減少資料量，減少索引量，另一方面也可以減少存儲消耗；
3、動态和靜态名額分離。采集的名額并非所有均需要監控，降需要監控資料做曆史存儲，靜态名額，存儲目前值即可；
4、對曆史資料表進行分區，表壓縮；
5、曆史資料按天分表友善進行滾動。
優化效果如下，節省空間近95%。
現階段主要是解決現網監控存在的問題，即在存儲和性能上進行了改良，緩解了網TDSQL監控痛點，已能夠經得住業務近期的增長和監控需求，但如何優化現有監控政策，提供更豐富的監控方法，如多名額的組合告警的政策，趨勢性告警是否有效等，仍是下個階段需要進行攻關的重點。