tcpdump解决运维生产中遇到问题

来源: DevOpSec公众号
作者: DevOpSec

作为技术人员tcpdump这个工具还是有必要了解的

当你遇到网络协议问题一筹莫展的时候，这时候往往可以通过tcpdump来看网络的通讯过程中发生了什么事，帮助快速定位问题。

本文只介绍工作用遇到的问题供大家参考，旨在给你工作中遇到类似问题提供解决灵感，具体tcpdump怎么使用google吧。

下面通过三个案例进行介绍：

案例一：flume写kafka日志报错

案例二：LB（负载均衡）增加请求header后，nginx日志获取不到header key client_ip

案例三：mysql QPS 特别高，但mysql并没有慢查询，想知道topK mysql语句

最后：场景的http协议抓包场景

案例一：`flume`写`kafka`日志报错

flume写kafka日志如下，没有其他报错。看下面报错，向kafka push数据TimeoutException

但在flume机器上telnet kafka 9092端口是通的

这是什么原因导致的呢？

看日志没有思路，tcpdump抓包看一下

13 May 2023 16:01:28,367 ERROR [SinkRunner-PollingRunner-DefaultSinkProcessor] (org.apache.flume.sink.kafka.KafkaSink.process:240)  - Failed to publish events
java.util.concurrent.ExecutionException: org.apache.kafka.common.errors.TimeoutException: Batch Expired
        at org.apache.kafka.clients.producer.internals.FutureRecordMetadata.valueOrError(FutureRecordMetadata.java:56)
        at org.apache.kafka.clients.producer.internals.FutureRecordMetadata.get(FutureRecordMetadata.java:43)
        at org.apache.kafka.clients.producer.internals.FutureRecordMetadata.get(FutureRecordMetadata.java:25)
        at org.apache.flume.sink.kafka.KafkaSink.process(KafkaSink.java:229)
        at org.apache.flume.sink.DefaultSinkProcessor.process(DefaultSinkProcessor.java:67)
        at org.apache.flume.SinkRunner$PollingRunner.run(SinkRunner.java:145)
        at java.lang.Thread.run(Thread.java:748)
Caused by: org.apache.kafka.common.errors.TimeoutException: Batch Expired
13 May 2023 16:01:28,367 ERROR [SinkRunner-PollingRunner-DefaultSinkProcessor] (org.apache.flume.SinkRunner$PollingRunner.run:158)  - Unable to deliver event. Exception follows.
org.apache.flume.EventDeliveryException: Failed to publish events
        at org.apache.flume.sink.kafka.KafkaSink.process(KafkaSink.java:252)
        at org.apache.flume.sink.DefaultSinkProcessor.process(DefaultSinkProcessor.java:67)
        at org.apache.flume.SinkRunner$PollingRunner.run(SinkRunner.java:145)
        at java.lang.Thread.run(Thread.java:748)
Caused by: java.util.concurrent.ExecutionException: org.apache.kafka.common.errors.TimeoutException: Batch Expired
        at org.apache.kafka.clients.producer.internals.FutureRecordMetadata.valueOrError(FutureRecordMetadata.java:56)
        at org.apache.kafka.clients.producer.internals.FutureRecordMetadata.get(FutureRecordMetadata.java:43)
        at org.apache.kafka.clients.producer.internals.FutureRecordMetadata.get(FutureRecordMetadata.java:25)
        at org.apache.flume.sink.kafka.KafkaSink.process(KafkaSink.java:229)
        ... 3 more

在flume机器上抓包

tcpdump port 9092 -s 0 -A -e -vvv

16:46:31.324786 52:54:00:6f:bf:d2 (oui Unknown) > 98:f2:b3:2b:74:f0 (oui Unknown), ethertype IPv4 (0x0800), length 97: (tos 0x0, ttl 63, id 3722, offset 0,flags [DF], proto TCP (6), length 83)
    flume-001.28230 > 192-168-160-10.kafka.release.svc.cluster.local.XmlIpcRegSvc: Flags [P.], cksum 0xc1b4 (incorrect -> 0x3b21), seq 14182:14225, ack 6634, win 31200, length 43
