最近新發(fā)現(xiàn)了一個開源項目叫pyroscope:一個開源持續(xù)Profiling平臺。
之所以關(guān)注到這個開源項目跟我以前的一個想法有一些契合，所以就先照著官方文檔，寫了個樣例試用
package main
import (
"github.com/gin-gonic/gin"
"github.com/pyroscope-io/pyroscope/pkg/agent/profiler"
)
func main() {
profiler.Start(profiler.Config{
ApplicationName: "backend.purchases",
ServerAddress: "http://localhost:4040",
})
r := gin.Default()
r.GET("/ping", func(c *gin.Context) {
c.JSON(200, gin.H{
"message": "pong",
})
})
r.Run()
}
先把服務(wù)跑起來再說，結(jié)果卻發(fā)現(xiàn)Agent上送Profiler經(jīng)常會有EOF錯誤，這讓我覺得有點尷尬，看到Issues上有人提了這個問題，在好奇心驅(qū)使下，準(zhǔn)備看看怎么回事
抓包分析
用wireshark抓包看了一下
發(fā)現(xiàn)竟然是服務(wù)端在先關(guān)閉連接，此時我還未看代碼，直接上此類服務(wù)應(yīng)該用長連接才對，翻看服務(wù)端代碼也是常規(guī)寫法
s := &http.Server{
Addr: ctrl.cfg.Server.ApiBindAddr,
Handler: mux,
ReadTimeout: 10 * time.Second,
WriteTimeout: 10 * time.Second,
MaxHeaderBytes: 1 << 20,
ErrorLog: golog.New(w, "", 0),
}
Agent端了也是默認(rèn)長連接的
&http.Client{
Transport: &http.Transport{
MaxConnsPerHost: cfg.UpstreamThreads,
},
Timeout: cfg.UpstreamRequestTimeout,
}
所以其實兩端都是支持長連接的，但連接確實是首先由服務(wù)端關(guān)閉的，這不合理啊，回頭再來看抓包信息，Agent發(fā)送了[FIN, ACK]以后，還發(fā)了一次POST請求，正常情況Server端應(yīng)該回一個ACK，不過由于經(jīng)過了[FIN]->[FIN, ACK]此時服務(wù)端已經(jīng)處于FIN_WAIT_1狀態(tài)了，正等對端回ACK和FIN，不過比較巧的是剛好Agent端此時發(fā)關(guān)了一個POST請求，此時服務(wù)端只能收數(shù)據(jù)，不能發(fā)送數(shù)據(jù)，所以服務(wù)端發(fā)回了一個RST
原因是什么？
現(xiàn)象分析完了，那為什么會出現(xiàn)這種情況呢？網(wǎng)上看到一些此類問題解決辦法是客戶端處理POST請求直接Close關(guān)掉連接，這個就沒法復(fù)用連接了，而且場景不同，根本不應(yīng)該這么暴力操作，還是要具體問題具體分析的。關(guān)注一個小細(xì)節(jié)，在Agent發(fā)起[SYN]建立連接到Server發(fā)起[FIN]關(guān)注連接時間間隔正好是10s，這個時間與Server的讀寫超時時間相同，而Agent的上送Profiler的默認(rèn)時間間隔也是10s，這之間會不會有什么關(guān)系？因為理想情況至少客戶端是應(yīng)該復(fù)用這個連接的，直覺上應(yīng)該是Agent端關(guān)閉連接才對的。果不其然，在server.go中找到了線索：
// IdleTimeout is the maximum amount of time to wait for the
// next request when keep-alives are enabled. If IdleTimeout
// is zero, the value of ReadTimeout is used. If both are
// zero, there is no timeout.
IdleTimeout time.Duration
服務(wù)端本意是想復(fù)用連接的，但是并沒有設(shè)置IdleTimeout，但是有設(shè)置ReadTimeout為10s秒，這正好是Agent端上送Profiler的間隔時間，所以很快就破案了，真是好巧不巧的，這個時間點卡的可真準(zhǔn)，其實一般情況服務(wù)端這么設(shè)置也沒問題，因為長連接通常適用于并發(fā)調(diào)用，以Agent端的調(diào)用頻率并不高，而且也沒有并發(fā)，所以將服務(wù)端IdleTimeout設(shè)置為魔數(shù)30s，就沒有再出現(xiàn)EOF的錯誤，然后我提了PR，很快就合入了主干。
總結(jié)
一開始上網(wǎng)搜解決方案，發(fā)現(xiàn)完全不是那么回事，果然是人云亦云，每個人給出的上下文不一樣，解決方案自然有差別。其實用wireshark抓一下包就能找到線索，大膽猜測，小心求證，數(shù)據(jù)總不會騙人的，源碼也靜待剖析。
參考：
