可觀測(cè)性概念

當(dāng)一個(gè)軟件或系統(tǒng)出于運(yùn)行狀態(tài)時(shí)，如果我們不對(duì)他加以觀測(cè)，那它的運(yùn)行狀態(tài)對(duì)我們來(lái)說(shuō)就是一個(gè)黑盒。

如上圖所示。

我們只能通過(guò)業(yè)務(wù)的表象來(lái)判斷它是否正常運(yùn)行，無(wú)法在故障發(fā)生前進(jìn)行預(yù)判，從而只能被動(dòng)解決問(wèn)題。

這類問(wèn)題在微服務(wù)時(shí)代體現(xiàn)的更加明顯，即便是業(yè)務(wù)已經(jīng)出現(xiàn)問(wèn)題，在沒(méi)有可觀測(cè)性系統(tǒng)的前提下想要定位問(wèn)題更是難上加難。

好在可觀測(cè)性這個(gè)概念由來(lái)已久，已經(jīng)由一些業(yè)界大佬抽象出幾個(gè)基本概念：

• Logs：離散的日志信息
• Metrics：聚合的指標(biāo)
• Trace：請(qǐng)求基本的鏈路追蹤

結(jié)合這三個(gè)指標(biāo)，我們排查問(wèn)題的流程一般如下：

首先根據(jù) metrics 來(lái)判斷是否有異常，這點(diǎn)可以通過(guò)在 Prometheus 的 AlertManager 配置一些核心的告警指標(biāo)。

比如當(dāng) CPU、內(nèi)存使用率超過(guò) 80% 或者某個(gè)應(yīng)用 Down 機(jī)后就發(fā)出告警。

groups:
- name: AllInstances
  rules:
  - alert: InstanceDown
    # Condition for alerting
    expr: up == 0
    for: 1m
    # Annotation - additional informational labels to store more information
    annotations:
      title: 'Instance {{ $labels.instance }} down'
      description: '{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 1 minute.'
    # Labels - additional labels to be attached to the alert
    labels:
      severity: 'critical'

這可以讓我們盡早發(fā)現(xiàn)故障。

之后我們可以通過(guò)鏈路信息找到發(fā)生故障的節(jié)點(diǎn)。

然后通過(guò)這里的 trace_id 在應(yīng)用中找到具體的日志：

mdc.trace_id:4a686dedcdf4e95b1a83b36e62563a96

再根據(jù)日志中的上下文確定具體的異常原因。

這就是一個(gè)完整的排查問(wèn)題的流程。

OpenTelemetry 發(fā)展歷史

在 OpenTelemetry 開(kāi)始之前還是先回顧下可觀測(cè)性的發(fā)展歷史，其中有幾個(gè)重要時(shí)間點(diǎn)：

• 2010 年 Google 發(fā)布了 Dapper 論文，給業(yè)界帶來(lái)了實(shí)現(xiàn)分布式追蹤的理論支持，之后的許多分布式鏈路追蹤實(shí)現(xiàn)都有它的影子
• kubernetes 的發(fā)布奠定了后續(xù)云原生社區(qū)的基礎(chǔ)
• Jaeger 發(fā)布后成為了主流的鏈路存儲(chǔ)系統(tǒng)
• 2019 年 OpenTracing 和 OpenCensus 合并為 OpenTelemetry
• 2021 年底 OpenTelemetry 發(fā)布第一個(gè) GA release 版本

OpenTelemetry 是什么？

以前我們所接觸到的類似于阿里的ARMS、美團(tuán)的 CAT、Pinpoint 這類系統(tǒng)大多都有一個(gè)公司在背后進(jìn)行驅(qū)動(dòng)，與廠商綁定的非常緊密。

而 OpenTelemetry 則相反，它主要由社區(qū)驅(qū)動(dòng)，參與的公司眾多；同時(shí)它定義和提供了一套可觀測(cè)性的標(biāo)準(zhǔn)（包括 API、SDK、規(guī)范等數(shù)據(jù)）。

