分布式鏈路追蹤工具pinpoint采樣率原理分析

一系列的服務上云后，可能分布在幾千甚至幾萬臺服務器上，服務與服務之間存在大量復雜的調用關系，而pinpoint在采集這些服務數(shù)據(jù)時，同樣會產生大量的報文。

在naver公司的在線門戶服務有海量請求。單個服務每天處理超過200億請求。如果要跟蹤所有的請求，解決的辦法是需要添加足夠多的網絡設施和服務器來來支撐收集數(shù)據(jù)。

但是對于這種非核心生產的監(jiān)控系統(tǒng)來說，是很不劃算的，浪費金錢又浪費資源。

在Pinpoint中，可以收集設置采樣，而不必跟蹤每個請求。在開發(fā)環(huán)境中請求量很小，每個數(shù)據(jù)都收集。而在產品環(huán)境請求量巨大，收集小比率的數(shù)據(jù)如1~5%，足夠檢查整個應用的狀態(tài)。采樣之后，可以最小化應用的網絡開銷并降低諸如網絡和服務器的設施費用。

對應的配置項在agent下的pinpoint.config文件中。

首先采樣率有開關配置。默認"profiler.sampling.rate=1"表示全部

Pinpoint 支持計數(shù)采樣，如果設置為10則只采樣10分之一的請求。我們計劃增加新的采樣器來更有效率的收集數(shù)據(jù)。

很多小伙伴，看到采樣率配置，以為是配置的百分比，上來就配一個0點幾，其實不是的，這里我們簡單來理解一下，我們只需要關注分母即可，比如要配10%的采樣，那么設置這個屬性的值為10即可。

pinpoint內部的是否采樣和采樣率，是通過Sampler對象來封裝的。

可以看到是通過com.google.inject.Inject注解來進行依賴注入的。

內部使用的是Google Guice ，它一個輕量級的依賴注入框架。和spring不同的是：Spring 耦合度低，而Guice 耦合度高，代碼級的標注，DI 標記 @inject 侵入代碼中，耦合到了類層面上來。

Guice 使用注解 Annotation，cglib, 效率高，這是與與 Spring 最明顯的一個區(qū)別，Spring 是在裝載配置文件的時候把該注入的地方都注入完，而 Guice 呢，則是在使用的時候去注射，運行效率和靈活性高。

某條請求是否被采樣，取決于整個鏈路開始的機器。該機器使用特定的采樣算法。采樣的標志會一直在鏈路中透傳。比如在http里面，會在header里面增加Pinpoint-Sampled字段，使用不同的值表示是否采樣。

上圖顯示pinpoint具體會使用到的一些Header。

具體的判斷邏輯，是通過SamplingFlagUtils類來實現(xiàn)的。

其實，代碼層面很簡單，就是判斷，如果不采樣，那就不發(fā)送大量的報文就行。

但是！

你總得告訴下游吧，不然怎么串聯(lián)起來呢，當然每個agent可以單獨有自己的采樣配置， 最好還是保持一致。

以httpclient4的插件為例。

從當前上下文里面獲取Trace對象，并判斷是否采樣，其Trace體系如下圖所示：

在請求發(fā)送到下游的機器之前，會從當前上下文里面獲取Trace對象。

如果不采樣，則嘗試在http頭部寫入Pinpoint-Sampled=s0, 其他信息都不傳遞。

如果為需要采樣，則不設置Pinpoint-Sampled字段，只設置其他trace相關字段，比如Header.HTTP_TRACE_ID等。

在服務端收到請求之后，會去查看請求里面是否有Pinpoint-Sampled字段和Pinpoint-TraceID等字段。分為下面幾種情況：

有Pinpoint-Sampled字段，并且值為s0，表示此條請求不采樣。

沒有Pinpoint-Sampled字段，但是有Pinpoint-TraceID等字段，表示此條請求被采樣。

沒有Pinpoint-Sampled字段，也沒有Pinpoint-TraceID等字段，認為接收該請求的機器，是整條鏈路的第一個機器，或者鏈路信息在前面有丟失。

在系統(tǒng)完成一次業(yè)務調用的過程中，會產生很多的調用鏈打點數(shù)據(jù)，在業(yè)務量大的時候，這些數(shù)據(jù)可能同樣會成為我們系統(tǒng)的負擔，所以對數(shù)據(jù)采樣很有必要，在保證樣本充足的情況下，同樣能夠進行數(shù)據(jù)分析和定位系統(tǒng)性能瓶頸，快速定位異常的服務。本篇文章我們介紹了如下內容：

pinpoint采樣率的概念和應用。

pinpoint采樣率的配置。

pinpoint使用的依賴注入框架Google Guice和spring的對比。

pinpoint的采樣原理。

可視化界面在線生成JVM參數(shù)

java內存溢出問題分析過程二(附MAT超全作文檔)

使用Eclipse Memory Analyzer Tool（MAT）分析線上故障(一)

一文讓你理解什么是shallow heap及retained heap

內存分析診斷系列-理解heap?dump

記一次服務器被當肉雞挖礦的經歷

如何編寫一個可復用的SpringBoot應用運維腳本

高效率編寫Dockerfile需要繞過的一些坑

Mysql百萬量級數(shù)據(jù)高效導入Redis

多線程之CountDownLatch的用法及原理筆記

我就知道你“在看”