2023年10月20日，博瑞資料2023秋季產品發布會圓滿落幕，新一代一體化智慧型觀測平台Bonree One 2023 Autumn發布，重點公升級資料採集、全域性拓撲、資料分析、會話回放等多個功能模組，為組織提供更輕量、更有序、更精準的超智慧型運維體驗。 
文章資訊
作者：博瑞資料中心-Holly數字智慧型中心大資料負責人;
本文由 InfoQ 發表。
背景
日誌、指標和呼叫鏈是可觀測性成功的三個要素，而這些要素的實現離不開資料採集、探頭採集和上報資料、後端服務接收和處理分析資料以實現可觀測性。 一般情況下，伺服器效能資料、服務相關資料、服務間呼叫資料都是通過探針採集和上報的，經過ETL處理後，成為可觀測性分析的重要依據。
探頭收集的資料量取決於兩個因素：
取樣率：取樣率越高，資料量越大，對應的可觀測性分析越全面。
服務呼叫量：業務服務呼叫頻率越高，對應的資料量越大，對應的可觀測性分析也會越複雜。
2000探頭的難度是什麼？
由於私有化部署資源有限，需要盡可能滿足企業的監控需求，因此博瑞資料的內測將以5臺機器的集群為部署標準，在資源固定的前提下，隨著探針數量的增加，主要難點如下：
業務場景有高峰波動，高峰時段服務呼叫是低峰時段的2倍+倍
業務資料同時儲存在多個業務場景中，包括呼叫鏈資料、指標資料、服務快照資料等。
這五颱機器是控制器服務、告警服務、業務查詢服務、資料呼叫鏈儲存、資料快照儲存、資料指標儲存、訊息中介軟體等多種業務的混合體，在資料量寫入較大的情況下，CPU、記憶體、磁碟IO的消耗是搶占的，影響了服務的穩定性。
如何優化**
鑑於上述困難，首先想到的是**，即減少服務元件的數量，減少服務資源的搶占。 二是業務儲存遷移，摒棄高消耗元件，使用低消耗元件來滿足業務需求。 最後，在合理的資料儲存方案的前提下，對儲存服務本身的效能進行優化，以滿足業務查詢的穩定性。
減少元件數量
Hadoop 儲存套件節點資料量大，是 J**A 服務，消耗大量資源，需要大量記憶體。 Hadoop的主要業務端是AI服務，AI團隊基於自研的資料處理框架構建了新一代的SwiftAI服務，只有一種元件型別，至少兩種部署服務。
業務儲存優化
目前，APM服務的儲存分為指標資料、跟蹤和快照三部分。 目前分別採用三種不同的儲存系統對資料進行支撐：指標資料儲存在ClickHouse中，Trace使用ES，快照資料儲存在自研物件儲存系統中。 在實際業務場景中，多個儲存引擎交叉訪問，在估算資源時沒有合理的尺度來衡量資源的上下限。 如果在一台機器上部署多個儲存引擎，勢必會影響服務的穩定性，因此減少APM服務的儲存元件成為可行的解決方案。
探針呼叫鏈資料基於ES儲存，存在以下痛點：
跟蹤資料的寫入時間與關聯的快照資料之間存在差異，並且寫入基於 ES 的資料時存在延遲。 ·ES 消耗大量資源，但消耗大量 CPU 和 IO，影響其他服務的穩定性。·ES的查詢效率不穩定，隨著資料量的增加，甚至可能查詢不對。
探針呼叫鏈的快照資料基於物件儲存系統進行儲存，存在以下痛點：
寫入不穩定，並且存在故障。 ·它消耗大量的CPU和I/O，並且很容易達到瓶頸。
鑑於前兩個元件存在明顯的痛點，將資料遷移到ClickHouse進行儲存，好處如下：
同時將Trace資料和關聯的快照資料寫入ClickHouse，以保證關聯資料的一致性。 ·ClickHouse寫入穩定，即使是檢索資料，資源消耗小。·ClickHouse讀取穩定，ClickHouse支援查詢熔斷、資源限制等方式，提高ClickHouse查詢的穩定性。·基於合理的批量積累策略，ClickHouse整體資源消耗穩定，毛刺點波動小。
儲存服務優化
如果將相關業務儲存集中起來，勢必會對ClickHouse服務產生影響，ClickHouse服務的優化和運維監控將更加重要。
在優化方面，我們從以下三個方向入手：
優化業務引數
外部分組依據前的最大位元組數：當RAM消耗超過此閾值時，分組依據會將多餘的臨時資料輸出到檔案系統中，並在磁碟上進行處理，通常建議配置為當前服務記憶體的80%。
外部排序前的最大位元組數：當涉及資料排序時，當 RAM 消耗超過此閾值時，Order By 會將多餘的臨時資料輸出到檔案系統中，並在磁碟上排序，通常建議配置為當前服務記憶體的 80%。
最大記憶體使用量：單個查詢可以使用的最大記憶體，通常建議為當前服務記憶體的 80%。
最大執行時間：查詢可以執行的最長時間，由服務響應時間的上限決定。
合理使用例項化檢視、索引和投影
針對不同的場景採用不同的加速方式，解決查詢效率問題。
高頻查詢應充分利用主鍵索引。
對於主鍵索引無法滿足的高頻查詢，可以使用索引來加速。
在排序操作方面，使用投影和物化檢視來加快速度，並且首選投影。
無法使用投影的場景可以使用例項化檢視。
監控、容錯支援。
為了解決多業務接入的複雜影響，需要對集群進行充分的監控，在容錯方面需要考慮更多的因素。
監測
主要跟蹤監控有寫和讀兩個方向，如每分鐘寫入次數、寫入消耗的時間、查詢QPS。
監控節點的狀態，如服務負載、合併任務數量、部分數量等，這些指標可以及時發現服務穩定性風險。
監控集群的餘額，如分段資料同步的延遲時間、各節點的查詢餘額、各節點的寫入餘額等，防止集群偏差。
容錯
單節點寫入節點異常不會影響整體服務寫入。
clickhouse單節點異常不會影響整個集群的寫入或讀取。
影響
AI 元件**。
將跟蹤跟蹤等相關資料遷移到 ck
為了實現最多可以支援2000個探頭的5個簇，我們首先需要做的就是減去，以減少元件之間的衝擊，這樣單個元件才能發揮更大的效率。 然後，圍繞這個元件，構建乙個更全面的生態系統，包括監控、運維和運營。 最後，圍繞業務使用場景進行深度優化，保證整體業務穩定性。
未來，我們將在ClickHouse核心上下功夫，不斷拓展ClickHouse的使用場景，與開發者分享博睿資料在ClickHouse方向上的探索與實踐，幫助Boree One朝著更快、更準確、更穩定的方向走得更遠。
要了解有關Bonree One整合智慧型可觀測性平台的更多資訊，請單擊本文末尾的“閱讀更多”，免費**完整版《博瑞資料博瑞One整合智慧型觀測平台***》。