當(dāng)前位置：首頁(yè) > 编程资源 > 编程问答 >内容正文

编程问答

【原创】packetbeat 之“request-response 错误关联”问题

發(fā)布時(shí)間：2024/4/17 编程问答 37 豆豆

生活随笔收集整理的這篇文章主要介紹了【原创】packetbeat 之“request-response 错误关联”问题小編覺(jué)得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.

2019獨(dú)角獸企業(yè)重金招聘Python工程師標(biāo)準(zhǔn)>>>

問(wèn)題描述

在基于 packetbeat 分析 redis 協(xié)議時(shí)發(fā)現(xiàn)，在某些情況下，基于 request-response 關(guān)聯(lián)出的 transaction 信息是錯(cuò)誤的，示例如下：

responsetime(947201 microseconds) ==> No.<1> ---- {"@timestamp":"2016-12-29T07:21:24.657Z","beat":{"hostname":"xg-mesos-39","name":"xg-mesos-39","version":"6.0.0-alpha1"},"bytes_in":14,"bytes_out":40,"client_ip":"10.0.242.43","client_port":7125,"client_proc":"","client_server":"","ip":"10.0.246.114","method":"PING","port":48877,"proc":"","query":"PING","redis":{"return_value":"[REPLCONF, ACK, 5372098]"},"resource":"","responsetime":947201,"server":"","status":"OK","type":"redis"}

從上述信息可以明顯看出，當(dāng)前 transaction 中關(guān)聯(lián)的 request 為 PING 命令，response 為 [REPLCONF, ACK, 5372098] 命令；

注意：因?yàn)?transaction 的構(gòu)建是基于 TCP 連接的，因此不會(huì)出現(xiàn)將不同 TCP 連接上的請(qǐng)求應(yīng)答錯(cuò)亂匹配的問(wèn)題；

問(wèn)題原因

上面錯(cuò)誤在于，將 PING 和 [REPLCONF, ACK, 5372098] 進(jìn)行了關(guān)聯(lián)，而這兩者明顯不是對(duì)應(yīng)關(guān)系；

通過(guò)梳理 Redis 協(xié)議相關(guān)資料可以知道：

PING 的使用
[客戶端-服務(wù)器] 使用客戶端向 Redis 服務(wù)器發(fā)送一個(gè) PING ，如果服務(wù)器運(yùn)作正常的話，會(huì)返回一個(gè) PONG 。通常用于測(cè)試與服務(wù)器的連接是否仍然生效，或者用于測(cè)量延遲值；
[Sentinel] 在默認(rèn)情況下，Sentinel 會(huì)以每秒一次的頻率向所有與它創(chuàng)建了命令連接的實(shí)例（包括主服務(wù)器、從服務(wù)器、其他 Sentinel 在內(nèi)）發(fā)送 PING 命令，并通過(guò)實(shí)例返回的 PING 命令回復(fù)（有效回復(fù)為 +PONG/-LOADING/-MASTERDOWN）來(lái)判斷實(shí)例是否在線（主觀下線狀態(tài)檢測(cè)）；
[主從復(fù)制] 當(dāng)從服務(wù)器成為主服務(wù)器的客戶端后，做的第一件事就是向主服務(wù)器發(fā)送一個(gè) PING 命令；兩個(gè)作用：a) 檢查套接字的讀寫狀態(tài)是否正常；b) 檢查主服務(wù)器能否正常處理命令請(qǐng)求；只有從服務(wù)器在規(guī)定時(shí)間內(nèi)讀取到主服務(wù)器返回的 PONG 才算成功；
[主從復(fù)制] Slaves 以預(yù)定義的周期向 server 發(fā)送 PING；該周期通過(guò) repl_ping_slave_period 選項(xiàng)進(jìn)行配置，默認(rèn)為 10 秒； The original replication protocol was vulnerable to network/Internet outages where the master detects the outage and closes the connection, but the slave does not. The slave thinks the connection is still open and the master simply has no updates to send (low traffic or no traffic). So the slave never disconnects and re-connects to restart the replication. I know this very well. I have some v2.0.x Redis instances that replicate across 3,000 miles and once or twice a month this problem occurs. Adding PING to the replication protocol solved that. The slave now detects the connection problem when the PING replies stop coming from the master. The slave can close its end of the connection and re-connect again.
[集群] 集群里的每個(gè)節(jié)點(diǎn)默認(rèn)每隔一秒鐘就會(huì)從已知節(jié)點(diǎn)列表中隨機(jī)選出五個(gè)節(jié)點(diǎn)，然后對(duì)這五個(gè)節(jié)點(diǎn)中最長(zhǎng)時(shí)間沒(méi)有發(fā)送過(guò) PING 消息的節(jié)點(diǎn)發(fā)送 PING 消息，以此來(lái)檢測(cè)被選中的節(jié)點(diǎn)是否在線；除此之外，如果節(jié)點(diǎn) A 最后一次收到節(jié)點(diǎn) B 發(fā)送的 PONG 消息的時(shí)間，距離當(dāng)前時(shí)間已經(jīng)超過(guò)了節(jié)點(diǎn) A 的 cluster-node-timeout 選項(xiàng)設(shè)置時(shí)長(zhǎng)的一半，那么節(jié)點(diǎn) A 也會(huì)向節(jié)點(diǎn) B 發(fā)送 PING 消息，這可以防止節(jié)點(diǎn) A 因?yàn)殚L(zhǎng)時(shí)間沒(méi)有隨機(jī)選中節(jié)點(diǎn) B 作為 PING 消息的發(fā)送對(duì)象，而導(dǎo)致對(duì)節(jié)點(diǎn) B 的信息更新滯后；
[REPLCONF, ACK, <replication_offset>] 的使用

