📚 课程目录第4章排查工具介绍

排查工具介绍：抓包三件套

排查日志丢失，说白了就是回答三个问题：数据到底发没发？中途丢在哪？采集端吃没吃进去？回答这些问题，离不开三样东西：tcpdump、Wireshark 和 Filebeat。我个人习惯把它们叫做“抓包三件套”，各管一摊，又互相补充。

tcpdump：命令行里的“照妖镜”

这是我最先亮出来的工具。你想想看，当业务说“我发了日志”而采集说“我没收到”时，谁在撒谎？让 tcpdump 在中间听一下就知道了。

常用套路

# 监听 eth0，只抓来源是某个 Filebeat 或应用的包
tcpdump -i eth0 -nn -s0 host 10.0.1.100
# -nn 让 IP 和端口不反解，省时间
# -s0 抓满包，不截断

# 抓完保存，回头慢慢分析
tcpdump -i eth0 -nn -s0 -w /tmp/log_dump.pcap host 10.0.1.100

我在项目中遇到过一个经典场景：用户说 Filebeat 配置没问题，就是不上传。我用 tcpdump 一看，好家伙，Filebeat 所在的机器根本就没往 Kafka 的 IP 发过任何 SYN 包。网络策略没通，上层流程走断了，底层的 tcpdump 一抓一个准。

我的小技巧：排查时多用组合过滤。比如 port 5044 只看 Filebeat 端口，tcp[13] & 2 != 0 只看 SYN 包，三行命令就能定位绝大多数网络层问题。

避坑指南

我曾经在生产环境直接 tcpdump 没加 -p，导致业务进程连不上网。记住了，用 tcpdump -p -i any 可以不把网卡设成混杂模式，安全第一。
抓包文件别乱扔。一个 100Mb 的 pcap 文件解压后可能吃掉几个 G 内存，先看文件大小再用 Wireshark 打开。

Wireshark：图形化“显微镜”

tcpdump 是获取证据，Wireshark 是分析证据。这东西界面功能多到让人眼花，但排查日志丢失，你只需要盯住几个地方。

两个最强过滤

场景	过滤表达式	能看出来什么
只看某个 TCP 流	`tcp.stream eq 0`	一次完整的三次握手 + 数据传输 + 四次挥手
只看重传和丢包	`tcp.analysis.retransmission`	网络有拥塞或丢包，数据可能没到对端

我习惯先看“Statistics → Conversations”里的字节数。如果源 IP 发了 1MB 数据，目的 IP 只收到 800KB，中间 200KB 去哪了？要么丢了，要么被对端窗口拒绝了。

核心逻辑：Wireshark 不会骗人，它只告诉你网卡上真实发生了什么。如果 Wireshark 里已经看到 Filebeat 发出数据并且 Kafka 回复了 ACK，那问题就不在网络层，往应用层查。

别再只看Hex了

你可以右键“Follow → TCP Stream”，直接把应用层内容拼出来。我曾经用这个功能看到 Filebeat 发出去的 JSON 里有一个字段换行符错误，导致 Logstash 解析失败。嗯，这种问题不看 TCP 流根本想不到。

注意：Wireshark 在大流量下容易卡死。生产环境推荐用 dumpcap（Wireshark 命令行版）后台抓包，再把小文件拉到图形界面分析。我自己就是这么干的。

Filebeat：采集端的“黑匣子”

Filebeat 是最后一道防线。如果说 tcpdump 和 Wireshark 看的是“路上发生了什么”，Filebeat 看的是“出发前和到达后发生了什么”。

注册表文件

Filebeat 有一个叫 registry/filebeat/log.json 的文件，记录了每个日志文件的读到哪了。这是排查“重复采集”或“跳过文件”的关键。

# 用 jq 看注册表摘要
cat data/registry/filebeat/log.json | jq '.[] | {source, offset, state}'

输出类似：

{
  "source": "/var/log/app/access.log",
  "offset": 1024512,
  "state": "open"
}

我记得有次用户反馈日志少了一段。我一查注册表，发现 offset 停在一个很大的值，而文件已经被轮转没了。简单说，Filebeat 觉得“这文件我读完了”，但实际上轮转过来的新日志它根本没碰。原因是轮转策略里 truncate 和 create 没区分，Filebeat 的 close_inactive 参数又设太短，文件被关掉后新日志写入，它没再重新打开。

核心配置检查项

参数	默认值	排查要点
`close_inactive`	5m	设太短，文件频繁关闭再打开，容易漏掉轮转间隙的日志
`scan_frequency`	10s	新文件产生到被扫描有10s延迟，要求高的场景可以改短
`backoff`	1s	重试间隔，网络抖动时改短一点能加快恢复

我的习惯：每配好一台 Filebeat，都先跑 ./filebeat test output 确认连接通，然后用 tail -f logs/filebeat 看一段时间，确认 Harvester started 和 Publish event 的日志出现在预期时间点。
说白了，别相信配置文件的“看起来对”，让 Filebeat 自己告诉你它行不行。

三件套协作图

下面这张图展示了排查时三个工具的使用位置和数据流向关系。

这张图其实很直观。排查时按三条线走：应用 → tcpdump → 目标端 确认数据有没有出网关；pcap → Wireshark 看网络质量；Filebeat → registry → 目标端 检查采集端是否正常。

打个比方，tcpdump 是你派出去的侦察兵，Wireshark 是情报分析室，Filebeat 是后方仓库管理员。每个环节的信息综合起来，日志丢在哪、为什么丢，基本就水落石出了。