Skip to main content
This page describes how to configure CockroachDB logs with the and a YAML payload. Most logging behaviors are configurable, including:
  • The log sinks that output logs to different locations, including over the network.
  • The that are mapped to each sink.
  • The used by the log messages.
  • The redaction of log messages.
  • The buffering of log messages.
For examples of how these settings can be used in practice, see .
In a future major release, certain events will be directed by default to new .To prepare for the change and assess potential downstream impacts on your logging setup and pipelines, review the cluster setting. After reviewing the documentation, set log.channel_compatibility_mode.enabled to false in a non-production environment.

​
Flag

To configure the logging behavior of a cockroach command, include one of these flags with the command:
  • , where is the YAML payload
  • , where is the path to a YAML file
To disable logging, set --log-dir to a blank directory (--log-dir=) instead of using one of the other logging flags. Do not use --log-dir=""; this creates a new directory named "" and stores log files in that directory. To apply changes to an existing node’s logging configuration, restart the node with the updated --log flag or point it to the updated --log-config-file. CockroachDB reads these settings during startup. Before restarting, use cockroach debug check-log-config to verify the effective configuration produced by your changes.
All support logging and can be configured with --log or --log-config-file. However, note that most messages related to cluster operation are generated by or . Other commands generate messages related to their own execution, which are mainly useful when troubleshooting the behaviors of those commands.

​
YAML payload

All log settings for a cockroach command are specified with a YAML payload in one of the following formats:
  • Block format, where each parameter is written on a separate line. For example, after creating a file logs.yaml, pass the YAML values with either --log-config-file or --log:
  • Inline format, where all parameters are specified on one line. For example, to generate an ops log file that collects the OPS and HEALTH channels (overriding the file groups defined for those channels in the default configuration):
    Note that the inline spaces must be preserved.
For clarity, this article uses the block format to describe the YAML payload, which has the overall structure:
Providing a logging configuration is optional. Any fields included in the YAML payload will override the same fields in the default logging configuration.
When you provide a minimal logging configuration for file-groups, CockroachDB replaces the entire default file-groups structure instead of merging only the specified fields. As a result, all logging channels flow into the default file sink, which can produce noisy logs and rapid log rotation. Partial YAML overrides that merge with the default logging configuration are not supported. To avoid misconfiguration, validate your logging settings using the cockroach debug check-log-config command.
To demonstrate this warning scenario, consider the following excerpt from the default logging configuration which has several file sinks followed by stderr. Note that each file sink has a max-group-size: 100MiB.
Next, consider the following minimal logging configuration. It moves the DEV and OPS channels from the default file sink to a new file sink called debug and increases the max-group-size for the default file sink to 1000MiB:
When the minimal configuration is applied, the effective configuration updates the max-group-size for the default file sink and adds a new debug file sink with the DEV and OPS channels. However, it also removes all other file sinks, such as changefeed, health, and kv-distribution. The entire file-groups structure is replaced rather than merging only the specified fields.
Log channels cannot be completely disabled. You can configure and , but you cannot turn off a log channel entirely. For example, a channel that is not explicitly configured for a is enabled in the default file group.

​
cockroach debug check-log-config

The cockroach debug check-log-config command helps you validate logging settings before starting or restarting nodes. It returns the YAML definitions and a URL to a visualization of the default logging configuration. When you run it without logging flags, it prints the default log configuration. If you pass a logging flag (for example, ), the output shows the configuration after your YAML payload is applied, so you can confirm the final sink, channel, and formatting behaviors.

​
Configure log sinks

Log sinks route events from specified to destinations outside CockroachDB. These destinations include: All supported output destinations are configured under sinks:
All supported sink types use the following common sink parameters:
ParameterDescription
filterMinimum severity level at which logs enter the channels selected for the sink. Accepts one of the valid or NONE, which excludes all messages from the sink output. For details, see Set logging levels.
formatLog message format to use for file or network sinks. Accepts one of the valid . For details, see file logging format, Fluentd logging format, HTTP logging format, and OTLP logging format.
format-optionsCustomization options for specified format. For available options for each format, see . For an example use case, see Set timezone.
redactWhen true, enables automatic redaction of personally identifiable information (PII) from log messages. This ensures that sensitive data is not transmitted when collecting logs centrally or over a network. For details, see Redact logs.
redactableWhen true, preserves redaction markers around fields that are considered sensitive in the log messages. The markers are recognized by and but may not be compatible with external log collectors. For details on how the markers appear in each format, see .
exit-on-errorWhen true, stops the Cockroach node if an error is encountered while writing to the sink. We recommend enabling this option on file sinks in order to avoid losing any log entries. When set to false, this can be used to mark certain sinks (such as stderr) as non-critical.
auditableIf true, enables exit-on-error on the sink. Also disables buffered-writes if the sink is under file-groups. This guarantees non-repudiability for any logs in the sink, but can incur a performance overhead and higher disk IOPS consumption. This setting is typically enabled for . File-based audit logging cannot coexist with the buffering configuration, so disable either buffering or auditable.
If not specified for a given sink, these parameter values are inherited from file-defaults (for file sinks), fluent-defaults (for Fluentd sinks), http-defaults (for HTTP sinks), and otlp-defaults (for OTLP sinks).

​
Output to files

CockroachDB can write messages to one or more log files. file-groups specifies the channels that output to each log file, along with its output directory and other configuration details. For example:
A file group name is arbitrary and is used to name the log files. The default file group is an exception. For details, see Log file naming.
Along with the common sink parameters, each file group accepts the following additional parameters:
ParameterDescription
channelsList of channels that output to this sink. Use a YAML array or string of , ALL to include all channels, or ALL EXCEPT {channels} to include all channels except the specified channel names. For more details on acceptable syntax, see Logging channel selection.
dirOutput directory for log files generated by this sink.
max-file-sizeApproximate maximum size of individual files generated by this sink. Used to specify the maximum size that a log file can grow before a new log file is created. Accepts a valid file size, such as 2MiB. Default:10MiB
max-group-sizeApproximate maximum combined size of all files to be preserved for this sink. Configures the maximum size for a logging group (for example, cockroach, cockroach-sql-audit, cockroach-auth, cockroach-sql-exec, cockroach-pebble), after which the oldest log file is deleted. An asynchronous garbage collection removes files that cause the file set to grow beyond this specified size. Accepts a valid file size, such as 1GiB. For high-traffic deployments, or to ensure log retention over longer periods of time, consider raising this value to 500MiB or 1GiB. Default:100MiB
file-permissionsThe chmod-style permissions on generated log files, formatted as a 3-digit octal number. The executable bit must not be set. Default:640 (readable by the owner or members of the group, writable by the owner).
buffered-writesWhen true, enables buffering of writes. Set to false to flush every log entry (i.e., propagate data from the cockroach process to the OS) and synchronize writes (i.e., ask the OS to confirm the log data was written to disk). Disabling this setting provides non-repudiation guarantees, but can incur a performance overhead and higher disk IOPS consumption. This setting is typically disabled for .
bufferingbuffering is disabled by default for file log sinks. Default: buffering: NONE. Note that enabling asynchronous buffering of file log sinks is in .

To configure buffering of log messages for the sink, use the following sub-parameters:
  • max-staleness: The maximum time a log message will wait in the buffer before a flush is triggered. Set to 0 to disable flushing based on elapsed time.
  • flush-trigger-size: The number of bytes that will trigger the buffer to flush. Set to 0 to disable flushing based on accumulated size.
  • max-buffer-size: The maximum size of the buffer: new log messages received when the buffer is full cause older messages to be dropped.
When max-staleness and flush-trigger-size are used together, whichever is reached first will trigger the flush. This setting is typically disabled for . For a usage example, refer to .

File-based audit logging cannot coexist with this buffering configuration, so disable either buffering or auditable.
If not specified for a given file group, the parameter values are inherited from file-defaults (except channels, which uses the default configuration).

​
Log file naming

Log files are named in the following format:
For example, a file group health will generate a log file that looks like this:
For each file group, a symlink points to the latest generated log file. It’s easiest to refer to the symlink. For example:
The files generated for a group named default are named after the pattern cockroach.{metadata}.log.

​
Access in DB Console

Log files can be accessed using the DB Console, which displays them in JSON format.
  1. and then click in the left-hand navigation.
  2. Under Raw Status Endpoints (JSON), click Log Files to view the JSON of all collected logs.
  3. Copy one of the log filenames. Then click Specific Log File and replace the cockroach.log placeholder in the URL with the filename.

​
Known limitations

Log files can only be accessed in the DB Console if they are stored in the same directory as the file sink for the DEV channel.

