网络排查案例课
杨胜辉
eBay 资深运维专家,流量系统负责人
22781 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 39 讲
实战三:不用抓包就能做的网络排查篇 (2讲)
网络排查案例课
15
15
1.0x
00:00/00:00
登录|注册

18 | 偶发性问题如何排查?

-G 新文件生成间隔
-C 每个文件大小
-W 循环文件数量
展示特定TCP流的数据包
结合管道符和grep进行输出优化
过滤并排序高耗时HTTP事务
Follow TCP Stream分析TCP流
排序找到耗时最高的事务
自定义列显示耗时
使用过滤器 http.time
确定响应时间阈值
确定慢/卡顿的标准
确认问题数据包已抓取
客户端持续刷新页面测试
根据预估时间跨度进行抓包
计算时间跨度
确认请求频率
结合应用日志进行分析
导出抓包文件
设定自动告警机制
人工观察应用日志或仪表盘
利用tcpdump的 -s 参数减小抓包文件大小
利用tcpdump的循环抓包参数
选择稀疏频率进行保守估计
利用用户反馈、应用日志、监控仪表盘统计
如何验证是否存在重传问题
分享tshark使用经验
使用tshark进行分析
Wireshark分析
定义问题
问题重现监控
抓包时长
预估问题频率和周期
抓包文件分析
观察和抓包
抓包策略
预估问题出现的时间跨度
思考题
命令行工具分析
抓包分析
实战案例:网站偶尔变慢
排查偶发性问题的策略

该思维导图由 AI 生成,仅供参考

