trafficserver-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dia...@apache.org
Subject svn commit: r896690 [2/2] - in /incubator/trafficserver/site/trunk/docs/admin: Glossary.htm errors.htm hier.htm monitor.htm preface.htm
Date Wed, 06 Jan 2010 22:02:55 GMT
Modified: incubator/trafficserver/site/trunk/docs/admin/hier.htm
URL: http://svn.apache.org/viewvc/incubator/trafficserver/site/trunk/docs/admin/hier.htm?rev=896690&r1=896689&r2=896690&view=diff
==============================================================================
--- incubator/trafficserver/site/trunk/docs/admin/hier.htm (original)
+++ incubator/trafficserver/site/trunk/docs/admin/hier.htm Wed Jan  6 22:02:55 2010
@@ -1,123 +1,123 @@
-<html>
-<head>
-<title>Traffic Edge Administrator’s Guide</title>
-<meta content="text/html; charset=UTF-8" http-equiv="content-type"/>
-
-<link rel="stylesheet" href="doc.css" type="text/css" media="all" /></head>
-
-<body>
-<h1>Hierarchical Caching</h1>
-<p>Traffic Server can participate in cache hierarchies, wherein requests not fulfilled
in one cache are routed to other regional caches, taking advantage of the contents and proximity
of nearby caches. </p>
-<p>This chapter discusses the following topics: </p>
-<ul>
-<li><a href="#UnderstandingCacheHierarchies"><em>Understanding Cache Hierarchies</em></a></li>
-<li><a href="#ParentCaching"><em>Parent Caching</em></a></li>
-<li><a href="#ICPPeering"><em>ICP Peering</em></a></li>
-</ul>
-<h2 id="UnderstandingCacheHierarchies">Understanding Cache Hierarchies</h2>
-<p>A cache hierarchy consists of cache levels   that communicate with each other. Traffic
Server supports several types of cache hierarchies. All cache hierarchies recognize the concept
of <em>parent</em> and <em>child</em>. A parent cache is a cache higher
up in the hierarchy, to which Traffic Server can forward requests. A child cache is a cache
for which Traffic Server is a parent.  </p>
-<p>Traffic Server supports the following hierarchical caching options: </p>
-<ul>
-  <li><a href="#ParentCaching"><em>Parent Caching</em></a></li>
-  <li><a href="#ICPPeering"><em>ICP (Internet Cache Protocol) Peering</em></a></li>
-</ul>
-<h2 id="ParentCaching">Parent Caching</h2>
-<p>If a Traffic Server node cannot find a requested object in its cache, then it  searches
a parent cache (which itself can search other caches) before finally retrieving the object
from the origin server. You can configure a Traffic Server node to use one or more parent
caches so that if one parent is unavailable, then another parent is availale to service requests.
This is called<i> </i><a href="#ParentFailover"><em>Parent Failover</em></a>.
Traffic Server will support parent caching for HTTP and HTTPS requests. </p>
-<p><strong>Note:</strong> If you do not want all requests to go to the
parent cache, then simply configure Traffic Server to route certain requests (such as requests
 containing specific URLs) directly to the origin server. SImply set parent proxy rules in
 <a href="files.htm#150269"><em>parent.config</em></a>.</p>
-<p>The figure below illustrates a simple cache hierarchy with a Traffic Server node
 configured to use a parent cache. In the following scenario, a client sends a request to