E..S..@.?.k........
nF#...d.q#..P.y........'.........
producer-1......log_flume_topic

16:46:31.325436 98:f2:b3:2b:74:f0 (oui Unknown) > 52:54:00:6f:bf:d2 (oui Unknown), ethertype IPv4 (0x0800), length 704: (tos 0x0, ttl 64, id 39463, offset 0, flags [DF], proto TCP (6), length 690)
    192-168-160-10.kafka.release.svc.cluster.local.XmlIpcRegSvc > flume-001.28230: Flags [P.], cksum 0x4359 (correct), seq 6634:7284, ack 14225, win 50470, length 650
E....'@.@......
....#.nFq#....e.P..&CY....................kafka-002..#.......kafka-003..#.......kafka-001..#.........log_flume_topic.............................................................
...................................................     ..........................................................................................................................................................................................................................................................................................................................................................................................................................

从上面抓包信息看kafka节点192-168-160-10.kafka.release.svc.cluster.local.XmlIpcRegSvc 回包内容有kafka-002..#.......kafka-003..#.......kafka-001..#.........log_flume_topic

kafka-002、kafka-003、kafka-001是kafka主机名，看到这里还是不是很直观，把数据包保存到文件通过whireshark分析一下

执行tcpdump port 9092 -s 0 -w kafka_traffic.pcap ，然后把文件用whireshark打开
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传
在这里插入图片描述
可以看到kafka协议有Kafka Metadata v0 request 和 Kafka Metadata v0 Response

点开Kafka Metadata v0 request协议看下详细信息
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传
在这里插入图片描述

点开Kafka Metadata v0 Response协议看下详细信息
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

在这里插入图片描述

在flume机器上ping kafka-002

ping kafka-002                                           
ping: cannot resolve kafka-002: Unknown host

到这里出现TimeoutException问题就清楚，flume client在写kafka之前，先从kafka拿到kafka的broker信息，kafka返回的broker 地址是主机名加端口

flume 拿到kafka-002 后通过dns解析失败，导致push evet失败

解决办法：

在flume机器上配置上kafka-002的hosts后，报错消失，问题解决

这里flume日志有些坑返回TimeoutException而非kafka-002 name reslove failed使定位问题增加难度

另一种解决办法：

为什么kakfa会返回kafka-002主机名而不是ip呢？

我们看一下kafka的配置文件，发现advertised.listeners=PLAINTEXT://kafka-002:9092
advertised.listeners参数的作用就是将Broker的Listener信息发布到Zookeeper中

所以flume从从kafka那里拿到的是主机名而不是ip，可以把kafka配置advertised.listeners改成ip重启kafka问题也能解决

案例二：`LB`（负载均衡）增加请求`header`后，`nginx`日志获取不到`header` `key` `client_ip`

先说一下场景

通过LB做七层负载均衡后remote_addr看到的是LB的ip，所以在负责均衡上把客户端的ip给增加到请求header client_ip 里。

在nginx里增加日志打印$http_client_ip，并没有获取到此header 的值

这是什么原因呢？

是不是负责LB运维的小伙伴没有增加client_ip header？

还是header加上了但值是空？

这就需要通过tcpdump抓包来验证一下我们的猜测。

在nginx上执行如下命令：

tcpdump -s 0 -A 'tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420'|grep client_ip

结果发现：

client_ip: 1.1.1.1

由抓包信息看客户端的ip是设置到header里的，说明LB的配置没问题，那问题来到了nginx这一侧。

为什么通过$http_client_ip没有获取到header的值？

通过nginx官网找header相关配置 http://nginx.org/en/docs/http/ngx_http_core_module.html 发现

Syntax:	underscores_in_headers on | off;
Default:	
underscores_in_headers off;
Context:	http, server