​
Output to Fluentd-compatible network collectors

CockroachDB can send logs over the network to a Fluentd-compatible log collector (e.g., Elasticsearch, Splunk). fluent-servers specifies the channels that output to a server, along with the server configuration details. For example:
A Fluentd sink can be listed more than once with different address values. This routes the same logs to different Fluentd servers.
Along with the common sink parameters, each Fluentd server accepts the following additional parameters:
ParameterDescription
channelsList of channels that output to this sink. Use a YAML array or string of , ALL to include all channels, or ALL EXCEPT {channels} to include all channels except the specified channel names. For more details on acceptable syntax, see Logging channel selection.
addressNetwork address and port of the log collector.
netNetwork protocol to use. Options are tcp, tcp4, tcp6, udp, udp4, udp6, or unix. Default:tcp Note: In most cases, use the default of tcp rather than udp. The UDP/IP protocol has a ~65 KB (65,507 bytes) limit per datagram. This limit is enforced by the operating system. Log lines that exceed this limit return a message too long error.
bufferingConfigures buffering of log messages for the sink, with the following sub-parameters:
  • max-staleness: The maximum time a log message will wait in the buffer before a flush is triggered. Set to 0 to disable flushing based on elapsed time. Default: 5s
  • flush-trigger-size: The number of bytes that will trigger the buffer to flush. Set to 0 to disable flushing based on accumulated size. Default: 1MiB
  • max-buffer-size: The maximum size of the buffer: new log messages received when the buffer is full cause older messages to be dropped. Default: 50MiB
When max-staleness and flush-trigger-size are used together, whichever is reached first will trigger the flush. buffering is enabled by default for Fluentd-compatible log sinks. To explicitly disable log buffering, specify buffering: NONE instead. This setting is typically disabled for . See Log buffering for more details and usage.
For an example network logging configuration, see .

​
Output to HTTP network collectors

CockroachDB can send logs over the network to an HTTP server. http-servers specifies the channels that output to a server, along with the server configuration details. For example:
An HTTP sink can be listed more than once with different address values. This routes the same logs to different HTTP servers.
Along with the common sink parameters, each HTTP server accepts the following additional parameters:
ParameterDescription
channelsList of channels that output to this sink. Use a YAML array or string of , ALL to include all channels, or ALL EXCEPT {channels} to include all channels except the specified channel names. For more details on acceptable syntax, see Logging channel selection.
addressNetwork address and port of the log collector.
methodHTTP method to use. Can be GET or POST. Default:POST
unsafe-tlsWhen true, bypasses TLS server validation. Default:false
timeoutTimeout before requests are abandoned. Default:0 (no timeout)
disable-keep-alivesWhen true, disallows reuse of the server connection across requests. Default:false (reuses connections)
compressionCompression method for the HTTP request body. Valid values gzip or none. Default:gzip
headersMap of key-value string pairs which will be appended to every request as custom HTTP headers.
file-based-headersMap of key-filepath string pairs. The file specified by the filepath only contains a value that corresponds to the key. The key from the YAML configuration and the value contained in the file will be appended to every request as a custom HTTP header. For example: file-based-headers: {X-CRDB-HEADER-KEY: /some/path/to/file\_with\_value, X-ANOTHER-HEADER-KEY: /other/path/to/file\_with\_another\_value} A value in a file can be updated without restarting the cockroach process. Instead, send SIGHUP to the cockroach process to notify it to refresh values.
bufferingConfigures buffering of log messages for the sink, with the following sub-parameters:
  • max-staleness: The maximum time a log message will wait in the buffer before a flush is triggered. Set to 0 to disable flushing based on elapsed time. Default: 5s
  • flush-trigger-size: The number of bytes that will trigger the buffer to flush. Set to 0 to disable flushing based on accumulated size. Default: 1MiB
  • max-buffer-size: The maximum size of the buffer: new log messages received when the buffer is full cause older messages to be dropped. Default: 50MiB
When max-staleness and flush-trigger-size are used together, whichever is reached first will trigger the flush. buffering is enabled by default for HTTP log sinks. To explicitly disable log buffering, specify buffering: NONE instead. This setting is typically disabled for . See Log buffering for more details and usage.
For an example network logging configuration, see . For an example that uses compression, headers, file-based-headers, and buffering parameters, see .

​
Output to OTLP-compatible network collectors

