目錄

自定義指標

除了 Istio 自帶的指標外，我們還可以自定義指標，要自定指標需要用到 Istio 提供的 Telemetry API，該 API 能夠靈活地配置指標、訪問日志和追蹤數(shù)據(jù)。Telemetry API 現(xiàn)在已經(jīng)成為 Istio 中的主流 API。

需要注意的是，Telemetry API 無法與 EnvoyFilter 一起使用，請查看此問題 issue。

從 Istio 版本 1.18 版本開始，Prometheus 的 EnvoyFilter 默認不會被安裝， 而是通過 meshConfig.defaultProviders 來啟用它，我們應(yīng)該使用 Telemetry API 來進一步定制遙測流程，新的 Telemetry API 不但語義更加清晰，功能也一樣沒少。

對于 Istio 1.18 之前的版本，應(yīng)該使用以下的 IstioOperator 配置進行安裝：

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:values:telemetry:enabled: truev2:enabled: false

Telemetry 資源對象的定義如下所示：

$ kubectl explain Telemetry.spec
GROUP:      telemetry.istio.io
KIND:       Telemetry
VERSION:    v1alpha1FIELD: spec <Object>DESCRIPTION:Telemetry configuration for workloads. See more details at:https://istio.io/docs/reference/config/telemetry.htmlFIELDS:accessLogging <[]Object>Optional.metrics       <[]Object>Optional.selector      <Object>Optional.tracing       <[]Object>Optional.

可以看到 Telemetry 資源對象包含了 accessLogging、metrics、selector 和 tracing 四個字段，其中 accessLogging 和 tracing 字段用于配置訪問日志和追蹤數(shù)據(jù)，而 metrics 字段用于配置指標數(shù)據(jù)，selector 字段用于配置哪些工作負載需要采集指標數(shù)據(jù)。

我們這里先來看下 metrics 字段的配置，該字段的定義如下所示：

$ kubectl explain Telemetry.spec.metrics
GROUP:      telemetry.istio.io
KIND:       Telemetry
VERSION:    v1alpha1FIELD: metrics <[]Object>DESCRIPTION:Optional.FIELDS:overrides     <[]Object>Optional.providers     <[]Object>Optional.reportingInterval     <string>Optional.

可以看到 metrics 字段包含了 overrides、providers 和 reportingInterval 三個字段。

• overrides 字段用于配置指標數(shù)據(jù)的采集方式。
• providers 字段用于配置指標數(shù)據(jù)的提供者，這里一般配置為 prometheus。
• reportingInterval 字段用于配置指標數(shù)據(jù)的上報間隔，可選的。目前僅支持 TCP 度量，但將來可能會將其用于長時間的 HTTP 流。默認持續(xù)時間為 5 秒。

1.刪除標簽

🚩 實戰(zhàn)：自定義指標-刪除標簽-2023.12.4(測試成功)

實驗環(huán)境：

k8s v1.27.6（containerd://1.6.20）（cni：flannel:v0.22.2）
istio v1.19.3(--set profile=demo)

實驗軟件：

鏈接：https://pan.baidu.com/s/1pMnJxgL63oTlGFlhrfnXsA?pwd=7yqb
提取碼：7yqb
2023.11.5-實戰(zhàn)：BookInfo 示例應(yīng)用-2023.11.5(測試成功)

比如以前需要在 Istio 配置的 meshConfig 部分配置遙測，這種方式不是很方便。比如我們想從 Istio 指標中刪除一些標簽以減少基數(shù)，那么你的配置中可能有這樣一個部分：

# istiooperator.yaml
telemetry:enabled: truev2:enabled: trueprometheus:enabled: trueconfigOverride:outboundSidecar:debug: falsestat_prefix: istiometrics:- tags_to_remove:- destination_canonical_service...

現(xiàn)在我們可以通過 Telemetry API 來配置，如下所示：

#remove-tags.yaml
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:name: remove-tagsnamespace: istio-system
spec:metrics:- providers:- name: prometheus # 指定指標數(shù)據(jù)的提供者overrides:- match: # 提供覆蓋的范圍，可用于選擇個別指標，以及生成指標的工作負載模式（服務(wù)器和/或客戶端）。如果未指定，則overrides 將應(yīng)用于兩種操作模式（客戶端和服務(wù)器）的所有指標。metric: ALL_METRICS # Istio 標準指標之一mode: CLIENT_AND_SERVER # 控制選擇的指標生成模式：客戶端和/或服務(wù)端。tagOverrides: # 要覆蓋的標簽列表destination_canonical_service:operation: REMOVE# disabled: true  # 是否禁用指標