a Traffic Server node that is a child in the cache hierarchy (because it's configured to forward
missed requests to a parent cache). The request is a cache miss, so  Traffic Server then forwards
the request to the parent cache, where it is a cache hit. The parent sends a copy of the content
to the Traffic Server, where it is cached and then served to the client. Future requests for
this content can now be served directly from the Traffic Server cache (until the data is stale
or expired).</p>
-<p><img src="images/cachehrc.jpg" width="848" height="572" /></p>
-<blockquote>
-  <p><em><b>Parent caching</b></em></p>
-</blockquote>
-<p><b>Note:</b> If the request is a cache miss on the parent, themn the
parent retrieves the content from the origin server (or from another cache, depending on the
parent’s configuration). The parent caches the content and then sends a copy to the Traffic
Server (its child), where it is cached and served to the client. </p>
-<h3 id="ParentFailover">Parent Failover</h3>
-<p>Traffic Server will support use of several parent caches so that if one parent cache
is not available, another parent cache can service client requests.  </p>
-<p>When you configure your Traffic Server to use more than one parent cache, Traffic
Server detects when a parent is not available and sends missed requests to another parent
cache. If you specify more than two parent caches, then the order in which the parent caches
are queried depends upon the parent proxy rules configured in the <a href="files.htm#150269"><em>parent.config</em></a>
configuration file. By default, the parent caches are queried in the order in which they are
listed in the configuration file. </p>
-<h3>Configuring Traffic Server to Use a Parent Cache  </h3>
-<p>To configure Traffic Server to use one or more parent caches, you must complete
the following steps: </p>
-<ul>
-  <li>Enable the parent caching option.  </li>
-  <li>Identify the parent cache you want to use to service missed requests. To use
<em>parent failover</em>, you must identify more than one parent cache so that
when a parent cache is unavailable, requests are sent to another parent cache.</li>
-</ul>
-<p><strong>Note:</strong> You need to configure the child cache only. No
additional configuration is needed for the Traffic Server parent cache. </p>
-<h5>Configure Traffic Server to use  a parent cache: </h5>
-<ol>
-  <li>In a text editor, open the <code>records.config</code> file located
in the Traffic Server <code>config</code> directory.  </li>
-  <li>Edit the following variable:</li>
-<br />
-<table width="1232" border="1">
-    <tr>
-      <th width="322" scope="col">Variable</th>
-      <th width="894" scope="col">Description</th>
-    </tr>
-    <tr>
-      <td><i><code>proxy.config.http.parent_proxy_routing_enable</code></i></td>
-      <td>Set this variable to 1 to enable the parent caching option.</td>
-  </tr>
-</table>
-<br />
-<li>Save and close the <code>records.config</code> file. </li>
-<li>In a text editor, open the <code>parent.config</code> file located
in the Traffic Server <code>config</code> directory. </li>
-<li>Set parent proxy rules to specify the parent cache to which you want missed requests
to be forwarded; refer to <a href="files.htm#150269"><em>parent.config</em></a>.
<br />
-  The following example configures Traffic Server to route all requests containing the regular
expression <code>politics</code> and the path <code>/viewpoint</code>
directly to the origin server (bypassing any parent hierarchies): <br /> <code>url_regex=politics
prefix=/viewpoint go_direct=true</code><br /><br />
-  The following example configures Traffic Server to direct all missed requests with URLs
beginning with <code>mms://host1</code> to the parent cache <code>parent1</code>.
If <code>parent1</code> cannot serve the requests, then requests are forwarded
to <code>parent2</code>. Because <code>round-robin=true</code>, Traffic
Server goes through the parent cache list in a round-robin based on client IP address. 
-  <br /><code>dest_host=host1 scheme=mms parent=”parent1;parent2” round-robin=strict</code><br
/><br />
-</li>
-<li>Save and close  <code>parent.config</code></li>
-<li>Navigate to the Traffic Server <code>bin</code> directory.</li>
-<li>Run the command <code>traffic_line -x</code> to apply the configuration
changes.</li>
-</ol>
-<h2 id="ICPPeering">ICP Peering</h2>
-<p>The Internet Cache Protocol (ICP) is used by proxy caches to exchange information
about their content. ICP query messages ask other caches if they are storing a particular
URL; ICP response messages reply with a hit or miss answer.  A cache exchanges ICP messages
only with specific <i>ICP peers</i>, which are neighboring caches that can receive
ICP messages. An ICP peer can be a <i>sibling cache</i> (which is at the same
level in the hierarchy) or a <i>parent cache</i> (which is one level up in the
hierarchy). </p>
-<p>If Traffic Server has ICP caching enabled, then it sends ICP queries to its ICP
peers when the HTTP request is a cache miss. If there are no hits but parents exist, then
a parent is selected using a round-robin policy. If no ICP parents exist, then Traffic Server
forwards the request to its HTTP parents. If there are no HTTP parent caches established,
then Traffic Server forwards the request to the origin server. </p>
-<p>If Traffic Server receives a hit message from an ICP peer, then Traffic Server sends
the HTTP request to that peer. However, it might turn out to be a cache miss because the original
HTTP request contains header information that is not communicated by the ICP query. For example,
the hit might not be the requested alternate. If an ICP hit turns out to be a miss, then Traffic
Server forwards the request to either its HTTP parent caches or to the origin server.  </p>
-<p>To configure a Traffic Server node to be part of an ICP cache hierarchy, you must
perform the following tasks: </p>
-<ul>
-  <li>Determine if the Traffic Server can receive ICP messages only, or if it can 
send <i>and</i> receive ICP messages. </li>
-  <li>Determine if Traffic Server can send messages directly to each ICP peer or send
a single message on a specified multicast channel. </li>
-  <li>Specify the port used for ICP messages. </li>
-  <li>Set the ICP query timeout. </li>
-  <li>Identify the ICP peers (siblings and parents) with which Traffic Server can communicate.</li>
-</ul>
-<h5>To configure Traffic Server to use an ICP cache hierarchy: </h5>
-<ol>
-  <li>In a text editor, open the <code>records.config</code> file located
in the Traffic Server <code>config</code> directory.  </li>
-  <li>Edit the following variables:</li>
-<br />
-<table width="1232" border="1">
-    <tr>
-      <th width="322" scope="col">Variable</th>
-      <th width="894" scope="col">Description</th>
-    </tr>
-    <tr>
-      <td><i><code>proxy.config.icp.enabled</code></i></td>
-      <td>Set this variable to:<br />
-     &nbsp;&nbsp;0 to disable ICP.<br />
-     &nbsp;&nbsp;1 to allow Traffic Server to receive ICP queries only.<br />
-     &nbsp;&nbsp;2 to allow Traffic Server to send and receive ICP queries.</td>
-    </tr>
-    <tr>
-      <td><i><code>proxy.config.icp.icp_port</code></i></td>
-      <td>Set this variable to specify the UDP port that you want to use for ICP messages.
The default is 3130. </td>
-    </tr>
-    <tr>
-      <td><i><code>proxy.config.icp.multicast_enabled</code></i></td>
-      <td>Set this variable to:<br />
-      &nbsp;&nbsp;0 to disable ICP multicast.<br />
-      &nbsp;&nbsp;1 to enable ICP multicast.</td>
-    </tr>
-    <tr>
-      <td><i><code>proxy.config.icp.query_timeout</code></i></td>
-      <td>Set this variable to specify the timeout used for ICP queries. The default
is 2 seconds.</td>
-    </tr>
-</table>
-<br />
-  <li>Save and close  <code>records.config</code></li>
-  <li>In a text editor, open the <code>icp.config</code> file located in
the Traffic Server <code>config</code> directory. </li>
-  <li>For each ICP peer you want to identify, enter a separate rule in the<code>
</code><a href="files.htm#115203"><em>icp.config</em></a> file.</li>
-  <li>Save and close  <code>icp.config</code></li>
-  <li>Navigate to the Traffic Server <code>bin</code> directory.  </li>
-  <li>Run the command <code>traffic_line -x</code> to apply the configuration
changes.</li>
-</ol>
-</body>  
+<html>
+<head>
+<title>Traffic Edge Administrator’s Guide</title>
+<meta content="text/html; charset=UTF-8" http-equiv="content-type"/>
+
+<link rel="stylesheet" href="doc.css" type="text/css" media="all" /></head>
+
+<body>
+<h1>Hierarchical Caching</h1>
+<p>Traffic Server can participate in cache hierarchies. Requests not fulfilled in one
cache are routed to other regional caches, thereby leveraging the contents and proximity of
nearby caches. </p>
+<p>This chapter discusses the following topics: </p>
+<ul>
+<li><a href="#UnderstandingCacheHierarchies">Understanding Cache Hierarchies</a></li>
+<li><a href="#ParentCaching">Parent Caching</a></li>
+<li><a href="#ICPPeering">ICP Peering</a></li>
+</ul>
+<h2 id="UnderstandingCacheHierarchies">Understanding Cache Hierarchies</h2>
+<p>A cache hierarchy consists of cache levels   that communicate with each other. Traffic
Server supports several types of cache hierarchies. All cache hierarchies recognize the concept
of <b>parent</b> and <b>child</b>. A parent cache is a cache higher
up in the hierarchy, to which Traffic Server can forward requests. A child cache is a cache
for which Traffic Server is a parent.  </p>
+<p>Traffic Server supports the following hierarchical caching options: </p>
+<ul>
+  <li><a href="#ParentCaching">Parent Caching</a></li>
+  <li><a href="#ICPPeering">ICP (Internet Cache Protocol) Peering</a></li>
+</ul>
+<h2 id="ParentCaching">Parent Caching</h2>
+<p>If a Traffic Server node cannot find a requested object in its cache, then it  searches
a parent cache (which itself can search other caches) before finally retrieving the object
from the origin server. You can configure a Traffic Server node to use one or more parent
caches so that if one parent is unavailable, then another parent is availale to service requests.
This is called <a href="#ParentFailover">Parent Failover</a>. Traffic Server will
support parent caching for HTTP and HTTPS requests. </p>
+<p><strong>Note:</strong> If you do not want all requests to go to the
parent cache, then simply configure Traffic Server to route certain requests (such as requests
 containing specific URLs) directly to the origin server. SImply set parent proxy rules in
 <a href="files.htm#150269">parent.config</a>.</p>