使用它你可以靈活的選擇和搭配任意的開(kāi)源或商業(yè)產(chǎn)品來(lái)組成你的可觀測(cè)性技術(shù)棧。

因?yàn)樯鐓^(qū)非?；钴S，所以當(dāng)前也幾乎支持主流的開(kāi)發(fā)語(yǔ)言。

OpenTelemetry 的架構(gòu)

OpenTelemetry 的架構(gòu)主要分為三個(gè)部分：

• 左側(cè)的客戶端 Agent，用于采集客戶端的數(shù)據(jù)，通常就是我們的應(yīng)用。
• 中間的是 Collector-Service，用于接受客戶端的數(shù)據(jù)、內(nèi)部處理、導(dǎo)出數(shù)據(jù)到各種存儲(chǔ)
• 右側(cè)的則是各種存儲(chǔ)層，用于存儲(chǔ) Metrics、Logs、Traces 這些數(shù)據(jù)。

我們基于官方推薦的技術(shù)架構(gòu)選型了我們的技術(shù)棧：

主要的區(qū)別就是使用 VictoriaMetrics 存儲(chǔ)指標(biāo)、StackRocks 存儲(chǔ) Trace，ElasticSearch 存儲(chǔ)日志。

只是目前我們的日志鏈路還沒(méi)有完全切換到 OpenTelemetry 的鏈路，依然是在 Pod 中掛載了一個(gè) sidecar，在這個(gè) sidecar 中通過(guò) filebeat 采集日志輸出到 elasticsearch，后續(xù)也會(huì)逐步遷移。

核心項(xiàng)目

Collecotor

OpenTelemetry 社區(qū)的項(xiàng)目眾多，其中大部分都是各種語(yǔ)言的 SDK 和 API，其中最為關(guān)鍵的應(yīng)該就是 opentelemetry-collector

也就是剛才架構(gòu)圖中的中間部分，我們可以把它理解為類似 APIGateway 的角色，所有上報(bào)的 OTel 數(shù)據(jù)都得經(jīng)過(guò)它的處理。

主要由以下三部分組成：

• Receiver：用于接受客戶端上報(bào)的數(shù)據(jù)
• Process：內(nèi)部的數(shù)據(jù)處理器
• Exporter：將數(shù)據(jù)導(dǎo)出到不同的存儲(chǔ)

由于 OpenTelemetry 社區(qū)非常的活躍，所以這里支持的 Receiver、Processor 和 Exporter 類型非常多。

其他核心項(xiàng)目

我們以 Java 為例，對(duì)業(yè)務(wù)開(kāi)發(fā)最重要的庫(kù)就是 opentelemetry-java-instrumentation

它可以打包一個(gè) javaagent 給我們使用：

# Java example
java -javaagent:path/to/opentelemetry-javaagent.jar \  
     -jar myapp.jar

同時(shí)也支持了我們?nèi)粘ｉ_(kāi)發(fā)的絕大多數(shù)框架和中間件。

支持的庫(kù)與框架列表

如果我們需要在應(yīng)用中自定義打樁一些 Span、Metrics ，就還需要 opentelemetry-java 這個(gè)項(xiàng)目。

它提供了具體的 SDK 可以方便的創(chuàng)建 Span 和 Metrics。

Trace

之后來(lái)看看 OpenTelemetry 中具體的三個(gè)維度的概念和應(yīng)用，首先是 Trace。

Trace 這個(gè)概念首先是 Google Dapper 論文中提到。

如上圖所示：一次用戶請(qǐng)求經(jīng)歷了 4 次 PRC 調(diào)用，分別也屬于不同的系統(tǒng)。

每一次 RPC 調(diào)用就會(huì)產(chǎn)生一個(gè) Span，將這些 span 串聯(lián)起來(lái)就能形成一個(gè)調(diào)用鏈路。

這個(gè) Span 主要包含以下信息：

• SpanName
• ParentID
• SpanID

當(dāng)我們將一個(gè) Span 放大后會(huì)看到更加具體的信息：