在命令傳播階段，從服務(wù)器默認(rèn)會(huì)以每秒一次的頻率，向主服務(wù)器發(fā)送該命令；該命令的作用為：a) 檢測(cè)主從服務(wù)器的網(wǎng)絡(luò)連接狀態(tài)；b) 輔助實(shí)現(xiàn) min-slaves 選項(xiàng)；c) 檢測(cè)命令丟失；

具體抓包數(shù)據(jù)如下

*3 $8 REPLCONF $3 ACK $11 81234009046 *3 $8 REPLCONF $3 ACK $11 81234009046 *3 $8 REPLCONF $3 ACK $11 81234009046 *3 $8 REPLCONF $3 ACK $11 81234009046 *3 $8 REPLCONF $3 ACK $11 81234009046 *3 $8 REPLCONF $3 ACK $11 81234009046 *3 $8 REPLCONF $3 ACK $11 81234009046 *3 $8 REPLCONF $3 ACK $11 81234009046 *3 $8 REPLCONF $3 ACK $11 81234009046 *1 $4 PING *3 $8 REPLCONF $3 ACK $11 81234009060

可以看到，在一個(gè) 10s 的抓包周期中，出現(xiàn)了 10 個(gè) [REPLCONF, ACK, xxxx] 和 1 個(gè) PING ；可以確定，該 PING 為基于 repl_ping_slave_period 選項(xiàng)的?；?PING ；

解決辦法

可以確認(rèn)的是，出現(xiàn) [REPLCONF, ACK, xxx] 命令的連接一定是 master 和 slave 進(jìn)行通信的連接；因此，一種簡(jiǎn)單的解決辦法就是針對(duì)該命令進(jìn)行過(guò)濾，從而避免 transaction 的構(gòu)建中出現(xiàn) [REPLCONF, ACK, xxx]，但這種方式可能會(huì)導(dǎo)致統(tǒng)計(jì)數(shù)據(jù)輸出時(shí)，多出一些 unmatched 的內(nèi)容；一種高級(jí)的解決辦法就是在檢測(cè)出該命令后，直接將該命令屬于的 TCP 流徹底剔除；

轉(zhuǎn)載于:https://my.oschina.net/moooofly/blog/849634

總結(jié)

以上是生活随笔為你收集整理的【原创】packetbeat 之“request-response 错误关联”问题的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。