+<p>The figure below illustrates a simple cache hierarchy with a Traffic Server node
 configured to use a parent cache. In the following scenario, a client sends a request to
a Traffic Server node that is a child in the cache hierarchy (because it's configured to forward
missed requests to a parent cache). The request is a cache miss, so  Traffic Server then forwards
the request to the parent cache, where it is a cache hit. The parent sends a copy of the content
to the Traffic Server, where it is cached and then served to the client. Future requests for
this content can now be served directly from the Traffic Server cache (until the data is stale
or expired).</p>
+<p><img src="images/cachehrc.jpg" width="848" height="572" /></p>
+<blockquote>
+  <p><em><b>Parent caching</b></em></p>
+</blockquote>
+<p><b>Note:</b> If the request is a cache miss on the parent, then the
parent retrieves the content from the origin server (or from another cache, depending on the
parent’s configuration). The parent caches the content and then sends a copy to  Traffic
Server (its child), where it is cached and served to the client. </p>
+<h3 id="ParentFailover">Parent Failover</h3>
+<p>Traffic Server  supports use of several parent caches. This ensures that if one
parent cache is not available, another parent cache can service client requests.  </p>
+<p>When you configure your Traffic Server to use more than one parent cache, Traffic
Server detects when a parent is not available and sends missed requests to another parent
cache. If you specify more than two parent caches, then the order in which the parent caches
are queried depends upon the parent proxy rules configured in the <a href="files.htm#150269">parent.config</a>
configuration file. By default, the parent caches are queried in the order they are listed
in the configuration file. </p>
+<h3>Configuring Traffic Server to Use a Parent Cache  </h3>
+<p>To configure Traffic Server to use one or more parent caches, you must complete
the following steps: </p>
+<ul>
+  <li>Enable the parent caching option.  </li>
+  <li>Identify the parent cache you want to use to service missed requests. To use
<b>parent failover</b>, you must identify more than one parent cache so that when
a parent cache is unavailable, requests are sent to another parent cache.</li>
+</ul>
+<p><strong>Note:</strong> You need to configure the child cache only. No
additional configuration is needed for the Traffic Server parent cache. </p>
+<h5>Configure Traffic Server to use  a parent cache: </h5>
+<ol>
+  <li>In a text editor, open the <code>records.config</code> file located
in the Traffic Server <code>config</code> directory.  </li>
+  <li>Edit the following variable:</li>
+<br />
+<table width="1232" border="1">
+    <tr>
+      <th width="322" scope="col">Variable</th>
+      <th width="894" scope="col">Description</th>
+    </tr>
+    <tr>
+      <td><i><code>proxy.config.http.parent_proxy_routing_enable</code></i></td>
+      <td>Set this variable to 1 to enable the parent caching option.</td>
+  </tr>
+</table>
+<br />
+<li>Save and close the <code>records.config</code> file. </li>
+<li>In a text editor, open the <code>parent.config</code> file located
in the Traffic Server <code>config</code> directory. </li>
+<li>Set parent proxy rules to specify the parent cache to which you want missed requests
to be forwarded; refer to <a href="files.htm#150269">parent.config</a>. <br
/>
+  The following example configures Traffic Server to route all requests containing the regular
expression <code>politics</code> and the path <code>/viewpoint</code>
directly to the origin server (bypassing any parent hierarchies): <br /> <code>url_regex=politics
prefix=/viewpoint go_direct=true</code><br /><br />
+  The following example configures Traffic Server to direct all missed requests with URLs
beginning with <code>mms://host1</code> to the parent cache <code>parent1</code>.
If <code>parent1</code> cannot serve the requests, then requests are forwarded
to <code>parent2</code>. Because <code>round-robin=true</code>, Traffic
Server goes through the parent cache list in a round-robin based on client IP address. 
+  <br /><code>dest_host=host1 scheme=mms parent=”parent1;parent2” round-robin=strict</code><br
/><br />
+</li>
+<li>Save and close  <code>parent.config</code></li>
+<li>Navigate to the Traffic Server <code>bin</code> directory.</li>
+<li>Run the command <code>traffic_line -x</code> to apply the configuration
changes.</li>
+</ol>
+<h2 id="ICPPeering">ICP Peering</h2>
+<p>The Internet Cache Protocol (ICP) is used by proxy caches to exchange information
about their content. ICP query messages ask other caches if they are storing a particular
URL; ICP response messages reply with a hit or miss answer.  A cache exchanges ICP messages
only with specific <b>ICP peers</b>, which are neighboring caches that can receive
ICP messages. An ICP peer can be a <b>sibling cache </b>(which is at the same
level in the hierarchy) or a <b>parent cache</b> (which is one level up in the
hierarchy). </p>
+<p>If Traffic Server has ICP caching enabled, then it sends ICP queries to its ICP
peers when the HTTP request is a cache miss. If there are no hits but parents exist, then
a parent is selected using a round-robin policy. If no ICP parents exist, then Traffic Server
forwards the request to its HTTP parents. If there are no HTTP parent caches established,
then Traffic Server forwards the request to the origin server. </p>
+<p>If Traffic Server receives a hit message from an ICP peer, then Traffic Server sends
the HTTP request to that peer. However, it might turn out to be a cache miss because the original
HTTP request contains header information that is not communicated by the ICP query. For example,
the hit might not be the requested alternate. If an ICP hit turns out to be a miss, then Traffic
Server forwards the request to either its HTTP parent caches or to the origin server.  </p>
+<p>To configure a Traffic Server node to be part of an ICP cache hierarchy, you must
perform the following tasks: </p>
+<ul>
+  <li>Determine if the Traffic Server can receive ICP messages only, or if it can 
send <i>and</i> receive ICP messages. </li>
+  <li>Determine if Traffic Server can send messages directly to each ICP peer or send
a single message on a specified multicast channel. </li>
+  <li>Specify the port used for ICP messages. </li>
+  <li>Set the ICP query timeout. </li>
+  <li>Identify the ICP peers (siblings and parents) with which Traffic Server can communicate.</li>
+</ul>
+<h5>To configure Traffic Server to use an ICP cache hierarchy: </h5>
+<ol>
+  <li>In a text editor, open the <code>records.config</code> file located
in the Traffic Server <code>config</code> directory.  </li>
+  <li>Edit the following variables:</li>
+<br />
+<table width="1232" border="1">
+    <tr>
+      <th width="322" scope="col">Variable</th>
+      <th width="894" scope="col">Description</th>
+    </tr>
+    <tr>
+      <td><i><code>proxy.config.icp.enabled</code></i></td>
+      <td>Set this variable to:<br />
+     &nbsp;&nbsp;0 to disable ICP.<br />
+     &nbsp;&nbsp;1 to allow Traffic Server to receive ICP queries only.<br />
+     &nbsp;&nbsp;2 to allow Traffic Server to send and receive ICP queries.</td>
+    </tr>
+    <tr>
+      <td><i><code>proxy.config.icp.icp_port</code></i></td>
+      <td>Set this variable to specify the UDP port that you want to use for ICP messages.
The default is 3130. </td>
+    </tr>
+    <tr>
+      <td><i><code>proxy.config.icp.multicast_enabled</code></i></td>
+      <td>Set this variable to:<br />
+      &nbsp;&nbsp;0 to disable ICP multicast.<br />
+      &nbsp;&nbsp;1 to enable ICP multicast.</td>
+    </tr>
+    <tr>
+      <td><i><code>proxy.config.icp.query_timeout</code></i></td>
+      <td>Set this variable to specify the timeout used for ICP queries. The default
is 2 seconds.</td>
+    </tr>
+</table>
+<br />
+  <li>Save and close  <code>records.config</code></li>
+  <li>In a text editor, open the <code>icp.config</code> file located in
the Traffic Server <code>config</code> directory. </li>
+  <li>For each ICP peer you want to identify, enter a separate rule in the <a href="files.htm#115203">icp.config</a>
file.</li>
+  <li>Save and close  <code>icp.config</code></li>
+  <li>Navigate to the Traffic Server <code>bin</code> directory.  </li>
+  <li>Run the command <code>traffic_line -x</code> to apply the configuration
changes.</li>
+</ol>
+</body>  
 </html>
