Find the answer to your Linux question:
Results 1 to 6 of 6
Thanks for looking. I am looking for a new command line tool to add into my Linux arsenal of trubleshooting. I often monitor LAN/WAN traffic and sometimes, the big solutions ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    May 2014
    Posts
    1

    Command line monitoring, mtr like but ongoing


    Thanks for looking.

    I am looking for a new command line tool to add into my Linux arsenal of trubleshooting.

    I often monitor LAN/WAN traffic and sometimes, the big solutions come into play, like nagios and other client/server setups. Sometimes however, I can't go installing lots of packages on some systems so need to rely on those nifty cool command line tools I can quickly yum or apt-get install to achieve similar results. The majority is the systems are debian BTW.

    My favorite tool is mtr to get some idea of the path to a server then maybe some other tool to see how bandwidth is doing. I often have to find problems over dedicated circuits for example. Using mtr and it's reporting function is great but it lacks long term current and historical details.

    I need something I can start from the command line, leave it running, letting it spew out ongoing stats without taking up a ton of network resources or upsetting some IT people because I am sending huge amounts of ICMP or other traffic to them. Being able to change the ports instead of using ICMP related ports would be killer.

    Maybe I could log into the Linux box to check the results or even have them emailed to me so I can take a look when I have a minute. Something which won't spew out gigs of data but would let me collect averages, store them into a file and keep on storing those averages so that maybe I could take a look at the overall results in a weeks time or something.

    The usual things are what I am looking for such as packet times, latency, hop changes, even bandwidth if I could do it without getting anyone upset by using which ever ports I need.

    I've been looking around for days and maybe I've missed some important results so I thought I might ask here and see if some of the guru's might have some thoughts on this.

    If you do, it certainly is much appreciated and thanks for your time!

  2. #2
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,677
    Look at wireshark.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  3. #3
    Just Joined!
    Join Date
    Apr 2008
    Posts
    44
    Quote Originally Posted by Rubberman View Post
    Look at wireshark.
    Wireshark is a great tool which I use all the time but it's not what I am asking about.

    One other way to put my question might have been, is there something I can pipe my mtr output into which might give me what I am looking for.

  4. $spacer_open
    $spacer_close
  5. #4
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,677
    Sorry, but I'm not familiar with mtr. I'll do some investigation to determine if that is possible however.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  6. #5
    Linux Newbie
    Join Date
    Jun 2012
    Location
    SF Bay area
    Posts
    196
    OK, I think I know what you're looking for. Twice now, for different jobs, I ended up writing scripts to read the output of looped "mtr" runs (with pauses between) to find when routes changed, when packet loss spiked, round trip times spiked, etc...

    I'll look to see if I can find a version that I can post, meaning any company specific stuff is removed. But in the meantime, I'll pass along some "lessons learned" from having used scripts like this before. One feature I ended up added were aliases that allow you to map lists of IP's (or domain names) to one "hop". Without it, ISP's that use multiple IP's for one router (or routers that are effectively the same) trigger the logic that looks for routing changes. If you write your own or find tools that look interesting, having a way to suppress noise like that is helpful.

    And another option that might be worth exploring is to use "traceroute" instead of "mtr" so you can use the "-A" option capture the AS numbers of all the hops along the way. Comparing those AS numbers instead of the actual IP numbers might prove more effective, since it will filter out some false positives.

    Also, if you want to capture effective bandwidth, running "curl" periodically is the best way to do it IMO. You can use the "-w" flag to output a variety of metrics from download speed to timers for different phases of the HTTP transaction (DNS, connect, first read from the server, etc...).

  7. #6
    Linux Newbie
    Join Date
    Jun 2012
    Location
    SF Bay area
    Posts
    196
    OK, I cleaned up a pair of scripts I wrote to capture "mtr" logs and then look for interesting data in the output. They are in a new Github repository at ~cnamejj sysops-scripts. The one that runs "mtr" (and "dig" to capture IP's) is called "periodic-mtr-with-dig". And the one to look through the output is called "filter-mtr-log".

    When I ran it on my home Ubuntu system to test it (after making edits to remove company specific stuff) I found that the format of "mtr" output on that system was different. So I had to tweak it to make it more flexible. If you try it and it doesn't work, post here or send e-mail and I'll see if your "mtr" output is confusing the script.

    The usability of the filtering script is correlated with how much you configure it to understand hostnames and IP's that are essentially equivalent. Check the source to see how it works and add in new patterns as you find them. In other words, you can refine it over time to ignore more and more false positives.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •