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

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

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

1、何為“可觀測”體系

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

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

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

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

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

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

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

明確需求

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

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

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

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

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

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

對于 traces 而言，或者 distributed traces，一般需要在系統(tǒng)中通過埋點來實現(xiàn)。

在開源工具中比較普遍的是 OpenTelemetry 的標準，它為常見的技術(shù)棧提供了無侵入式埋點的方法。在炎凰數(shù)據(jù)平臺中，也是使用了 OpenTelemetry 這種無侵入式的 instrumentation 來實現(xiàn) traces 數(shù)據(jù)的生成。

• 選擇合適的工具

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

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

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

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

（1）高復(fù)雜度

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

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

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

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

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

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

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

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

（3）一般的用戶體驗

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

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

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

2、解決方案：一體化可觀測平臺

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（4）可視化

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

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

（5）其他

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

當可觀測數(shù)據(jù)被采集到炎凰數(shù)據(jù)平臺之后，metrics / traces / logs 分別存在不同的數(shù)據(jù)集（相當于數(shù)據(jù)庫中表的概念）里。主要的原因是為了性能上的優(yōu)化調(diào)整，因為通常是按數(shù)據(jù)集查詢，在查詢某一類型數(shù)據(jù)時，性能不會受另外兩種數(shù)據(jù)的數(shù)據(jù)量影響而下降。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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