📄 monitoring.htm
字号:
<html>
<head>
<title>Monitoring your Network with Linux</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<script src="http://www.google-analytics.com/urchin.js" type="text/javascript">
</script>
<script type="text/javascript">
_uacct = "UA-129330-1";
urchinTracker();
</script>
</head>
<body bgcolor="#FFFFFF">
<center>
<p><font size="+1"><b>Monitoring your Network with Linux</b></font><br>
<font color="#9c9c9c" size="-1">by Roberto Lopez - Fri, 4 Feb
2000 10:35:29am</font>
</center>
<p> Whether you deploy a large or a medium size network within your enterprise,
you have probably experienced small problems like sporadically poor response
times and/or delays from your business applications. If your network is exceptionally
large (ranging from departmental LANs to interconnected remote locations) you
surely know of the implications of a lack of planning or anarchic growth. These
implications might include (but are not limited to): <br>
<ul>
<li>Constantly poor response time</li>
<br>
<li>Network outages</li>
<br>
<li>Ghost services running in your LAN</li>
</ul>
<br>
Such problems could prove fatal to your day to day operations. I'm sure you know
what downtime can mean to your business. Finding an immediate solution is not
always plausible but attempting to track the problem is an essential part of proper
system administration. There are some tools available for Linux that can help
you find your way to network stability. I plan to demonstrate how those tools
not only help system administrators but may also be useful for other staff members
who have a need to know what type of system resources need to be purchased, when
they need to be purchased and, finally, why they need to be purchased.. <br>
<br>
<b><u>MRTG</u></b> <br>
<br>
MRTG (<a href="http://www.mrtg.org">http://www.mrtg.org</a>) can monitor your
WAN links. You can also monitor network activity for a particular server if you
feel that is necessary. MRTG users SNMP (Single Network Management Protocol) to
perform such tasks. MRTG can monitor anything that supports SNMP (<a href="http://www.freesoft.org/CIE/RFC/1157/5.htm">http://www.freesoft.org/CIE/RFC/1157/5.htm</a>)
(e.g. server load, server uptime, etc.). <br>
<br>
MRTG provides a web interface that allows you to monitor your bandwidth <br>
utilization and keeps history on the behavior of your link. With this data, you
can perform one of the most importants task of an IT manager or consultant: <i>capacity
planning</i>. Under- or overestimating system resource utilization is quite common
when system monitors are not used. With MRTG you can predict, with some degree
of certainty, when you will need to make changes to your current bandwidth. <br>
<br>
Another advantage is the ability to track your need for <i>network traffic redistribution</i>.
With the help of MRTG, you should be able to notice under- or overutilization
of your link. Depending on how often you monitor (the default server monitoring
occurs every 5 minutes), it is possible for MRTG to give you the full picture
of your bandwidth utilization for any given day. <br>
<br>
In my opinion, the greatest advantage of MRTG is generates statistical graphics
- which you can publish to the web - to monitor your network from anywhere. Keeping
a "visual" history of bandwidth utilization gives you tremendous power to take
actions with the information. For example, statistical graphics can help you to
prove the need for a link upgrade or even a downgrade. <br>
<br>
MRTG may certainly change the perception that you have of your link(s) usage.
<br>
<br>
<b><u>NTOP</u></b> <br>
<br>
<a href="http://www.ntop.org/">NTOP</a> is helpful as an "emergency"
tool. When you are experiencing response time delays or you suspect that something
is wrong with your network, NTOP allows you to easily monitor the protocols running
on your LAN and to determine the utilization of each. <br>
<br>
NTOP comes very well when suspicious behavior is found on your network. Suppose
you have a set of local clients accessing a database on your LAN. They claim that
time response is very poor. You embark on a search to determine who or what is
to blame. You generally have 2 options: the application or the network. You ask
the application engineer(s) to determine that the application is OK. They determine
that it is. You move on to the network engineers who come to find out that you
have a very high retransmission packet rate caused by the server's faulty network
card (a problem to be detected by the sysadmin using standard linux/unix commands).
In a situation like this, it is likely that they were able to determine this by
using a tool like NTOP. Without the help of NTOP and similar tools, finding the
cause of the problem could have been extremely tedious. <br>
<br>
Some very useful sections of NTOP include: <br>
<br>
<ul>
<li>'Active TCP Sessions" - shows what is taking place on your network at that
specific moment. For example:<br>
<br>
<center>
<table width="80%" border="0" cellspacing="4" cellpadding="0">
<tr valign="top">
<td width="16%">Client</td>
<td width="14%">Server </td>
<td width="14%">Data Sent</td>
<td width="14%">Data Rcvd</td>
<td width="14%">Active Since</td>
<td width="14%">Last Seen</td>
<td width="14%">Duration
</tr>
<tr valign="top">
<td width="16%">123.231.213.1</td>
<td width="14%"> mail_server</td>
<td width="14%">3.6 MB</td>
<td width="14%">3.8 MB 12/08/99</td>
<td width="14%">19:40:01</td>
<td width="14%">12/20/99 20:47:31</td>
<td width="14%">12 day(s) 1:07:02</td>
</tr>
</table>
</center>
<br>
All this information can be accessed using any standard web browser. To have
enough information to work on, you may wish to run NTOP for at least a couple
of days (non-stop) in a production environment. (This may vary depending on
the size of your network. For a medium departmental LAN, a couple of days
should be fine).</li>
<br>
<br>
<li>'Connection Matrix' - shows which station is talking to what <br>
server and the amount of traffic being exchanged</li>
<br>
<br>
<li>Monitoring of the most intensive bandwidth senders and receivers - Heavy
traffic is not only caused by physical media but also by other system intensive
actions (e.g. users downloading large files). This can cause severe bottlenecks
to your LAN.</li>
</ul>
<br>
<br>
The NTOP data presentation is impressive. Bar and Pie charts are used to demonstrate
protocol utilization and packet size distribution. Data gathered from the monitoring
can be logged in a file for posterior plotting using any spreadsheet application
such as Sun's <a href="http://www.sun.com/products/staroffice/get.cgi">Star Office</a>.
If you want to keep all of the information stored for future structured retrieval,
NTOP gives you the option to store it in a SQL database. <br>
<br>
The author of NTOP has created an excellent document describing how NTOP can be
used to measure network traffic. This document can be found at <a href="http://jake.unipi.it/~deri/ntop_IEEE.pdf.gz">http://jake.unipi.it/~deri/ntop_IEEE.pdf.gz</a>.
<br>
<br>
<b><u>Conclusion</u></b> <br>
<br>
Finding network problems does not necessarily lead to instant solutions. Correct
interpretation is still needed. Sometimes it can be frustrating to have a lot
of information without finding the answer to your problems. That why this task
should be taken by a network professional. However, network monitoring can truly
be an asset to your corporation as a whole.
</body>
</html>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -