You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@trafficserver.apache.org by di...@apache.org on 2010/01/08 23:15:51 UTC
svn commit: r897335 - /incubator/trafficserver/site/trunk/docs/admin/log.htm
Author: dianes
Date: Fri Jan 8 22:15:50 2010
New Revision: 897335
URL: http://svn.apache.org/viewvc?rev=897335&view=rev
Log:
minor edits, grammar, formatting corrections
Modified:
incubator/trafficserver/site/trunk/docs/admin/log.htm
Modified: incubator/trafficserver/site/trunk/docs/admin/log.htm
URL: http://svn.apache.org/viewvc/incubator/trafficserver/site/trunk/docs/admin/log.htm?rev=897335&r1=897334&r2=897335&view=diff
==============================================================================
--- incubator/trafficserver/site/trunk/docs/admin/log.htm (original)
+++ incubator/trafficserver/site/trunk/docs/admin/log.htm Fri Jan 8 22:15:50 2010
@@ -10,67 +10,74 @@
<p>Traffic Server generates log files that contain information about every request it receives and every error it detects.</p>
<p>This chapter discusses the following topics: </p>
<ul>
-<li><a href="#UnderstandingTrafficEdgeLogFiles"><em>Understanding Traffic Server Log Files</em></a></li>
-<li><a href="#UnderstandingEventLogFiles"><em>Understanding Event Log Files</em></a></li>
-<li><a href="#ManagingEventLogFiles"><em>Managing Event Log Files</em></a></li>
-<li><a href="#ChoosingEventLogFileFormats"><em>Choosing Event Log File Formats</em></a></li>
-<li><a href="#RollingEventLogFiles"><em>Rolling Event Log Files</em></a></li>
-<li><a href="#SplittingEventLogFiles"><em>Splitting Event Log Files</em></a></li>
-<li><a href="#CollatingEventLogFiles"><em>Collating Event Log Files</em></a></li>
-<li><a href="#ViewingLoggingStatistics"><em>Viewing Logging Statistics</em></a></li>
-<li><a href="#ViewingLogFiles"><em>Viewing Log Files</em></a></li>
-<li><a href="#ExampleEventLogFileEntries"><em>Example Event Log File Entries</em></a></li>
-<li><a href="#SupportTraditionalCustomLogging"><em>Support for Traditional Custom Logging</em></a></li>
+<li><a href="#UnderstandingTrafficEdgeLogFiles">Understanding Traffic Server Log Files</a></li>
+<li><a href="#UnderstandingEventLogFiles">Understanding Event Log Files</a></li>
+<li><a href="#ManagingEventLogFiles">Managing Event Log Files</a></li>
+<li><a href="#ChoosingEventLogFileFormats">Choosing Event Log File Formats</a></li>
+<li><a href="#RollingEventLogFiles">Rolling Event Log Files</a></li>
+<li><a href="#SplittingEventLogFiles">Splitting Event Log Files</a></li>
+<li><a href="#CollatingEventLogFiles">Collating Event Log Files</a></li>
+<li><a href="#ViewingLoggingStatistics">Viewing Logging Statistics</a></li>
+<li><a href="#ViewingLogFiles">Viewing Log Files</a></li>
+<li><a href="#ExampleEventLogFileEntries">Example Event Log File Entries</a></li>
+<li><a href="#SupportTraditionalCustomLogging">Support for Traditional Custom Logging</a></li>
</ul>
<h2 id="UnderstandingTrafficEdgeLogFiles">Understanding Traffic Server Log Files</h2>
<p>Traffic Server records information about every transaction (or request) it processes and every error it detects in log files. Traffic Server keeps three types of log files: </p>
<ul>
- <li><em>Error log files</em> record information about why a particular transaction was in error. </li>
- <li><em>Event log files</em> (also called <em>access log files</em>) record information about the state of each transaction that Traffic Server processes. </li>
- <li><em>System log files</em> record system information, including messages about the state of Traffic Server and errors or warnings it produces. This kind of information might include a note that event log files were rolled, a warning that cluster communication timed out, or an error indicating that Traffic Server was restarted. Traffic Server posts alarms signifying error conditions in Traffic Manager; refer to <a href="monitor.htm#WorkingTrafficManagerAlarms"><em>Working with Traffic Manager Alarms</em></a> for details. <br />
+ <li><b>Error log files</b> record information about why a particular transaction was in error. </li>
+ <li><b>Event log files</b> (also called <b>access log files</b>) record information about the state of each transaction Traffic Server processes. </li>
+ <li><b>System log files</b> record system information, including messages about the state of Traffic Server and errors/warnings it produces. This kind of information might include a note that event log files were rolled, a warning that cluster communication timed out, or an error indicating that Traffic Server was restarted. <br />
All system information messages are logged with the system-wide logging facility <b><code>syslog</code></b> under the daemon facility. The <code>syslog.conf</code> configuration file (stored in the <code>/etc</code> directory) specifies where these messages are logged. A typical location is <code>/var/log/messages</code> (Linux). <br />
The <code>syslog</code> process works on a system-wide basis, so it serves as the single repository for messages from all Traffic Server processes (including <code>traffic_server</code>, <code>traffic_manager</code>, and <code>traffic_cop</code>). <br />
System information logs observe a static format. Each log entry in the log contains information about the date and time the error was logged, the hostname of the Traffic Server that reported the error, and a description of the error or warning. <br />
- Refer to <em><a href="errors.htm">Traffic Server Error Messages</a></em> for a list of the messages logged by Traffic Server. </li>
+ Refer to <a href="errors.htm">Traffic Server Error Messages</a> for a list of the messages logged by Traffic Server. </li>
+</ul>
+<p>By default, Traffic Server creates both error and event log files and records system information in system log files. You can disable event logging and/or error logging by setting the configuration variable <code><i>proxy.config.log2.logging_enabled</i></code> (in the <code>records.config</code> file) to one of the following values: <ul>
+
+ <li><code>0</code> to disable both event and error logging </li>
+ <li><code>1</code> to enable error logging only </li>
+ <li><code>2</code> to enable transaction logging only </li>
+ <li><code>3</code> to enable both transaction and error logging</li>
</ul>
-<p>By default, Traffic Server creates both error and event log files and records system information in system log files. You can disable event logging and/or error logging by setting the configuration variable <code><i>proxy.config.log2.logging_enabled</i></code> (in the <code>records.config</code> file) to one of the following values: <code>0</code> to disable both event and error logging, <code>1</code> to enable error logging only, <code>2</code> to enable transaction logging only, or <code>3</code> to enable both transaction and error logging. </p>
<h2 id="UnderstandingEventLogFiles">Understanding Event Log Files</h2>
-<p>Event log files record information about every request that Traffic Server processes. By analyzing the log files, you can determine how many people use the Traffic Server cache, how much information each person requested, what pages are most popular, and so on. Traffic Server supports several standard log file formats, such as Squid and Netscape, and user-defined custom formats. You can analyze the standard format log files with off-the-shelf analysis packages. To help with log file analysis, you can separate log files so that they contain information specific to protocol or hosts. You can also configure Traffic Server to roll log files automatically at specific intervals during the day or when they reach a certain size.</p>
+<p>Event log files record information about every request that Traffic Server processes. By analyzing the log files, you can determine how many people use the Traffic Server cache, how much information each person requested, what pages are most popular, and so on. Traffic Server supports several standard log file formats, such as Squid and Netscape, as well as user-defined custom formats. You can analyze the standard format log files with off-the-shelf analysis packages. To help with log file analysis, you can separate log files so they contain information specific to protocol or hosts. You can also configure Traffic Server to roll log files automatically at specific intervals during the day or when they reach a certain size.</p>
<p>The following sections describe the Traffic Server logging system features and discuss how to:</p>
<ul>
<li><b>Manage your event log files</b><br />
- You can choose a central location for storing log files, set how much disk space to use for log files, and set how and when to roll log files; refer to <a href="#ManagingEventLogFiles"><em>Managing Event Log Files</em></a>. </li>
+ You can choose a central location for storing log files, set how much disk space to use for log files, and set how and when to roll log files. Refer to <a href="#ManagingEventLogFiles">Managing Event Log Files</a>. </li>
<li><b>Choose different event log file formats </b><br />
- You can choose which standard log file formats you want to use for traffic analysis: for example, Squid or Netscape. Alternatively, you can use the Traffic Server custom format, which is XML-based and enables you to institute more control over the type of information recorded in log files. Refer to <a href="#ChoosingEventLogFileFormats"><em>Choosing Event Log File Formats</em></a>. <br />
+ You can choose which standard log file formats you want to use for traffic analysis, such as Squid or Netscape. Alternatively, you can use the Traffic Server custom format, which is XML-based and enables you to institute more control over the type of information recorded in log files. Refer to <a href="#ChoosingEventLogFileFormats">Choosing Event Log File Formats</a>. <br />
</li>
<li><b>Roll event log files automatically</b><br />
- You can configure Traffic Server to roll event log files when they reach a certain size or at specific intervals during the day so that you can identify and manipulate log files that are no longer active; refer to <a href="#RollingEventLogFiles"><em>Rolling Event Log Files</em></a>. </li>
+
+ Configure Traffic Server to roll event log files at specific intervals during the day or when they reach a certain size; this enables you to identify and manipulate log files that are no longer active. Refer to <a href="#RollingEventLogFiles">Rolling Event Log Files</a>. </li>
<li><b>Separate log files according to protocols and hosts</b><br />
- You can configure Traffic Server to create separate log files for different protocols. You can also configure Traffic Server to generate separate log files for requests served by different hosts; refer to <a href="#SplittingEventLogFiles"><em>Splitting Event Log Files</em></a>. </li>
+ Configure Traffic Server to create separate log files for different protocols. You can also configure Traffic Server to generate separate log files for requests served by different hosts. Refer to <a href="#SplittingEventLogFiles">Splitting Event Log Files</a>. </li>
<li><b>Collate log files from different Traffic Server nodes</b><br />
- You can designate one or more nodes on the network to serve as log collation servers. These servers, which might either be standalone or part of Traffic Server, enable you to keep all logged information in well-defined locations; refer to <a href="#CollatingEventLogFiles"><em>Collating Event Log Files</em></a>. </li>
+ Designate one or more nodes on the network to serve as log collation servers. These servers, which might be standalone or part of Traffic Server, enable you to keep all logged information in well-defined locations. Refer to <a href="#CollatingEventLogFiles">Collating Event Log Files</a>. </li>
<li><b>View statistics about the logging system</b><br />
- Traffic Server provides statistics about the logging system. You can access the statistics through Traffic Manager or through Traffic Line; refer to <a href="#ViewingLoggingStatistics"><em>Viewing Logging Statistics</em></a>. </li>
- <li><b>Interpret log file entries for the log file formats</b>; refer to <a href="#ExampleEventLogFileEntries"><em>Example Event Log File Entries</em></a>. </li>
+ Traffic Server provides statistics about the logging system; you can access these statistics via Traffic Line. Refer to <a href="#ViewingLoggingStatistics">Viewing Logging Statistics</a>. </li>
+ <li><b>Interpret log file entries for the log file formats</b><br />
+ Refer to <a href="#ExampleEventLogFileEntries">Example Event Log File Entries</a>. </li>
</ul>
<h2 id="ManagingEventLogFiles">Managing Event Log Files</h2>
-<p>You can manage your event log files and control where they are located, how much space they can consume, and how low disk space in the logging directory is handled. </p>
+<p>Traffic Server enables you to control where event log files are located and how much space they can consume. Additionally you can specify how to handle low disk space in the logging directory. </p>
<h3>Choosing the Logging Directory </h3>
-<p>By default, Traffic Server writes all event log files in the <code>logs</code> directory located in the directory where you installed Traffic Server. To use a different directory, refer to <a href="#SettingLogFileManagementOptions"><em>Setting Log File Management Options</em></a>. </p>
+<p>By default, Traffic Server writes all event log files in the <code>logs</code> directory located in the directory where you installed Traffic Server. To use a different directory, refer to <a href="#SettingLogFileManagementOptions">Setting Log File Management Options</a>. </p>
<h3>Controlling Logging Space </h3>
-<p>Traffic Server enables you to control the amount of disk space that the logging directory can consume. This allows the system to operate smoothly within a specified space window for a long period of time. After you establish a space limit, Traffic Server continues to monitor the space in the logging directory. When the free space dwindles to the headroom limit (see <a href="#SettingLogFileManagementOptions"><em>Setting Log File Management Options</em></a>), it enters a low space state and takes the following actions: </p>
+<p>Traffic Server enables you to control the amount of disk space that the logging directory can consume. This allows the system to operate smoothly within a specified space window for a long period of time. After you establish a space limit, Traffic Server continues to monitor the space in the logging directory. When the free space dwindles to the headroom limit (see <a href="#SettingLogFileManagementOptions">Setting Log File Management Options</a>), it enters a low space state and takes the following actions: </p>
<ul>
- <li>If the autodelete option (discussed in <a href="#RollingEventLogFiles"><em>Rolling Event Log Files</em></a>) is <em>enabled</em>, then Traffic Server identifies previously rolled log files (log files with the <code>.old</code> extension). It starts deleting files one by one, beginning with the oldest file, until it emerges from the low state. Traffic Server logs a record of all files it deletes in the system error log. </li>
- <li>If the autodelete option is <em>disabled</em> or there are not enough old log files to delete for the system to emerge from its low space state, then Traffic Server issues a warning and continues logging until space is exhausted, at which point it stops event logging. Traffic Server resumes event logging when enough space becomes available for it to exit its low space state. You can make space available either by removing files from the logging directory manually or by explicitly increasing the logging space limit. </li>
+ <li>If the autodelete option (discussed in <a href="#RollingEventLogFiles">Rolling Event Log Files</a>) is <em>enabled</em>, then Traffic Server identifies previously-rolled log files (i.e., log files with the <code>.old</code> extension). It starts deleting files one by one, beginning with the oldest file, until it emerges from the low state. Traffic Server logs a record of all deleted files in the system error log. </li> </br>
+ <li>If the autodelete option is <em>disabled</em> or there are not enough old log files to delete for the system to emerge from its low space state, then Traffic Server issues a warning and continues logging until space is exhausted. When avilable space is consumed, event logging stops. Traffic Server resumes event logging when enough space becomes available for it to exit the low space state. To make space available, either explicitly increase the logging space limit or remove files from the logging directory manually. </li>
</ul>
-<p>You can run a <code>cron</code> script in conjunction with Traffic Server to automatically remove old log files from the logging directory (before Traffic Server enters the low space state) and relocate them to a temporary partition. Once the files are relocated, you can run a variety of log analysis scripts on them. Then you can compress the logs and move to an archive location, or simply delete them. </p>
+<p>You can run a <code>cron</code> script in conjunction with Traffic Server to automatically remove old log files from the logging directory before Traffic Server enters the low space state. Relocate the old log files to a temporary partition, where you can run a variety of log analysis scripts. Following analysis, either compress the logs and move to an archive location, or simply delete them. </p>
<h3 id="SettingLogFileManagementOptions">Setting Log File Management Options </h3>
<p>To set log management options, follow the steps below:</p>
<ol>
<li>In a text editor, open the <code>records.config</code> file located in the <code>config</code> directory. </li>
<li>Edit the following variables: </li>
- <br />
-<table width="1232" border="1">
+ <table width="1232" border="1">
<tr>
<th width="322" scope="col">Variable</th>
<th width="894" scope="col">Description</th>
@@ -90,7 +97,6 @@
<td>Enter the tolerance for the log space limit. The default value is 10 MB.</td>
</tr>
</table>
-<br />
<li>Save and close the <code>records.config</code> file. </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>
@@ -98,20 +104,19 @@
<h2 id="ChoosingEventLogFileFormats">Choosing Event Log File Formats</h2>
<p>Traffic Server supports the following log file formats: </p>
<ul>
- <li>Standard formats, such as Squid or Netscape; refer to <a href="#UsingStandardFormats"><em>Using Standard Formats</em></a>. </li>
- <li>The Traffic Server custom format; refer to <a href="#UsingCustomFormat"><em>Using the Custom Format</em></a>. </li>
+ <li>Standard formats, such as Squid or Netscape; refer to <a href="#UsingStandardFormats">Using Standard Formats</a>. </li>
+ <li>The Traffic Server custom format; refer to <a href="#UsingCustomFormat">Using the Custom Format</a>. </li>
</ul>
-<p>In addition to the standard and custom log file format, you can choose whether to save log files in binary or ASCII; refer to <a href="#ChoosingBinaryASCII"><em>Choosing Binary or ASCII</em></a>. <br />
- Event log files consume substantial disk space. Creating log entries in multiple formats at the same time can consume disk resources very quickly and adversely impact Traffic Server performance. </p>
+<p>In addition to the standard and custom log file format, you can choose whether to save log files in binary or ASCII; refer to <a href="#ChoosingBinaryASCII">Choosing Binary or ASCII</a>. <br />
+Event log files consume substantial disk space. Creating log entries in multiple formats at the same time can consume disk resources very quickly and adversely impact Traffic Server performance. </p>
<h3 id="UsingStandardFormats">Using Standard Formats </h3>
-<p>The standard log formats include Squid, Netscape Common, Netscape extended, and Netscape Extended-2. The standard log file formats can be analyzed with a wide variety of off-the-shelf log-analysis packages. You should use one of the standard event log formats unless you need information that these formats do not provide. Refer to <a href="#UsingCustomFormat"><em>Using the Custom Format</em></a>.</p>
+<p>The standard log formats include Squid, Netscape Common, Netscape extended, and Netscape Extended-2. The standard log file formats can be analyzed with a wide variety of off-the-shelf log-analysis packages. You should use one of the standard event log formats unless you need information that these formats do not provide. Refer to <a href="#UsingCustomFormat">Using the Custom Format</a>.</p>
<h4 id="SettingStandardLogFileFormatOptions">Setting Standard Log File Format Options </h4>
<p>Set standard log file format options by following the steps below:</p>
<ol>
<li>In a text editor, open the <code>records.config</code> file located in the <code>config</code> directory. </li>
<li>To use the Squid format, edit the following variables:</li>
- <br />
-<table width="1232" border="1">
+ <table width="1232" border="1">
<tr>
<th width="322" scope="col">Variable</th>
<th width="894" scope="col">Description</th>
@@ -133,10 +138,8 @@
<td>Enter the header text you want to display at the top of the Squid log files. Enter <code>NULL</code> if you do not want to use a header. </td>
</tr>
</table>
-<br />
<li>To use the Netscape Common format, edit the following variables: </li>
- <br />
-<table width="1232" border="1">
+ <table width="1232" border="1">
<tr>
<th width="322" scope="col">Variable</th>
<th width="894" scope="col">Description</th>
@@ -158,10 +161,8 @@
<td>Enter the header text you want to display at the top of the Netscape Common log files. Enter <code>NULL</code> if you do not want to use a header.</td>
</tr>
</table>
-<br />
<li>To use the Netscape Extended format, edit the following variables: </li>
- <br />
-<table width="1232" border="1">
+ <table width="1232" border="1">
<tr>
<th width="322" scope="col">Variable</th>
<th width="894" scope="col">Description</th>
@@ -183,10 +184,8 @@
<td>Enter the header text you want to display at the top of the Netscape Extended log files. Enter <code>NULL</code> if you do not want to use a header.</td>
</tr>
</table>
-<br />
<li>To use the Netscape Extended-2 format, edit the following variables:</li>
- <br />
-<table width="1232" border="1">
+ <table width="1232" border="1">
<tr>
<th width="322" scope="col">Variable</th>
<th width="894" scope="col">Description</th>
@@ -208,27 +207,26 @@
<td>Enter the header text you want to display at the top of the Netscape Extended-2 log files. Enter <code>NULL</code> if you do not want to use a header.</td>
</tr>
</table>
-<br />
- <li>Save and close the <code>records.config</code> file. </li>
+<li>Save and close the <code>records.config</code> file. </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>
<h3 id="UsingCustomFormat">Using the Custom Format</h3>
-<p>The XML-based custom log format is more flexible then the standard log file formats, and gives you more control over the type of information recorded in your log files. You should create a custom log format if you need data for analysis that's not available in the standard formats. You can decide what information to record for each Traffic Server transaction and create filters to define which transactions to log. </p>
+<p>The XML-based custom log format is more flexible then the standard log file formats and gives you more control over the type of information recorded in log files. You should create a custom log format if you need data for analysis that's not available in the standard formats. You can decide what information to record for each Traffic Server transaction and create filters that specify which transactions to log. </p>
<p>The heart of the XML-based custom logging feature is the XML-based logging configuration file (<code>logs_xml.config</code>) that enables you to create very modular descriptions of logging objects. The <code>logs_xml.config</code> file uses three types of objects to create custom log files, as detailed below. To generate a custom log format, you must specify at least one <code>LogObject</code> definition (one log file is produced for each <code>LogObject</code> definition). </p>
<ul>
- <li>The <code>LogFormat</code> object defines the content of the log file using print-style format strings. </li>
- <li>The <code>LogFilter</code> object defines a filter so that you include or exclude certain information from the log file. </li>
- <li>The <code>LogObject</code> object specifies all the information needed to produce a log file: </li>
+ <li>The <code><b>LogFormat</b></code> object defines the content of the log file using printf-style format strings. </li>
+ <li>The <code><b>LogFilter</b></code> object defines a filter so that you include or exclude certain information from the log file. </li>
+ <li>The <code><b>LogObject</b></code> object specifies all the information needed to produce a log file. Items marked with an asterisk (*) are required.</li>
<ul>
- <li>The name of the log file (required). </li>
- <li>The format to be used (required). This can be a standard format (Squid or Netscape) or a previously defined custom format (a previously defined <code>LogFormat</code> object). </li>
- <li>The file mode (ASCII, Binary, or ASCII_PIPE). The default is ASCII. <br />
- The ASCII_PIPE mode writes log entries to a UNIX-named pipe (a buffer in memory). Other processes can then read the data using standard I/O functions. The advantage of using this option is that Traffic Server does not have to write to disk, which frees disk space and bandwidth for other tasks. When the buffer is full, Traffic Server drops log entries and issues an error message indicating how many entries were dropped. Traffic Server writes only complete log entries to the pipe, therefore, only full records are dropped. </li>
- <li>Any filters you want to use (previously defined <code>LogFilter</code> objects). </li>
+ <li>*The name of the log file. </li>
+ <li>*The format to be used. This can be a standard format (Squid or Netscape) or a previously-defined custom format (i.e., a previously-defined <code>LogFormat</code> object). </li>
+ <li>The file mode: <code>ASCII</code>, <code>Binary</code>, or <code>ASCII_PIPE</code>. The default is <code>ASCII</code>. <br />
+ The <code>ASCII_PIPE</code> mode writes log entries to a UNIX-named pipe (a buffer in memory); other processes can then read the data using standard I/O functions. The advantage of this option is that Traffic Server does not have to write to disk, which frees disk space and bandwidth for other tasks. When the buffer is full, Traffic Server drops log entries and issues an error message indicating how many entries were dropped. Because Traffic Server only writes complete log entries to the pipe, only full records are dropped. </li>
+ <li>Any filters you want to use (i.e., previously-defined <code>LogFilter</code> objects). </li>
<li>The collation servers that are to receive the log files. </li>
- <li>The protocols you want to log (if the protocols tag is used, then Traffic Server will only log transactions from the protocols listed; otherwise, all transactions for all protocols are logged). </li>
- <li>The origin servers you want to log (if the servers tag is used, then Traffic Server will only log transactions for the origin servers listed; otherwise, transactions for all origin servers are logged). </li>
+ <li>The protocols you want to log. If the protocols tag is used, then Traffic Server will only log transactions from the protocols listed; otherwise, all transactions for all protocols are logged. </li>
+ <li>The origin servers you want to log. If the <code>servers</code> tag is used, then Traffic Server will only log transactions for the origin servers listed; otherwise, transactions for all origin servers are logged. </li>
<li>The header text you want the log files to contain. The header text appears at the beginning of the log file, just before the first record. </li>
<li>The log file rolling options.</li>
</ul>
@@ -237,8 +235,7 @@
<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">
+ <table width="1232" border="1">
<tr>
<th width="322" scope="col">Variable</th>
<th width="894" scope="col">Description</th>
@@ -252,17 +249,16 @@
<td>Make sure this variable is set to 1 (the default value).</td>
</tr>
</table>
-<br />
<li>Save and close the <code>records.config</code> file. </li>
<li>Open the <code>logs_xml.config</code> file located in the Traffic Server <code>config</code> directory. </li>
- <li>Add <code>LogFormat</code>, <code>LogFilter</code>, and <code>LogObject</code> specifications to the configuration file. See <a href="files.htm#131440"><em>logs_xml.config</em></a> for detailed information about this file.</li>
- <li>Save and close the <code>logs_xml.config</code> file. </li>
+ <li>Add <code>LogFormat</code>, <code>LogFilter</code>, and <code>LogObject</code> specifications to the configuration file. For detailed information about this file, see <a href="files.htm#131440">logs_xml.config</a>.</li>
+ <li>Save and close the <code>log</code><code>s_xml.config</code> file. </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>
+ <li>Run the command <code>traffic_line -x</code> to apply your configuration changes. </li>
</ol>
<h4>Creating Summary Log Files </h4>
<p>Traffic Server performs several hundred operations per second; therefore, event log files can quickly grow to large sizes. Using SQL-like aggregate operators, you can configure Traffic Server to create summary log files that summarize a set of log entries over a specified period of time. This can significantly reduce the size of the log files generated. </p>
-<p>To generate a summary log file, create a <code>LogFormat</code> object in the XML-based logging configuration file (<code>logs_xml.config</code>) using the following SQL-like aggregate operators: </p>
+<p>To generate a summary log file, create a <code>LogFormat</code> object in the XML-based logging configuration file (<code>logs_xml.config</code>) using the SQL-like aggregate operators below. You can apply each of these operators to specific fields, over a specified interval.</p>
<ul>
<li><code>COUNT </code></li>
<li><code>SUM </code></li>
@@ -270,13 +266,12 @@
<li><code>FIRST </code></li>
<li><code>LAST </code></li>
</ul>
-<p>You can apply each of these operators to specific fields, over a specified interval. </p>
<h5>To create a summary log file format: </h5>
<ol>
<li>Access the <code>logs_xml.config</code> file located in the Traffic Server <code>config</code> directory. </li>
<li>Define the format of the log file as follows:<br /><code><LogFormat><br /> <Name = "summary"/><br /> <Format = "%<<em>operator</em>(<em>field</em>)> : %<<em>operator</em>(<em>field</em>)>"/><br /> <Interval = "<em>n</em>"/><br /> </Format><br />
</code>
- where <em><code>operator</code></em> is one of the five aggregate operators (COUNT, SUM, AVERAGE, FIRST, LAST), <em><code>field</code></em> is the logging field you want to aggregate, and <code> <em>n</em></code> is the interval (in seconds) between summary log entries. You can specify more than one <code>operator</code> in the format line.<code> </code>For more information, refer to <a href="files.htm#131440"><em>logs_xml.config</em></a>.<br />
+ where <em><code>operator</code></em> is one of the five aggregate operators (<code>COUNT</code>, <code>SUM</code>, <code>AVERAGE</code>, <code>FIRST</code>, <code>LAST</code>), <em><code>field</code></em> is the logging field you want to aggregate, and <code> <em>n</em></code> is the interval (in seconds) between summary log entries. You can specify more than one <code><i>operator</i></code> in the format line. For more information, refer to <a href="files.htm#131440">logs_xml.config</a>.<br />
<br />
The following example format generates one entry every 10 seconds. Each entry contains the timestamp of the last entry of the interval, a count of the number of entries seen within that 10-second interval, and the sum of all bytes sent to the client:
<br /><code><LogFormat><br /> <Name = "summary"/><br /> <Format = "%<LAST(cqts)> : %<COUNT(*)> : %<SUM(psql)>"/><br /> <Interval = "10"/><br /> </Format></code><br />
@@ -291,12 +286,13 @@
<p>You can configure the Traffic Server to create event log files in either of the following: </p>
<ul>
<li><b>ASCII</b><br />
- These files are human-readable and can be processed using standard, off-the-shelf log-analysis tools. However, Traffic Server must perform additional processing to create the files in ASCII; this mildly impacts system overhead. ASCII files also tend to be larger than the equivalent binary files. ASCII log files have a <code>.log</code> filename extension by default. </li>
+ These files are human-readable and can be processed using standard, off-the-shelf log analysis tools. However, Traffic Server must perform additional processing to create the files in ASCII, which mildly impacts system overhead. ASCII files also tend to be larger than the equivalent binary files. By default, ASCII log files have a <code>.log</code> filename extension. </li>
<li><b>Binary</b><br />
- These files generate lower system overhead and generally occupying less space on the disk (depending on the type of information being logged) than ASCII files. Hwever, you must use a converter application before you can read or analyze these files using standard tools. Binary log files use a <code>.blog</code> filename extension by default. </li>
+ These files generate lower system overhead and generally occupy less space on the disk than ASCII files (depending on the type of information being logged). However, you must use a converter application before you can read or analyze binary files via standard tools. By default, binary log files use a <code>.blog</code> filename extension. </li>
</ul>
-<p>While binary log files typically require less disk space, there are exceptions. For example, the value 0 (zero) requires only one byte to store in ASCII but requires four bytes when stored as a binary integer. On the other hand, if you define a custom format that logs IP addresses, a binary log file would only require four bytes of storage per 32-bit address. However, the same IP address stored in dot notation would require around 15 characters (bytes) in an ASCII log file. Before selecting ASCII or binary for your log files, consider the type of data that will be logged. For example, try logging for one day using ASCII and then another day using binary. Assuming that the number of requests is roughly the same for both days, you can calculate a rough metric that compares the two formats. </p>
-<p>For standard log formats, select Binary or ASCII; refer to <a href="#SettingStandardLogFileFormatOptions"><em>Setting Standard Log File Format Options</em></a>. For the custom log format, specify ASCII or Binary mode in the <code>LogObject</code>; refer to <a href="#UsingCustomFormat"><em>Using the Custom Format</em></a>. In addition to the ASCII and binary options, you can also write custom log entries to a UNIX-named pipe (a buffer in memory). Other processes can then read the data using standard I/O functions. The advantage of using this option is that Traffic Server does not have to write to disk, which frees disk space and bandwidth for other tasks. In addition, writing to a pipe does not stop when logging space is exhausted because the pipe does not use disk space. Refer to <a href="files.htm#131440"><em>logs_xml.config</em></a> for more information about the ASCII_PIPE option.</p>
+<p>While binary log files typically require less disk space, there are exceptions. <br/>
+ For example: the value <code>0</code> (zero) requires only one byte to store in ASCII, but requires four bytes when stored as a binary integer. Conversely: if you define a custom format that logs IP addresses, then a binary log file would only require four bytes of storage per 32-bit address. However, the same IP address stored in dot notation would require around 15 characters (bytes) in an ASCII log file. Therefore, it's wise to consider the type of data that will be logged before you select ASCII or binary for your log files. For example, you might try logging for one day using ASCII and then another day using binary. If the number of requests is roughly the same for both days, then you can calculate a rough metric that compares the two formats. </p>
+<p>For standard log formats, select Binary or ASCII (refer to <a href="#SettingStandardLogFileFormatOptions">Setting Standard Log File Format Options</a>). For the custom log format, specify ASCII or Binary mode in the <code>LogObject</code> (refer to <a href="#UsingCustomFormat">Using the Custom Format</a>). In addition to the ASCII and binary options, you can also write custom log entries to a UNIX-named pipe (i.e., a buffer in memory). Other processes can then read the data using standard I/O functions. The advantage of using this option is that Traffic Server does not have to write to disk, which frees disk space and bandwidth for other tasks. In addition, writing to a pipe does not stop when logging space is exhausted because the pipe does not use disk space. Refer to <a href="files.htm#131440">logs_xml.config</a> for more information about the <code>ASCII_PIPE</code> option.</p>
<h3>Using logcat to Convert Binary Logs to ASCII </h3>
<p>You must convert a binary log file to ASCII before you can analyze it using standard tools. </p>
<h5>To convert a binary log file to ASCII: </h5>
@@ -337,34 +333,34 @@
</tr>
</table>
<br />
- <strong>Note: </strong>Use only one of the following options at any given time: -S, -C, -E, or -2. <br />
- If no input files are specified, then <code>logcat</code> reads from the standard input (<code>stdin</code>). If you do not specify an output file, then <code>logcat</code> writes to the standard output (<code>stdout</code>). For example, to convert a binary log file to an ASCII file, you can use the <code>logcat</code> command with either of the following options below:
- <pre>logcat binary_file > ascii_file<br />logcat -o ascii_file binary_file</pre>The binary log file is not modified by this command. </li>
-</ol>
+ <strong>Note: </strong>Use only one of the following options at any given time: <code>-S</code>, <code>-C</code>, <code>-E</code>, or<code> -2</code>. <br />
+ If no input files are specified, then <code>logcat</code> reads from the standard input (<code>stdin</code>). If you do not specify an output file, then <code>logcat</code> writes to the standard output (<code>stdout</code>). <p> For example, to convert a binary log file to an ASCII file, you can use the <code>logcat</code> command with either of the following options below:
+ <pre>logcat binary_file > ascii_file<br />logcat -o ascii_file binary_file</code></pre>
+
+The binary log file is not modified by this command. </li></ol>
<h2><a name="RollingEventLogFiles"></a>Rolling Event Log Files</h2>
<p>Traffic Server provides automatic log file rolling. This means that at specific intervals during the day or when log files reach a certain size, Traffic Server closes its current set of log files and opens new log files. You should roll log files several times a day. Rolling every six hours is a good guideline to start with. </p>
<p>Log file rolling offers the following benefits: </p>
<ul>
<li>It defines an interval over which log analysis can be performed. </li>
- <li>It keeps any single log file from becoming too large and assists in keeping the logging system within the specified space limits. </li>
+ <li>It keeps any single log file from becoming too large and helps to keep the logging system within the specified space limits. </li>
<li>It provides an easy way to identify files that are no longer being used so that an automated script can clean the logging directory and run log analysis programs.</li>
</ul>
<h3>Rolled Log Filename Format </h3>
-<p>Traffic Server provides a consistent name format for rolled log files that enables you to easily identify log files. When Traffic Server rolls a log file, it saves and closes the old file before it starts a new file. Traffic Server renames the old file to include the following information: </p>
+<p>Traffic Server provides a consistent naming scheme for rolled log files that enables you to easily identify log files. When Traffic Server rolls a log file, it saves and closes the old file before it starts a new file. Traffic Server renames the old file to include the following information: </p>
<ul>
<li>The format of the file (such as <code>squid.log</code>). </li>
<li>The hostname of the Traffic Server that generated the log file. </li>
- <li>Two timestamps separated by a hyphen (-). The first timestamp is a <i>lower bound</i> for the timestamp of the first record in the log file. The lower bound is the time when the new buffer for log records is created. Under low load, the first timestamp in the filename can be different from the timestamp of the first entry. Under normal load, the first timestamp in the filename and the timestamp of the first entry are similar. The second timestamp is an <i>upper bound</i> for the timestamp of the last record in the log file (this is normally the rolling time). </li>
+ <li>Two timestamps separated by a hyphen (-). The first timestamp is a <b>lower bound</b> for the timestamp of the first record in the log file. The lower bound is the time when the new buffer for log records is created. Under low load, the first timestamp in the filename can be different from the timestamp of the first entry. Under normal load, the first timestamp in the filename and the timestamp of the first entry are similar. The second timestamp is an <b>upper bound </b>for the timestamp of the last record in the log file (this is normally the rolling time). </li>
<li>The suffix <code>.old</code>, which makes it easy for automated scripts to find rolled log files. </li>
</ul>
<p>Timestamps have the following format: <br /><code>%Y%M%D.%Hh%Mm%Ss-%Y%M%D.%Hh%Mm%Ss</code></p>
<p>The following table describes the format: </p>
- <br />
<table width="1232" border="1">
<tr>
<th width="322" scope="col">Code</th>
<th width="894" scope="col">Description</th>
- </tr>
+ </tr>
<tr>
<td><code>%Y</code></td>
<td>The year in four-digit format. For example: 2000.</td>
@@ -393,12 +389,13 @@
<br />
<p>The following is an example of a rolled log filename: <br /><code>squid.log.mymachine.20000912.12h00m00s-20000913.12h00m00s.old</code><br />
<br />
-The logging system buffers log records before writing them to disk. When a log file is rolled, the log buffer might be partially full. If so, then the first entry in the new log file will have a timestamp earlier than the time of rolling. When the new log file is rolled, its first timestamp will be a lower bound for the timestamp of the first entry. Fr example, suppose logs are rolled every three hours, and the first rolled log file is:<br />
-<code>squid.log.mymachine.19980912.12h00m00s-19980912.03h00m00s.old</code><br />
-<br />
-If the lower bound for the first entry in the log buffer at 3:00:00 is 2:59:47, then the next log file will have the following timestamp when rolled:
-<br />
-<code>squid.log.mymachine.19980912.02h59m47s-19980912.06h00m00s.old</code></p>
+The logging system buffers log records before writing them to disk. When a log file is rolled, the log buffer might be partially full. If it is, then the first entry in the new log file will have a timestamp earlier than the time of rolling. When the new log file is rolled, its first timestamp will be a lower bound for the timestamp of the first entry. </p>
+<p>For example, suppose logs are rolled every three hours, and the first rolled log file is:<br />
+ <code>squid.log.mymachine.19980912.12h00m00s-19980912.03h00m00s.old</code><br />
+ <br />
+ If the lower bound for the first entry in the log buffer at 3:00:00 is 2:59:47, then the next log file will have the following timestamp when rolled:
+ <br />
+ <code>squid.log.mymachine.19980912.02h59m47s-19980912.06h00m00s.old</code></p>
<p>The contents of a log file are always between the two timestamps. Log files do not contain overlapping entries, even if successive timestamps appear to overlap. </p>
<h3>Rolling Intervals</h3>
<p>Log files are rolled at specific intervals relative to a given hour of the day. Two options control when log files are rolled: </p>
@@ -408,13 +405,11 @@
</ul>
<p>Both the offset hour and the rolling interval determine when log file rolling starts. Rolling occurs every rolling interval and at the offset hour. For example, if the rolling interval is six hours and the offset hour is 0 (midnight), then the logs will roll at midnight (00:00), 06:00, 12:00, and 18:00 each day. If the rolling interval is 12 hours and the offset hour is 3, then logs will roll at 03:00 and 15:00 each day. </p>
<h3>Setting Log File Rolling Options </h3>
-<p>To set log file rolling options, including configuring Traffic Server to roll log files when they reach a certain size, follow the steps below:</p>
+<p>To set log file rolling options and/or configure Traffic Server to roll log files when they reach a certain size, follow the steps below:</p>
<ol>
<li>In a text editor, open the <code>records.config</code> file located in the <code>config</code> directory. </li>
<li>Edit the following variables: </li>
- <br />
-
-<table width="1232" border="1">
+ <table width="1232" border="1">
<tr>
<th width="322" scope="col">Variable</th>
<th width="894" scope="col">Description</th>
@@ -437,25 +432,24 @@
</tr>
<tr>
<td><code><i>proxy.config.log2.rolling_interval_sec</i></code></td>
- <td>Set this variable to the rolling interval in seconds. The minimum value is 300 seconds (5 minutes). The maximum value is 86400 seconds (one day).<b> Note:</b> If you start Traffic Server within a few minutes of the next rolling time, rolling might not occur until the following rolling time.</td>
+ <td>Set this variable to the rolling interval in seconds. The minimum value is 300 seconds (5 minutes). The maximum value is 86400 seconds (one day).<b> Note:</b> If you start Traffic Server within a few minutes of the next rolling time, then rolling might not occur until the next rolling time.</td>
</tr>
<tr>
<td><code><i>proxy.config.log2.auto_delete_rolled_file</i></code></td>
<td>Set this variable to 1 to enable autodeletion of rolled files.</td>
</tr>
</table>
-<br />
<li>Save and close the <code>records.config</code> file. </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>
<p>You can fine-tune log file rolling settings for a custom log file in the <code>LogObject</code> specification in the <code>logs_xml.config</code> file. The custom log file uses the rolling settings in its <code>LogObject</code>, which override the default settings you specify in Traffic Manager or the <code>records.config</code> file described above. </p>
<h2 id="SplittingEventLogFiles">Splitting Event Log Files</h2>
-<p>By default, Traffic Server uses standard log formats, and generates log files that contain HTTP and ICP transactions in the same file. However, you can enable log splitting if you prefer to log transactions for different protocols in separate log files. </p>
+<p>By default, Traffic Server uses standard log formats and generates log files that contain HTTP & ICP transactions in the same file. However, you can enable log splitting if you prefer to log transactions for different protocols in separate log files. </p>
<h3>ICP Log Splitting </h3>
-<p>When ICP log splitting is enabled, Traffic Server records ICP transactions in a separate log file with a name that contains icp. For example: if you enable the Squid format, then all ICP transactions are recorded in the <code>squid-icp.log</code> file. When you disable ICP log splitting, Traffic Server records all ICP transactions in the same log file as HTTP transactions. </p>
+<p>When ICP log splitting is enabled, Traffic Server records ICP transactions in a separate log file with a name that contains <b><code>icp</code></b>. For example: if you enable the Squid format, then all ICP transactions are recorded in the <code>squid-icp.log</code> file. When you disable ICP log splitting, Traffic Server records all ICP transactions in the same log file as HTTP transactions. </p>
<h3><a name="HTTPHostLogSplitting"></a>HTTP Host Log Splitting </h3>
-<p>HTTP host log splitting enables you to record HTTP transactions for different origin servers in separate log files. When HTTP host log splitting is enabled, Traffic Server creates a separate log file for each origin server that's listed in the<code> </code><a href="#EditingLogHostsConfigFile"><em>log_hosts.config</em></a> file. When both ICP and HTTP host log splitting are enabled, Traffic Server generates separate log files for HTTP transactions (based on the origin server) and places all ICP transactions in their own respective log files. For example, if the <code>log_hosts.config</code> file contains the two origin servers <code>uni.edu</code> and <code>company.com</code> and Squid format is enabled, then Traffic Server generates the following log files: </p>
+<p>HTTP host log splitting enables you to record HTTP transactions for different origin servers in separate log files. When HTTP host log splitting is enabled, Traffic Server creates a separate log file for each origin server that's listed in the<code> </code><a href="#EditingLogHostsConfigFile">log_hosts.config</a> file. When both ICP and HTTP host log splitting are enabled, Traffic Server generates separate log files for HTTP transactions (based on the origin server) and places all ICP transactions in their own respective log files. For example, if the <code>log_hosts.config</code> file contains the two origin servers <code>uni.edu</code> and <code>company.com</code> and Squid format is enabled, then Traffic Server generates the following log files: </p>
<br />
<table width="1232" border="1">
<tr>
@@ -501,7 +495,7 @@
</tr>
</table>
<br />
-<p>Traffic Server also enables you to create XML-based <a href="#UsingCustomFormat"><em>Custom Log Formats</em></a> that offer even greater control over log file generation. </p>
+<p>Traffic Server also enables you to create XML-based <a href="#UsingCustomFormat">Custom Log Formats</a> that offer even greater control over log file generation. </p>
<h3>Setting Log Splitting Options </h3>
<p>To set log splitting options, follow the steps below:</p>
<ol>
@@ -551,9 +545,9 @@
<p><strong>Note: </strong>Log collation can have an impact on network performance. Because all nodes are forwarding their log data buffers to the single collation server, a bottleneck can occur.<strong> </strong>In addition, collated log files contain timestamp information for each entry, but entries in the files do not appear in strict chronological order. You may want to sort collated log files before doing analysis. </p>
<p>To configure Traffic Server to collate event log files, you must perform the following tasks: </p>
<ul>
- <li>Either <a href="#ConfiguringTrafficEdgeCollationServer"><em>Configure Traffic Server Node to Be a Collation Server</em></a> or install & configure a <a href="#UsingStandaloneCollator"><em> Standalone Collator</em></a>. </li>
- <li><a href="#ConfiguringTrafficEdgeCollationClient"><em>Configure Traffic Server Nodes to Be a Collation Clients</em></a>. </li>
- <li>Add an attribute to the <code>LogObject</code> specification in the <code>logs_xml.config</code> file if you are using custom log file formats; refer to <a href="#CollatingCustomEventLogFiles"><em>Collating Custom Event Log Files</em></a>. <br />
+ <li>Either <a href="#ConfiguringTrafficEdgeCollationServer">Configure Traffic Server Node to Be a Collation Server</a> or install & configure a <a href="#UsingStandaloneCollator"> Standalone Collator</a>. </li>
+ <li><a href="#ConfiguringTrafficEdgeCollationClient">Configure Traffic Server Nodes to Be a Collation Clients</a>. </li>
+ <li>Add an attribute to the <code>LogObject</code> specification in the <code>logs_xml.config</code> file if you are using custom log file formats; refer to <a href="#CollatingCustomEventLogFiles">Collating Custom Event Log Files</a>. <br />
</li>
</ul>
<h3 id="ConfiguringTrafficEdgeCollationServer">Configuring Traffic Server to Be a Collation Server </h3>
@@ -589,7 +583,7 @@
<p>If you do not want the log collation server to be a Traffic Server node, then you can install and configure a standalone collator (SAC) that will dedicate more of its power to collecting, processing, and writing log files.</p>
<h5>To install and configure a standalone collator: </h5>
<ol>
- <li>Configure your Traffic Server nodes as log collation clients; refer to <a href="#ConfiguringTrafficEdgeCollationClient"><em>Configuring Traffic Server to Be a Collation Client</em></a>. </li>
+ <li>Configure your Traffic Server nodes as log collation clients; refer to <a href="#ConfiguringTrafficEdgeCollationClient">Configuring Traffic Server to Be a Collation Client</a>. </li>
<li>Copy the <code>sac</code> binary from the Traffic Server <code>bin</code> directory to the machine serving as the standalone collator. </li>
<li>Create a directory called <code>config</code> in the directory that contains the <code>sac</code> binary. </li>
<li>Create a directory called <em><code>internal</code></em> in the <code>config</code> directory you created in Step 3 (above). This directory is used internally by the standalone collator to store lock files. </li>
@@ -624,7 +618,7 @@
</tr>
<tr>
<td><code><i>proxy.config.log2.collation_mode</i></code></td>
- <td>Set this variable to 2 to configure this Traffic Server node to be a log collation client and send standard formatted log entries to the collation server.<br />To send custom XML-based formatted log entries to the collation server, you must add a log object specification to the <code>logs_xml.config</code> file; refer to <a href="#UsingCustomFormat"><em>Using the Custom Format</em></a>.</td>
+ <td>Set this variable to 2 to configure this Traffic Server node to be a log collation client and send standard formatted log entries to the collation server.<br />To send custom XML-based formatted log entries to the collation server, you must add a log object specification to the <code>logs_xml.config</code> file; refer to <a href="#UsingCustomFormat">Using the Custom Format</a>.</td>
</tr>
<tr>
<td><code><i>proxy.config.log2.collation_host</i></code></td>
@@ -673,7 +667,7 @@
<li>The number of access events skipped (because they were filtered) since Traffic Server installation. </li>
<li>The number of access events written to the event error log since Traffic Server installation. </li>
</ul>
-<p>You can retrieve the statistics via the Traffic Line command-line interface; refer to <em><a href="monitor.htm">Monitoring Traffic</a></em>. </p>
+<p>You can retrieve the statistics via the Traffic Line command-line interface; refer to <a href="monitor.htm">Monitoring Traffic</a>. </p>
<h2 id="ViewingLogFiles">Viewing Log Files</h2>
<p>You can view the system, event, and error log files Traffic Server creates. You can also delete a log file or copy it to your local systemif you have the correct user permissions. Traffic Server displays only one MB of information in the log file. If the log file you select to view is bigger than 1MB, then Traffic Server truncates the file and displays a warning message indicating that the file is too big.</p>
<h2 id="ExampleEventLogFileEntries">Example Event Log File Entries</h2>
@@ -707,8 +701,7 @@
<tr>
<td>4</td>
<td>crc/pssc</td>
- <td>The cache result code; how the cache responded to the request: <code>HIT</code>, <code>MISS</code>, and so on. Cache result codes are described <a href="trouble.htm#0_21826"><em>here</em></a>.<br />
- The proxy response status code (the HTTP response status code from Traffic Server to client). </td>
+ <td>The cache result code; how the cache responded to the request: <code>HIT</code>, <code>MISS</code>, and so on. Cache result codes are described <a href="trouble.htm#0_21826">here</a>.<br /> The proxy response status code (the HTTP response status code from Traffic Server to client). </td>
</tr>
<tr>
<td>5</td>
@@ -871,15 +864,15 @@
<tr>
<td>20</td>
<td>crc</td>
- <td>The cache result code; how the Traffic Server cache responded to the request: HIT, MISS, and so on. Cache result codes are described <a href="trouble.htm#0_21826"><em>here</em></a>.</td>
+ <td>The cache result code; how the Traffic Server cache responded to the request: HIT, MISS, and so on. Cache result codes are described <a href="trouble.htm#0_21826">here</a>.</td>
</tr>
</table>
<p> </p>
<h2 id="SupportTraditionalCustomLogging">Support for Traditional Custom Logging</h2>
<p>Traffic Server supports traditional custom logging in addition to the XML-based custom logging, which is more versatile and therefore recommended.</p>
-<p>Traffic Server's format converter only converts traditional log configuration files named <code>logs.config</code>. If you are using a traditional log configuration file with a name other than <code>logs.config</code>, then you must convert the file yourself after installation; refer to <a href "#UsingCustLogFmtCnvrt"><em>Using cust_log_fmt_cnvrt</em></a>. If you opt to use traditional custom logging instead of the more versatile XML-based custom logging, then you must enable the traditional custom logging option manually. Furthermore, if you want to configure Traffic Server as a collation client that sends log entries in traditional custom formats, then you must set collation options manually. Use the following procedures. </p>
+<p>Traffic Server's format converter only converts traditional log configuration files named <code>logs.config</code>. If you are using a traditional log configuration file with a name other than <code>logs.config</code>, then you must convert the file yourself after installation; refer to <a href "#UsingCustLogFmtCnvrt">Using cust_log_fmt_cnvrt</a>. If you opt to use traditional custom logging instead of the more versatile XML-based custom logging, then you must enable the traditional custom logging option manually. Furthermore, if you want to configure Traffic Server as a collation client that sends log entries in traditional custom formats, then you must set collation options manually. Use the following procedures. </p>
<h3>Enabling Traditional Custom Logging </h3>
-<p>To enable custom logging, you must edit a configuration file manually. To edit your existing traditional custom log formats, modify the <a href="files.htm#149839"><em>logs.config</em></a> file as before.</p>
+<p>To enable custom logging, you must edit a configuration file manually. To edit your existing traditional custom log formats, modify the <a href="files.htm#149839">logs.config</a> file as before.</p>
<h5>To enable traditional custom logging: </h5>
<ol>
<li>In a text editor, open the <code>records.config</code> file located in the <code>config</code> directory. </li>