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.config 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 all Traffic Server processes (including traffic_server and traffic_manager).

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