你好,我是胜辉。
在开始今天的课之前,我先问你一个问题:你在工作中没有遇到过那种“神出鬼没”的故障?就是说大部分时候情况都是正常的,但偶尔会来一下故障的那种。我猜有 99% 的可能你遇到过。
这种问题挺麻烦,经常是我们准备排查的时候,现场就没有了。那么,没有第一手的详细数据,我们还能查到问题的根因吗?
在我以往的实践当中,我发现不少人在对这个问题的认识上,会有两个常见的误区。
误区 1:没有现场,也没有抓包,但只要我们有历史记录,就能通过它查到根因。
这里说的历史记录,是指应用日志、性能指标等。的确,很多问题通过查看历史记录,就可以解决。但还有一些问题场景,单靠历史记录是无法查到根因的。
比如这样一个场景:用户访问页面时偶尔遇到 HTTP 503 错误。而 LB 日志里,记录的其实也是一次 HTTP 503,以及“后端服务不可用”这类信息。但是如果我们继续追问:为什么当时后端服务不可用呢?当时网络上有什么问题导致这种不可用呢?
日志并不能告诉我们这些问题的答案。这是它本身的局限性导致的,即它的视角是应用层,并不是网络层,所以天生就无法了解底层网络到底发生了什么。这种时候,你是不是有一种“隔靴搔痒”的感觉?
事实上,这类问题的排查,需要在重现(reproduce)问题时做全面的排查工作(比如抓包),拿到最真实全面的信息后,才能真正彻底完成。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文介绍了使用 tshark 命令行工具进行网络排查和分析的方法。作者首先指出了排查过程中的两个常见误区,然后提出了针对偶发性问题的重现和排查策略,包括预估问题出现的时间跨度、抓包时长的确定、定时观察和导出抓包文件等步骤。通过一个实际案例展示了如何利用这些策略来解决偶尔网站变慢的问题。文章还介绍了如何在网络视角上精确定义问题,并使用 tshark 实现对大量 HTTP 事务的性能分析。通过过滤器和自定义列,读者可以方便地进行数据分析和统计,从而快速定位问题。最后,文章提到了可能存在的其他排查可能性,并指出了相应的解决方法。整体而言,本文提供了实用的排查方法和技巧,对于面临类似问题的读者具有一定的指导意义。文章还提到了 tshark 在命令行形式下的优势,以及如何利用 tshark 对大量 HTTP 事务的耗时进行统计,为问题排查和性能调优提供帮助。文章内容丰富,技术性强,对读者进行了全面的指导和启发。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《网络排查案例课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(8)

  • 最新
  • 精选
  • 分清云淡
    tshark、tcpdump常用案例我整理了文字版放这里了:https://www.weibo.com/1667773473/LrrLQirmv 基本上我们的服务器模板里必备这些,紧急情况下让远程复制粘贴就行

    作者回复: 确实,很多命令全记住也不容易,我也有很多小本本:)

    2022-05-21
    2
    4
  • 那时刻
    请问老师,[Time since request: xxx seconds]对应于 http.time,这个对应关系在哪里可以查找到呢?

    作者回复: 你把[Time since request: xxx seconds]右单击选择apply as column,然后主窗口里多了一个列。你对这个列右单击选择edit column,就能看到它的fields里面的内容就是http.time了~

    2022-03-02
    2
    3
  • 晴天了
    有一个疑问 问下老师. 场景: 客户端a 请求 nginx b. nginx b将请求通过tcp转发给php-fpm c 开启的9000端口. 问题: a 到 b的http包可以抓到. 但是b到c的请求我就不知道该怎么筛选了. 目前想到的办法是将http的内容转为16进制, 然后在wareshark通过data.data contains hexString 进行筛选. 但是http是分段的, 有时可能会抓不到. 老师有没有更准确的办法教授一下 感谢.

    作者回复: 你好,这里应该是两个不同的TCP连接: 连接1:a到b 连接2:b的nginx到b自己的php-fpm,通过本地的TCP 9000端口 HTTP事务是在这两个中传输的时候,大部分信息是不变的,特别是payload。所以你可以尝试我在第17讲介绍的方法,当时也是在HAProxy两侧不同TCP连接中定位同一个HTTP事务。具体来说就是利用下面这种过滤器,在连接1和连接2中分别找到它: tcp contains "xxxx"

    2022-03-28
    2
    2
  • Bachue Zhou
    ‪抓包常态化的误区,搞技术的人都能理解,偏偏某些领导无法理解或不愿意理解‬。

    作者回复: 这种情况是有点无奈。不过可以换一个想法,看看领导的诉求是什么。“常态化抓包”是目标还是手段?看看领导的目标具体是什么,达成这个目标的手段可以是什么,可以不是什么? 我们常犯的错误,是把手段当成了目标:)

    2022-11-01归属地:上海
    2
    1
  • Realm
    1 tshark -R "tcp.analysis.retransmission || tcp.analysis.out_of_order" 通过-R 指定过滤条件,抓重传和乱序的包 2 双向抓包对比,确认是否有重传;

    作者回复: 两个都对了,厉害了!tshark的功能确实很强大,也很实用,在后续课程里会继续介绍的

    2022-03-02
    1
  • kissingers
    最终还是通过抓包来分析的,有没有这类问题不通过抓包,比如通过现象--->可能原因分析---->找到原因比如配置等问题的案例分享

    作者回复: 这种案例当然有,不过有点过于经验性,我希望这个课程是提供一种具体到细节和原理性的分析。这种分析方法应该是要掌握的,即使你到后期可以做到“通过现象--->可能原因分析---->找到原因”,但脱离了这个抓包分析的能力,就有点不扎实。各种软件的配置项都会变化,我们需要学习的知识最好要少一些“偶然性知识”(比如某个软件的某个配置叫某个名字,在它的值为某个数字的时候会出现某种问题),而多一些“必然性知识”(网络协议是十多年二十多年都不会有大的改变的)。

    2022-05-10
  • 汤玉民
    老师 非常棒的课程

    作者回复: 谢谢你的支持:)

    2022-03-29
  • JianXu
    看到这里我觉得抓包对老师来说基本上就是“瑞士军刀”。对于偶发性问题,监控数据挺重要的。我司就要全面上线SLB , Mesh … 节点多,还是分布式系统,排查偶发性问题更难了。

    作者回复: 是的,对于我们大规模应用,对各种数据源的依赖性更高。另外,跳数越多,排查复杂度越高,课程里的案例算比较简单的,大规模应用下的问题耗时更长,基本上少不了多次的来回,比如: 第一回:大致确定问题位置,比如是靠近客户端,还是靠近LB,还是靠近服务端 第二回:在这个相对小的范围里利用现有的日志或者打开新的debug日志,进一步缩小范围 第三回:上tcpdump等工具来定位根因

    2022-03-21
收起评论
显示
设置
留言
8
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部