\ No newline at end of file

Modified: incubator/trafficserver/site/trunk/docs/admin/monitor.htm
URL: http://svn.apache.org/viewvc/incubator/trafficserver/site/trunk/docs/admin/monitor.htm?rev=896690&r1=896689&r2=896690&view=diff
==============================================================================
--- incubator/trafficserver/site/trunk/docs/admin/monitor.htm (original)
+++ incubator/trafficserver/site/trunk/docs/admin/monitor.htm Wed Jan  6 22:02:55 2010
@@ -1,56 +1,53 @@
-<html>
-<head>
-<title>Traffic Edge Administrator’s Guide</title>
-<meta content="text/html; charset=UTF-8" http-equiv="content-type"/>
-
-<link rel="stylesheet" href="doc.css" type="text/css" media="all" /></head>
-
-<body>
-<h1>Monitoring Traffic</h1>
-<p>Traffic Server provides several options for monitoring system performance and analyzing
network traffic.</p>
-<p>This chapter discusses the following topics:</p>
-<ul>
-<li><a href="#TrafficEdgeMonitoringTools"><em>Traffic Server Monitoring
Tools</em></a></li>
-<li><a href="#WorkingTrafficManagerAlarms"><em>Working with Traffic Manager
Alarms</em></a></li>
-<li><a href="#ViewingStatisticsTrafficLine"><em>Viewing Statistics from
Traffic Line</em></a></li> 
-</ul>
-<h2 id="TrafficEdgeMonitoringTools">Traffic Server Monitoring Tools</h2>
-<p> Traffic Server provides the following tools to monitor system performance and analyze
network traffic:</p>
-<ul>
- <li>Traffic Server  can send email that's triggered by alarms that signal any detected
failure conditions; refer to <a href="#WorkingTrafficManagerAlarms"><em>Working
with Traffic Manager Alarms</em></a>.</li>
- <li>The Traffic Line command-line interface provides an alternative method of viewing
Traffic Server performance and network traffic information; refer to <a href="#ViewingStatisticsTrafficLine"><em>Viewing
Statistics from Traffic Line</em></a>.</li>
- <li>The Traffic Shell command-line tool provides yet another alternative method of
viewing Traffic Server performance and network traffic information; refer to <a href="getstart.htm#StartingTrafficShell"><em>Starting
Traffic Shell</em></a>. </li>
-</ul>
-<h2 id="WorkingTrafficManagerAlarms">Working with Traffic Manager Alarms</h2>
-<p>Traffic Server signals an alarm when it detects a problem; for example, the space
allocated to event logs could be full or Traffic Server may not be able to write to a configuration
file.</p>
-<h3>Configuring Traffic Server to Email Alarms</h3>
-<p>To configure Traffic Server to send an email to a specific address whenever an alarm
occurs, follow the steps below:</p>
-<ol>
-  <li>In a text editor, open the <code>records.config</code> file located
in the Traffic Server <code>config</code> directory.</li>
-  <li>Set the  <code><i>proxy.config.alarm_email</i></code>
variable to the email address alarms will be routed to.</li>
-  <li>Save and close the <code>records.config</code> file.</li>
-  <li>Navigate to the Traffic Server <code>bin</code> directory. <br
/>
-  </li>
-  <li>Run the command <code>traffic_line -x</code> to apply the configuration
changes.</li>
-</ol>
-<h3>Using a Script File for Alarms</h3>
-<p>Alarm messages are built into Traffic Server - you cannot change them. However,
you can write a script file to execute certain actions when an alarm is signaled. Traffic
Server provides a sample script file named <code>example_alarm_bin.sh</code> in
the <code>bin</code> directory; simply modify the file to suit your needs.</p>
-<h2 id="ViewingStatisticsTrafficLine">Viewing Statistics from Traffic Line</h2>
-<p>As an alternative to using Traffic Manager, you can use the Traffic Line command-line
interface to view statistics about Traffic Server performance and web traffic. Traffic Line
provides a quick way of viewing Traffic Server statistics via command-line interface. In addition
to viewing statistics, you can also configure, stop, and restart the Traffic Server system.
For additional information, refer to <a href="configure.htm#ConfiguringTrafficEdgeUsingTrafficLine"><em>Configuring
Traffic Server Using Traffic Line</em></a> and <em><a href="cli.htm">Traffic
Line Commands</a></em>.  You can view specific information about a Traffic Server
node or cluster by specifying the variable that corresponds to the statistic you want to see.
-</p>
-<h5>To view a statistic:</h5>
-<ol>
- <li>Log on to a Traffic Server node as the Traffic Server administrator;   navigate
to the Traffic Server <code>bin</code> directory. <br />
- </li>
- <li>Enter the following command: <br />
- <code>traffic_line -r <em>variable</em></code><br />
- where <em><code>variable</code></em> is the variable  representing
the information you want to view. For a list of  variables you can specify, refer to <a
href="cli.htm#1025718"><em>Traffic Line Variables</em></a>. <br />
<br />
- For example, the following command displays the document hit rate for the Traffic Server
node: <br />
- <code>traffic_line -r proxy.node.http.cache_hit_ratio</code><br />
- <br />
- If the Traffic Server <code>bin</code> directory is not in your path, then prepend
the Traffic Line command with <code>./</code> (for example: <code>./traffic_line
-r <em>variable</em></code>).</li>
-</ol>
-
-
-</body>
+<html>
+<head>
+<title>Traffic Edge Administrator’s Guide</title>
+<meta content="text/html; charset=UTF-8" http-equiv="content-type"/>
+
+<link rel="stylesheet" href="doc.css" type="text/css" media="all" /></head>
+
+<body>
+<h1>Monitoring Traffic</h1>
+<p>Traffic Server provides several options for monitoring system performance and analyzing
network traffic.</p>
+<p>This chapter discusses the following topics:</p>
+<ul>
+<li><a href="#TrafficEdgeMonitoringTools">Traffic Server Monitoring Tools</a></li>
+<li><a href="#WorkingTrafficManagerAlarms">Working with Traffic Manager Alarms</a></li>
+<li><a href="#ViewingStatisticsTrafficLine">Viewing Statistics from Traffic Line</a></li>