到这里真相大白，nginx默认会忽略用户自定义带下划线的header避免和nginx自带的header key冲突

修改nginx配置设置underscores_in_headers no; 后问题解决

案例三：`mysql` `QPS` 特别高，但`mysql`并没有慢查询，想知道`topK` `mysql`语句

mysql 负载变高且qps也变的特别高，但没有慢查询，也可能是sql query time 设置的不合理导致慢查询没有暴露出来，担心长时间这样下去会影响数据库的性能，想知道是什么语句导致？

这里没有开启mysql的审计，调用方没有记录日志，也不好排查

那怎么处理呢？有没有非侵入且不需要研发干涉的情况下拿到topK sql？

这时候我们的tcpdump就闪亮登场了

抓取mysql通用脚本如下：

cat /tmp/mdump.sh
tcpdump -i eth0 -s 0 -l -w - port 3306 | strings | perl -e '
while(<>) { chomp; next if /^[^ ]+[ ]*$/;
    if(/^(SELECT|UPDATE|DELETE|INSERT|SET|COMMIT|ROLLBACK|CREATE|DROP|ALTER|CALL)/i)
    {
        if (defined $q) { print "$q\n"; }
        $q=$_;
    } else {
        $_ =~ s/^[ \t]+//; $q.=" $_";
    }
}'

在qps高的mysql机器上执行

sh /tmp/mdump.sh > /tmp/m.sql
30s后ctrl + c
然后执行如下命令获取top 10 SQL

grep -i ' from ' /tmp/m.sql |grep -i ' where ' |awk -F'where|WHERE' '{print $1}'|sort|uniq -c |sort -rnk1|head -n 10

找到高频sql可以找开发沟通，是否有新业务功能上线，优化方案。

由此看类似的组件也能通过这种形式进行抓包定位问题

这里再推荐一个MySQL、Redis、MongoDB、http网络抓包工具
https://github.com/40t/go-sniffer

最后：场景的http协议抓包场景

抓取HTTP GET 请求

tcpdump -i enp0s8 -s 0 -A 'tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420'

解释：

tcp\[((tcp\[12:1\] & 0xf0) >> 2):4\]定义了我们所要截取的字符串的位置（http header的后面）的4 bytes。

0x47455420是G E T 的ASCII码。

Character	ASCII Value
G	47
E	45
T	54
Space	20

抓取HTTP POST 请求

tcpdump -i enp0s8 -s 0 -A 'tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x504F5354

0x504F5354代表的是 P O S T的ASCII码.

目的端口为80的HTTP GET请求

tcpdump -i enp0s8 -s 0 -A 'tcp dst port 80 and tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420'

目的端口为80或443的HTTP GET 和POST请求(来自10.10.10.10)

tcpdump -i enp0s8 -s 0 -A 'tcp dst port 80 or tcp dst port 443 and tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420 or tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x504F5354' and host 10.10.10.10

抓取HTTP GET和POST request和response

tcpdump -i enp0s8 -s 0 -A 'tcp dst port 80 and tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420 or tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x504F5354 or tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x48545450 or tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x3C21444F and host 10.10.10.10'

过滤目的端口为80，host为10.10.10.10，http get/post 的request和response

0x3C21444F是'<' 'D' 'O' 'C'的ASCII码，作为html文件的标识符

0x48545450是'H' 'T' 'T' 'P'的ASCII码，用来抓取HTTP response

监测所有的HTTP request URL（GET/POST）

tcpdump -i enp0s8 -s 0 -v -n -l | egrep -i "POST /|GET /|Host:"

抓取POST请求里的password

tcpdump -i enp0s8 -s 0 -A -n -l | egrep -i "POST /|pwd=|passwd=|password=|Host:"

抓取Request和response里的cookie

tcpdump -i enp0s8 -nn -A -s0 -l | egrep -i 'Set-Cookie|Host:|Cookie:'

过滤HTTP header

#从header里过滤出user-agent
tcpdump -vvAls0 | grep 'User-Agent:'