在上面的 Telemetry 資源對象中我們指定了一個 metrics 字段，表示用來自定義指標的，然后通過 providers.name 字段指定指標數(shù)據(jù)的提供者為 prometheus，然后最重要的是 overrides 字段，用于配置指標數(shù)據(jù)的采集方式。

其中 overrides.match.metric 字段用來指定要覆蓋的 Istio 標準指標，支持指標如下所示：

名稱	描述
ALL_METRICS	使用這個枚舉表示應(yīng)將覆蓋應(yīng)用于所有 Istio 默認指標。
REQUEST_COUNT	對應(yīng)用程序的請求計數(shù)器，適用于 HTTP、HTTP/2 和 GRPC 流量。Prometheus 提供商將此指標導(dǎo)出為：istio_requests_total。Stackdriver 提供商將此指標導(dǎo)出為：istio.io/service/server/request_count（服務(wù)器模式）istio.io/service/client/request_count（客戶端模式）
REQUEST_DURATION	請求持續(xù)時間的直方圖，適用于 HTTP、HTTP/2 和 GRPC 流量。Prometheus 提供商將此指標導(dǎo)出為：istio_request_duration_milliseconds。Stackdriver 提供商將此指標導(dǎo)出為：istio.io/service/server/response_latencies（服務(wù)器模式）istio.io/service/client/roundtrip_latencies（客戶端模式）
REQUEST_SIZE	請求體大小的直方圖，適用于 HTTP、HTTP/2 和 GRPC 流量。Prometheus 提供商將此指標導(dǎo)出為：istio_request_bytes。Stackdriver 提供商將此指標導(dǎo)出為：istio.io/service/server/request_bytes（服務(wù)器模式）istio.io/service/client/request_bytes（客戶端模式）
RESPONSE_SIZE	響應(yīng)體大小的直方圖，適用于 HTTP、HTTP/2 和 GRPC 流量。Prometheus 提供商將此指標導(dǎo)出為：istio_response_bytes。Stackdriver 提供商將此指標導(dǎo)出為：istio.io/service/server/response_bytes（服務(wù)器模式）istio.io/service/client/response_bytes（客戶端模式）
TCP_OPENED_CONNECTIONS	工作負載生命周期中打開的 TCP 連接計數(shù)器。Prometheus 提供商將此指標導(dǎo)出為：istio_tcp_connections_opened_total。Stackdriver 提供商將此指標導(dǎo)出為：istio.io/service/server/connection_open_count（服務(wù)器模式）istio.io/service/client/connection_open_count（客戶端模式）
TCP_CLOSED_CONNECTIONS	工作負載生命周期中關(guān)閉的 TCP 連接計數(shù)器。Prometheus 提供商將此指標導(dǎo)出為：istio_tcp_connections_closed_total。Stackdriver 提供商將此指標導(dǎo)出為：istio.io/service/server/connection_close_count（服務(wù)器模式）istio.io/service/client/connection_close_count（客戶端模式）
TCP_SENT_BYTES	TCP 連接期間發(fā)送的響應(yīng)字節(jié)計數(shù)器。Prometheus 提供商將此指標導(dǎo)出為：istio_tcp_sent_bytes_total。Stackdriver 提供商將此指標導(dǎo)出為：istio.io/service/server/sent_bytes_count（服務(wù)器模式）istio.io/service/client/sent_bytes_count（客戶端模式）
TCP_RECEIVED_BYTES	TCP 連接期間接收的請求字節(jié)計數(shù)器。Prometheus 提供商將此指標導(dǎo)出為：istio_tcp_received_bytes_total。Stackdriver 提供商將此指標導(dǎo)出為：istio.io/service/server/received_bytes_count（服務(wù)器模式）istio.io/service/client/received_bytes_count（客戶端模式）
GRPC_REQUEST_MESSAGES	每發(fā)送一個 gRPC 消息時遞增的客戶端計數(shù)器。Prometheus 提供商將此指標導(dǎo)出為：istio_request_messages_total
GRPC_RESPONSE_MESSAGES	每發(fā)送一個 gRPC 消息時遞增的服務(wù)器計數(shù)器。Prometheus 提供商將此指標導(dǎo)出為：istio_response_messages_total

