領先一步
VMware 提供培訓和認證，以加速您的進展。
了解更多Spring Cloud Sleuth 3.1.0 版本已發布！
隨著 Spring Cloud 2021.0.0 (又名 Jubilee) 的發布，我們非常高興地宣布 Spring Cloud Sleuth 3.1.0 正式推出。在這篇部落格文章中，我們將介紹最值得注意的已發布功能。
以下是最值得注意的功能列表，我們將在本篇文章的後續部分中詳細說明。
- JDBC #1930
- Tomcat Valve #1329
- Spring Vault #1952
- 自動產生標籤表以供文件使用 #1950
- Spring Cloud Deployer #1947
- R2DBC #1524
- Kafka #2013 和 Reactor Kafka #1708
- Spring TX #1941
- Spring Batch #1904
- RSocket #1677
- Spring Cloud Task #1903
- Spring Cloud Config #1915
- Spring Cloud CircuitBreaker Reactive #1910
- Cassandra #1974
- Spring Session #1961
- Spring Security #2011
- Prometheus Exemplars #2039
- Spring Cloud Stream Reactive #2038
- Reactive Mongo #2044
- 抽象化的 Redis Instrumentation #2046
- 用於儲存追蹤的自訂 Actuator #1879
JDBC
我們正在以追蹤表示法裝飾 DataSource。我們委派實際的代理到 p6spy 或 datasource-proxy。為了使用此功能，您需要在類別路徑上擁有它們。
查看 文件 以取得更多詳細資訊。
這裡 您可以找到一個範例，描述了此整合。
Tomcat Valve
此變更背後的主要驅動力是，直到 Sleuth 3.1 為止，您的 Tomcat 記錄檔都不會有任何追蹤資訊。透過此變更，我們正在檢測 Tomcat，因此我們在請求的生命週期中更早，並且可以使用追蹤資訊檢測所有可能的記錄檔。
查看 文件 以取得更多詳細資訊。
這裡 您可以找到一個範例，描述了此整合。
Spring Vault
我們正在檢測 Spring Vault 使用的 RestTemplate 或 WebClient 實例，以與 Vault 進行通訊。
查看 文件 以取得更多詳細資訊。
這裡 您可以找到一個範例，描述了 RestTemplate 的此整合。
這裡 您可以找到一個範例，描述了 WebClient 的此整合。
自動產生標籤表以供文件使用
在追蹤世界中，沒有什麼比建立一個 span 卻沒有啟動它或沒有停止它更令人沮喪的了。我們已經受夠了這種情況......我們面臨的另一個挑戰是，我們甚至不再記得我們建立了多少個 span、它們的名稱是什麼以及在它們上面設定了多少個標籤/事件。
我們決定改變在 Sleuth 中編寫程式的方式，以便我們可以引入某些自動化。我們檢測程式碼一次，但是我們能夠在測試時開啟其他斷言，以驗證 span 是否已啟動和停止等。此外，在文件建置時，我們會解析來源並建置一個 span 表格以及一些詳細資訊。
您可以查看 文件 以查看該自動化的結果。
Spring Cloud Deployer
如果您在類別路徑上有執行 Spring Cloud Deployer，我們會以追蹤表示法包裝 AppDeployer。我們正在以預設間隔輪詢應用程式的狀態。
查看 文件 以取得更多詳細資訊。
這裡 您可以找到一個範例，描述了此整合。
R2DBC
如果您在類別路徑上有 R2DBC Proxy，我們將檢測 ConnectionFactory，使其包含自訂的 ProxyExecutionListener。
查看 文件 以取得更多詳細資訊。
這裡 您可以找到一個範例，描述了此整合。
Kafka 和 Reactor Kafka
我們裝飾 Kafka 用戶端 (KafkaProducer 和 KafkaConsumer) 以為每個生產或消費的事件建立一個 span。我們還提供 TracingKafkaProducerFactory 和 TracingKafkaConsumerFactory 以與 Reactor Kafka 用戶端 (分別為 KafkaSender 和 KafkaReceiver) 搭配使用。此外，我們還裝飾上下文中可用的任何 Spring Kafka ProducerFactory 和 ConsumerFactory。
查看 文件 以取得更多詳細資訊。
這裡 您可以找到一個範例，描述了 Kafka 生產者的此整合。
這裡您可以找到一個範例，說明 Kafka consumer 的整合。
這裡您可以找到一個範例，說明 Kafka Reactive producer 的整合。
這裡您可以找到一個範例，說明 Kafka Reactive consumer 的整合。
Spring TX
如果您的類別路徑上有 Spring Tx，我們會檢測 `PlatformTransactionManager` 和 `ReactiveTransactionManager`，以便在建立新的交易時建立一個 span。
請查看文件以取得更多詳細資訊。
這裡 您可以找到一個範例，描述了此整合。
Spring Batch
如果您的類別路徑上有 Spring Batch 正在執行，我們會包裝 `StepBuilderFactory` 和 `JobBuilderFactory` 以傳播追蹤上下文。
請查看文件以取得更多詳細資訊。
這裡您可以找到一個範例，說明此整合。
RSocket
如果您的類別路徑上有 Spring RSocket 正在執行，我們會包裝 inbound 和 outbound 通訊，以透過 metadata 傳播追蹤上下文
請查看文件以取得更多詳細資訊。
這裡您可以找到一個範例，說明 RSocket 伺服器的整合。
這裡您可以找到一個範例，說明 RSocket 客戶端的整合。
Spring Cloud Task
如果您的類別路徑上有 Spring Cloud Task 正在執行，我們會檢測 `TaskExecutionListener` 和 `CommandLineRunner` 和 `ApplicationRunner`。
這裡您可以找到一個範例，說明此整合。
Spring Cloud Config
如果您的類別路徑上有 Spring Cloud Config Server 正在執行，我們會將 `EnvironmentRepository` 包裝在一個 span 中。
請查看文件以取得更多詳細資訊。
這裡您可以找到一個範例，說明此整合。
Spring Cloud CircuitBreaker Reactive
如果您的類別路徑上有 Spring Cloud CircuitBreaker，我們會將傳遞的 command `Supplier` 和 fallback `Function` 包裝在其追蹤表示法中。
請查看文件以取得更多詳細資訊。
這裡您可以找到一個範例，說明此整合。
Cassandra
如果您的類別路徑上有 Spring Data Cassandra，我們將檢測 Casandra 的 `CqlSession` 和 `ReactiveSession` 介面，並且我們正在提供我們自己的 `RequestTracker` 實作。
請查看文件以取得更多詳細資訊。
這裡您可以找到一個範例，說明非 reactive Cassandra 的整合。
這裡您可以找到一個範例，說明 reactive Cassandra 的整合。
Spring Session
如果您的類別路徑上有 Spring Session，我們會檢測 `Session` 儲存庫，該儲存庫會將所有操作包裝在一個 span 中。
請查看文件以取得更多詳細資訊。
這裡您可以找到一個範例，說明此整合。
Spring Security
如果您的類別路徑上有 Spring Security，我們會建立一個 `SecurityContextChangedListener` 的實作，當上下文變更時，該實作會使用事件標註目前的 span。
這裡您可以找到一個範例，說明此整合。
Prometheus Exemplars
Exemplars 是附加到指標的 metadata (請參閱：Prometheus Exemplars)，例如：traceId，以便您可以取得指標的範例 traceId。
我們正在將 Sleuth 與 Prometheus 整合，以便如果有人使用 Prometheus Java Client，他們可以使用 Sleuth 取得 Exemplars。此問題也與 Micrometer Exemplars 支援相關，請參閱。
這裡您可以閱讀更多有關此問題的資訊。
關於此功能，有幾點注意事項
- Micrometer 目前不支援 exemplars，我們計劃在下一個版本中執行 (在此期間您可以使用 Prometheus client)
- 這是 Prometheus 中的一項實驗性功能，您需要使用功能旗標明確啟用它 (請參閱：範例)
- 同樣地，您需要在 Grafana 資料來源中設定它，並定義追蹤後端的 URL 模式 (請參閱：Zipkin 範例)
- 您還需要確保在您要使用 exemplars 的儀表板面板上啟用 exemplar 旗標 (請參閱：範例儀表板)
- 您的追蹤後端 (例如：Zipkin) 不需要任何設定，您只需要知道後端用來引用 traceId 的 URL 模式 (請參閱上面的 URL 模式)
Spring Cloud Stream Reactive
Spring Cloud Sleuth 可以檢測 Spring Cloud Function。由於 Spring Cloud Stream 使用 Spring Cloud Function，因此您可以直接使用訊息傳遞檢測。
實現此目的的方法是提供一個以 `Message` 作為參數的 `Function` 或 `Consumer` 或 `Supplier`，例如 `Function<Message<String>, Message<Integer>>`。
如果類型不是 `Message`，則不會進行檢測。
對於 reactive `Consumer<Flux<Message<?>>>`，請記得在呼叫 `.subscribe()` 之前手動關閉 span 並清除上下文。
這裡您可以找到一個範例，說明 producer 的整合。
這裡您可以找到一個範例，說明 consumer 的整合。
Reactive Mongo (反應式 Mongo)
我們正在新增命令監聽器，將所有命令包裝在一個 span 中。 這適用於反應式和非反應式的情況。
這裡 您可以找到一個範例，描述了這個整合。
抽象化的 Redis 檢測
透過這個 PR，Redis 檢測可以適用於其他的追蹤器 (Tracers)，例如 OpenTelemetry。
用於儲存追蹤的自定義 Actuator
Spring Cloud Sleuth 提供了一個 traces Actuator 端點，可以儲存完成的 spans。 該端點可以透過 HTTP Get 方法查詢以簡單地檢索儲存的 spans 列表，或者透過 HTTP Post 方法檢索列表並清除它。
查看 文件 了解更多詳情。
保持聯繫！
這個版本引入了大量的檢測。 我們很樂意看到您的追蹤！ 您可以前往我們的 Gitter 並貼上您的追蹤螢幕截圖，以便我們分析如何改進它。
如有任何問題，請隨時 ping 我們
- 在 Github 上
- 在 Gitter 上
- 在 Stackoverflow 上