可觀測(cè)性是近年來(lái)的熱門話題之一。一個(gè)具備良好可觀測(cè)性的系統(tǒng)可以提高企業(yè)的生產(chǎn)效率，提高產(chǎn)品的質(zhì)量、用戶滿意度等。尤其是隨著容器云原生微服務(wù)架構(gòu)技術(shù)的廣泛應(yīng)用，系統(tǒng)組件越來(lái)越多，處理請(qǐng)求的鏈路越來(lái)越長(zhǎng)，故障排查也面臨著更高難度的挑戰(zhàn)，這也是很多企業(yè)存在的普遍痛點(diǎn)。本文將分享炎凰數(shù)據(jù)如何通過(guò)新的可觀測(cè)化能力平臺(tái)來(lái)幫助企業(yè)對(duì)IT系統(tǒng)或者業(yè)務(wù)系統(tǒng)進(jìn)行監(jiān)控，對(duì)性能進(jìn)行可視化監(jiān)測(cè)。

一、如何建設(shè)系統(tǒng)的可觀測(cè)體系

首先簡(jiǎn)單介紹一下如何建設(shè)系統(tǒng)的可觀測(cè)體系。

1、何為“可觀測(cè)”體系

為了提高企業(yè)系統(tǒng)運(yùn)維時(shí)排查故障的效率，亟待引入新的可觀測(cè)數(shù)據(jù)和能力?？捎^測(cè)性即通過(guò)系統(tǒng)輸出的信號(hào)來(lái)度量和理解系統(tǒng)的狀態(tài)。因此系統(tǒng)能夠輸出的信號(hào)的類型和質(zhì)量就決定了系統(tǒng)可觀測(cè)性的質(zhì)量高低。

有三個(gè)重要的可觀測(cè)信號(hào)：Metrics（指標(biāo)）、Traces（調(diào)用鏈）以及 Logs（日志）。這三種觀測(cè)信號(hào)的應(yīng)用已較為成熟，有著眾多的開(kāi)源工具可供選擇。

這三種數(shù)據(jù)類型通常被稱為可觀測(cè)性的“三大支柱”，但在 CNCF 最新的可觀測(cè)性白皮書(shū)當(dāng)中更傾向于將其稱為“三個(gè)主要的信號(hào)”。原因是“三大支柱”，容易給人造成建設(shè)可觀測(cè)體系三者缺一不可的錯(cuò)覺(jué)。但實(shí)際上信號(hào)的選擇更應(yīng)從用戶的實(shí)際需求出發(fā)，對(duì)于有些用戶而言，例如 Metrics 配合 Logs 即可滿足系統(tǒng)的可觀測(cè)性需求。

然而，在使用容器云原生和微服務(wù)架構(gòu)的情況下，要建設(shè)起具備高度可觀測(cè)性的系統(tǒng)，這三類數(shù)據(jù)確實(shí)均有必要。故障診斷過(guò)程中，三者分別發(fā)揮了如下作用：Metrics 用于衡量關(guān)于系統(tǒng)整體行為和健康狀況的數(shù)據(jù)，所以它可以監(jiān)測(cè)系統(tǒng)是否存在問(wèn)題；Traces，尤其是分布式調(diào)用鏈數(shù)據(jù)，可以快速定位發(fā)生問(wèn)題的位置；Logs 則可以記錄發(fā)生了什么問(wèn)題。如果企業(yè)的可觀測(cè)體系建設(shè)完備良好，將極大提升問(wèn)題排查效率，對(duì)生產(chǎn)力的提高和產(chǎn)品的穩(wěn)定性都會(huì)有很大幫助。

除了這三種最重要的信號(hào)之外，還有其他一些信號(hào)，比如 dumps、profiles 和 events。這三種信號(hào)可能范圍并不是很廣，成熟度也不是很高。關(guān)于 dumps 在后面分享中將會(huì)被提及，因此先做個(gè)簡(jiǎn)要介紹。

Dumps 是程序崩潰時(shí)產(chǎn)生的 core-dump 中的信息，一般會(huì)包含程序崩潰時(shí)的一些內(nèi)部的狀態(tài)，比如內(nèi)存狀態(tài)，所以有時(shí)能比 logs 更直接地定位問(wèn)題。因此如果能把 dumps 數(shù)據(jù)納入可觀測(cè)體系，將有助于提升系統(tǒng)故障排查的效率。但在云原生微服務(wù)的架構(gòu)下，定位和獲取 dumps 數(shù)據(jù)的難度比以前更大。

2、三步走建設(shè)系統(tǒng)的可觀測(cè)體系

明確需求

首先需要明確需求。大多時(shí)候探討可觀測(cè)系統(tǒng)實(shí)現(xiàn)的情況，是在探討如何實(shí)現(xiàn)及時(shí)觀測(cè)系統(tǒng)的健康狀態(tài)、快速發(fā)現(xiàn)和排查問(wèn)題。實(shí)際上可觀測(cè)系統(tǒng)也可以用來(lái)解決其他的問(wèn)題，比如了解用戶的行為習(xí)慣，進(jìn)一步指導(dǎo)公司對(duì)產(chǎn)品和投入的規(guī)劃等。