+</ul>
+<h2 id="TrafficEdgeMonitoringTools">Traffic Server Monitoring Tools</h2>
+<p> Traffic Server provides the following tools to monitor system performance and analyze
network traffic:</p>
+<ul>
+ <li>Traffic Server  can send email that's triggered by alarms that signal any detected
failure conditions; refer to <a href="#WorkingTrafficManagerAlarms">Working with Traffic
Manager Alarms</a>.</li>
+ <li>The Traffic Line command-line interface provides an alternative method of viewing
Traffic Server performance and network traffic information; refer to <a href="#ViewingStatisticsTrafficLine">Viewing
Statistics from Traffic Line</a>.</li>
+ <li>The Traffic Shell command-line tool provides yet another alternative method of
viewing Traffic Server performance and network traffic information; refer to <a href="getstart.htm#StartingTrafficShell">Starting
Traffic Shell</a>.</li>
+</ul>
+<h2 id="WorkingTrafficManagerAlarms">Working with Traffic Manager Alarms</h2>
+<p>Traffic Server signals an alarm when it detects a problem. For example, the space
allocated to event logs could be full or Traffic Server may not be able to write to a configuration
file.</p>
+<h3>Configuring Traffic Server to Email Alarms</h3>
+<p>To configure Traffic Server to send an email to a specific address whenever an alarm
occurs, follow the steps below:</p>
+<ol>
+  <li>In a text editor, open the <code>records.config</code> file located
in the Traffic Server <code>config</code> directory.</li>
+  <li>Set the  <code><i>proxy.config.alarm_email</i></code>
variable to the email address alarms will be routed to.</li>
+  <li>Save and close the <code>records.config</code> file.</li>
+  <li>Navigate to the Traffic Server <code>bin</code> directory. <br
/>
+  </li>
+  <li>Run the command <code>traffic_line -x</code> to apply the configuration
changes.</li>
+</ol>
+<h3>Using a Script File for Alarms</h3>
+<p>Alarm messages are built into Traffic Server - you cannot change them. However,
you can write a script file to execute certain actions when an alarm is signaled. Traffic
Server provides a sample script file named <code>example_alarm_bin.sh</code> in
the <code>bin</code> directory; simply modify the file to suit your needs.</p>
+<h2 id="ViewingStatisticsTrafficLine">Viewing Statistics from Traffic Line</h2>
+<p>You can use the Traffic Line command-line interface to view statistics about Traffic
Server performance and web traffic. In addition to viewing statistics, you can also configure,
stop, and restart the Traffic Server system. For additional information, refer to <a href="configure.htm#ConfiguringTrafficEdgeUsingTrafficLine">Configuring
Traffic Server Using Traffic Line</a> and <a href="cli.htm">Traffic Line Commands</a>.
 You can view specific information about a Traffic Server node or cluster by specifying the