比如我們這里配置的指標為 ALL_METRICS 則表示要覆蓋所有的 Istio 標準指標。

overrides.match.mode 則表示選擇網(wǎng)絡(luò)流量中底層負載的角色，如果負載是流量的目標（從負載的角度看，流量方向是入站），則將其視為作為 SERVER 運行。如果負載是網(wǎng)絡(luò)流量的源頭，則被視為處于 CLIENT 模式（流量從負載出站）。

名稱	描述
CLIENT_AND_SERVER	選擇適用于工作負載既是網(wǎng)絡(luò)流量的源頭，又是目標的場景。
CLIENT	選擇適用于工作負載是網(wǎng)絡(luò)流量的源頭的場景。
SERVER	選擇適用于工作負載是網(wǎng)絡(luò)流量的目標的場景。

另外的 tagOverrides 字段表示要覆蓋選定的指標中的標簽名稱和標簽表達式的集合，該字段中的 key 是標簽的名稱，value 是對標簽執(zhí)行的操作，可以添加、刪除標簽，或覆蓋其默認值。

字段	類型	描述	是否必需
operation	Operation	操作控制是否更新/添加一個標簽，或者移除它。	否
value	string	當操作為 UPSERT時才考慮值。值是基于屬性的 CEL 表達式。例如：string(destination.port)和 request.host。Istio 暴露所有標準的 Envoy 屬性。此外，Istio 也將節(jié)點元數(shù)據(jù)作為屬性暴露出來。更多信息請參見 自定義指標文檔。	否

對應(yīng)的操作 Operator 可以配置 UPSERT 和 REMOVE 兩個操作：

名稱	描述
UPSERT	使用提供的值表達式插入或更新標簽。如果使用 UPSERT操作，則必須指定 value字段。
REMOVE	指定標簽在生成時不應(yīng)包含在指標中。

• 現(xiàn)在我們直接應(yīng)用上面的這個資源對象，然后我們再去訪問下 productpage 應(yīng)用，再次驗證下指標數(shù)據(jù)中是否包含我們移除的 destination_canonical_service 標簽。

istioctl dashboard prometheus --address 0.0.0.0

看下當前指標：（是含有這個destination_canonical_service 標簽的）

部署資源，再次驗證：

[root@master1 istio]#kubectl apply -f remove-tags.yaml 
telemetry.telemetry.istio.io/remove-tags created
[root@master1 istio]#kubectl get telemetries.telemetry.istio.io -nistio-system
NAME          AGE
remove-tags   21s#重新去訪問一次
istioctl dashboard prometheus --address 0.0.0.0

從上面的結(jié)果可以看到，我們已經(jīng)成功刪除了 destination_canonical_service 標簽，這樣就可以減少指標數(shù)據(jù)的基數(shù)了，可以用同樣的方法再去刪除一些不需要的標簽。

另外需要注意在 Telemetry 對象中我們還可以通過 selector 字段來配置哪些工作負載應(yīng)用這個遙測策略，如果未設(shè)置，遙測策略將應(yīng)用于與遙測策略相同的命名空間中的所有工作負載，當然如果是在 istio-system 命名空間中則會應(yīng)用于所有命名空間中的工作負載。

測試結(jié)束。😘

2.添加指標

🚩 實戰(zhàn)：自定義指標-刪除標簽-2023.12.4

實驗環(huán)境：

k8s v1.27.6（containerd://1.6.20）（cni：flannel:v0.22.2）
istio v1.19.3(--set profile=demo)

實驗軟件：

鏈接：https://pan.baidu.com/s/1pMnJxgL63oTlGFlhrfnXsA?pwd=7yqb
提取碼：7yqb
2023.11.5-實戰(zhàn)：BookInfo 示例應(yīng)用-2023.11.5(測試成功)

• 上面我們已經(jīng)介紹了如何刪除指標中的標簽，那么我們也可以通過 Telemetry API 來添加指標中的標簽，如下所示：