前面所述，并非一定要將所有重要的信號(hào)都納入才能實(shí)現(xiàn)系統(tǒng)的可觀測(cè)。因此，首先應(yīng)明確希望通過(guò)提高系統(tǒng)的可觀測(cè)性解決什么問(wèn)題，需求明確之后方能進(jìn)一步探討需要采集何種數(shù)據(jù)來(lái)滿足需求。提高系統(tǒng)的可觀測(cè)性，不能期待建設(shè)一步到位，應(yīng)從當(dāng)前最重要的需求入手，循序漸進(jìn)。因?yàn)榻ㄔO(shè)起一個(gè)良好的可觀測(cè)系統(tǒng)，需要考慮到的問(wèn)題非常多。比如可以先納入指標(biāo)數(shù)據(jù)，之后再逐步納入日志數(shù)據(jù)或者調(diào)用鏈數(shù)據(jù)，以及其他一些數(shù)據(jù)。這種方式也符合現(xiàn)在企業(yè)應(yīng)用建設(shè)初期所采用的方法，即快速啟動(dòng)，快速試錯(cuò)，在得到正確反饋時(shí)再不斷改進(jìn)。

找到數(shù)據(jù)源

在明確了需求之后，需要了解數(shù)據(jù)來(lái)源有哪些，復(fù)雜程度可能不同。因?yàn)橛行?shù)據(jù)可能已經(jīng)存在，只需要采集和分析；也有可能現(xiàn)在的系統(tǒng)還不具備輸出某些數(shù)據(jù)的能力，需要進(jìn)行部分系統(tǒng)改造以便輸出觀測(cè)數(shù)據(jù)。

例如 logs 應(yīng)該是被普遍熟知的。在構(gòu)建每個(gè)系統(tǒng)的時(shí)候，打 log 是必不可少的要求，log 一般會(huì)寫(xiě)到本地文件中，或者是通過(guò)網(wǎng)絡(luò)發(fā)送到中心化的日志服務(wù)。值得注意的是，log 的格式目前并沒(méi)有通用規(guī)范，所以當(dāng)我們使用 log 數(shù)據(jù)來(lái)觀測(cè)系統(tǒng)的時(shí)候，有可能需要對(duì) log 的內(nèi)容做格式化處理，這取決于需求和選用的日志分析工具的要求。

對(duì)于 metrics 而言，目前 Prometheus 應(yīng)屬于事實(shí)上的標(biāo)準(zhǔn)，大部分開(kāi)源工具都內(nèi)置了 Prometheus 的 exporter，用戶只要簡(jiǎn)單地打開(kāi)就可以使用。對(duì)于企業(yè)自研的系統(tǒng)，也有工具方便地實(shí)現(xiàn) Prometheus exporter。

對(duì)于 traces 而言，或者 distributed traces，一般需要在系統(tǒng)中通過(guò)埋點(diǎn)來(lái)實(shí)現(xiàn)。

在開(kāi)源工具中比較普遍的是 OpenTelemetry 的標(biāo)準(zhǔn)，它為常見(jiàn)的技術(shù)棧提供了無(wú)侵入式埋點(diǎn)的方法。在炎凰數(shù)據(jù)平臺(tái)中，也是使用了 OpenTelemetry 這種無(wú)侵入式的 instrumentation 來(lái)實(shí)現(xiàn) traces 數(shù)據(jù)的生成。

• 選擇合適的工具

明確了數(shù)據(jù)源之后，就該選擇合適的工具了，包括數(shù)據(jù)采集、數(shù)據(jù)分析的工具。在 CNCF 的 landscape 中，專門開(kāi)辟了關(guān)于可觀測(cè)性的專題，并且從 logs、metrics 和 traces 角度進(jìn)行了簡(jiǎn)單分類，是很好的參考。例如通常用于處理指標(biāo)數(shù)據(jù)的工具是 Prometheus；處理日志，有 Fluentd、Elasticsearch；處理調(diào)用鏈的有 Jaeger、OpenTelemetry 等。每個(gè)工具處理數(shù)據(jù)類型時(shí)或在不同使用場(chǎng)景中都有所側(cè)重。因此在基于它們建設(shè)一套完備的可觀測(cè)體系時(shí)，往往需要通過(guò)多個(gè)工具的組合才能滿足最終的需求。

二、企業(yè)建設(shè)可觀測(cè)體系時(shí)的痛點(diǎn)

1、企業(yè)建設(shè)系統(tǒng)可觀測(cè)體系時(shí)的痛點(diǎn)

經(jīng)過(guò)調(diào)研，當(dāng)前建設(shè)可觀測(cè)系統(tǒng)面臨的挑戰(zhàn)可以總結(jié)為以下幾大方面：

（1）高復(fù)雜度

如前面所言，metrics、traces 和 logs 數(shù)據(jù)可以從不同的維度提供系統(tǒng)的可觀測(cè)性，因此在建設(shè)全面的可觀測(cè)體系時(shí)，需要采用多種類型的數(shù)據(jù)，為不同類型的數(shù)據(jù)選擇合適的工具。這將面臨的問(wèn)題是系統(tǒng)的復(fù)雜度將非常高。

上圖為 CNCF 在一年多以前的調(diào)研結(jié)果，數(shù)據(jù)顯示被調(diào)查的大部分企業(yè)都面臨著上述問(wèn)題。例如其中的一個(gè)問(wèn)題：“使用可觀測(cè)性工具，你已經(jīng)遇到或者感覺(jué)將要遇到的最大挑戰(zhàn)是什么？”，結(jié)果顯示排名第一的答案是：系統(tǒng)的復(fù)雜度太高，難以使用。排名第二的挑戰(zhàn)是缺少相關(guān)文檔的支持，其根本原因還是系統(tǒng)過(guò)于復(fù)雜，缺乏良好的可用性。體系的復(fù)雜度高意味著需要投入更多的資源，不論是開(kāi)發(fā)工程師還是運(yùn)維工程師都需要掌握更多的相關(guān)技術(shù)，最終體現(xiàn)在更高的建設(shè)成本和運(yùn)維成本，這違背了建設(shè)可觀測(cè)系統(tǒng)用以實(shí)現(xiàn)降本增效的目的和初衷。

（2）數(shù)據(jù)孤島

第二個(gè)痛點(diǎn)是數(shù)據(jù)孤島的問(wèn)題。由于數(shù)據(jù)存儲(chǔ)分析工具的不同，導(dǎo)致不能快速關(guān)聯(lián)metrics 、traces 和 logs 進(jìn)行綜合分析。首先需要闡明的是，為什么把這些數(shù)據(jù)關(guān)聯(lián)起來(lái)的能力很重要？如上圖所示，左圖顯示的是 metrics、traces 和 logs 數(shù)據(jù)之間的關(guān)聯(lián)性，首先三種數(shù)據(jù)均為時(shí)序數(shù)據(jù)，在發(fā)生的時(shí)間點(diǎn)上有相關(guān)性，因此可以通過(guò)一個(gè)時(shí)間窗口來(lái)過(guò)濾出相關(guān)數(shù)據(jù)。

除了數(shù)據(jù)發(fā)生時(shí)間的維度之外，在每個(gè)可觀測(cè)數(shù)據(jù)上還可以通過(guò)一些元數(shù)據(jù)進(jìn)行綁定，把數(shù)據(jù)與目標(biāo)來(lái)源綁定，例如來(lái)自同一臺(tái)主機(jī)、同一個(gè)應(yīng)用，或者是同一個(gè)用戶的請(qǐng)求等。用時(shí)間窗口加上目標(biāo)來(lái)源的元數(shù)據(jù)，便于找到來(lái)自特定目標(biāo)的觀測(cè)數(shù)據(jù)。

一個(gè)簡(jiǎn)單的例子，調(diào)用鏈數(shù)據(jù)和日志數(shù)據(jù)可以通過(guò)元數(shù)據(jù) trace ID 和 span ID 進(jìn)行關(guān)聯(lián)，當(dāng)我們?cè)?traces 數(shù)據(jù)中發(fā)現(xiàn)了一條慢的請(qǐng)求，而且定位到了導(dǎo)致問(wèn)題的 span，那么可以通過(guò) trace ID 和 span ID 的關(guān)聯(lián)，快速定位到問(wèn)題發(fā)生的 log。

實(shí)際上，metrics 和其余兩種數(shù)據(jù)之間也存在類似的關(guān)聯(lián)方式。在低級(jí)別的范圍內(nèi)將它們關(guān)聯(lián)起來(lái)，可以在我們通過(guò)多個(gè)信號(hào)或者視角來(lái)觀測(cè)系統(tǒng)時(shí)更加靈活順暢，可以通過(guò)在不同信號(hào)之間的快速轉(zhuǎn)換大幅提升故障排查的效率。

綜上，若因數(shù)據(jù)存儲(chǔ)分析工具的不同形成數(shù)據(jù)孤島，會(huì)導(dǎo)致很難將多種數(shù)據(jù)類型關(guān)聯(lián)，進(jìn)而限制我們從可觀測(cè)數(shù)據(jù)中挖掘更多價(jià)值的能力。

（3）一般的用戶體驗(yàn)

用戶體驗(yàn)不佳其實(shí)是前面所提及的兩個(gè)問(wèn)題導(dǎo)致的。一個(gè)具有高復(fù)雜度的系統(tǒng)，且不具備數(shù)據(jù)關(guān)聯(lián)的能力，不僅意味著對(duì)使用者的要求比較高，且有可能仍舊無(wú)法有效解決目標(biāo)系統(tǒng)的可觀測(cè)問(wèn)題。這一問(wèn)題也曾在 CNCF 的調(diào)查文件中體現(xiàn)。

