翻譯自 The Architecture of Modern Observability Platforms 。作者 KEVIN LIN 。

現(xiàn)代可觀測(cè)性平臺(tái)的架構(gòu)，數(shù)字藝術(shù)

可觀測(cè)性平臺(tái)是一個(gè)端到端的系統(tǒng)，幫助組織了解其應(yīng)用程序和服務(wù)的健康狀況。這種了解來(lái)自于現(xiàn)代可觀測(cè)性的三大支柱：指標(biāo)（時(shí)間序列數(shù)據(jù)）、日志（基于文本的數(shù)據(jù)）和跟蹤（帶有關(guān)聯(lián)數(shù)據(jù)/元數(shù)據(jù)的請(qǐng)求數(shù)據(jù)）。

現(xiàn)代可觀測(cè)性的挑戰(zhàn)是規(guī)?！覀儾辉僦挥袉蝹€(gè)主機(jī)運(yùn)行 LAMP 堆棧，每天生成幾兆字節(jié)的可觀測(cè)性數(shù)據(jù)，而是現(xiàn)在有數(shù)千個(gè)服務(wù)的 Kubernetes 集群，每小時(shí)產(chǎn)生數(shù)千兆字節(jié)的可觀測(cè)性數(shù)據(jù)。

在規(guī)模上收集、攝取、存儲(chǔ)和查詢(xún)可觀測(cè)性數(shù)據(jù)是現(xiàn)代可觀測(cè)性平臺(tái)的設(shè)計(jì)目標(biāo)。根據(jù)底層架構(gòu)的不同，運(yùn)行這些平臺(tái)的成本可能相差 100 倍以上。本文介紹了實(shí)施不同類(lèi)型架構(gòu)的不同解決方案。

可觀測(cè)性流水線

在深入討論架構(gòu)之前，先了解一些概念。在利用可觀測(cè)性數(shù)據(jù)時(shí)，有四個(gè)明確的階段：

1. 收集：可觀測(cè)性數(shù)據(jù)在邊緣收到（通常以在主機(jī)上運(yùn)行的代理形式）

2. 攝?。嚎捎^測(cè)性數(shù)據(jù)在目標(biāo)地處理（通常涉及批處理、壓縮和其他轉(zhuǎn)換，以使數(shù)據(jù)以最佳格式存儲(chǔ)）

3. 存儲(chǔ)：可觀測(cè)性數(shù)據(jù)保留（通常涉及索引）

4. 查詢(xún)：可觀測(cè)性數(shù)據(jù)被查找（通常涉及將查詢(xún)轉(zhuǎn)換為對(duì)底層存儲(chǔ)系統(tǒng)的 GET/LIST 請(qǐng)求）

可觀測(cè)性架構(gòu)

獨(dú)立的不同組件

隨著可觀測(cè)性從檢查?syslog?演變?yōu)閷?zhuān)用的監(jiān)控系統(tǒng)，早期的平臺(tái)為每個(gè)可觀測(cè)性支柱構(gòu)建了高度專(zhuān)業(yè)化的服務(wù)。這意味著指標(biāo)、日志和跟蹤是由完全獨(dú)立的系統(tǒng)處理的，具有獨(dú)立的收集、存儲(chǔ)和查詢(xún)層。

在開(kāi)源世界中，可能會(huì)運(yùn)行 Prometheus、Elasticsearch 和 Jaeger。以下是每個(gè)服務(wù)的流水線列表。

指標(biāo)的 Prometheus 流水線：

日志的 Elasticsearch 流水線：

跟蹤的 Jaeger 流水線：

在此期間成立的可觀測(cè)性供應(yīng)商（例如 Splunk、New Relic、Datadog）很可能是基于類(lèi)似架構(gòu)構(gòu)建的（即每個(gè)支柱都有獨(dú)立的服務(wù)）。

統(tǒng)一收集

隨著可觀測(cè)性范圍的增加（以及供應(yīng)商的增多），開(kāi)始出現(xiàn)了一些標(biāo)準(zhǔn)。這最終導(dǎo)致了 Open Telemetry (OTEL) 在 2019 年發(fā)布，它是這一領(lǐng)域兩個(gè)重要項(xiàng)目 OpenTracing 和 OpenCensus 合并后的產(chǎn)物。

到 2023 年，該標(biāo)準(zhǔn)已經(jīng)（大部分）成熟——它提供了一個(gè)供應(yīng)商中立的規(guī)范和實(shí)現(xiàn)，用于從任何來(lái)源收集指標(biāo)、日志和跟蹤數(shù)據(jù)，并將其發(fā)送到任何目的地。

目前所有的可觀測(cè)性供應(yīng)商都支持 OTEL 。

統(tǒng)一存儲(chǔ)

隨著可觀測(cè)性數(shù)據(jù)越來(lái)越龐大，人們開(kāi)始意識(shí)到使用高性能數(shù)據(jù)庫(kù)來(lái)存儲(chǔ)和索引所有這些數(shù)據(jù)的方法并不具備可擴(kuò)展性。

與其在昂貴的數(shù)據(jù)庫(kù)中預(yù)先索引所有內(nèi)容，不如只進(jìn)行部分索引，并將數(shù)據(jù)存儲(chǔ)在云對(duì)象存儲(chǔ)解決方案（例如 S3 ，通常采用 gzip + parquet 格式）中，這樣可以將每字節(jié)的成本降低一個(gè)數(shù)量級(jí)。

在開(kāi)源世界中，您可以在以下解決方案中找到這種架構(gòu)：

• 用于指標(biāo)的 Prometheus 搭配?Cortex/Mimir?后端