• TraceId
• SpanName
• ParentID
• SpanID
• 開(kāi)始時(shí)間
• 結(jié)束時(shí)間 在 Dapper 論文中使用 Annotations 來(lái)存放 span 的屬性，當(dāng)然也可以自定義存放一些數(shù)據(jù)，比如圖中的 "foo"。

在 OpenTelemetry 的 SDK 中稱為  attribute，而在 Jaeger 的 UI 中又稱為 tag，雖然叫法不同，但本質(zhì)上是一個(gè)東西。

最終就會(huì)形成上圖中的樹狀結(jié)構(gòu)的調(diào)用關(guān)系。

Span Kind

Span 中還有一個(gè)非常重要的概念，就是 Span Kind，也就是 Span 的類型，這個(gè)類型可以在排查問(wèn)題時(shí)很容易得知該服務(wù)的類型。

按照官方的定義，Span 的類型分為：

• Client
• Server
• Internal
• Producer
• Consumer

對(duì)于 RPC 的客戶端和服務(wù)端自然就對(duì)應(yīng) Client 和 Server，而使用了消息隊(duì)列的生產(chǎn)者消費(fèi)者對(duì)應(yīng)的就是 Produce 和 Consumer。

除此之外發(fā)生在應(yīng)用內(nèi)部的一些關(guān)鍵 Span 的類型就是 Internal，比如我們需要對(duì)業(yè)務(wù)的某些關(guān)鍵函數(shù)生成 Span 時(shí)，此時(shí)的 Span 類型通常也都是 Internal。

上下文傳遞

在 Trace 中有一個(gè)關(guān)鍵技術(shù)問(wèn)題需要被解決，也就是 Context 的上下文傳遞。

這個(gè)特別是在分布式系統(tǒng)中必須要解決，我們可以簡(jiǎn)單把它理解為如何把上游生成的 trace_id 傳遞到下游，這樣才能在追蹤的鏈路追蹤系統(tǒng)中串聯(lián)起來(lái)。

這個(gè)關(guān)鍵的技術(shù)名詞在 OpenTelemetry 中稱為：Context Propagation.

在分布式系統(tǒng)中，數(shù)據(jù)都是通過(guò)網(wǎng)絡(luò)傳遞的，所以這里的本質(zhì)問(wèn)題依然是如何將上下文數(shù)據(jù)序列化之后，在下游可以反序列化到 Context 中。

聰明的小伙伴應(yīng)該已經(jīng)想到，我們可以將 trace_id 寫入到跨進(jìn)程調(diào)用的元數(shù)據(jù)中：

• http 可以存放在 http header 中
• gRPC 可以存放在 meta 中
• Pulsar 可以存放在消息的 properties 中
• 其余的中間件和框架也是同理

然后在遠(yuǎn)程調(diào)用之前使用 Inject 將數(shù)據(jù)注入到這些元數(shù)據(jù)里，下游在接收到請(qǐng)求后再通過(guò)一個(gè)Extract 函數(shù)將元數(shù)據(jù)解析到 Context 中，這樣 trace_id 就可以串聯(lián)起來(lái)了。

上圖就是 Pulsar 和 gRPC 傳遞 trace_id 的過(guò)程，數(shù)據(jù)都是存放在元數(shù)據(jù)中的，這里的 traceparent 的值本質(zhì)上就是 trace_id.

具體的代碼細(xì)節(jié)我會(huì)在下一篇繼續(xù)分析。

Metrics

Metrics 相對(duì)于 Trace 來(lái)說(shuō)則是要簡(jiǎn)單許多，OpenTelemetry 定義了許多命名規(guī)范和標(biāo)準(zhǔn)，這樣大家在復(fù)用社區(qū)的一些監(jiān)控模板時(shí)就要更加容易一些。

Metrics Exemplars

Metrics 還提供了一個(gè) Exemplar 的功能，它的主要作用是可以將 Metrics 和 Trace 關(guān)聯(lián)在一起，這樣在通過(guò) Metrics 發(fā)現(xiàn)問(wèn)題時(shí)，就可以直接跳轉(zhuǎn)到鏈路系統(tǒng)。