如上圖所示，左圖的問(wèn)題是“下一年關(guān)于可觀測(cè)性規(guī)劃，你的優(yōu)先級(jí)最高的事情是什么？”60% 的回答指明需要找到最佳實(shí)踐，說(shuō)明被調(diào)研者普遍對(duì)于現(xiàn)有的可觀測(cè)系統(tǒng)滿意度較低，認(rèn)為仍有較大的改良空間。

右圖的問(wèn)題是“如果需要你使用可觀測(cè)系統(tǒng)，會(huì)有什么顧慮嗎？”多數(shù)回答主要集中在使用的難度上，包括集成可觀測(cè)系統(tǒng)的難度以及學(xué)習(xí)如何使用可觀測(cè)系統(tǒng)的難度等。

2、解決方案：一體化可觀測(cè)平臺(tái)

針對(duì)上述痛點(diǎn)，是否有好的解決方案，能夠保持系統(tǒng)的復(fù)雜度可控，同時(shí)支持可觀測(cè)數(shù)據(jù)之間的快速流轉(zhuǎn)聯(lián)通，并且對(duì)用戶而言是易用且有效的？答案就是一體化可觀測(cè)平臺(tái)。

（1）統(tǒng)一的數(shù)據(jù)采集工具

一體化可觀測(cè)平臺(tái)首先需要有統(tǒng)一的數(shù)據(jù)采集工具，支持不同類型的可觀測(cè)數(shù)據(jù)的采集，并能夠在采集端完成一些數(shù)據(jù)的處理，例如為數(shù)據(jù)附加元數(shù)據(jù)，或者對(duì)數(shù)據(jù)內(nèi)容和格式進(jìn)行處理，目的是便于后續(xù)數(shù)據(jù)的存儲(chǔ)和分析。比如 OpenTelemetry 就是在向該方向努力，爭(zhēng)取成為標(biāo)準(zhǔn)。但目前而言，可能在日志方面還不夠完善。

（2）統(tǒng)一的數(shù)據(jù)存儲(chǔ)、分析平臺(tái)

統(tǒng)一的數(shù)據(jù)和存儲(chǔ)和分析平臺(tái)，可以實(shí)現(xiàn)不同類型數(shù)據(jù)的查詢和數(shù)據(jù)的高效關(guān)聯(lián)。

（3）統(tǒng)一的用戶接口

統(tǒng)一的用戶接口，包括分析查詢語(yǔ)言、可視化和告警等。用戶使用統(tǒng)一接口查詢數(shù)據(jù)時(shí)，系統(tǒng)可以快速地在不同類型的數(shù)據(jù)之間流轉(zhuǎn)，通過(guò)一套統(tǒng)一的分析查詢語(yǔ)言，統(tǒng)一的可視化和告警等功能，有效降低系統(tǒng)使用的復(fù)雜度?？傮w而言，統(tǒng)一的用戶接口可極大降低用戶的使用門檻。

三、關(guān)于炎凰數(shù)據(jù)公司及產(chǎn)品

1、炎凰數(shù)據(jù)簡(jiǎn)介

炎凰數(shù)據(jù)成立于 2020 年，是一家專注于研發(fā)云原生新一代異構(gòu)大數(shù)據(jù)即時(shí)分析平臺(tái)的公司，炎凰數(shù)據(jù)平臺(tái)（YHP）是我們的產(chǎn)品。其中值得一提的是，平臺(tái)核心的大數(shù)據(jù)分析引擎，是由我們自主研發(fā)，擁有全部知識(shí)產(chǎn)權(quán)。

炎凰數(shù)據(jù)平臺(tái)的架構(gòu)如上圖所示。

在此數(shù)據(jù)平臺(tái)上，支持將多種類型的數(shù)據(jù)源數(shù)據(jù)導(dǎo)入平臺(tái)，通過(guò)存儲(chǔ)引擎為數(shù)據(jù)建立索引，并存入文件系統(tǒng)。數(shù)據(jù)分析引擎則負(fù)責(zé)執(zhí)行來(lái)自用戶的查詢?nèi)蝿?wù)。基于這套查詢引擎，平臺(tái)提供了豐富的用戶接口，例如可視化的儀表板、告警、即席查詢等功能，方便用戶進(jìn)行數(shù)據(jù)探索和數(shù)據(jù)知識(shí)的積累。用戶可以基于上述平臺(tái)功能和接口來(lái)應(yīng)對(duì)不同的使用場(chǎng)景，包括IT 運(yùn)維領(lǐng)域、可觀測(cè)領(lǐng)域、生產(chǎn)領(lǐng)域等。

2、炎凰數(shù)據(jù)平臺(tái)功能及特性

（1）系統(tǒng)架構(gòu)

平臺(tái)使用云原生微服務(wù)架構(gòu)，使用 Kubernetes 編排服務(wù)，也支持 Kubernetes 的各種拓展方式和管理方式。

