---
title: Logging settings
description: 
url: https://www.elastic.co/elastic/docs-builder/docs/3244/reference/kibana/configuration-reference/logging-settings
products:
  - Kibana
applies_to:
  - Self-managed Elastic deployments: Generally available
---

# Logging settings
You do not need to configure any additional settings to use the logging features in Kibana. 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, Kibana will fail to start with the detailed error message.
</note>

Kibana 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), or shipped to an OpenTelemetry (OTLP) endpoint.
- 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 Kibana.

For details on audit logging settings, refer to the [Kibana security settings](/elastic/docs-builder/docs/3244/reference/kibana/configuration-reference/security-settings#audit-logging-settings).

## Logging settings

The following list 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 Kibana](https://www.elastic.co/docs/deploy-manage/monitor/logging-configuration/kibana-logging) guide and complete [examples](https://www.elastic.co/docs/deploy-manage/monitor/logging-configuration/kibana-log-settings-examples) for common configuration use cases.
<definitions>
  <definition term="logging.appenders[].&lt;appender-name&gt;">
    <supported-on>Self-managed Elastic deployments: Generally available</supported-on>

Unique appender identifier.
Datatype: `string`
  </definition>
  <definition term="logging.appenders[].console">
    <supported-on>Self-managed Elastic deployments: Generally available</supported-on>

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`](https://www.elastic.co/docs/deploy-manage/monitor/logging-configuration/kibana-log-settings-examples#log-in-json-ecs-example).
<applies-to>Elastic Stack: Generally available since 9.1</applies-to> `%error` is present since Stack version 9.1.
Datatype: `string`
  </definition>
  <definition term="logging.appenders[].file">
    <supported-on>Self-managed Elastic deployments: Generally available</supported-on>

Allows you to specify a fileName to write log records to disk. To write [all log records to file](https://www.elastic.co/docs/deploy-manage/monitor/logging-configuration/kibana-log-settings-examples#log-to-file-example), add the file appender to `root.appenders`. If configured, you also need to specify [`logging.appenders.file.pathName`](https://www.elastic.co/docs/deploy-manage/monitor/logging-configuration/kibana-log-settings-examples#log-to-file-example).
Datatype: `string`
  </definition>
  <definition term="logging.appenders[].rolling-file">
    <supported-on>Self-managed Elastic deployments: Generally available</supported-on>

Similar to [Log4j's](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`](https://www.elastic.co/docs/deploy-manage/monitor/logging-configuration/kibana-logging#size-limit-triggering-policy) and [`time-interval`](https://www.elastic.co/docs/deploy-manage/monitor/logging-configuration/kibana-logging#time-interval-triggering-policy).
Datatype: `string`
  </definition>
  <definition term="logging.appenders[].otel">
    <stack-availability>Elastic Stack: Planned</stack-availability>
    <supported-on>Self-managed Elastic deployments: Generally available</supported-on>

Ships log records to an OpenTelemetry-compatible (OTLP) endpoint over HTTP, Protobuf, or gRPC. Records are buffered by the OpenTelemetry SDK's `BatchLogRecordProcessor` and flushed periodically or on shutdown.
To forward all logs to an OTLP endpoint, add the appender to `logging.root.appenders`:
```yaml
logging:
  appenders:
    otlp:
      type: otel
      protocol: proto
      url: https://collector:4318/v1/logs
      headers:
        Authorization: 'Bearer <token>'
      attributes:
        '[deployment.environment]': production
  root:
    appenders: [default, otlp]
```

Datatype: `string`
  </definition>
  <definition term="logging.appenders[].&lt;appender-name&gt;.type">
    <supported-on>Self-managed Elastic deployments: Generally available</supported-on>

The appender type determines where the log messages are sent. Required.
Datatype: `enum`
Options:
- `console`
- `file`
- `otel`
- `rewrite`
- `rolling-file`
  </definition>
  <definition term="logging.appenders[].&lt;appender-name&gt;.fileName">
    <supported-on>Self-managed Elastic deployments: Generally available</supported-on>

Determines the filepath where the log messages are written to for file and rolling-file appender types. Required for appenders that write to file.
Datatype: `string`
  </definition>
  <definition term="logging.appenders[].&lt;appender-name&gt;.policy.type">
    <supported-on>Self-managed Elastic deployments: Generally available</supported-on>

Specify the triggering policy for when a rollover should occur for the `rolling-file` type appender.
Datatype: `string`
  </definition>
  <definition term="logging.appenders[].&lt;appender-name&gt;.policy.interval">
    <supported-on>Self-managed Elastic deployments: Generally available</supported-on>

Specify the time interval for rotating a log file for a `time-interval` type `rolling-file` appender.
Datatype: `string`
Default: `24h`
  </definition>
  <definition term="logging.appenders[].&lt;appender-name&gt;.policy.size">
    <supported-on>Self-managed Elastic deployments: Generally available</supported-on>

Specify the size limit at which the policy should trigger a rollover for a `size-limit` type `rolling-file` appender.
Datatype: `string`
Default: `100mb`
  </definition>
  <definition term="logging.appenders[].&lt;appender-name&gt;.policy.modulate">
    <supported-on>Self-managed Elastic deployments: Generally available</supported-on>

Whether the interval should be adjusted to cause the next rollover to occur on the interval boundary.
Datatype: `bool`
Default: `true`
  </definition>
  <definition term="logging.appenders[].&lt;appender-name&gt;.strategy.type">
    <supported-on>Self-managed Elastic deployments: Generally available</supported-on>

Rolling file strategy type. Only `numeric` is currently supported.
Datatype: `string`
  </definition>
  <definition term="logging.appenders[].&lt;appender-name&gt;.strategy.pattern">
    <supported-on>Self-managed Elastic deployments: Generally available</supported-on>

The suffix to append to the file path when rolling. Must include `%i`.
Datatype: `string`
  </definition>
  <definition term="logging.appenders[].&lt;appender-name&gt;.strategy.max">
    <supported-on>Self-managed Elastic deployments: Generally available</supported-on>

The maximum number of files to keep. The maximum is `100`.
Datatype: `int`
Default: `7`
  </definition>
  <definition term="logging.appenders[].&lt;appender-name&gt;.url">
    <stack-availability>Elastic Stack: Planned</stack-availability>
    <supported-on>Self-managed Elastic deployments: Generally available</supported-on>

The OTLP endpoint URL to which log records are shipped. Required for the `otel` appender type.
The expected path depends on the chosen protocol:
- HTTP/Protobuf (`http` or `proto`): typically ends in `/v1/logs`. For example, `https://collector:4318/v1/logs`.
- gRPC (`grpc`): a bare host and port without a path. For example, `https://collector:4317`.

Datatype: `string`
  </definition>
  <definition term="logging.appenders[].&lt;appender-name&gt;.protocol">
    <stack-availability>Elastic Stack: Planned</stack-availability>
    <supported-on>Self-managed Elastic deployments: Generally available</supported-on>

The transport protocol used to send log records to the OTLP endpoint. Applies to the `otel` appender type only.
- `proto` (default): OTLP over HTTP using Protobuf encoding. More compact than `http` (JSON) and more broadly compatible than `grpc`, which requires HTTP/2.
- `http`: OTLP over HTTP using JSON encoding.
- `grpc`: OTLP over gRPC. Headers must be provided as gRPC metadata key-value pairs.

Datatype: `enum`
Default: `proto`
Options:
- `proto`
- `http`
- `grpc`
  </definition>
  <definition term="logging.appenders[].&lt;appender-name&gt;.headers">
    <stack-availability>Elastic Stack: Planned</stack-availability>
    <supported-on>Self-managed Elastic deployments: Generally available</supported-on>

Optional map of HTTP headers sent with every request to the OTLP endpoint. Applies to the `otel` appender type only. Commonly used for authentication. For example, `Authorization: 'Bearer <token>'` or `Authorization: 'ApiKey <base64>'`.
For the `grpc` protocol the key-value pairs are sent as gRPC metadata instead of HTTP headers.
<warning>
  Header values are stored in plain text in `kibana.yml`. Use a secrets management solution or environment-variable substitution to avoid exposing credentials.
</warning>

Datatype: `object`
  </definition>
  <definition term="logging.appenders[].&lt;appender-name&gt;.attributes">
    <stack-availability>Elastic Stack: Planned</stack-availability>
    <supported-on>Self-managed Elastic deployments: Generally available</supported-on>

Optional map of additional OpenTelemetry resource attributes merged on top of the auto-detected host, process, OS, and service attributes. Applies to the `otel` appender type only. Can be used to set or override attributes such as `service.name` or `deployment.environment`.
Because Kibana expands dotted YAML keys into nested objects, wrap dotted attribute names in square brackets:
```yaml
attributes:
  '[service.name]': my-kibana
  '[deployment.environment]': production
```

Datatype: `object`
  </definition>
  <definition term="logging.appenders[].&lt;appender-name&gt;.layout.type">
    <supported-on>Self-managed Elastic deployments: Generally available</supported-on>

Determines how the log messages are displayed. Required.
Datatype: `enum`
Options:
- `pattern`: Provides human-readable output.
- `json`: Provides ECS-compliant output.
  </definition>
  <definition term="logging.appenders[].&lt;appender-name&gt;.layout.highlight">
    <supported-on>Self-managed Elastic deployments: Generally available</supported-on>

Optional boolean to highlight log messages in color. Applies to `pattern` layout only.
Datatype: `bool`
Default: `false`
  </definition>
  <definition term="logging.appenders[].&lt;appender-name&gt;.layout.pattern">
    <supported-on>Self-managed Elastic deployments: Generally available</supported-on>

Optional [string pattern](https://www.elastic.co/docs/deploy-manage/monitor/logging-configuration/kibana-logging#pattern-layout) for placeholders that will be replaced with data from the actual log message. Applicable to pattern type layout only.
Datatype: `string`
  </definition>
  <definition term="logging.root.appenders[]">
    <supported-on>Self-managed Elastic deployments: Generally available</supported-on>

List of specific appenders to apply to `root`. Defaults to `console` with `pattern` layout.
Datatype: `string`
  </definition>
  <definition term="logging.root.level">
    <supported-on>Elastic Cloud Hosted: Generally available, Self-managed Elastic deployments: Generally available</supported-on>

Specify default verbosity for all log messages to fall back to if not specifically configured at the individual logger level. 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.
Datatype: `enum`
Default: `info`
Options:
- `all`
- `fatal`
- `error`
- `warn`
- `info`
- `debug`
- `trace`
- `off`
  </definition>
  <definition term="logging.loggers[].&lt;logger&gt;.name">
    <supported-on>Self-managed Elastic deployments: Generally available</supported-on>

Specific logger instance.
Datatype: `string`
  </definition>
  <definition term="logging.loggers[].&lt;logger&gt;.level">
    <supported-on>Self-managed Elastic deployments: Generally available</supported-on>

Specify verbosity of log messages for a logger context. Optional and inherits the verbosity of any ancestor logger, up to the `root` logger `level`.
Datatype: `enum`
Options:
- `all`
- `fatal`
- `error`
- `warn`
- `info`
- `debug`
- `trace`
- `off`
  </definition>
  <definition term="logging.loggers[].&lt;logger&gt;.appenders">
    <supported-on>Self-managed Elastic deployments: Generally available</supported-on>

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.
Datatype: `string`
  </definition>
  <definition term="deprecation.enable_http_debug_logs">
    <supported-on>Self-managed Elastic deployments: Generally available</supported-on>

Optional boolean to log debug messages when a deprecated API is called.
Datatype: `bool`
Default: `false`
  </definition>
</definitions>