kibana/docs/reference/configuration-reference/logging-settings.md
Maryam Saeidi 3d86a175d7
Extend default log pattern on server-side to include error information (#219940)
## Release Notes
Kibana logging's pattern layout, used by default for the console
appender, will now use a new default pattern layout
`[%date][%level][%logger] %message %error`. This will include the error
name and stack trace if these were included in the log entry. To opt out
of this behavior users can omit the `%error` placeholder from their log
pattern config in kibana.yml e.g.:
```
logging:
  appenders:
    console:
      type: console
      layout:
        type: pattern
        pattern: "[%date][%level][%logger] %message"
```

## Summary

Previously, when we pass the error in meta, the information related to
stacktrace and error message was not available in console. This PR
changed the default pattern to also include error information if it is
provided in meta (similar to the way that the logging happens when error
is directly passed to logger.error).

New pattern: (added `%error` at the end)
```
[%date][%level][%logger] %message %error
```

Here you can see the difference:

Logger:

```
server.logger.error(
        `Unable to create Synthetics monitor ${monitorWithNamespace[ConfigKey.NAME]}`,
        { error: e }
      );
```

#### Before


![image](https://github.com/user-attachments/assets/4f3ff751-84d5-4b5b-b6a9-d49f868a9606)

#### After


![image](https://github.com/user-attachments/assets/e22b8e45-1b0a-4d8c-b51d-5dfb3938da4f)


### Alternative
We could also change the MetaConversion and include this information,
but we might have additional meta information which I am not sure if it
is OK to be logged by default. Let me know if you prefer changing
MetaConversion instead of adding a new error conversion.

<details>
<summary>Code changes for MetaConversion</summary>

```
function isError(x: any): x is Error {
  return x instanceof Error;
}

export const MetaConversion: Conversion = {
  pattern: /%meta/g,
  convert(record: LogRecord) {
    if (!record.meta) {
      return '';
    }
    const { error, ...rest } = record.meta;
    const metaString = Object.keys(rest).length !== 0 ? JSON.stringify(rest) : '';
    let errorString = '';

    if (isError(record.meta?.error)) {
      errorString = record.meta?.error.stack || '';
    }

    return [metaString, errorString].filter(Boolean).join(' ');
  },
};
```
</details>

Here is how adjusting meta will look like in this case:


![image](https://github.com/user-attachments/assets/d7dce9bc-7147-472d-b434-373322f41bbf)
2025-05-22 16:57:42 +02:00

80 lines
No EOL
8.3 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

---
mapped_pages:
- https://www.elastic.co/guide/en/kibana/current/logging-settings.html
- https://github.com/elastic/cloud/blob/master/docs/cloud-enterprise/ce-kibana-logging-settings.asciidoc
applies_to:
deployment:
self: all
---
# Logging settings [logging-settings]
You do not need to configure any additional settings to use the logging features in {{kib}}. Logging is enabled by default and will log at `info` level using the `pattern` layout, which outputs logs to `stdout`.
However, if you are planning to ingest your logs using Elasticsearch or another tool, we recommend using the `json` layout, which produces logs in ECS format. In general, `pattern` layout is recommended when raw logs will be read by a human, and `json` layout when logs will be read by a machine.
::::{note}
The logging configuration is validated against the predefined schema and if there are any issues with it, {{kib}} will fail to start with the detailed error message.
::::
{{kib}} relies on three high-level entities to set the logging service: appenders, loggers, and root. These can be configured in the `logging` namespace in `kibana.yml`.
* Appenders define where log messages are displayed (stdout or console) and their layout (`pattern` or `json`). They also allow you to specify if you want the logs stored and, if so, where (file on the disk).
* Loggers define what logging settings, such as the level of verbosity and the appenders, to apply to a particular context. Each log entry context provides information about the service or plugin that emits it and any of its sub-parts, for example, `metrics.ops` or `elasticsearch.query`.
* Root is a logger that applies to all the log entries in {{kib}}.
The following table serves as a quick reference for different logging configuration keys. Note that these are not stand-alone settings and may require additional logging configuration. See the [Configure Logging in {{kib}}](docs-content://deploy-manage/monitor/logging-configuration/kibana-logging.md) guide and complete [examples](docs-content://deploy-manage/monitor/logging-configuration/kibana-log-settings-examples.md) for common configuration use cases.
| | |
| --- | --- |
| `logging.appenders[].<appender-name>` | Unique appender identifier. |
| `logging.appenders[].console:` | Appender to use for logging records to **stdout**. By default, uses the `[%date][%level][%logger] %message %error` **pattern*** layout. To use a ***json**, set the [layout type to `json`](docs-content://deploy-manage/monitor/logging-configuration/kibana-log-settings-examples.md#log-in-json-ecs-example). |
| `logging.appenders[].file:` | Allows you to specify a fileName to write log records to disk. To write [all log records to file](docs-content://deploy-manage/monitor/logging-configuration/kibana-log-settings-examples.md#log-to-file-example), add the file appender to `root.appenders`. If configured, you also need to specify [`logging.appenders.file.pathName`](docs-content://deploy-manage/monitor/logging-configuration/kibana-log-settings-examples.md#log-to-file-example). |
| `logging.appenders[].rolling-file:` | Similar to [Log4js](https://logging.apache.org/log4j/2.x/) `RollingFileAppender`, this appender will log to a file and rotate if following a rolling strategy when the configured policy triggers. There are currently two policies supported: [`size-limit`](docs-content://deploy-manage/monitor/logging-configuration/kibana-logging.md#size-limit-triggering-policy) and [`time-interval`](docs-content://deploy-manage/monitor/logging-configuration/kibana-logging.md#time-interval-triggering-policy). |
| `logging.appenders[].<appender-name>.type` | The appender type determines where the log messages are sent. Options are `console`, `file`, `rewrite`, `rolling-file`. Required. |
| `logging.appenders[].<appender-name>.fileName` | Determines the filepath where the log messages are written to for file and rolling-file appender types. Required for appenders that write to file. |
| `logging.appenders[].<appender-name>.policy.type` | Specify the triggering policy for when a rollover should occur for the `rolling-file` type appender. |
| `logging.appenders[].<appender-name>.policy.interval` | Specify the time interval for rotating a log file for a `time-interval` type `rolling-file` appender. **Default 24h** |
| `logging.appenders[].<appender-name>.policy.size` | Specify the size limit at which the policy should trigger a rollover for a `size-limit` type `rolling-file` appender. **Default 100mb**. |
| `logging.appenders[].<appender-name>.policy.interval` | Specify the time interval at which the policy should trigger a rollover for a time-interval type `rolling-file` appender. |
| `logging.appenders[].<appender-name>.policy.modulate` | Whether the interval should be adjusted to cause the next rollover to occur on the interval boundary. Boolean. Default `true`. |
| `logging.appenders[].<appender-name>.strategy.type` | Rolling file strategy type. Only `numeric` is currently supported. |
| `logging.appenders[].<appender-name>.strategy.pattern` | The suffix to append to the file path when rolling. Must include `%i`. |
| `logging.appenders[].<appender-name>.strategy.max` | The maximum number of files to keep. Optional. Default is `7` and the maximum is `100`. |
| `logging.appenders[].<appender-name>.layout.type` | Determines how the log messages are displayed. Options are `pattern`, which provides human-readable output, or `json`, which provides ECS-compliant output. Required. |
| `logging.appenders[].<appender-name>.layout.highlight` | Optional boolean to highlight log messages in color. Applies to `pattern` layout only. Default is `false`. |
| `logging.appenders[].<appender-name>.layout.pattern` | Optional [string pattern](docs-content://deploy-manage/monitor/logging-configuration/kibana-logging.md#pattern-layout) for placeholders that will be replaced with data from the actual log message. Applicable to pattern type layout only. |
| `logging.root.appenders[]` | List of specific appenders to apply to `root`. Defaults to `console` with `pattern` layout. |
| `logging.root.level` | Specify default verbosity for all log messages to fall back to if not specifically configured at the individual logger level. Options are `all`, `fatal`, `error`, `warn`, `info`, `debug`, `trace`, `off`. The `all` and `off` levels can be used only in configuration and are just handy shortcuts that allow you to log every log record or disable logging entirely or for a specific logger. Default is `info`. |
| `logging.loggers[].<logger>.name:` | Specific logger instance. |
| `logging.loggers[].<logger>.level` | Specify verbosity of log messages for <logger> context. Optional and inherits the verbosity of any ancestor logger, up to the `root` logger `level`. |
| `logging.loggers[].<logger>.appenders` | Determines the appender to apply to a specific logger context as an array. Optional and falls back to the appender(s) of the `root` logger if not specified. |
| $$$enable-http-debug-logs$$$ `deprecation.enable_http_debug_logs` | Optional boolean to log debug messages when a deprecated API is called. Default is `false`. |
## Logging and audit settings [logging-and-audit-settings]
To update these settings, refer to [APM settings](/reference/configuration-reference/apm-settings.md).
`logging.verbose`
: If set to _true_, all events are logged, including system usage information and all requests. Defaults to _false_.
`logging.quiet`
: If set to _true_, all logging output other than error messages is suppressed. Defaults to _false_.
`elasticsearch.logQueries`
: When set to _true_, queries sent to Elasticsearch are logged (requires `logging.verbose` set to _true_). Defaults to _false_.
`xpack.security.audit.enabled`
: When set to _true_, audit logging is enabled for security events. Defaults to _false_.
`xpack.security.audit.appender.type`
: When set to _"rolling-file"_ and `xpack.security.audit.enabled` is set to _true_, Kibana ECS audit logs are enabled.
Beginning with version 8.0, this setting is no longer necessary for ECS audit log output; it's only necessary to set `xpack.security.audit.enabled` to `true`
`xpack.security.audit.ignore_filters`
: List of filters that determine which audit events should be excluded from the ECS audit log.
`xpack.security.audit.appender.kind`
: When set to _"rolling-file"_ and `xpack.security.audit.enabled` is set to _true_, Kibana ECS audit logs are enabled.