其一，數(shù)據(jù)引擎方面，存算分離的架構(gòu)，計(jì)算層和存儲(chǔ)層可以獨(dú)立拓展。

其二，支持單機(jī)或者集群部署。例如單機(jī)部署時(shí)，平臺(tái)的所有組件可以在同一臺(tái)服務(wù)器上運(yùn)行。當(dāng)用戶在做測(cè)試，或者是查詢數(shù)據(jù)量不大且沒(méi)有高可用數(shù)據(jù)需求時(shí)，只需要單臺(tái)服務(wù)器即可滿足用戶的數(shù)據(jù)分析需求。當(dāng)數(shù)據(jù)量增大，或者有了數(shù)據(jù)高可用的需求之后，再拓展到集群的部署方式。

其三，支持標(biāo)準(zhǔn)的 Restful API 接口，用于和外部系統(tǒng)的集成。對(duì)于特定的功能模塊，還提供二次開(kāi)發(fā)的框架。譬如，用戶可以在我們的平臺(tái)上拓展用戶自己的 SQL 函數(shù)、可視化控件等。

（2）數(shù)據(jù)采集

平臺(tái)內(nèi)置了多種數(shù)據(jù)導(dǎo)入的方式，較為常用的有 Syslog、Kafka 等。除此之外，對(duì)于邊緣數(shù)據(jù)的采集，我們也提供了自研的數(shù)據(jù)采集器 DataScale。炎凰數(shù)據(jù)平臺(tái)自身在采集可觀測(cè)數(shù)據(jù)的時(shí)候，也是依賴于該自研數(shù)據(jù)采集器。

（3）數(shù)據(jù)引擎

關(guān)于數(shù)據(jù)引擎，首先需要特別指出的是，炎凰數(shù)據(jù)平臺(tái)支持混合建模，即同時(shí)支持讀時(shí)建模和寫(xiě)時(shí)建模。讀時(shí)建?？梢詫?duì)非結(jié)構(gòu)化或者半結(jié)構(gòu)化的數(shù)據(jù)有更好的處理能力。在數(shù)據(jù)導(dǎo)入數(shù)據(jù)平臺(tái)之前，不需要額外的處理，而是在查詢階段構(gòu)建數(shù)據(jù)模型。

第二，使用標(biāo)準(zhǔn) SQL 作為查詢語(yǔ)言。平臺(tái)內(nèi)的任何數(shù)據(jù)都可以通過(guò)標(biāo)準(zhǔn)的 SQL 進(jìn)行查詢，意味著對(duì)于很多用戶而言使用門檻大幅降低。同時(shí)我們也提供了豐富的標(biāo)量函數(shù)和表函數(shù)等，便于用戶使用 SQL 完成各種數(shù)據(jù)計(jì)算任務(wù)。

第三，平臺(tái)還支持基于預(yù)計(jì)算的計(jì)算加速，比如實(shí)時(shí)物化視圖等。

（4）可視化

平臺(tái)內(nèi)置豐富的圖表，例如折線圖，柱狀圖等。圖表支持二次開(kāi)發(fā)，用戶可以按照需求，按照開(kāi)發(fā)框架引入所需的圖表。

豐富的圖表還可以構(gòu)建成儀表板，即用戶可以在儀表板中任意加入圖表以及設(shè)置圖表的大小和比例等。另外值得一提的是，儀表板支持動(dòng)態(tài)參數(shù)引入，可以根據(jù)查詢的結(jié)果動(dòng)態(tài)顯示圖表中的內(nèi)容，并且支持下鉆以及數(shù)據(jù)的跳轉(zhuǎn)關(guān)聯(lián)等交互動(dòng)作。

（5）其他

另外，還有告警和即時(shí)分析功能，這在數(shù)據(jù)分析領(lǐng)域或者在可觀測(cè)性場(chǎng)景下都是非常實(shí)用的功能。

四、建設(shè) YHP 自身可觀測(cè)性的實(shí)踐

接下來(lái)介紹炎凰數(shù)據(jù)平臺(tái)（YHP）自身可觀測(cè)性的實(shí)踐。

1、自研數(shù)據(jù)采集器

炎凰數(shù)據(jù)平臺(tái)對(duì)可觀測(cè)性數(shù)據(jù)的采集，都是通過(guò)自研的數(shù)據(jù)采集器 DataScale 來(lái)完成的，支持 metrics、traces 和 logs 三種可觀測(cè)數(shù)據(jù)的采集。

在過(guò)去，用戶采集不同類型的可觀測(cè)數(shù)據(jù)通常需要使用不同的工具，比如通過(guò) OpenTelemetry 的 collector 采集 trace 數(shù)據(jù)；使用 Prometheus 的 exporter 拉取日志數(shù)據(jù)。