#add-tags.yaml
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:name: add-tags
spec:metrics:- overrides:- match:metric: REQUEST_COUNTmode: CLIENTtagOverrides:destination_x:operation: UPSERTvalue: "upstream_peer.labels['app'].value" # 必須加上雙引號- match:metric: REQUEST_COUNTtagOverrides:destination_port:value: "string(destination.port)"request_host:value: "request.host"providers:- name: prometheus

在上面的這個資源對象中我們在 tagOverrides 中首先添加了如下的配置：

destination_x:operation: UPSERTvalue: "upstream_peer.labels['app'].value"

表示我們要添加一個名為 destination_x 的標簽，然后通過 value 字段指定標簽的值為 upstream_peer.labels['app'].value，這個值是一個 CEL 表達式（common expression）（必須在 JSON 中用雙引號引用字符串）。Istio 暴露了所有標準的 Envoy 屬性，對于出站請求，對等方元數(shù)據(jù)作為上游對等方(upstream_peer)的屬性可用；對于入站請求，對等方元數(shù)據(jù)作為下游對等方(downstream_peer)的屬性可用，包含以下字段：

屬性	類型	值
name	string	Pod 名
namespace	string	Pod 所在命名空間
labels	map	工作負載標簽
owner	string	工作負載 owner
workload_name	string	工作負載名稱
platform_metadata	map	平臺元數(shù)據(jù)
istio_version	string	代理的版本標識
mesh_id	string	網(wǎng)格唯一 ID
app_containers	list<string>	應(yīng)用容器的名稱列表
cluster_id	string	工作負載所屬的集群標識

例如，用于出站配置中的對等應(yīng)用標簽的表達式是 upstream_peer.labels['app'].value，所以上面我們最終添加的 destination_x 這個標簽的值為上游對等方的 app 標簽的值。

另外添加的兩個標簽 destination_port 和 request_host 的值分別為 string(destination.port) 和 request.host，這兩個值就來源于暴露的 Envoy 屬性。

另外這個資源對象我們指定的是 default 命名空間，則只會對 default 命名空間中的工作負載應(yīng)用這個遙測策略。

• 同樣應(yīng)用這個資源對象后，再次訪問 productpage 應(yīng)用產(chǎn)生指標，現(xiàn)在我們可以看到指標中已經(jīng)包含了我們添加的標簽了。

[root@master1 istio]#kubectl apply -f add-tags.yaml 
telemetry.telemetry.istio.io/add-tags created
[root@master1 istio]#kubectl get telemetries.telemetry.istio.io 
NAME       AGE
add-tags   20s#istioctl dashboard prometheus --address 0.0.0.0

測試結(jié)束。😘

• 奇怪：我這里沒有現(xiàn)象……（prometheus都已經(jīng)刪除重建過了的…… 先擱置吧。）

3.禁用指標

對于禁用指標則相對更簡單了。

比如我們通過以下配置禁用所有指標：

apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:name: remove-all-metricsnamespace: istio-system
spec:metrics:- providers:- name: prometheusoverrides:- disabled: truematch:mode: CLIENT_AND_SERVERmetric: ALL_METRICS

通過以下配置禁用 REQUEST_COUNT 指標：

apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:name: remove-request-countnamespace: istio-system
spec:metrics:- providers:- name: prometheusoverrides:- disabled: truematch:mode: CLIENT_AND_SERVERmetric: REQUEST_COUNT

通過以下配置禁用客戶端的 REQUEST_COUNT 指標：

apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:name: remove-clientnamespace: istio-system
spec:metrics:- providers:- name: prometheusoverrides:- disabled: truematch:mode: CLIENTmetric: REQUEST_COUNT

通過以下配置禁用服務(wù)端的 REQUEST_COUNT 指標：

apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:name: remove-servernamespace: istio-system
spec:metrics:- providers:- name: prometheusoverrides:- disabled: truematch:mode: SERVERmetric: REQUEST_COUNT

到這里我們就了解了如何通過 Telemetry API 來自定義指標了，這樣我們就可以根據(jù)自身的需求來定制了。

分布式追蹤

分布式追蹤可以讓用戶對跨多個分布式服務(wù)網(wǎng)格的請求進行追蹤分析，可以通過可視化的方式更加深入地了解請求的延遲，序列化和并行度。Istio 利用 Envoy 的分布式追蹤功能提供了開箱即用的追蹤集成，Istio 提供了安裝各種追蹤后端服務(wù)的選項，并且通過配置代理來自動發(fā)送追蹤 Span 到分布式追蹤系統(tǒng)服務(wù)，比如 Zipkin、Jaeger、Lightstep、Skywalking 等后端服務(wù)。

