通過Trace ID和Span ID已經實現了對分布式系統中的請求跟蹤，而這些記錄的跟蹤信息最終會被分析系統收集起來，并用來實現對分布式系統的監控和分析功能，比如：預警延遲過長的請求鏈路、查詢請求鏈路的調用明細等。此時，我們在對接分析系統時就會碰到一個問題：分析系統在收集跟蹤信息的時候，需要收集多少量的跟蹤信息才合適呢？

[[226406]]

理論上來說，我們收集的跟蹤信息越多就可以更好的反映出系統的實際運行情況，并給出更精準的預警和分析，但是在高并發的分布式系統運行時，大量的請求調用會產生海量的跟蹤日志信息，如果我們收集過多的跟蹤信息將會對我們整個分布式系統的性能造成一定的影響，同時保存大量的日志信息也需要不少的存儲開銷。所以，在Sleuth中采用了抽象收集的方式來為跟蹤信息打上收集標記，也就是我們之前在日志信息中看到的第四個boolean類型的值，它代表了該信息是否要被后續的跟蹤信息收集器獲取和存儲。

在Sleuth中的抽樣收集策略是通過Sampler接口實現的，它的定義如下：

public interface Sampler { 
    /** 
     * @return true if the span is not null and should be exported to the tracing system 
    */ 
    boolean isSampled(Span span); 
} 

通過實現isSampled方法，Spring Cloud Sleuth會在產生跟蹤信息的時候調用它來為跟蹤信息生成是否要被收集的標志。需要注意的是，即使isSampled返回了false，它僅代表該跟蹤信息不被輸出到后續對接的遠程分析系統（比如：Zipkin），對于請求的跟蹤活動依然會進行，所以我們在日志中還是能看到收集標識為false的記錄。

默認情況下，Sleuth會使用PercentageBasedSampler實現的抽樣策略，以請求百分比的方式配置和收集跟蹤信息，我們可以通過在application.properties中配置下面的參數對其百分比值進行設置，它的默認值為0.1，代表收集10%的請求跟蹤信息。

spring.sleuth.sampler.percentage=0.1 

在開發調試期間，通常會收集全部跟蹤信息輸出到遠程倉庫，我們可以將其值設置為1，或者也可以通過創建AlwaysSampler的Bean（它實現的isSampled方法始終返回true）來覆蓋默認的PercentageBasedSampler策略，比如：

@Bean 
public AlwaysSampler defaultSampler() { 
    return new AlwaysSampler(); 
} 

在實際使用時，通過與Span對象中存儲信息的配合，我們可以根據實際情況做出更貼近需求的抽樣策略，比如實現一個僅對包含指定Tag的抽樣策略：

public class TagSampler implements Sampler { 
 
    private String tag; 
 
    public TagSampler(String tag) { 
        this.tag = tag; 
    } 
 
    @Override 
    public boolean isSampled(Span span) { 
        return span.tags().get(tag) != null; 
    } 
} 

由于跟蹤日志信息的數據價值往往僅在最近的一段時間內非常有用，比如：一周。那么我們在設計抽樣策略時，主要考慮在不對系統造成明顯性能影響的情況下，以在日志保留時間窗內充分利用存儲空間的原則來實現抽樣策略。

完整示例：

讀者可以根據喜好選擇下面的兩個倉庫中查看trace-1和trace-2兩個項目：

Github：https://github.com/dyc87112/SpringCloud-Learning/

Gitee：https://gitee.com/didispace/SpringCloud-Learning/

【本文為51CTO專欄作者“翟永超”的原創稿件，轉載請通過51CTO聯系作者獲取授權】

戳這里，看該作者更多好文