variable that corresponds to the statistic you want to see. </p>
+<h5>To view a statistic:</h5>
+<ol>
+ <li>Log on to a Traffic Server node as the Traffic Server administrator;   navigate
to the Traffic Server <code>bin</code> directory. <br />
+ </li>
+ <li>Enter the following command: <br />
+ <code>traffic_line -r <em>variable</em></code><br />
+ where <em><code>variable</code></em> is the variable  representing
the information you want to view. For a list of  variables you can specify, refer to <a
href="cli.htm#1025718">Traffic Line Variables</a>. <br /> <br />
+ For example, the following command displays the document hit rate for the Traffic Server
node: <br />
+ <code>traffic_line -r proxy.node.http.cache_hit_ratio</code><br />
+ <br />
+ If the Traffic Server <code>bin</code> directory is not in your path, then prepend
the Traffic Line command with <code>./</code> (for example: <code>./traffic_line
-r <em>variable</em></code>).</li>
+</ol>
+</body>
 </html>
\ No newline at end of file

Modified: incubator/trafficserver/site/trunk/docs/admin/preface.htm
URL: http://svn.apache.org/viewvc/incubator/trafficserver/site/trunk/docs/admin/preface.htm?rev=896690&r1=896689&r2=896690&view=diff
==============================================================================
--- incubator/trafficserver/site/trunk/docs/admin/preface.htm (original)
+++ incubator/trafficserver/site/trunk/docs/admin/preface.htm Wed Jan  6 22:02:55 2010
@@ -1,55 +1,56 @@
-<html>
-<head>
-<title>Traffic Edge Administrator’s Guide</title>
-<meta content="text/html; charset=UTF-8" http-equiv="content-type"/>
-
-<link rel="stylesheet" href="doc.css" type="text/css" media="all" /></head>
-
-<body>
-<h1>Preface</h1>
-<p>This manual describes how to use and configure Traffic Server<sup><font
size="-1"></font></sup>. </p>
-<p>For information about installing Traffic Server, refer to the <em>Traffic
Server Installation Guide</em>. For information about unsupported features and last-minute
information not available in this manual, refer to the <em>Release Notes</em>.
 The <i>Administrator's Guide</i> covers the following topics: </p>