一次完整的鏈路是由多個 span 組成的，每個 span 代表了一次請求的一部分，每個 span 都有一個唯一的 ID，這個 ID 用來標識這個 span，同時還有一個父 span 的 ID，用來標識這個 span 的父 span，這樣就可以將多個 span 組成一個鏈路了。將不同的 span 關(guān)聯(lián)到一起的方式是通過將父 span 的 ID 傳遞給子 span，這樣就可以將多個 span 關(guān)聯(lián)起來了，也就是上下文傳遞。

上下文傳遞

盡管 Istio 代理能夠自動發(fā)送 Span，但需要一些附加信息才能將這些 Span 加到同一個調(diào)用鏈，所以當代理發(fā)送 Span 信息的時候，應(yīng)用程序需要附加適當?shù)?HTTP 請求頭信息，這樣才能夠把多個 Span 加到同一個調(diào)用鏈。

要做到這一點，每個應(yīng)用程序必須從每個傳入的請求中收集請求頭（Header），并將這些請求頭轉(zhuǎn)發(fā)到傳入請求所觸發(fā)的所有傳出請求。 具體選擇轉(zhuǎn)發(fā)哪些請求頭取決于所配置的跟蹤后端。

雖然 Istio 代理能夠自動發(fā)送 span 信息，但它們需要一些提示來將整個跟蹤關(guān)聯(lián)起來。應(yīng)用程序需要傳播適當?shù)?HTTP 頭，以便當代理發(fā)送 span 信息時，span 能夠正確地關(guān)聯(lián)到單個跟蹤中。為了實現(xiàn)這一點，應(yīng)用程序需要從傳入的請求中收集和傳播頭信息到所有的外發(fā)請求。要傳播的頭信息的選擇取決于所使用的跟蹤配置。

首先所有應(yīng)用程序必須轉(zhuǎn)發(fā)以下請求頭：

• x-request-id：這是 Envoy 專用的請求頭，用于對日志和追蹤進行一致的采樣。

對于 Zipkin、Jaeger、Stackdriver 和 OpenCensus Agent，應(yīng)轉(zhuǎn)發(fā) B3 請求頭格式：

• x-b3-traceid
• x-b3-spanid
• x-b3-parentspanid
• x-b3-sampled
• x-b3-flags

這些是 Zipkin、Jaeger、OpenCensus 和許多其他工具支持的請求頭。

B3 是一個跟蹤上下文傳播的格式，它起源于 Zipkin 項目，但后來被其他許多分布式跟蹤工具所采用。B3 的名字來源于 BigBrotherBird，它的主要目的是為了在服務(wù)之間傳播跟蹤上下文。它是由一組特定的 HTTP 頭部組成的，可以傳遞跟蹤信息，如 trace ID、span ID、采樣決策等。

對于 Datadog，應(yīng)轉(zhuǎn)發(fā)以下請求頭，對于許多語言和框架而言，這些轉(zhuǎn)發(fā)由 Datadog 客戶端庫自動處理。

• x-datadog-trace-id
• x-datadog-parent-id
• x-datadog-sampling-priority

對于 Lightstep，應(yīng)轉(zhuǎn)發(fā) OpenTracing span 上下文請求頭：

• x-ot-span-context

對于 Stackdriver 和 OpenCensus Agent，可以使用以下任一請求頭來替代 B3 多請求頭格式。

• grpc-trace-bin：標準的 gRPC 追蹤頭。
• traceparent：追蹤所用的 W3C 追蹤上下文標準，受所有 OpenCensus、OpenTelemetry 和 Jaeger 客戶端庫所支持。
• x-cloud-trace-context：由 Google Cloud 產(chǎn)品 API 使用。

W3C Trace Context 規(guī)范為追蹤上下文傳播數(shù)據(jù)的交換定義了一種普遍認同的格式 - 稱為追蹤上下文。Trace Context 是一個在分布式追蹤中用于跨服務(wù)和跨進程傳遞 trace 數(shù)據(jù)的標準。它定義了如何在 HTTP headers 中編碼 trace 數(shù)據(jù)，以便在不同的服務(wù)間傳遞這些數(shù)據(jù)。具體來說，Trace Context 包含兩個部分：traceparent 和 tracestate。

