traffic_ctl [OPTIONS] SUBCOMMAND [OPTIONS]
traffic_ctl is used to display and manipulate configure a running Traffic Server. traffic_ctl includes a number of subcommands that control different aspects of Traffic Server:
- traffic_ctl alarm
Display and manipulate Traffic Server alarms
- traffic_ctl config
Manipulate and display configuration records
- traffic_ctl metric
Manipulate performance and status metrics
- traffic_ctl server
Stop, restart and examine the server
- traffic_ctl storage
Manipulate cache storage
- traffic_ctl plugin
Interact with plugins.
- traffic_ctl host
Manipulate host status. parents for now but will be expanded to origins.
To use traffic_ctl, traffic_manager needs to be running.
List all alarm events that have not been acknowledged (cleared).
Clear (acknowledge) all current alarms.
Clear (acknowledge) an alarm event. The arguments are a specific alarm number (e.g. ‘’1’’), or an alarm string identifier (e.g. ‘’MGMT_ALARM_PROXY_CONFIG_ERROR’’).
Display the default values for all configuration records. The –records flag has the same behavior as
traffic_ctl config get --records.
Display all the known information about a configuration record. This includes the current and default values, the data type, the record class and syntax checking expression.
Display configuration records that have non-default values. The –records flag has the same behavior as
traffic_ctl config get --records.
[--records] RECORD [RECORD...]¶
Display the current value of a configuration record.
If this flag is provided,
traffic_ctl config getwill emit results in
[--records] REGEX [REGEX...]¶
Display the current values of all configuration variables whose names match the given regular expression. The –records flag has the same behavior as
traffic_ctl config get --records.
Initiate a Traffic Server configuration reload. Use this command to update the running configuration after any configuration file modification. If no configuration files have been modified since the previous configuration load, this command is a no-op.
The timestamp of the last reconfiguration event (in seconds since epoch) is published in the proxy.node.config.reconfigure_time metric.
Set the named configuration record to the specified value. Refer to the
records.configdocumentation for a list of the configuration variables you can specify. Note that this is not a synchronous operation.
Display detailed status about the Traffic Server configuration system. This includes version information, whether the internal configuration store is current and whether any daemon processes should be restarted.
Display the current value of the specifies statistics.
Display the current values of all statistics whose names match the given regular expression.
Reset the named statistics to zero.
Shut down and immediately restart Traffic Server
This option modifies the behavior of
traffic_ctl server restartsuch that traffic_server is not shut down until the number of active client connections drops to the number given by the
The default behavior of
traffic_ctl server restartis to restart traffic_server. If this option is specified, traffic_manager is also restarted.
Start traffic_server if it is already running.
Clear the disk cache upon startup.
Clear the DNS resolver cache upon startup.
Show the current proxy server status, indicating if we’re running or not.
Stop the running traffic_server process.
Show a full stack trace of all the traffic_server threads.
PATH [PATH ...]¶
Mark a cache storage device as offline. The storage is identified by PATH which must match exactly a path specified in
storage.config. This removes the storage from the cache and redirects requests that would have used this storage to other storage. This has exactly the same effect as a disk failure for that storage. This does not persist across restarts of the traffic_server process.
Send a message to plugins. All plugins that have hooked the
TSLifecycleHookID::TS_LIFECYCLE_MSG_HOOKwill receive a callback for that hook. The TAG and DATA will be available to the plugin hook processing. It is expected that plugins will use TAG to select relevant messages and determine the format of the DATA.
HOSTNAME [HOSTNAME ...]¶
Get the current status of the hosts used in parent.config as a next hop in a multi-tiered cache heirarchy. The value 0 or 1 is returned indicating that the host is marked as down ‘0’ or marked as up ‘1’. If a host is marked as down, it will not be used as the next hop parent, another host marked as up will be chosen.
--time seconds --reason 'active|local|manual' HOSTNAME [HOSTNAME ...]¶
Marks the listed hosts as down so that they will not be chosen as a next hop parent. If the –time option is included, the host is marked down for the specified number of seconds after which the host will automatically be marked up. 0 seconds marks the host down indefinitely until marked up manually and is the default. A reason tag may be used when marking a host down. Valid values are ‘manual’, ‘active’, and ‘local’, ‘manual’ is used as the default if no reason is specified. The tags are used to indicate wether the host was marked down manually or by an ‘active’ or ‘local’ health check. ‘self_detect’ indicates that a parent entry in parent.config was marked down because the entry refers to the local host so, it is automatically marked down to prevent requests from looping. A host is not marked up until all reason codes are cleared by marking up the host for the specified reason code.
A stat is created for each host, with a the host fqdn and is prefixed with the string proxy.process.host_status with a string value. The string value is a serialized representation of the Host status struct showing all current data ie, reasons, marked down times, and down time for each host. The stats may be viewed using the traffic_ctl metric command or through the stats_over_http endpoint.
--reason 'active|local|manual' HOSTNAME [HOSTNAME ...]¶
Marks the listed hosts as up so that they will be available for use as a next hop parent. By default, the ‘manual’ reason tag is used when marking up a host. Use the –reason tag to mark the host reason code as up using one of ‘manual’, ‘active’, or ‘local’. The ‘self_detect’ is an internal reason code used by parent selection to mark down a parent when it is identified as itself and `proxy.config.http.parent_proxy.self_detect’ is set to the default of 2. ‘self_detect’ down cannot be set or unset with traffic_ctl
Mark down a host with traffic_ctl and view the associated host stats:
$ traffic_ctl host down cdn-cache-02.foo.com --reason manual
$ /opt/trafficserver/bin/traffic_ctl metric match host_status proxy.process.host_status.cdn-cache-01.foo.com HOST_STATUS_DOWN,ACTIVE:UP:0:0,LOCAL:UP:0:0,MANUAL:DOWN:1556896844:0,SELF_DETECT:UP:0 proxy.process.host_status.cdn-cache-02.foo.com HOST_STATUS_UP,ACTIVE:UP:0:0,LOCAL:UP:0:0,MANUAL:UP:0:0,SELF_DETECT:UP:0 proxy.process.host_status.cdn-cache-origin-01.foo.com HOST_STATUS_UP,ACTIVE:UP:0:0,LOCAL:UP:0:0,MANUAL:UP:0:0,SELF_DETECT:UP:0
In the example above, ‘cdn-cache-01.foo.com’ is unavailable, HOST_STATUS_DOWN and was marked down for the manual reason, MANUAL:DOWN:1556896844:0, at the time indicated by the UNIX time stamp 1556896844. To make the host available, one would have to clear the manual reason using:: traffic_ctl host up cdn-cache-01.foo.com –reason manual
Configure Traffic Server to insert
Via header in the response to
$ traffic_ctl config set proxy.config.log.squid_log_enabled 1 $ traffic_ctl config set proxy.config.log.squid_log_is_ascii 1 $ traffic_ctl config reload