市面上有大量支持不同數(shù)據(jù)源的數(shù)據(jù)采集工具，但在我們的數(shù)據(jù)采集器里，將這些常見(jiàn)的數(shù)據(jù)采集方式統(tǒng)一集成在平臺(tái)的數(shù)據(jù)采集器內(nèi)部。不僅如此，數(shù)據(jù)采集器還可以配置數(shù)據(jù)源以及在對(duì)接數(shù)據(jù)源之后構(gòu)建數(shù)據(jù)處理的邏輯。因此，OpenTelemetry 的 collector，或者是 Prometheus exporter 的 scraper，以及其他各種數(shù)據(jù)源，都可以作為數(shù)據(jù)采集器的 source 配置在內(nèi)。

2、加工數(shù)據(jù)

數(shù)據(jù)被采集集中之后，會(huì)被流轉(zhuǎn)至數(shù)據(jù)處理模塊進(jìn)行數(shù)據(jù)加工處理，例如給數(shù)據(jù)附加元數(shù)據(jù)信息，之后再將數(shù)據(jù)導(dǎo)入炎凰數(shù)據(jù)平臺(tái)。

使用統(tǒng)一的數(shù)據(jù)采集器的好處主要有兩點(diǎn)：其一是所有數(shù)據(jù)源的接入能夠被統(tǒng)一管理，并且提供了具有很好的用戶體驗(yàn)的 UI，使用戶能夠以可視化的方式來(lái)管理數(shù)據(jù)的接入；其二是在數(shù)據(jù)存儲(chǔ)到平臺(tái)之前，可以在采集端對(duì)數(shù)據(jù)進(jìn)行加工處理，比如補(bǔ)充元數(shù)據(jù)，處理數(shù)據(jù)的結(jié)構(gòu)和格式，便于后續(xù)的存儲(chǔ)和分析。

3、YHP 中數(shù)據(jù)采集器的部署

上圖是炎凰數(shù)據(jù)平臺(tái)中數(shù)據(jù)采集器的部署方式。數(shù)據(jù)采集通常有兩種場(chǎng)景，一是在數(shù)據(jù)平臺(tái)的各個(gè)節(jié)點(diǎn)上采集本地?cái)?shù)據(jù)，另一個(gè)是使用中心節(jié)點(diǎn)采集服務(wù)數(shù)據(jù)。因此炎凰數(shù)據(jù)平臺(tái)中的數(shù)據(jù)采集器有兩種部署方式，一種是按 Kubernetes DaemonSet 的方式部署，在每個(gè)節(jié)點(diǎn)運(yùn)行。這種數(shù)據(jù)采集器會(huì)采集本地的日志文件，從本地的 node exporter 上拉取主機(jī)的 metrics。

另外一種方式是用 Kubernetes Deployment 的方式運(yùn)行數(shù)據(jù)采集器。作為 aggregator，負(fù)責(zé)拉取平臺(tái)中各個(gè)應(yīng)用的指標(biāo)數(shù)據(jù)，以及接收來(lái)自 Web 服務(wù)的 traces。

上述兩種方式保證了既不會(huì)漏掉任何數(shù)據(jù)，也不會(huì)出現(xiàn)數(shù)據(jù)的重復(fù)采集。

4、YHP 自身可觀測(cè)數(shù)據(jù)的存儲(chǔ)

當(dāng)可觀測(cè)數(shù)據(jù)被采集到炎凰數(shù)據(jù)平臺(tái)之后，metrics / traces / logs 分別存在不同的數(shù)據(jù)集（相當(dāng)于數(shù)據(jù)庫(kù)中表的概念）里。主要的原因是為了性能上的優(yōu)化調(diào)整，因?yàn)橥ǔＪ前磾?shù)據(jù)集查詢，在查詢某一類型數(shù)據(jù)時(shí)，性能不會(huì)受另外兩種數(shù)據(jù)的數(shù)據(jù)量影響而下降。

由在文章開(kāi)頭關(guān)于三個(gè)重要指標(biāo)的圖示中可見(jiàn)，不同類型的數(shù)據(jù)的數(shù)據(jù)量的量級(jí)是不同的，通常最多的是日志數(shù)據(jù)。對(duì)于 metrics 數(shù)據(jù)的查詢，實(shí)際情況下都需要比較快的響應(yīng)速度，因此使用上述存儲(chǔ)方式，就不會(huì)因?yàn)?logs 或 traces 的大數(shù)據(jù)量而影響查詢 metrics 的性能。

使用多個(gè)數(shù)據(jù)集的另一個(gè)好處是可以為不同類型的數(shù)據(jù)設(shè)置不同的生命周期。不同類型的數(shù)據(jù)根據(jù)相應(yīng)的使用場(chǎng)景和不同的特性，需要保存的周期也不同。例如 logs 和 traces 通常需要較長(zhǎng)的保存周期；而指標(biāo)數(shù)據(jù)，可能只需要保存近期的數(shù)據(jù)。

所以從右圖中可見(jiàn)，我們可以為每個(gè)數(shù)據(jù)集設(shè)置限制容量，或者利用數(shù)據(jù)的時(shí)間戳用時(shí)間窗口做限制。當(dāng)然用戶也可以特殊處理某些特定場(chǎng)景的數(shù)據(jù)。例如出于合規(guī)的原因，或者出于其他原因需要保留數(shù)據(jù)，但不希望影響到查詢性能，也可以選擇把數(shù)據(jù)歸檔到指定的路徑去。

上圖是數(shù)據(jù)被采集進(jìn)來(lái)之后，數(shù)據(jù)的內(nèi)容呈現(xiàn)形式。三個(gè)圖分別顯示的是調(diào)用鏈數(shù)據(jù)（traces）、指標(biāo)數(shù)據(jù)（metrics）和日志數(shù)據(jù)（logs）。左上角的圖是指標(biāo)數(shù)據(jù)。帶下劃線開(kāi)頭的都是附加的元數(shù)據(jù)字段，非下劃線開(kāi)頭的都是指標(biāo)數(shù)據(jù)的原始字段。比如圖中“counter.value”字段的值以及指標(biāo)的名字都是原始字段。此外附加的信息，比如節(jié)點(diǎn)信息、類型信息、主機(jī)信息，這些元數(shù)據(jù)信息都是在后面做關(guān)聯(lián)查詢時(shí)使用。

右邊的圖，是調(diào)用鏈的數(shù)據(jù)。元數(shù)據(jù)同樣被附加在以下劃線開(kāi)頭的字段，其中包括屬于哪個(gè)服務(wù)、來(lái)自于哪個(gè) Kubernetes 的 namespace 等等。下方的原始字段，也都是符合 OpenTelemetry 標(biāo)準(zhǔn)的 tag 字段。

左下角的圖，是一個(gè)普通的日志數(shù)據(jù)，其中高亮處為 trace ID。當(dāng)我們打開(kāi)了炎凰數(shù)據(jù)平臺(tái)的可觀測(cè)性相關(guān)功能時(shí)，會(huì)將日志中的調(diào)用鏈的 trace ID、span ID 寫(xiě)入 logs，便于依據(jù) trace ID 和 span ID 得到這個(gè)應(yīng)用相關(guān)的日志信息。

5、統(tǒng)一 SQL 關(guān)聯(lián)查詢

上圖是一個(gè)查詢的例子：通過(guò)使用統(tǒng)一的 SQL 查詢分別查詢 traces 和 logs，以及通過(guò) trace ID 關(guān)聯(lián)數(shù)據(jù)進(jìn)行查詢。

如圖所示，左邊的 yhp_monitoring_traces，是存儲(chǔ) traces 的數(shù)據(jù)集?？梢酝ㄟ^(guò)解析出的字段進(jìn)行過(guò)濾，得到目標(biāo)的調(diào)用鏈記錄。例如目標(biāo)數(shù)據(jù)為 HTTP 返回值為大于等于 400 的異常的請(qǐng)求調(diào)用記錄，且從 root span 開(kāi)始的、kind=2 的 trace。得到了相關(guān)的 trace ID 之后，再用另外的查詢，從 _internal 的數(shù)據(jù)集中把這個(gè) trace 相關(guān)的所有日志篩選出來(lái)，查看請(qǐng)求究竟在服務(wù)里面發(fā)生了什么事情。這是一個(gè)手動(dòng)去做關(guān)聯(lián)查詢的場(chǎng)景。炎凰數(shù)據(jù)平臺(tái)的儀表板是支持下鉆功能的，這意味著在儀表板上，用戶可以設(shè)置通過(guò)點(diǎn)擊儀表板上的相關(guān)查詢得到 trace ID，直接跳轉(zhuǎn)到日志查詢的結(jié)果。

6、可視化告警一體化監(jiān)測(cè)駕駛艙

上圖展示的是基于可觀測(cè)數(shù)據(jù)構(gòu)建的統(tǒng)一可視化儀表板和告警?；谥笜?biāo)數(shù)據(jù)和調(diào)用鏈數(shù)據(jù)去構(gòu)建可視化看板，直觀展示平臺(tái)是否存在異常。另外告警功能體現(xiàn)在各組件的巡檢功能上，即每隔幾分鐘定期檢測(cè)平臺(tái)有無(wú)異常出現(xiàn)。若有異常出現(xiàn)，則會(huì)在該儀表板中顯示出異常狀態(tài)，并且在下方的告警列表中會(huì)有相應(yīng)的告警。同時(shí)也附加了針對(duì) logs 中的已知問(wèn)題的告警場(chǎng)景。

中間的圖展示的是基于 metrics 的儀表板，基于主機(jī)的 metrics 數(shù)據(jù)來(lái)展示主機(jī)當(dāng)前的系統(tǒng)狀態(tài)。右圖則是基于 metrics 和 traces 來(lái)展示一個(gè) Web 應(yīng)用的健康狀況。這些示例展示了利用一體化可觀測(cè)平臺(tái)構(gòu)建可觀測(cè)性的一個(gè)很大的優(yōu)勢(shì)就是避免了數(shù)據(jù)孤島的問(wèn)題。當(dāng)需要觀測(cè)一個(gè)應(yīng)用的健康狀況時(shí)，所有相關(guān)的觀測(cè)性數(shù)據(jù)都可以被集中作為健康程度的指標(biāo)數(shù)據(jù)進(jìn)行可視化。