• traceparent 以便攜、固定長度的格式描述了傳入請求在其追蹤鏈路中的位置。它的設(shè)計重點是快速解析，每個跟蹤工具都必須正確設(shè)置 traceparent，即使它僅依賴于 tracestate 中的供應(yīng)商特定信息。
• tracestate 通過一組 name/value 鍵值對表示來擴展帶有供應(yīng)商特定數(shù)據(jù)的 traceparent。將信息存儲在 tracestate 中是可選的。

使用 W3C 跟蹤上下文上下文傳播接收 HTTP 請求可能如下所示：

GET /my-service HTTP/1.1
Host: myhost.com
traceparent: 00–0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331–01
tracestate: abc=00f067aa0ba902b7,xyz=99f067aa0ba902b7

traceparent 字段

Traceparent HTTP Header 字段標識跟蹤系統(tǒng)中的傳入請求，這是一個必要的部分，它由 4 個部分組成，所有字段都使用 16 進制編碼：

• version：系統(tǒng)適配的追蹤上下文版本，當前版本是 00。
• trace-id：一個全局唯一的 ID，用于標識整個 trace，它是一個 32 個字符的十六進制字符串。
• parent-id：一個服務(wù)內(nèi)唯一的 ID，用于標識調(diào)用鏈中的當前操作（通常是一個函數(shù)或者請求處理器）。它是一個 16 個字符的十六進制字符串。
• trace-flags：用于控制 trace 的行為，例如是否需要被采樣等。

比如我們有一個前端應(yīng)用中的一個接口中添加了 Trace Context，它的 traceparent 就是這樣的：

比如我們這里一次 HTTP 請求中通過 Header 傳遞的 Traceparent 值為 00-a237a2ca46023ce3e1d214ad2866c9c0-d00a29e113663fed-01，對應(yīng)到 Jaeger UI 中 trace id 為 a237a2ca46023ce3e1d214ad2866c9c0，parent id（也就是父級的 span id）為 d00a29e113663fed，trace flags 為 01。

tracestate 字段

tracestate 這是一個可選的部分，用于跨多個服務(wù)傳遞額外的 trace 信息。它是一個鍵值對列表，列表中的每一項都由一個服務(wù)添加。服務(wù)可以在 tracestate 中添加一些自定義的數(shù)據(jù)，例如服務(wù)的版本、部署環(huán)境等。

Jaeger

接下來我們來看下如何在 Istio 中集成 Jaeger，Jaeger 是一個開源的分布式追蹤系統(tǒng)，它由 Uber 開源，用于監(jiān)視和故障排除復(fù)雜的分布式系統(tǒng)。同樣我們這里還是以 Bookinfo 為例進行說明。

• 首先要安裝 Jaeger，我們這里只是演示，可以直接使用下面的方式進行安裝：

$ kubectl apply -f samples/addons/jaeger.yaml
$ kubectl get pods -n istio-system -l app=jaeger
NAME                     READY   STATUS    RESTARTS         AGE
jaeger-db6bdfcb4-qpmmv   1/1     Running   20 (5h40m ago)   29d
$ kubectl get svc -n istio-system
NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)                                                                      AGE
jaeger-collector       ClusterIP      10.107.60.208    <none>        14268/TCP,14250/TCP,9411/TCP,4317/TCP,4318/TCP                               29d
tracing                ClusterIP      10.98.235.44     <none>        80/TCP,16685/TCP                                                             29d
zipkin                 ClusterIP      10.98.118.194    <none>        9411/TCP                                                                     29d
# ......

如果是要在生產(chǎn)環(huán)境中使用 Jaeger，則需要參考官方文檔進行部署。

• 安裝 Jaeger 完畢后，需要指定 Istio Envoy Proxy 代理向 Deployment 發(fā)送流量，可以使用 --set meshConfig.defaultConfig.tracing.zipkin.address=jaeger-collector:9411 進行配置，此外默認的采樣率為 1%，可以通過 --set meshConfig.defaultConfig.tracing.sampling=100 來修改采樣率。

istioctl install --set profile=demo --set meshConfig.defaultConfig.tracing.zipkin.address=jaeger-collector:9411 --set meshConfig.defaultConfig.tracing.sampling=100 -y

