最近新發(fā)現(xiàn)了一個(gè)開源項(xiàng)目叫pyroscope:一個(gè)開源持續(xù)Profiling平臺(tái)。
之所以關(guān)注到這個(gè)開源項(xiàng)目跟我以前的一個(gè)想法有一些契合，所以就先照著官方文檔，寫了個(gè)樣例試用
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ù)跑起來(lái)再說(shuō)，結(jié)果卻發(fā)現(xiàn)Agent上送Profiler經(jīng)常會(huì)有EOF錯(cuò)誤，這讓我覺得有點(diǎn)尷尬，看到Issues上有人提了這個(gè)問題，在好奇心驅(qū)使下，準(zhǔn)備看看怎么回事
抓包分析
用wireshark抓包看了一下
發(fā)現(xiàn)竟然是服務(wù)端在先關(guān)閉連接，此時(shí)我還未看代碼，直接上此類服務(wù)應(yīng)該用長(zhǎng)連接才對(duì)，翻看服務(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)長(zhǎng)連接的
&http.Client{
Transport: &http.Transport{
MaxConnsPerHost: cfg.UpstreamThreads,
},
Timeout: cfg.UpstreamRequestTimeout,
}
所以其實(shí)兩端都是支持長(zhǎng)連接的，但連接確實(shí)是首先由服務(wù)端關(guān)閉的，這不合理啊，回頭再來(lái)看抓包信息，Agent發(fā)送了[FIN, ACK]以后，還發(fā)了一次POST請(qǐng)求，正常情況Server端應(yīng)該回一個(gè)ACK，不過(guò)由于經(jīng)過(guò)了[FIN]->[FIN, ACK]此時(shí)服務(wù)端已經(jīng)處于FIN_WAIT_1狀態(tài)了，正等對(duì)端回ACK和FIN，不過(guò)比較巧的是剛好Agent端此時(shí)發(fā)關(guān)了一個(gè)POST請(qǐng)求，此時(shí)服務(wù)端只能收數(shù)據(jù)，不能發(fā)送數(shù)據(jù)，所以服務(wù)端發(fā)回了一個(gè)RST
原因是什么？
現(xiàn)象分析完了，那為什么會(huì)出現(xiàn)這種情況呢？網(wǎng)上看到一些此類問題解決辦法是客戶端處理POST請(qǐng)求直接Close關(guān)掉連接，這個(gè)就沒法復(fù)用連接了，而且場(chǎng)景不同，根本不應(yīng)該這么暴力操作，還是要具體問題具體分析的。關(guān)注一個(gè)小細(xì)節(jié)，在Agent發(fā)起[SYN]建立連接到Server發(fā)起[FIN]關(guān)注連接時(shí)間間隔正好是10s，這個(gè)時(shí)間與Server的讀寫超時(shí)時(shí)間相同，而Agent的上送Profiler的默認(rèn)時(shí)間間隔也是10s，這之間會(huì)不會(huì)有什么關(guān)系？因?yàn)槔硐肭闆r至少客戶端是應(yīng)該復(fù)用這個(gè)連接的，直覺上應(yīng)該是Agent端關(guān)閉連接才對(duì)的。果不其然，在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的間隔時(shí)間，所以很快就破案了，真是好巧不巧的，這個(gè)時(shí)間點(diǎn)卡的可真準(zhǔn)，其實(shí)一般情況服務(wù)端這么設(shè)置也沒問題，因?yàn)殚L(zhǎng)連接通常適用于并發(fā)調(diào)用，以Agent端的調(diào)用頻率并不高，而且也沒有并發(fā)，所以將服務(wù)端IdleTimeout設(shè)置為魔數(shù)30s，就沒有再出現(xiàn)EOF的錯(cuò)誤，然后我提了PR，很快就合入了主干。
總結(jié)
一開始上網(wǎng)搜解決方案，發(fā)現(xiàn)完全不是那么回事，果然是人云亦云，每個(gè)人給出的上下文不一樣，解決方案自然有差別。其實(shí)用wireshark抓一下包就能找到線索，大膽猜測(cè)，小心求證，數(shù)據(jù)總不會(huì)騙人的，源碼也靜待剖析。
參考：