-<ul>
-  <li><a href="intro.htm"><em>Chapter 1</em></a> provides an
overview of Traffic Server features and components. </li>
-  <li><a href="getstart.htm"><em>Chapter 2</em></a> through
<a href="log.htm"><em>Chapter 11</em></a> provide procedural information
about starting, monitoring, configuring, and maintaining Traffic Server. </li>
-  <li><a href="stats.htm"><em>Appendix A</em></a> through <a
href="errors.htm"><em>Appendix F</em></a> provide Traffic Server reference
information. </li>
-  <li><a href="trouble.htm"><em>Appendix G</em></a> discusses
frequently asked questions (FAQs) and provides troubleshooting tips. </li>
-  <li>The <a href="Glossary.htm"><em>Glossary</em></a> defines
terminology related to and used throughout this manual.</li>
-</ul>
-<h2>Who Should Read This Manual</h2>
-<p>This manual is intended for Traffic Server system administrators who configure,
run, and administer Traffic Server systems. To use this manual, you should understand web
proxy caching, TCP/IP network protocols, network administration and management, and the Linux
operating system. </p>
-<h2>Conventions Used in This Manual </h2>
-<p>This manual uses the following typographic conventions.</p>
-<table width="993" border="1">
-  <tr>
-    <th width="154" scope="col">Convention</th>
-    <th width="711" scope="col">Purpose</th>
-  </tr>
-  <tr>
-    <td><em>italic</em></td>
-    <td>Represents emphasis and introduces terms: for example, “the <em>reverse
proxy</em> option.”   </td>
-  </tr>
-  <tr>
-    <td><strong>bold</strong></td>
-    <td>Represents graphical user interface options and menu names: for example, click
the <strong>Protocols</strong> button.</td>
-  </tr>
-  <tr>
-    <td><pre>monospaced face</pre></td>
-    <td>Represents commands, filenames, file content, and computer input and output:
for example, “use the <code>reconfigure</code> command.”</td>
-  </tr>
-  <tr>
-    <td><pre><em>monospaced italic</em></pre></td>
-    <td>Represents variables for which you should substitute a value: for example,
“enter <code>filename</code>.” </td>
-  </tr>
-  <tr>
-    <td>brackets [ ]</td>
-    <td>Enclose optional command arguments in command syntax: for example, <code>add
<em>pathname</em> [<em>size</em>]</code>. </td>
-  </tr>
-  <tr>
-    <td>vertical line |</td>
-    <td>Separates value options in command syntax: for example, <code>open tcp|udp
ports <em>o_ports</em></code>.</td>
-  </tr>
-</table>
-
-</body>
+<html>
+<head>
+<title>Traffic Edge Administrator’s Guide</title>
+<meta content="text/html; charset=UTF-8" http-equiv="content-type"/>
+
+<link rel="stylesheet" href="doc.css" type="text/css" media="all" /></head>
+
+<body>
+<h1>Preface</h1>
+<p>This manual describes how to use and configure Traffic Server<sup><font
size="-1"></font></sup>. </p>
+<p>For information about installing Traffic Server, refer to the <em>Traffic
Server Installation Guide</em>. For information about unsupported features and last-minute
information not available in this manual, refer to the <em>Release Notes</em>.</p>
+<p> The <i>Traffic Server Administrator's Guide</i> covers the following
topics: </p>
+<ul>
+  <li><a href="intro.htm">Chapter 1</a> provides an overview of Traffic
Server features and components. </li>
+  <li><a href="getstart.htm">Chapter 2</a> through <a href="log.htm">Chapter
11</a> provide procedural information about starting, monitoring, configuring, and maintaining
Traffic Server. </li>
+  <li>The <a href="stats.htm">Appendices</a> provide Traffic Server reference
information. </li>
+  <li>The Troubleshooting <a href="trouble.htm">Appendix</a> discusses
frequently asked questions (FAQs) and provides troubleshooting tips. </li>
+  <li>The <a href="Glossary.htm">Glossary</a> defines terminology related
to and used throughout this manual.</li>
+</ul>
+<h2>Who Should Read This Manual</h2>
+<p>This manual is intended for Traffic Server system administrators who configure,
run, and administer Traffic Server systems. To use this manual, you should understand web
proxy caching, TCP/IP network protocols, network administration and management, and the Linux
operating system. </p>
+<h2>Conventions Used in This Manual </h2>
+<p>This manual uses the following typographic conventions.</p>
+<table width="993" border="1">
+  <tr>
+    <th width="154" scope="col">Convention</th>
+    <th width="711" scope="col">Purpose</th>
+  </tr>
+  <tr>
+    <td><em>italic</em></td>
+    <td>Represents emphasis and introduces terms: for example, “the <em>reverse
proxy</em> option.”   </td>
+  </tr>
+  <tr>
+    <td><strong>bold</strong></td>
+    <td>Represents graphical user interface options and menu names: for example, click
the <strong>Protocols</strong> button.</td>
+  </tr>
+  <tr>
+    <td><pre>monospaced face</pre></td>
+    <td>Represents commands, filenames, file content, and computer input and output:
for example, “use the <code>reconfigure</code> command.”</td>
+  </tr>
+  <tr>
+    <td><pre><em>monospaced italic</em></pre></td>
+    <td>Represents variables for which you should substitute a value: for example,
“enter <code>filename</code>.” </td>
+  </tr>
+  <tr>
+    <td>brackets [ ]</td>
+    <td>Enclose optional command arguments in command syntax: for example, <code>add
<em>pathname</em> [<em>size</em>]</code>. </td>
+  </tr>
+  <tr>
+    <td>vertical line |</td>
+    <td>Separates value options in command syntax: for example, <code>open tcp|udp
ports <em>o_ports</em></code>.</td>
+  </tr>
+</table>
+
+</body>
 </html>
\ No newline at end of file



Mime
View raw message