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

一、如何建設系統的可觀測體系

首先簡單介紹一下如何建設系統的可觀測體系。

1、何為“可觀測”體系

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

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

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

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

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

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

2、三步走建設系統的可觀測體系

明確需求

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

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

找到數據源

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

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

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

對于 traces 而言，或者 distributed traces，一般需要在系統中通過埋點來實現。

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

• 選擇合適的工具

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

二、企業建設可觀測體系時的痛點

1、企業建設系統可觀測體系時的痛點

經過調研，當前建設可觀測系統面臨的挑戰可以總結為以下幾大方面：

（1）高復雜度

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

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

（2）數據孤島

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

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

一個簡單的例子，調用鏈數據和日志數據可以通過元數據 trace ID 和 span ID 進行關聯，當我們在 traces 數據中發現了一條慢的請求，而且定位到了導致問題的 span，那么可以通過 trace ID 和 span ID 的關聯，快速定位到問題發生的 log。

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

綜上，若因數據存儲分析工具的不同形成數據孤島，會導致很難將多種數據類型關聯，進而限制我們從可觀測數據中挖掘更多價值的能力。

（3）一般的用戶體驗

用戶體驗不佳其實是前面所提及的兩個問題導致的。一個具有高復雜度的系統，且不具備數據關聯的能力，不僅意味著對使用者的要求比較高，且有可能仍舊無法有效解決目標系統的可觀測問題。這一問題也曾在 CNCF 的調查文件中體現。

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

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

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

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

（1）統一的數據采集工具

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

（2）統一的數據存儲、分析平臺

統一的數據和存儲和分析平臺，可以實現不同類型數據的查詢和數據的高效關聯。

（3）統一的用戶接口

統一的用戶接口，包括分析查詢語言、可視化和告警等。用戶使用統一接口查詢數據時，系統可以快速地在不同類型的數據之間流轉，通過一套統一的分析查詢語言，統一的可視化和告警等功能，有效降低系統使用的復雜度。總體而言，統一的用戶接口可極大降低用戶的使用門檻。

三、關于炎凰數據公司及產品

1、炎凰數據簡介

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

炎凰數據平臺的架構如上圖所示。

在此數據平臺上，支持將多種類型的數據源數據導入平臺，通過存儲引擎為數據建立索引，并存入文件系統。數據分析引擎則負責執行來自用戶的查詢任務。基于這套查詢引擎，平臺提供了豐富的用戶接口，例如可視化的儀表板、告警、即席查詢等功能，方便用戶進行數據探索和數據知識的積累。用戶可以基于上述平臺功能和接口來應對不同的使用場景，包括IT 運維領域、可觀測領域、生產領域等。

2、炎凰數據平臺功能及特性

（1）系統架構

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

其一，數據引擎方面，存算分離的架構，計算層和存儲層可以獨立拓展。

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

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

（2）數據采集

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

（3）數據引擎

關于數據引擎，首先需要特別指出的是，炎凰數據平臺支持混合建模，即同時支持讀時建模和寫時建模。讀時建模可以對非結構化或者半結構化的數據有更好的處理能力。在數據導入數據平臺之前，不需要額外的處理，而是在查詢階段構建數據模型。

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

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

（4）可視化

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

豐富的圖表還可以構建成儀表板，即用戶可以在儀表板中任意加入圖表以及設置圖表的大小和比例等。另外值得一提的是，儀表板支持動態參數引入，可以根據查詢的結果動態顯示圖表中的內容，并且支持下鉆以及數據的跳轉關聯等交互動作。

（5）其他

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

四、建設 YHP 自身可觀測性的實踐

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

1、自研數據采集器

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

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

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

2、加工數據

數據被采集集中之后，會被流轉至數據處理模塊進行數據加工處理，例如給數據附加元數據信息，之后再將數據導入炎凰數據平臺。

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

3、YHP 中數據采集器的部署

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

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

上述兩種方式保證了既不會漏掉任何數據，也不會出現數據的重復采集。

4、YHP 自身可觀測數據的存儲

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

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

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

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

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

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

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

5、統一 SQL 關聯查詢

上圖是一個查詢的例子：通過使用統一的 SQL 查詢分別查詢 traces 和 logs，以及通過 trace ID 關聯數據進行查詢。

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

6、可視化告警一體化監測駕駛艙

上圖展示的是基于可觀測數據構建的統一可視化儀表板和告警?；谥笜藬祿驼{用鏈數據去構建可視化看板，直觀展示平臺是否存在異常。另外告警功能體現在各組件的巡檢功能上，即每隔幾分鐘定期檢測平臺有無異常出現。若有異常出現，則會在該儀表板中顯示出異常狀態，并且在下方的告警列表中會有相應的告警。同時也附加了針對 logs 中的已知問題的告警場景。

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

7、炎凰數據平臺 dumps 數據的采集

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

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

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

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

8、Kubernetes 的健康監測

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

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

9、炎凰數據平臺最新版本

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