• 用于日志的?Loki

• 用于跟蹤的?Tempo

采用對(duì)象存儲(chǔ)后端的可觀測(cè)性供應(yīng)商：logz、grafana cloud 和 axiom 。

注意：ClickHouse 是一種高性能的開(kāi)源列式數(shù)據(jù)庫(kù)，也是存儲(chǔ)指標(biāo)、日志和追蹤數(shù)據(jù)的常用解決方案。然而，ClickHouse 的一個(gè)缺點(diǎn)是它將存儲(chǔ)層和查詢(xún)層耦合在一起，這意味著在基于 ClickHouse 的架構(gòu)中，基本的解耦（我們稍后將在本文中討論）是不可行的。

統(tǒng)一攝取

當(dāng)所有可觀測(cè)性數(shù)據(jù)都使用統(tǒng)一存儲(chǔ)后，簡(jiǎn)化其攝取就成為可能。

由于數(shù)據(jù)量大、吞吐量高，以及流量模式的突變，規(guī)?；瘯r(shí)的攝取非常困難。因此，您可以使用像 Kafka 這樣的流式平臺(tái)來(lái)整合所有數(shù)據(jù)。這些平臺(tái)專(zhuān)為實(shí)時(shí)大規(guī)模攝取數(shù)據(jù)設(shè)計(jì)，并允許實(shí)時(shí)對(duì)數(shù)據(jù)進(jìn)行豐富和轉(zhuǎn)換。

我不知道有任何采用這種架構(gòu)的開(kāi)源可觀測(cè)性項(xiàng)目?？赡艿脑蚴牵悄褂媒y(tǒng)一存儲(chǔ)后端為所有三個(gè)支柱構(gòu)建了一個(gè)可觀測(cè)性平臺(tái)，否則構(gòu)建專(zhuān)用的攝取機(jī)制比部署 Kafka 等流式平臺(tái)更高效。

可觀測(cè)性供應(yīng)商 Coralogix 采用了一種類(lèi)似的統(tǒng)一基于流的架構(gòu)。

統(tǒng)一查詢(xún)

當(dāng)所有可觀測(cè)性數(shù)據(jù)都存儲(chǔ)在統(tǒng)一存儲(chǔ)中時(shí)，簡(jiǎn)化查詢(xún)就成為可能（通常也是必要的）。

當(dāng)數(shù)據(jù)被索引時(shí)，查詢(xún)數(shù) TB 的數(shù)據(jù)是昂貴的，并且當(dāng)數(shù)據(jù)沒(méi)有索引時(shí)，以可接受的延遲進(jìn)行查詢(xún)也很困難。這時(shí)，大規(guī)模并行處理（MPP）技術(shù)就發(fā)揮作用了——通過(guò)啟動(dòng)多個(gè)處理器來(lái)獨(dú)立處理數(shù)據(jù)（使用類(lèi)似 Spark 和 Trino 的工具），再結(jié)合元數(shù)據(jù)存儲(chǔ)（如 Hive 或 Apache Iceberg ），可以在幾秒鐘內(nèi)處理數(shù) TB 的"非索引"數(shù)據(jù)。

與攝取類(lèi)似，我不知道有任何采用這種架構(gòu)的開(kāi)源可觀測(cè)性平臺(tái)。原因與攝取類(lèi)似——除非從一開(kāi)始就構(gòu)建支持統(tǒng)一存儲(chǔ)的可觀測(cè)性平臺(tái)，否則部署像 Spark 或 Trino 這樣的工具的開(kāi)銷(xiāo)不值得。

可觀測(cè)性供應(yīng)商 Observe?采用了使用 Snowflake 作為其 MPP 引擎的統(tǒng)一查詢(xún)架構(gòu)。

最后的思考

世界上有很多可觀測(cè)性數(shù)據(jù)和許多平臺(tái)可以幫助您利用這些數(shù)據(jù)。這一切都有代價(jià)——主要驅(qū)動(dòng)因素是可觀測(cè)性平臺(tái)的底層架構(gòu)（以及供應(yīng)商希望實(shí)現(xiàn)的利潤(rùn)）。

通過(guò)統(tǒng)一存儲(chǔ)層，可觀測(cè)性平臺(tái)能夠在規(guī)模上實(shí)現(xiàn)擴(kuò)展，同時(shí)將成本降低一個(gè)數(shù)量級(jí)。統(tǒng)一攝取層和查詢(xún)層也有可能帶來(lái)類(lèi)似的好處。

現(xiàn)在有機(jī)會(huì)通過(guò)統(tǒng)一可觀測(cè)性管道的每個(gè)層面來(lái)創(chuàng)建一個(gè)更具規(guī)模和可負(fù)擔(dān)性的可觀測(cè)性平臺(tái)。在之前的文章中，我們展示了對(duì)比 Datadog ，通過(guò)將日志統(tǒng)一處理可以將成本降低 95% 以上。

這種統(tǒng)一架構(gòu)有效地將規(guī)?；目捎^測(cè)性變?yōu)樯唐坊ｋS著被觀察數(shù)據(jù)量的持續(xù)增長(zhǎng)，這是一件好事——按照我們目前的速度，即使企業(yè)公司也開(kāi)始尋找替代解決方案來(lái)降低成本。

盡管如此，擁有數(shù)據(jù)只是開(kāi)始——真正的價(jià)值在于將這些信息轉(zhuǎn)化為洞察力和業(yè)務(wù)結(jié)果。一旦我們不再擔(dān)心成本，我們就可以盡早回到專(zhuān)注于這一點(diǎn)。