技术控

    今日:68| 主题:49270
收藏本版 (1)
最新软件应用技术尽在掌握

[其他] 手把手教你用Sar诊断问题

[复制链接]

立即注册CoLaBug.com会员,免费获得投稿人的专业资料,享用更多功能,玩转个人品牌!

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
如今各种高大上的监控工具早已经让人目不暇接了,但是熟悉基础的 Linux 监控命令依然是必要的,就好比 IDE 再好用,我们也得学会 vi 或者 emacs 才行。如果让我选一个必须学会的 Linux 监控命令的话,那么我想我一定会选 sar,没有之一。
  监控命令 sar 隶属于 sysstat 包,监控的内容可以说是无所不包,常见的有:
  
       
  • sar -q:查看 Load   
  • sar -u:查看 CPU   
  • sar -r:查看 Memory   
  • sar -b:查看 IO  
  除了这些常用的基础用法,还有一些更高级的用法:
  
       
  • sar -n DEV -f /var/log/sa/sa01:查看本月 1 号的网卡流量情况   
  • sar -n SOCK -f /var/log/sa/sa01:查看本月 1 号的网络连接情况  
  缺省情况下,sar 会每 10mins 搜集一次数据,然后保存到「/var/log/sa」里,如果我们想查看历史数据,可以在执行 sar 时通过「-f」参数指定具体的日志文件。不过需要说明的是,每 10mins 一次的采样周期实在有点久,我强烈建议大家改成每 1min 采样一次:
  [code]shell> cat /etc/cron.d/sysstat
# Run system activity accounting tool every 1 minute
* * * * * root /usr/lib64/sa/sa1 1 1
# 0 * * * * root /usr/lib64/sa/sa1 600 6 &
# Generate a daily summary of process accounting at 23:53
53 23 * * * root /usr/lib64/sa/sa2 -A[/code]  如果你对着文档挨个参数测试,那么很有可能会遇到错误提示:
  Requested activities not available in file /var/log/sa/sa…
  这是因为 sar 并没有把所有数据都归档保存,所以当你请求无效数据的时候,自然就报错了,好消息是我们可以通过 SADC_OPTIONS 来设置把那些数据归档:
  [code]shell> cat /etc/sysconfig/sysstat
# sysstat-9.0.4 configuration file.

# How long to keep log files (in days).
# If value is greater than 28, then log files are kept in
# multiple directories, one for each month.
HISTORY=28

# Compress (using gzip or bzip2) sa and sar files older than (in days):
COMPRESSAFTER=31

# Parameters for the system activity data collector (see sadc manual page)
# which are used for the generation of log files.
SADC_OPTIONS="-S XALL"[/code]  关于 SADC_OPTIONS 的介绍,请参考「man sadc」。本文设置为 XALL,也就是保存一切数据,除非你的硬盘可用空间少得可怜,否则我强烈建议你设置为 XALL。
   坏消息是如果仅仅是修改了 SADC_OPTIONS,那么很可能会无效, FAQ :
  IMPORTANT NOTE: The list of activities that are saved in a file can no longer be modified once the file has been created. So it is important to use the proper options the first time sadc is called (whether via a crontab, a script like sa1 or even the script used to insert a RESTART message when the machine is rebooted).
  当然,我们并不用重启服务器,只要删除 /var/log/sa 下的旧日志即可。
  最后,让我们讲解一个实战的例子来作为本文的结尾:sar 可以用来监控各种错误事件,比如通过「sar -n ETCP 1」实时监控 TCP 相关的错误事件:
     
手把手教你用Sar诊断问题-1 (accounting,activity,网络连接,Memory,system)
   sar -n ETCP 1
    如上我们可以发现 estres/s 和 orsts/s 都出现了错误数不为零的情况:
  
       
  • estres/s: The number of times per second TCP connections have made a direct transition to the CLOSED state from either the ESTABLISHED state or the CLOSE-WAIT state [tcpEstabResets].   
  • orsts/s: The number of TCP segments sent per second containing the RST flag [tcpOutRsts].  
  说明:关于 estres/s 和 orsts/s 介绍中结尾出现的 tcpEstabResets 和 tcpOutRsts 源自何处?你可以参考「nstat -z | grep -iE ‘tcpEstabResets|tcpOutRsts’」。
  两者都是关于 RESET 的数据,区别是:estres/s 指的是每秒收到的 RESET 数量;orsts/s 指的是发出的 RESET 数量。从数据上看 estres/s 的问题更严重,几乎无时无刻都在不停的收到 RESET,为了探明究竟,我们用 tcpdump 抓包,然后用 wireshark 查看:

手把手教你用Sar诊断问题-2 (accounting,activity,网络连接,Memory,system)
   Wireshark
    通过「tcp.flags.reset == 1」语法我们能筛选出所有的 RESET 包,然后在鼠标右键菜单里选择「Follow TCP Stream」就可以跟踪一个具体的 TCP 会话,如图片下方所示,对方在和我方进行了 TCP 三次握手之后,直接就 RESET 了!
  实际上,问题分析到这里,我们已经找到了 estres/s 的源头了,不过对方为什么要发送这么多 RESET?说起来这是一台阿里云的服务器,在配置负债均衡的时候错误的选择了 TCP 监控的方式,而阿里云的 TCP 监控本身又 DDoS 般粗野:一大堆请求通过三次握手确认端口是否存活,然后并没有通过正常的四次握手关闭连接,而是直接通过 RESET 关闭连接。至于为什么阿里云如此选择?我猜可能它不想出现 TIME_WAIT 吧,呵呵!
友荐云推荐




上一篇:浅入浅出 Android 安全:第三章 Android 本地用户空间层安全
下一篇:Go: An Innovation in Programming Practice
酷辣虫提示酷辣虫禁止发表任何与中华人民共和国法律有抵触的内容!所有内容由用户发布,并不代表酷辣虫的观点,酷辣虫无法对用户发布内容真实性提供任何的保证,请自行验证并承担风险与后果。如您有版权、违规等问题,请通过"联系我们"或"违规举报"告知我们处理。

Carrolljed 发表于 4 天前
逆袭成功。。。。。。
回复 支持 反对

使用道具 举报

蒋旭 发表于 3 天前
小手一抖,一分拿走!
回复 支持 反对

使用道具 举报

*滑动验证:
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

我要投稿

推荐阅读

扫码访问 @iTTTTT瑞翔 的微博
回页顶回复上一篇下一篇回列表手机版
手机版/CoLaBug.com ( 粤ICP备05003221号 | 文网文[2010]257号 )|网站地图 酷辣虫

© 2001-2016 Comsenz Inc. Design: Dean. DiscuzFans.

返回顶部 返回列表