• 現(xiàn)在我們就可以通過下面的命令來查看 Jaeger UI 了：

istioctl dashboard jaeger --address 0.0.0.0[root@master1 ~]#kubectl get istiooperators.install.istio.io -nistio-system
NAME              REVISION   STATUS   AGE
installed-state                       26d[root@master1 ~]#kubectl get istiooperators.install.istio.io -nistio-system -oyaml
……meshConfig:accessLogFile: /dev/stdoutdefaultConfig:proxyMetadata: {}tracing:sampling: 100zipkin:address: jaeger-collector:9411

http://172.29.9.61:16686/

• 接下來我們只需要訪問下 Bookinfo 應(yīng)用，然后在 Jaeger UI 中就可以看到追蹤數(shù)據(jù)了。要查看追蹤數(shù)據(jù)，必須向服務(wù)發(fā)送請求。請求的數(shù)量取決于 Istio 的采樣率，采樣率在安裝 Istio 時設(shè)置，默認采樣速率為 1%。在第一個跟蹤可見之前，我們需要發(fā)送至少 100 個請求。使用以下命令向 productpage 服務(wù)發(fā)送 100 個請求：

for i in $(seq 1 100); do curl -s -o /dev/null "http://$GATEWAY_URL/productpage"; donefor i in $(seq 1 100); do curl -s -o /dev/null "http://172.29.9.61:31666/productpage"; done

• 從儀表盤左邊面板的 Service 下拉列表中選擇 productpage.default 并點擊 Find Traces：

奇怪哇：我這里只有2個服務(wù)哦。。。

• 然后我們可以點擊訪問 /productpage 的鏈路詳細信息：

追蹤信息由一組 Span 組成，每個 Span 對應(yīng)一個 Bookinfo Service。這些 Service 在執(zhí)行 /productpage 請求時被調(diào)用，或是 Istio 內(nèi)部組件，例如：istio-ingressgateway。

• 在系統(tǒng)架構(gòu)頁面也可以看到對應(yīng)的 DAG 圖：

關(guān)于我

我的博客主旨：

• 排版美觀，語言精煉；
• 文檔即手冊，步驟明細，拒絕埋坑，提供源碼；
• 本人實戰(zhàn)文檔都是親測成功的，各位小伙伴在實際操作過程中如有什么疑問，可隨時聯(lián)系本人幫您解決問題，讓我們一起進步！

🍀 微信二維碼
x2675263825 （舍得）， qq：2675263825。

🍀 微信公眾號
《云原生架構(gòu)師實戰(zhàn)》

🍀 個人博客站點

http://onedayxyy.cn/

🍀 語雀

https://www.yuque.com/xyy-onlyone

🍀 csdn

https://blog.csdn.net/weixin_39246554?spm=1010.2135.3001.5421

🍀 知乎

https://www.zhihu.com/people/foryouone

最后

好了，關(guān)于本次就到這里了，感謝大家閱讀，最后祝大家生活快樂，每天都過的有意義哦，我們下期見！

690384132)]

🍀 微信公眾號
《云原生架構(gòu)師實戰(zhàn)》

[外鏈圖片轉(zhuǎn)存中…(img-6x2RM7AH-1701690384133)]

🍀 個人博客站點

http://onedayxyy.cn/

[外鏈圖片轉(zhuǎn)存中…(img-oZnYMCzV-1701690384133)]

[外鏈圖片轉(zhuǎn)存中…(img-SrUrEOAh-1701690384134)]

🍀 語雀

https://www.yuque.com/xyy-onlyone

[外鏈圖片轉(zhuǎn)存中…(img-tkH0lDiV-1701690384134)]

🍀 csdn

https://blog.csdn.net/weixin_39246554?spm=1010.2135.3001.5421

[外鏈圖片轉(zhuǎn)存中…(img-VSRnaRiY-1701690384134)]

🍀 知乎

https://www.zhihu.com/people/foryouone

[外鏈圖片轉(zhuǎn)存中…(img-z6nY6FJF-1701690384135)]

最后

好了，關(guān)于本次就到這里了，感謝大家閱讀，最后祝大家生活快樂，每天都過的有意義哦，我們下期見！

[外鏈圖片轉(zhuǎn)存中…(img-3dUX2kKM-1701690384136)]