Understanding Traffic Server Logs

Traffic Server records information about every transaction (or request) it processes and every error it detects in log files. This information is separated into various logs, which are discussed below.

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. 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.

Enabling Logs

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 proxy.config.log.logging_enabled in records.yaml to one of the following values:

Value	Description
0	Disable both event and error logging.
1	Enable error logging only.
2	Enable event logging only.
3	Enable both event and error logging.

Log Types

Three separate classes of log files exist: System Logs, Error Logs, and Event Logs. The fourth log type covered here, Summary Logs are a special instance of the event logs, but instead of including details of individual transactions, the summary logs allow you to emit log entries which aggregate all events that occur over arbitrary periods of time (the specific period of time being a fixed configuration of each summary log you create).

System Logs

System log files record system information, including messages about the state of Traffic Server and any errors or warnings it produces. This kind of information might include a note that event log files were rolled or an error indicating that Traffic Server was restarted. If Traffic Server is failing to start properly on your system(s), this is the first place you'll want to look for possible hints as to the cause.

All system information messages are logged with the system-wide logging facility syslog under the daemon facility. The syslog.conf(5) configuration file (stored in the /etc directory) specifies where these messages are logged. A typical location is /var/log/messages (Linux).

The syslog(8) process works on a system-wide basis, so it serves as the single repository for messages from Traffic Server process (traffic_server).

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.

Error Logs

Error log files record information about why a particular transaction was in error. Refer to エラーメッセージ for a list of the messages logged by Traffic Server.

Event Logs

Event log files (also called access logs) record information about the state of each transaction Traffic Server processes and form the true bulk of logging output in Traffic Server installations. Most of the remaining documentation in this chapter applies to creating, formatting, rotating, and filtering event logs.

Individual event log outputs are configured in logging.yaml and as such, the documentation provided in that configuration file's section should be consulted in concert with the sections of this chapter.

Summary Logs

Summary logs are an extension of the event logs, but instead of providing details for individual events, aggregate statistics are presented for all events occurring within the specified time window. Summary logs have access to all of the same fields as event logs, with the restriction that every field must be used within an aggregating function. Summary logs may not mix both aggregated and unaggregated fields.

The aggregating functions available are:

Function	Description
AVG	Average (mean) of the given field's value from all events within the interval. May only be used on numeric fields.
COUNT	The total count of events which occurred within the interval. No field name is necessary (COUNT(*) may be used instead).
FIRST	The value of the first event, chronologically, which was observed within the interval. May be used with any type of field; numeric or otherwise.
LAST	The value of the last event, chronologically, which was observed within the interval. May be used with any type of field; numeric or otherwise.
SUM	Sum of the given field's value from all events within the interval. May only be used on numeric fields.

Summary logs are defined in logging.yaml just like regular event logs, with the only two differences being the exclusive use of the aforementioned aggregate functions and the specification of an interval, as so:

formats:
- name: mysummary
  format: '%<operator(field)> , %<operator(field)>'
  interval: n

The interval itself is given with n as the number of seconds for each period of aggregation. There is no default value.

Logging Performance

In normal operations, log entries are strictly ordered in the output file. This serialization of entries comes at a cost as multiple threads potentially contend for log access. For binary logs or when order does not matter, ATS supports faster logging where each thread can buffer its own entries. In this mode, log parsers will need to expect out of order entries, but ATS can log much larger transaction rates. Consider adding fields to the log format that include the timestamp so entries can be reordered if necessary (see Timestamps and Durations)

formats:
- name: mysummary
  format: '%<operator(field)> , %<operator(field)>'
  fast: true