trace linux?Linux tracert替代命令
linux下tracert命令的作用
1.命令格式:
traceroute [参数] [主机]
2.命令功能:
traceroute指令让你追踪网络数据包的路由途径,预设数据包大小是40Bytes,用户可另行设置。
具体参数格式:traceroute [-dFlnrvx][-f<存活数值>][-g<网关>…][-i<网络界面>][-m<存活数值>][-p<通信端口>][-s<来源地址>][-t<服务类型>][-w<超时秒数>][主机名称或IP地址][数据包大小]《Linux就该这么学》一起学习linux
3.命令参数:
-d使用Socket层级的排错功能。
-f设置第一个检测数据包的存活数值TTL的大小。
-F设置勿离断位。
-g设置来源路由网关,最多可设置8个。
-i使用指定的网络界面送出数据包。
-I使用ICMP回应取代UDP资料信息。
-m设置检测数据包的最大存活数值TTL的大小。
-n直接使用IP地址而非主机名称。
-p设置UDP传输协议的通信端口。
-r忽略普通的Routing Table,直接将数据包送到远端主机上。
-s设置本地主机送出数据包的IP地址。
-t设置检测数据包的TOS数值。
-v详细显示指令的执行过程。
-w设置等待远端主机回报的时间。
-x开启或关闭数据包的正确性检验。
4实例:
实例4.1: traceroute www.baidu.com
实例4.2:跳数设置
命令:traceroute-m 10 www.baidu.com
Linux Trace机日志可视化查找工具
笔者身边有个经常查询事件日志的Linux Trace机,鉴于查看日志的使用频率较高,笔者想着做个可视化终端来帮助定位查找,提高效率。在命令行中查找日志的过程是:1、当天(24小时内)的日志直接读取日志文件,使用专用工具读取;2、超过24小时的日志需要到相应的日期目录下,根据时间定位到压缩后的日志,解压缩.gz文件,解压缩后就是文本文件,可使用vi编辑器。
可视化查找工具的目的就是要远程到Trace机,根据给定的日期和时间选择对应的日志,输出到可视化界面上,然后运维人员可以根据关键字定位到日志具体信息,或者更深一步,根据日志直接输出问题。
平时的积累太重要了,这个方案笔者边写这篇文章边思考,基本没有遇到上面不可解决的大问问题,有些问题笔者以前的文章都测试过。想到做这个工具,笔者心有成竹,都有一套解决方案,可能花时间的还是一些小问题。
笔者选择LabVIEW作为开发平台,PLINK作为远程连接工具。下面几个问题概括了笔者的一点思路,和大家分享一下。
1、 LabVIEW怎么SSH远程到Trace机
这个问题笔者以前做过,可以参考文化中-LabVIEW通过PLINK远程到Linux系统,或者愿意花钱的话选择 ALAB SSH工具,参考文章-LabVIEW远程SSH到Linux系统。在这里就不在赘述了。
2、怎么将日志输出到 LabVIEW的字符串显示控件里面
当天(24小时内)的日志直接使用专用工具读取输出到字符串中,压缩.gz文件怎么处理呢?笔者这里想了四个大同小异的方法:1、gunzip filename.gz,解压文件,然后cat filename,gunzip直接解压是不保留源文件的;2、gunzip–c filename.gz ,可以解压缩并保留源文件,文件的内容直接输出,没有生成解压后文件,这样可以省去cat指令来查看文件;3、gunzip-cv filename.gz> filename,可以保留源文件和压缩后文件,然后使用cat filename;4、zcat filename.gz 不解压文件可以直接查看文件内容。笔者使用第四种方法。
那么问题来了,.gz文件要是被人已经解压了,只有解压后的filename?那么可以使用或命令||,逻辑或,当用此连接符连接多个命令时,前面的命令执行成功,则后面的命令不会执行,前面的命令执行失败,后面的命令才会执行。请看笔者在kali linux中的测试。关于两个命令的逻辑关系的连接符,请参考文章-Linux多个SHELL命令怎么顺序执行。
结合上面的两个部分,笔者来使用labview来测试一下。关于plink中文为啥乱码的问题待回头解决吧,不过Trace机里面也没有中文。命令||的第一条命令没有执行成功,错误信息也没有显示出来,很不错!
3、日志输出到字符串控件,怎么关键字检索
使用搜索拆分字符串函数,然后将检索的字符串改变颜色高亮显示。笔者做了个简单的例子,但是针对有上万行的来说,这个检索例子需要优化,需要添加事件结构,通过按钮定位到关键字,然后NEXT按钮一步步检索到关键字。这个待笔者这几天把他做出来,先把思路放在这里。
还有针对日志,需要分析日志结构,通过全日志的分析提炼出问题所在,比如没有哪个类型的报文等等,可以做得智能化一点,提供给运维人员简单实用的提醒信息。
或者做的更加主动一点,定时分析新的日志,得到一些有用的信息。
测试前面板:
测试程序框图:
4、给定日期和时间,怎么定位到日志文件
日期好说,根据给定的日期信息,按照日期格式进入到对应的目录。时间就没有那么方便了,日志是隔段时间生成一个文件,给定时间后,要根据日志文件的时间来精确定位到目的文件。
进入到相应日期的目录,找到输出所有文件名,将给定的时间按照格式命令,找到这个时间范围的文件。笔者想到两个方法:1、labview远程到相应日期的目录,使用”ls-l“指令输出所有文件名,所有文件的时间字符串有了,给定的时间字符串有了,那么就是字符串操作的问题了;2、在 Trace上写个shell脚本,根据$1给定的时间参数,查找并输出对应的日志文件的名称,然后labview远程远程调用这个脚本得到文件名。
这两种方法待笔者更新文章再补充,其实也不难,就是要花时间测试。
5、不仅仅做日志分析,可以添加维护功能
比如笔者以前写的远程保存交换机配置文件,参考文章-关于交换机保存配置的一点思考,比如指令:PLINK-pw password username@192.168.31.82-ssh-batch"di cu"> switch%date:~,4%%date:~5,2%%date:~8,2%.txt 就可以将华为交换机的配置文件保存到本地。
还可以将使用PuTTY提供的文件传输工具PSCP(PuTTY Secure Copy client)或者PSFTP工具来远程拷贝Linux程序的配置文件。PSCP和PLINK类似,在exe的目录下运行pscp可以查看其参数说明。
测试结果如下,那么从Linux服务器拷贝配置文件就方便了。
设计思路大概如此,笔者做出来的话,不赶工的话一个星期可以调试好。里面有些细节需要优化,笔者觉得labview抑或你使用的其他开发平台,和shell基本结合来完成可能会更加方便和高效。笔者觉得最大难点在于做一个优雅的界面,现在是看脸的时代,要长得好看,还有就是日志分析上面,日志生成过程需要慢慢理清才能根据日志得到准确的解读。
Linux之traceroute命令
显示数据包到主机间的路径,traceroute命令用于追踪数据包在网络上的传输时的全部路径,它默认发送的数据包大小是40字节。通过traceroute我们可以知道信息从你的计算机到互联网另一端的主机是走的什么路径。当然每次数据包由某一同样的出发点(source)到达某一同样的目的地(destination)走的路径可能会不一样,但基本上来说大部分时候所走的路由是相同的。traceroute通过发送小的数据包到目的设备直到其返回,来测量其需要多长时间。一条路径上的每个设备traceroute要测3次。输出结果中包括每次测试的时间(ms)和设备的名称(如有的话)及其ip地址。
Traceroute的实现一共有三种方法,分别是:
命令格式
traceroute(选项)(参数)
命令选项
命令参数
主机:指定目的主机IP地址或主机名。
简单用法
记录按序列号从1开始,每个记录就是一跳,每跳表示一个网关,我们看到每行有三个时间,单位是ms,其实就是-q的默认参数。探测数据包向每个网关发送三个数据包后,网关响应后返回的时间;如果用traceroute-q 4 rumenz.com,表示向每个网关发送4个数据包。
有时我们traceroute一台主机时,会看到有一些行是以星号表示的。出现这样的情况,可能是防火墙封掉了ICMP的返回信息,所以我们得不到什么相关的数据包返回数据。有时我们在某一网关处延时比较长,有可能是某台网关比较阻塞,也可能是物理设备本身的原因。当然如果某台DNS出现问题时,不能解析主机名、域名时,也会有延时长的现象;您可以加-n参数来避免DNS解析,以IP格式输出数据。
如果在局域网中的不同网段之间,我们可以通过traceroute来排查问题所在,是主机的问题还是网关的问题。如果我们通过远程来访问某台服务器遇到问题时,我们用到traceroute追踪数据包所经过的网关,提交IDC服务商,也有助于解决问题;但目前看来在国内解决这样的问题是比较困难的,就是我们发现问题所在,IDC服务商也不可能帮助我们解决。
设置跳数显示IP地址,不查主机名把探测包的个数设置为值4绕过正常的路由表,直接发送到网络相连的主机探测包的等待响应时间设置为3秒Traceroute的工作原理UDP和 ICMP Traceroute
Traceroute的基本原理是向外发送带有逐次递增 TTL的数据包从而获取的路径中每一跳的信息。
Host A向 Host B做 traceroute,Host A第一次会发出一个 TTL=1的数据包,当该数据包到达 R1时,TTL会变为 0(网络上每经过一跳 TTL会减去 1),R1会将 TTL=0的数据包丢弃并返回一个 ICMP Time Exceeded给 Host A。Host A发出第二个数据包并将 TTL增加1(TTL=2),该数据包到达 R2后 TTL=0,R2向 Host A返回 ICMP Time Exceeded。依此类推,直到 TTL增加到一个合适的值让数据包顺利到达 Host B,Host B会返回一个 Final Replay给 Host A。UDP和 ICMP traceroute的区别就在于向外发送的数据包(上图中红色标明的 packet)和最后的 final reply。
TCP Traceroute同样利用了 TTL来探测网络路径但是它向外发送的是 TCP SYN数据包,这样做最大的好处就是穿透防火墙的几率更大因为 TCP SYN看起来是试图建立一个正常的 TCP连接。关于 Cisco的 traceroute更详细的资料可以参考 Cisco Using the traceroute Command on Operating Systems(Document ID:22826)。