7、炎凰數(shù)據(jù)平臺(tái) dumps 數(shù)據(jù)的采集

這里將簡(jiǎn)述為了提高系統(tǒng)可觀測(cè)性，對(duì)更多可觀測(cè)性相關(guān)數(shù)據(jù)類型的嘗試。在自研的數(shù)據(jù)處理引擎開(kāi)發(fā)過(guò)程中，發(fā)生 core-dump 的場(chǎng)景是比較常見(jiàn)的。若能夠快速分析 core-dump 的信息，能夠有效提高開(kāi)發(fā)效率。

但目前針對(duì) dumps 信息的采集，尚未有成熟的方案。且因 Linux kernel 的一些限制，尚未找到非常理想的采集方式。在 Docker 社區(qū)中有提到一些方案，例如允許每個(gè) container 去設(shè)置 core-dump 文件的 pattern 等，但這種技術(shù)可能短期內(nèi)還無(wú)法實(shí)現(xiàn)。

當(dāng)前，炎凰數(shù)據(jù)平臺(tái)采集 dumps 信息的方式是使用共享的 Kubernetes PV，用于存儲(chǔ)各個(gè)服務(wù)的 core-dump 文件，每個(gè)服務(wù)都在自己的專屬目錄下生成 core-dump 文件。數(shù)據(jù)采集器從共享的 PV 中采集所有服務(wù)的 dumps 數(shù)據(jù)，再通過(guò) core-dump 文件的路徑或者文件名的信息來(lái)補(bǔ)充元信息標(biāo)識(shí)，用以注明 core-dump 是發(fā)生在哪個(gè)服務(wù)的哪個(gè)模塊。

Dumps 數(shù)據(jù)被導(dǎo)入炎凰數(shù)據(jù)平臺(tái)之后，同樣可以創(chuàng)建儀表板，還有相關(guān)的告警。儀表板可以展示各個(gè)服務(wù)發(fā)生 core-dump 的歷史，倘若 core-dump 文件能夠被解析出來(lái)，在這個(gè)儀表板的下半部分，還可以直接展示出 core-dump 發(fā)生時(shí)刻的 backtrace，讓開(kāi)發(fā)人員可以快速了解發(fā)生異常的原因，節(jié)省自行尋找 core-dump 文件并解析所花費(fèi)的時(shí)間。

8、Kubernetes 的健康監(jiān)測(cè)

最后是關(guān)于 Kubernetes 健康監(jiān)測(cè)。目前，在炎凰數(shù)據(jù)平臺(tái)尚未建立一套關(guān)于 Kubernetes 的數(shù)據(jù)采集體系。但我們采用了一種類似于監(jiān)測(cè)網(wǎng)絡(luò)鏈路健康狀況的方式，使用了一款名為 Kuberhealthy 的工具。它會(huì)主動(dòng)執(zhí)行 Kubernetes 的一些操作，例如拉取鏡像、獲取 Pod，并記錄操作的結(jié)果，這些操作結(jié)果可以通過(guò) Prometheus 的 exporter 輸出。我們將該數(shù)據(jù)導(dǎo)入到炎凰數(shù)據(jù)平臺(tái)中，再通過(guò)構(gòu)建告警和儀表板來(lái)監(jiān)測(cè) Kubernetes 集群的健康狀況。

綜上所述，一體化可觀測(cè)平臺(tái)的優(yōu)勢(shì)還是比較明顯的。首先統(tǒng)一了數(shù)據(jù)的采集、分析、存儲(chǔ)三大模塊的過(guò)程，極大降低了系統(tǒng)的復(fù)雜度，減少了系統(tǒng)的運(yùn)維成本和系統(tǒng)需要的資源等。同時(shí)一體化可觀測(cè)平臺(tái)提供了較強(qiáng)的、能夠關(guān)聯(lián)不同類型數(shù)據(jù)的能力，也提供了挖掘可觀測(cè)數(shù)據(jù)更多價(jià)值的可能性。并且在用戶體驗(yàn)上，統(tǒng)一的用戶界面也提高了易用性。

9、炎凰數(shù)據(jù)平臺(tái)最新版本

炎凰數(shù)據(jù)平臺(tái)最新的版本是 2.11（*此處的2.11版本具體指2023年8月5日DataFunSummit2023：云原生大數(shù)據(jù)峰會(huì)的分享版本），同時(shí)推出了企業(yè)版和社區(qū)版。社區(qū)版是完全免費(fèi)的版本，用戶可以在本地運(yùn)行單機(jī)版，而且其中很多數(shù)據(jù)分析的核心功能與企業(yè)版并沒(méi)有區(qū)別，企業(yè)版更多的是著力于一些與企業(yè)相關(guān)的、側(cè)重企業(yè)運(yùn)營(yíng)的功能。歡迎大家關(guān)注和體驗(yàn)。