CockroachDB can send logs to an OpenTelemetry-compatible server using the OTLP protocol (e.g., Datadog agent). For a complete list of log servers that support the OTLP protocol, see the OpenTelemetry registry. Define otlp-servers to select channels and configure connection and protocol details. For example:
Along with the common sink parameters, each OTLP server accepts the following additional parameters:
ParameterDescription
channelsList of channels that output to this sink. Use a YAML array or string of , ALL, or ALL EXCEPT {channels}. See Logging channel selection for syntax.
addressNetwork address of the OTLP collector endpoint for log ingestion, formatted as {host}:{port}.
modeProtocol used to export logs. Valid values grpc or http. Default:grpc
headersMap of key-value string pairs which will be appended to every request as custom gRPC or HTTP headers depending on the mode selected. For example, "x-api-key": "YOUR\_API\_KEY\_HERE".
compressionCompression for requests. Valid values gzip or none. Default:gzip
bufferingConfigures buffering of log messages for the sink, with the following sub-parameters:
  • max-staleness: The maximum time a log message will wait in the buffer before a flush is triggered. Set to 0 to disable flushing based on elapsed time. Default: 5s
  • flush-trigger-size: The number of bytes that will trigger the buffer to flush. Set to 0 to disable flushing based on accumulated size. Default: 1MiB
  • max-buffer-size: The maximum size of the buffer: new log messages received when the buffer is full cause older messages to be dropped. Default: 50MiB
When max-staleness and flush-trigger-size are used together, whichever is reached first will trigger the flush. buffering is enabled by default for OTLP log sinks. To explicitly disable log buffering, specify buffering: NONE instead. This setting is typically disabled for . See Log buffering for more details and usage.
For an example network logging configuration, see .

​
Output to stderr

CockroachDB can output messages to the standard error stream (stderr), which prints them to the machine’s terminal but does not store them. stderr specifies the channels that output to the stream. For example:
Along with the common sink parameters, stderr accepts the following additional parameters:
The format parameter for stderr can be set to any one of the valid . It is set to by default.
ParameterDescription
channelsList of channels that output to this sink. Use a YAML array or string of , ALL to include all channels, or ALL EXCEPT {channels} to include all channels except the specified channel names. For more details on acceptable syntax, see Logging channel selection.
no-colorWhen true, removes terminal color escape codes from the output.
Because server start-up messages are always emitted at the start of the standard error stream, it is generally difficult to automate integration of stderr with log analyzers. We recommend using file logging or network logging via Fluentd or HTTP instead of stderr when integrating with automated monitoring software.
By default, cockroach start and cockroach start-single-node do not print any messages to stderr. However, if the cockroach process does not have access to on-disk storage, all messages are printed to stderr.

​
Logging channel selection

Log channels cannot be completely disabled. You can configure and , but you cannot turn off a log channel entirely. For example, a channel that is not explicitly configured for a is enabled in the default file group. For each sink, multiple channels can be selected. Note that:
  • Spacing between items will vary according to the syntax used.
  • Channel selection is case-insensitive.
These selections are equivalent:
By default, the severity level set by filter in the sink configuration is used. However, you can specify a different severity level for each channel. For more information on severity levels, see Set logging levels. These selections are equivalent:
Brackets are optional when selecting a single channel:
To select all channels, using the all keyword:
To select all channels except for a subset, using the all except keyword prefix:

​
Configure logging defaults

When setting up a logging configuration, it’s simplest to define shared parameters in file-defaults, fluent-defaults, http-defaults, and otlp-defaults and override specific values as needed in file-groups, fluent-servers, http-servers, otlp-servers and stderr. For a complete example, see the default configuration.
You can verify your current settings by running cockroach debug check-log-config with the applicable logging flag. The command returns the YAML definitions and a URL to a visualization of the logging configuration.
This section describes some recommended defaults.

​
Set file defaults

Defaults for log files are set in file-defaults, which accepts all common sink parameters and the file group parameters dir, max-file-size, max-group-size, file-permissions, and buffered-writes.

​
Logging directory

By default, CockroachDB adds log files to a logs subdirectory in the first on-disk (default: cockroach-data):
Each Cockroach node generates log files in the directory specified by its logging configuration. These logs detail the internal activity of that node without visibility into the behavior of other nodes. When troubleshooting, it’s best to refer to the output directory for the cluster log files, which collect the messages from all active nodes.
In cloud deployments, the will be subject to an IOPS budget. Adding logs to the store directory will excessively consume IOPS. For this reason, cloud deployments should output log files to a separate directory with fewer IOPS restrictions. You can override the default logging directory like this:

​
File logging format

The default message format for log files is . Each crdb-v2 log message starts with a flat prefix that contains event metadata (e.g., severity, date, timestamp, channel), followed by the event payload. For details on the metadata, see . If you plan to read logs programmatically, you can switch to a or format:
format refers to the envelope of the log message, which contains the event metadata. This is separate from the event payload, which corresponds to its .

​
Set Fluentd defaults

Defaults for Fluentd-compatible network sinks are set in fluent-defaults, which accepts all common sink parameters. Note that the server parameters address and net are not specified in fluent-defaults:
  • address must be specified for each sink under fluent-servers.
  • net is not required and defaults to tcp.

​
Fluentd logging format

The default message format for network output is . Each log message is structured as a JSON payload that can be read programmatically. The json-fluent-compact and formats include a tag field that is required by the Fluentd protocol. For details, see .
format refers to the envelope of the log message. This is separate from the event payload, which is structured according to .

​
Set HTTP defaults

Defaults for HTTP sinks are set in http-defaults, which accepts all common sink parameters. Note that the server parameters address and method are not specified in http-defaults:
  • address must be specified for each sink under http-servers.
  • method is not required and defaults to POST.

​
HTTP logging format

The default message format for HTTP output is . Each log message is structured as a JSON payload that can be read programmatically. For details, see .
format refers to the envelope of the log message. This is separate from the event payload, which is structured according to .

​
Set OTLP defaults

Defaults for OTLP sinks are set in otlp-defaults, which accepts all common sink parameters. Note that the server parameter addressis not specified in otlp-defaults. The address must be specified for each sink under otlp-servers.

​
OTLP logging format

The default message format for OTLP output is . Each log message is structured as a JSON payload that can be read programmatically. For details, see .
format refers to the envelope of the log message. This is separate from the event payload, which is structured according to .

​
Set logging levels

Log messages are associated with a when they are generated. Each logging sink accepts messages from each logging channel at a minimum severity level. This minimum severity level can be specified per sink or by default using the filter attribute. Messages with severity levels below the configured threshold do not enter logging channels and are discarded. The default configuration uses the following severity levels for and :
  • file-defaults, fluent-defaults, and http-defaults each use filter: INFO. Since INFO is the lowest severity level, file and network sinks will emit all log messages.
  • stderr uses filter: NONE and does not emit log messages.
  • The default file group uses filter: INFO for events from the DEV and OPS channels, and filter: WARNING for all others.
All other cockroach commands use filter: WARNING and log to stderr by default, with these exceptions:
  • uses filter: INFO.
  • uses filter: NONE (discards all log messages).
You can override the file-defaults, fluent-defaults, and http-defaults severity levels on a per-sink basis. For example, this will include DEV events at severity WARNING:
You can also override the filter attribute and set severity levels on a per-channel basis. For example, this will include DEV events at severity INFO, and OPS events at severity ERROR:

​
Set timezone

Using the format-options sink parameter, you may set the timezone for a specified log format.

​
timezone for text formats

The log output formats and support the format option timezone. When specified, the corresponding timezone is used to produce the timestamp column. The value can be any timezone name recognized by the Go standard library. For example:
The timezone offset is included with the timestamp to ensure that the times can be read back precisely. Example logging output:

​
datetime field for JSON format

The log output format supports the format options datetime-format and datetime-timezone. datetime-format controls whether a datetime field with human-readable timestamp values is included in the logs. Valid values for this option are:
  • none: Disable the creation of the datetime field. This is the default value.
  • iso8601 or rfc3339: Format the timestamp like “2006-01-02T15:04:05.999999999Z”.
  • rfc1123: Format the timestamp like “Mon, 02 Jan 2006 15:04:05 +0000”.
The existing timestamp field with epoch values remains unchanged for backward-compatibility. datetime-timezone selects which timezone to use when formatting the datetime field. The value can be any timezone name recognized by the Go standard library. The default value is UTC. datetime-timezone must be combined with datetime-format set to a valid format since the default value for the datetime-format option is none and therefore the datetime field is not included by default. For example:
Example logging output:
Enabling the datetime field introduces CPU overhead and is nearly always unnecessary.When sending output to a log collector (for example, via Fluent or Datadog), the log collector can be configured to transform the epoch values in the timestamp field into a human-readable format.When inspecting a formatted log file produced by CockroachDB, you can use the command to convert the log into format which includes timestamps in the rfc3339 format.

