建站
咨詢
售后
建站咨詢
新聞中心
譯者 | 陳峻
成都創(chuàng)新互聯(lián)是一家專業(yè)提供崆峒企業(yè)網(wǎng)站建設(shè),專注與成都做網(wǎng)站、網(wǎng)站建設(shè)、HTML5、小程序制作等業(yè)務(wù)。10年已為崆峒眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)站設(shè)計(jì)公司優(yōu)惠進(jìn)行中。
審校 | 孫淑娟
無論您是否已經(jīng)實(shí)現(xiàn)了微服務(wù)，您的系統(tǒng)往往會由反向代理、應(yīng)用程序、以及數(shù)據(jù)庫等多個組件組成。只要服務(wù)請求流經(jīng)的組件數(shù)量越多，您對于監(jiān)控的需求就越強(qiáng)烈。當(dāng)然，監(jiān)控只是狀態(tài)跟蹤的開始，您更需要一個能夠橫跨所有組件的聚合性視圖，通過指標(biāo)和日志兩個維度，來實(shí)現(xiàn)可觀察性。
1.W3C的規(guī)范
具有跟蹤能力的解決方案通常能夠通過異構(gòu)技術(shù)棧，來規(guī)范化監(jiān)控的標(biāo)準(zhǔn)格式。目前，市場上已經(jīng)存在了幾個不同的實(shí)現(xiàn)規(guī)范。而在大多數(shù)情況下，正如下面著名的XKCD漫畫所描述的那樣，一個新的規(guī)范需求往往會導(dǎo)致另一個額外規(guī)范的實(shí)施。
在此，我向你介紹一個新的、市場正在遵守的W3C規(guī)范--Trace Context。該規(guī)范定義了標(biāo)準(zhǔn)的HTTP標(biāo)頭和一種數(shù)值的格式，來支持分布式跟蹤場景的上下文信息。畢竟，上下文信息不但能夠唯一地標(biāo)識分布式系統(tǒng)中的各種請求，而且定義了一種添加和傳播提供者特定信息的方法。而Trace Context規(guī)范恰好標(biāo)準(zhǔn)化了上下文信息在服務(wù)之間的發(fā)送和修改方式。其中也包含了兩個如下圖所示的關(guān)鍵性概念：
- 跟蹤（Trace）需要遵循跨越多個組件的請求路徑。
- 跨越（Span）被綁定到了單個組件上，并通過父子關(guān)系，鏈接到另一個跨越。
目前Trace Context已經(jīng)有了多種實(shí)現(xiàn)，而其中一種便是OpenTelemetry。
2.OpenTelemetry可作為黃金標(biāo)準(zhǔn)
OpenTelemetry是一種工具、API和SDK的集合，適用于多種語言。用戶可以使用它來檢測、生成、收集和導(dǎo)出指標(biāo)、日志和跟蹤等遙測類型的數(shù)據(jù)，以便分析軟件的性能和行為。
OpenTelemetry是一個由CNCF管理的項(xiàng)目。在它之前已有如下兩個項(xiàng)目：
- OpenTracing，顧名思義是專注于跟蹤的
- OpenCensus，其目標(biāo)是管理指標(biāo)和跟蹤
通過合并兩個項(xiàng)目的日志功能，OpenTelemetry目前提供了一組專注于可觀察性的層面。該層面具有如下特征：
- 通過多種語言檢測API
- 用不同的語言規(guī)范化實(shí)現(xiàn)
- 提供諸如收集器等基礎(chǔ)設(shè)施組件
- 提供諸如W3C Trace Context的互操作性格式
值得注意的是，OpenTelemetry雖然是Trace Context的一種實(shí)現(xiàn)，但是其功能更為廣泛。Trace Context將自身限制在HTTP場景中，而OpenTelemetry則可以跨越到Kafka等非Web組件上。
3.用例
下面，讓我們以某個電商網(wǎng)站為例，進(jìn)行深入探討。假設(shè)該電商網(wǎng)站是圍繞微服務(wù)設(shè)計(jì)的，其中包含了管理產(chǎn)品的catalog和處理產(chǎn)品價格的pricing，這兩個微服務(wù)。如下圖所示，catalog是一個用Kotlin編寫的Spring Boot應(yīng)用，而pricing一個Python Flask應(yīng)用。
每個微服務(wù)都可以通過REST API被訪問到，并且受到API網(wǎng)關(guān)的保護(hù)。當(dāng)用戶訪問該應(yīng)用時，主頁會從后臺獲取所有產(chǎn)品、及其價格的信息，予以呈現(xiàn)。而跟蹤則可以讓我們跨過微服務(wù)或數(shù)據(jù)庫網(wǎng)關(guān)，去跟蹤某個請求的路徑。
4.網(wǎng)關(guān)處的跟蹤
我們將使用Apache APISIX在入口點(diǎn)（也就是網(wǎng)關(guān)）處生成跟蹤ID。此處的Apache APISIX提供了諸如：負(fù)載均衡、動態(tài)上游、金絲雀發(fā)布、斷路器、身份驗(yàn)證、可觀察性等，豐富的流量管理功能。同時，基于插件架構(gòu)的Apache APISIX，通過提供OpenTelemetry插件，來根據(jù)OpenTelemetry的規(guī)范產(chǎn)生跟蹤數(shù)據(jù)。不過，該插件僅支持基于HTTP的二進(jìn)制編碼--OLTP。
下面，讓我們來配置opentelemetry插件：
YAML
apisix:
enable_admin: false #1
config_center: yaml #1
plugins:
-OpenTelemetry #2
plugin_attr:
opentelemetry:
resource:
service.name: APISIX #3
collector:
address: jaeger:4318 #4
#1：在獨(dú)立模式下運(yùn)行Apache APISIX，以便應(yīng)用易于被理解。
#2：將opentelemetry配置為全局插件。
#3：設(shè)置服務(wù)的名稱。它將成為出現(xiàn)在跟蹤顯示組件中的名稱。
#4：將跟蹤發(fā)送到j(luò)aeger服務(wù)處。我們將在下文中詳細(xì)討論。
為了跟蹤每一條路由，我們需要通過如下代碼，將插件設(shè)置為全局插件，而無需向每條路由添加插件：
YAML
global_rules:
- id: 1
plugins:
opentelemetry:
sampler:
name:
#1：由于跟蹤本身也會對性能產(chǎn)生影響，而且追蹤的內(nèi)容越多，影響也就越大，因此，我們?nèi)孀屑?xì)平衡性能影響與可觀察性的收益。不過，在本例中，我們?nèi)匀幌Ｍ軌蚋櫭總€請求。
5.收集、存儲和顯示跟蹤
雖然Trace Context是一種W3C規(guī)范，而且OpenTelemetry是事實(shí)上的標(biāo)準(zhǔn)，但是目前市場上仍存在許多收集、存儲和顯示跟蹤的解決方案。例如，Elastic技術(shù)棧雖然可以處理各種存儲和顯示，但是用戶必須依靠其他產(chǎn)品進(jìn)行收集；而Jaeger和Zipkin則能夠通過一個完整的套件，全面實(shí)現(xiàn)收集、存儲和顯示跟蹤。
早于OpenTelemetry的Jaeger和Zipkin雖然有著各自不同的跟蹤傳輸格式，但是它們都能夠與OpenTelemetry的格式相集成。鑒于Jaeger能夠提供一個一體化的Docker鏡像，而且每個功能都有其對應(yīng)的組件，同時它們被嵌入在同一個鏡像中，以方便配置。因此，我在此選用Jaeger。其鏡像的相關(guān)端口分配如下：
|
端口 |
協(xié)議 |
組件 |
功能 |
|
16686 |
HTTP |
查詢 |
服務(wù)前端 |
|
4317 |
HTTP |
收集器 |
如果啟用的話，接受通過gRPC的OpenTelemetry協(xié)議（OTLP） |
|
4318 |
HTTP |
收集器 |
如果啟用的話，接受通過HTTP的OpenTelemetry協(xié)議 |
其Docker Compose的代碼為：
YAML
services:
jaeger:
image: jaegertracing/all-in-one:1.37 #1
environment:
- COLLECTOR_OTLP_ENABLED=true #2
ports:
- "16686:16686" #3
#1：使用all-in-one的鏡像。
#2：啟用OpenTelemetry格式的收集器（非常重要）。
#3：暴露UI端口。
至此，我們已經(jīng)完成了基礎(chǔ)設(shè)施的構(gòu)建，下面我們將專注于在應(yīng)用中啟用跟蹤。
6.Flask應(yīng)用的跟蹤
pricing服務(wù)是一個簡單的Flask應(yīng)用程序。它提供了從數(shù)據(jù)庫中獲取單個產(chǎn)品與價格的端點(diǎn)。下面是對應(yīng)的代碼：
Python
@app.route('/price/') #1-2
def price(product_str: str) -> Dict[str, object]:
product_id = int(product_str)
price: Price = Price.query.get(product_id) #3
if price is None:
return jsonify({'error': 'Product not found'}), 404
else:
low: float = price.value - price.jitter #4
high: float = price.value + price.jitter #4
return {
'product_id': product_id,
'price': round(uniform(low, high), 2) #4
}
#1：端點(diǎn)
#2：路由需要產(chǎn)品的ID。
#3：使用SQLAlchemy從數(shù)據(jù)庫中獲取數(shù)據(jù)。
#4：在此，我們會隨機(jī)產(chǎn)生價格。當(dāng)然，真實(shí)定價引擎并非如此。
值得注意的是，為了觀察跟蹤，我們在此采用的是低效的、每次僅調(diào)用并獲取單一價格的方式。而在現(xiàn)實(shí)生活中，路由應(yīng)該能夠接受多個產(chǎn)品的ID，并在一個“請求-響應(yīng)”中獲取所有相關(guān)的價格。
我們可以用自動和手動兩種方式來檢測應(yīng)用。由于手動需要付出開發(fā)時間，而自動既省力又快速，因此我建議您從自動開始，如需添加手動的方式。
首先，我們需要添加幾個Python包：
- opentelemetry-distro[otlp]==0.33b0
- opentelemetry-instrumentation
- opentelemetry-instrumentation-flask
接著，我們需要配置如下參數(shù)：
YAML
pricing:
build: ./pricing
environment:
OTEL_EXPORTER_OTLP_ENDPOINT: http://jaeger:4317 #1
OTEL_RESOURCE_ATTRIBUTES: service.name=pricing #2
OTEL_METRICS_EXPORTER: none #3
OTEL_LOGS_EXPORTER:
左右滑動查看完整代碼
#1：將跟蹤發(fā)送給Jaeger。
#2：設(shè)置服務(wù)的名稱。它將成為出現(xiàn)在跟蹤顯示組件中的名稱。
#3：在此，我們暫時忽略日志和指標(biāo)。
然后，我們并不使用標(biāo)準(zhǔn)的flask run命令，而是將其進(jìn)行如下包裝：
Shell
opentelemetry-instrument flask run
至此，我們已經(jīng)從方法調(diào)用和Flask路由中，收集到了跨越。
下面，我們以手動的方式，按需添加額外的跨度：
Python
fromOpenTelemetryimport trace
@app.route('/price/')
def price(product_str: str) -> Dict[str, object]:
product_id = int(product_str)
with tracer.start_as_current_span("SELECT * FROM PRICE WHERE ID=:id", attributes={":id": product_id}) as span: #1
price: Price = Price.query.get(product_id)
# ...
#1：使用配置的標(biāo)簽和屬性添加一個額外的跨度。
7.Spring Boot應(yīng)用的跟蹤
catalog服務(wù)是用Kotlin開發(fā)的Reactive Spring Boot應(yīng)用。它提供了如下兩個端點(diǎn)：
- 獲取單個產(chǎn)品
- 獲取所有產(chǎn)品
兩者都是先查看產(chǎn)品數(shù)據(jù)庫，再查詢上述pricing服務(wù)的價格。
而對于Python而言，我們同樣可以利用自動和手動兩種檢測方法。在此，讓我們先從唾手可得的自動化開始。在JVM上，我們通過一個代理來實(shí)現(xiàn)：
Shell
java -javaagent :opentelemetry-javaagent.jar -jar catalog.jar
與Python一樣，它為每個方法的調(diào)用和HTTP的入口點(diǎn)創(chuàng)建了跨越。同時，它還會檢測JDBC的調(diào)用。在本例的Reactive棧中，我們使用的是R2DBC。因此，我們需要配置如下默認(rèn)行為：
YAML
catalog:
build: ./catalog
environment:
APP_PRICING_ENDPOINT: http://pricing:5000/price
OTEL_EXPORTER_OTLP_ENDPOINT: http://jaeger:4317 #1
OTEL_RESOURCE_ATTRIBUTES: service.name=orders #2
OTEL_METRICS_EXPORTER: none #3
OTEL_LOGS_EXPORTER:
#1：將跟蹤發(fā)送給Jaeger。
#2：設(shè)置服務(wù)的名稱。它將成為出現(xiàn)在跟蹤顯示組件中的名稱。
#3：在此，我們暫時忽略日志和指標(biāo)。
而對于Python而言，我們直接添加手動檢測。當(dāng)然，目前有兩個選項(xiàng)可被采用：程序化和基于注釋。除非我們引入Spring Cloud Sleuth，否則前者會略顯復(fù)雜。下面，讓我們來添加額外的依賴性：
XMLio.opentelemetry.instrumentation opentelemetry-instrumentation-annotations 1.17.0-alpha
其對應(yīng)的注釋性代碼為：
Kotlin
@WithSpan("ProductHandler.fetch") //1
suspend fun fetch(@SpanAttribute("id") id: Long): Result{ //2
val product = repository.findById(id)
return if (product == null) Result.failure(IllegalArgumentException("Product $id not found"))
else Result.success(product)
}
#1：使用配置的標(biāo)簽添加一個額外的跨越。
#2：將參數(shù)用作屬性，將鍵（key）設(shè)置為id，其對應(yīng)的值則設(shè)置為參數(shù)的運(yùn)行時數(shù)值。
8.輸出結(jié)果
下面，我們通過如下命令來查看該示例的結(jié)果：
Shell
curl localhost:9080/products
curl localhost:9080/products/1
通過如下Jaeger UI，我們可以找到兩條跟蹤（每次調(diào)用一條）：
我們也可以深入研究單個跟蹤的跨越：
值得注意的是，我們還可以在沒有前文那張UML圖表的情況下，推斷出其數(shù)據(jù)流圖。此類數(shù)據(jù)流圖很好地顯示了組件的內(nèi)部調(diào)用。而且，每個跨越都包含了由自動與手動檢測添加進(jìn)來的屬性：
9.小結(jié)
綜上所述，我通過簡單的示例，展示了如何使用OpenTelemetry，跨過微服務(wù)或數(shù)據(jù)庫網(wǎng)關(guān)，實(shí)現(xiàn)對某個請求路徑的端對端跟蹤。
雖然在現(xiàn)實(shí)世界中，跟蹤可能會涉及與HTTP無關(guān)的組件，例如Kafka和消息隊(duì)列等，但是大多數(shù)系統(tǒng)仍然會以某種方式去依賴HTTP。而且，跨組件地跟蹤HTTP請求，是實(shí)現(xiàn)系統(tǒng)可觀察性的良好開端。
原文鏈接：https://dzone.com/articles/end-to-end-tracing-with-opentelemetry
網(wǎng)頁題目：如何使用OpenTelemetry進(jìn)行端對端跟蹤
當(dāng)前URL：http://www.5511xx.com/article/djojehj.html