因?yàn)?trace_id 可以通過(guò) MDC 和日志關(guān)聯(lián)，所以我們可以直接通過(guò) Metrics 定位具體應(yīng)用的日志，這樣排查問(wèn)題的效率將會(huì)非常高。

擴(kuò)展信息

以上就是關(guān)于 OpenTelemetry 的整體架構(gòu)，下面來(lái)擴(kuò)展一些內(nèi)容。

eBPF

eBPF 是一個(gè)運(yùn)行在 Linux 內(nèi)核中的虛擬機(jī)，它提供一套特殊的指令集并允許我們?cè)诓恢匦戮幾g內(nèi)核、也不需要重啟應(yīng)用的情況下加載自定義的邏輯。

eBPF 技術(shù)具有三大特點(diǎn)：

• 第一是無(wú)侵入，動(dòng)態(tài)掛載，目標(biāo)進(jìn)程無(wú)需重啟，而且因?yàn)槭?Linux 內(nèi)核提供功能，所以與語(yǔ)言無(wú)關(guān)，任何語(yǔ)言都可以支持。
• 第二是高性能，eBPF 字節(jié)碼會(huì)被 JIT 成機(jī)器碼后執(zhí)行，效率非常高；
• 第三是更加安全，它會(huì)運(yùn)行在自己的沙箱環(huán)境中，不會(huì)導(dǎo)致目標(biāo)進(jìn)程崩潰。

eBPF 雖然有很多優(yōu)點(diǎn)，同時(shí)也有一些局限性，比如我想監(jiān)控業(yè)務(wù)代碼中的某個(gè)具體指標(biāo)（訂單創(chuàng)建數(shù)量），此時(shí)它就難以實(shí)現(xiàn)了，所以還得看我們的應(yīng)用場(chǎng)景。更適合一些云平臺(tái)，或者更偏向底層的應(yīng)用。

目前 eBPF 的應(yīng)用場(chǎng)景還不夠廣泛，但假以時(shí)日一定會(huì)成為可觀測(cè)領(lǐng)域的未來(lái)之星。

SigNoz

不知道大家發(fā)現(xiàn)沒(méi)有，如果我們直接 OpenTelemetry 技術(shù)棧會(huì)需要為 Trace、Metrics、Logs 選擇不同的存儲(chǔ)，而且他們的查詢界面也分散在不同的地方。

那有沒(méi)有一個(gè)統(tǒng)一的平臺(tái)可以給我們提供完整的可觀測(cè)體驗(yàn)?zāi)兀?/p>

有這樣的需求那就有對(duì)應(yīng)的廠商實(shí)現(xiàn)了：

SigNoz 就是這樣的平臺(tái)，它將 OpenTelemetry-collector 和數(shù)據(jù)存儲(chǔ)全部整合在了一起，同時(shí)全面兼容  OpenTelemetry；可以說(shuō)它就是基于 OpenTelemetry 構(gòu)建的一個(gè)可觀測(cè)產(chǎn)品。

對(duì)于一些中小廠商，不想單獨(dú)維護(hù)這些組件時(shí)是非常有用的。

OpenObserve

OpenObserve在 SigNoz 的基礎(chǔ)上做的更加極致一些，它提供了一個(gè)統(tǒng)一的存儲(chǔ)可以存放日志、Trace、Metrics 等數(shù)據(jù)。

這樣我們就可以只使用一個(gè)數(shù)據(jù)庫(kù)存放所有的數(shù)據(jù)，同時(shí)它也提供了完整的 UI，并且也全面兼容 OpenTelemetry。

這樣對(duì)于運(yùn)維來(lái)說(shuō)會(huì)更加簡(jiǎn)單，只是可能帶來(lái)的副作用就是需要與它完全綁定。

總結(jié)

以上就是 OpenTelemetry 在企業(yè)的應(yīng)用，大家可以根據(jù)自己的情況選擇自建 OTel 的技術(shù)棧，還是選擇 SigNoz 和 OpenObserve 這類的標(biāo)準(zhǔn)化產(chǎn)品。