​
Redact logs

CockroachDB can redact personally identifiable information (PII) from log messages. The logging system includes two parameters that handle this differently:
  • redact is disabled by default. When enabled, redact automatically redacts sensitive data from logging output. We do not recommend enabling this on the DEV channel because it impairs our ability to troubleshoot problems.
  • redactable is enabled by default. This places redaction markers around sensitive fields in log messages. These markers are recognized by and , which aggregate CockroachDB log files and can be instructed to redact sensitive data from their output.
When collecting logs centrally (e.g., in data mining scenarios where non-privileged users have access to logs) or over a network (e.g., to an external log collector), it’s safest to enable redact:
In addition, the DEV channel should be output to a separate logging directory, since it is likely to contain sensitive data. See DEV channel.
External log collectors can misinterpret the cockroach debug redaction markers (< >), since they are specific to CockroachDB. To prevent this issue when using network sinks, disable redactable:
If the default redaction behavior and policies do not meet redaction requirements, we recommend using the external log collectors with the redaction markers (< >) to redact. In this case, enable redactable.

​
DEV channel

The DEV channel is used for debug and uncategorized messages. It can therefore be noisy and contain sensitive (PII) information. We recommend configuring DEV separately from the other logging channels. When sending logs to a Fluentd-compatible or HTTP network collector, DEV logs should also be excluded from network collection. In this example, the dev file group is reserved for DEV logs. These are output to a cockroach-dev.log file in a custom disk dir:
To ensure that you are protecting sensitive information, also redact your logs.

​
Log buffering for network sinks

The network (Fluentd-compatible, HTTP, and OTLP-compatible) log sinks support the buffering of log messages by default. With log buffering configured, log messages are held in a buffer for a configurable time period or accumulated message size threshold before being written to the target log sink together as a batch. Log buffering helps to ensure consistent low-latency log message writes over the network even in high-traffic, high-contention scenarios. The following shows a basic log configuration with buffering configured for a Fluentd-compatible log sink:
With this logging configuration:
  • CockroachDB will hold log messages in a buffer for up to 20s (the max-staleness setting), or up to a collected size of 2MiB (the flush-trigger-size setting), before writing (“flushing”) the buffer to the log file. When both settings are used, whichever case is met first triggers the buffer flush.
  • If at any point the accumulated message size of buffer flushes (as triggered by reaching either the configured max-staleness or flush-trigger-size value) exceeds 100MiB (the max-buffer-size setting), all new incoming log messages received are dropped until the accumulated message size in the buffer once more falls below this value.
  • For the HEALTH only, override the file-defaults value of 20s for max-staleness, instead flushing messages to the log file within up to 2s.
Logs are flushed automatically upon CockroachDB startup only if CockroachDB is managed using systemd. Alternatively, you may explicitly disable log buffering by setting buffering to NONE. The following log configuration explicitly disables log buffering for just the OPS channel on a Fluentd-compatible log sink:
The following disables log buffering completely for the Fluentd-compatible sink:

​
Stray error capture

Certain events, such as uncaught software exceptions (panics), bypass the CockroachDB logging system. However, they can be useful in troubleshooting. For example, if CockroachDB crashes, it normally logs a stack trace to what caused the problem. To ensure that these stray errors can be tracked, CockroachDB does not send them to stderr by default. Instead, stray errors are output to a cockroach-stderr.log file in the default logging directory. You can change these settings in capture-stray-errors:
When capture-stray-errors is disabled, redactable cannot be enabled on the stderr sink. This is because stderr will contain both stray errors and logged events and cannot apply redaction markers in a reliable way. Note that redact can still be enabled on stderr in this case.

​
Default logging configuration

The YAML payload below represents the default logging behavior of and .
For high-traffic deployments that output log messages to files, consider raising file-defaults: {max-group-size} to 500MiB or 1GiB to extend log retention.
Note that a default dir is not specified for file-defaults and capture-stray-errors:
  • The default dir for file-defaults is inferred from the first on-disk . See Logging directory.
  • The default dir for capture-stray-errors is inherited form file-defaults.

​
See also