配置日志

Kibana 日志系统有三个主要组件：记录器、追加器和布局。 这些组件允许我们根据消息类型和级别记录消息，控制这些消息的格式以及最终日志的显示或存储位置。

记录器定义应将哪些日志设置应用于特定记录器。

追加器定义日志消息的显示位置（例如，标准输出或控制台）和存储位置（例如，磁盘上的文件）。

布局定义日志消息的格式以及它们包含的信息类型。

目前我们支持以下日志级别：off、fatal、error、warn、info、debug、trace、all。

级别是有序的，所以 off > fatal > error > warn > info > debug > trace > all。

如果日志记录的级别高于或等于其记录器的级别，则该日志记录将被记录器记录。例如：如果 API 调用的输出配置为在 info 级别记录，并且传递给 API 调用的参数设置为 debug，并且 kibana.yml 中的全局日志配置设置为 debug，则输出和参数都会被记录。 如果日志级别设置为 info，则会忽略调试日志，这意味着你只会获得 API 输出的记录，而不会获得参数的记录。

无论 root 记录器级别如何，始终会遵循在插件级别设置的日志记录。换句话说，如果根记录器设置为致命，并且 pluginA 日志记录设置为 debug，则调试日志仅针对 pluginA 显示，而其他日志仅报告 fatal。

all 和 off 级别只能在配置中使用，它们是方便的快捷方式，允许你记录每个日志记录或完全禁用特定记录器的日志记录。这些级别也可以使用 cli 参数指定。

每个追加器都应该准确地知道如何在写入控制台或磁盘上的文件之前格式化日志消息。此行为由布局控制，并通过每个自定义追加器的 appender.layout 配置属性进行配置。目前我们没有为自定义追加器定义任何默认布局，因此应该始终明确地做出选择。

目前支持两种类型的布局：pattern 和 json。

使用 pattern 布局，可以使用特殊占位符 %conversion_pattern 定义字符串模式，这些占位符将被实际日志消息中的数据替换。默认情况下，使用以下模式：[%date][%level][%logger] %message。

开箱即用的转换如下

level 输出日志事件的级别。%level 输出示例：TRACE、DEBUG、INFO。

logger 输出发布日志事件的记录器的名称。 %logger 输出示例：server、server.http、server.http.kibana。

message 输出与日志事件关联的应用程序提供的消息。

meta 如果事件中存在 meta 对象数据，则以 json 格式输出其条目。 %meta 输出示例

// Meta{from: 'v7', to: 'v8'}
'{"from":"v7","to":"v8"}'
// Meta empty object
'{}'
// no Meta provided
''

date 输出日志事件的日期。 日期转换说明符后可以跟一对大括号，其中包含预定义的日期格式和规范时区名称的名称。 时区名称应为 TZ 数据库名称中的一个。如果未明确指定，则时区默认为主机时区。 %date 输出示例

pid 输出进程 ID。

模式布局还提供 highlight 选项，允许你使用不同的颜色突出显示日志消息的某些部分。如果日志消息被转发到支持颜色的终端，则突出显示非常方便。

使用 json 布局，日志消息将以 ECS 格式格式化为 JSON 字符串，其中包含时间戳、日志级别、记录器、消息文本以及可能与日志消息本身关联的任何其他元数据。

每个记录器都有一个唯一的名称，该名称遵循分层命名规则。如果记录器的名称后跟一个 . 是后代记录器的前缀，则该记录器被认为是另一个记录器的祖先。例如，名为 a.b 的记录器是记录器 a.b.c 的祖先。所有顶级记录器都是记录器层次结构顶部的特殊 root 记录器的后代。 root 记录器始终存在，已完全配置，默认情况下记录到 info 级别。 如果在 kibana.yml 中指定任何其他日志配置，则还必须配置 root 记录器。

你可以为特定的记录器配置日志级别和追加器。如果一个记录器只配置了日志级别，那么应用于该记录器的追加器配置将从祖先记录器继承，直到 root 记录器。

Root

root 记录器具有专用的配置节点，因为此记录器是特殊的，应始终存在。默认情况下，root 配置为 info 级别和 default 追加器，该追加器也始终可用。这是所有自定义记录器将使用的配置，除非它们被显式重新配置。

例如，要查看回退到 root 记录器配置的所有日志消息，只需向配置添加一行

logging.root.level: all

或者使用 off 完全禁用日志记录

logging.root.level: off

指标日志

metrics.ops 记录器配置为 debug 级别，并且将以规则的间隔自动输出示例系统和进程信息。记录的指标是收集的数据的子集，并按以下格式在日志消息中格式化

日志间隔与系统和进程信息刷新的间隔相同，并且可以在 ops.interval 下配置

ops.interval: 5000

最小间隔为 100 毫秒，默认值为 5000 毫秒。

请求和响应日志

http.server.response 记录器配置为 debug 级别，并且将自动输出有关 Kibana 服务器上发生的 http 请求和响应的数据。该消息包含一些高级信息，相应的日志元数据包含以下内容

与 Log4j 的 RollingFileAppender 类似，此追加器将记录到文件中，并在配置的策略触发时按照滚动策略进行轮换。

触发策略确定何时应发生轮换。

目前支持两种策略：size-limit 和 time-interval。

大小限制触发策略

此策略将在文件达到预定大小时轮换该文件。

logging:
  appenders:
    rolling-file:
      type: rolling-file
      fileName: /var/logs/kibana.log
      policy:
        type: size-limit
        size: 50mb
      strategy:
        //...
      layout:
        type: pattern

选项包括

在执行轮换之前，日志文件应达到的最大大小。默认值为 100mb

时间间隔触发策略

此策略将每隔给定的时间间隔轮换该文件。

logging:
  appenders:
    rolling-file:
      type: rolling-file
      fileName: /var/logs/kibana.log
      policy:
        type: time-interval
        interval: 10s
        modulate: true
      strategy:
        //...
      layout:
        type: pattern

选项包括

滚动发生的频率。默认值为 24h

是否应调整间隔，以使下一次滚动发生在间隔边界上。

例如，如果调整为 true 且间隔为 4h，如果当前时间是凌晨 3 点，则第一次滚动将发生在凌晨 4 点，然后下一次滚动将发生在早上 8 点、中午、下午 4 点等。默认值为 true。

滚动策略确定滚动应如何发生：滚动文件的命名以及它们的保留策略。

目前仅支持一种策略：numeric。

数字滚动策略

此策略将在滚动时使用给定的模式为文件添加后缀，并保留固定数量的滚动文件。

logging:
  appenders:
    rolling-file:
      type: rolling-file
      fileName: /var/logs/kibana.log
      policy:
        // ...
      strategy:
        type: numeric
        pattern: '-%i'
        max: 2
      layout:
        type: pattern

例如，使用此配置

选项包括

滚动时附加到文件路径的后缀。必须包括 %i，因为这是将转换为文件索引的值。

例如，如果 fileName: /var/logs/kibana.log 和 pattern: '-%i'，则创建的滚动文件将为 /var/logs/kibana-1.log、/var/logs/kibana-2.log 等。默认值为 -%i

要保留的最大文件数。达到此数量后，将删除最旧的文件。默认值为 7

与 log4j 的 RewriteAppender 类似，此附加器充当一种中间件，在将提供的日志事件传递给另一个附加器之前对其进行修改。

logging:
  appenders:
    my-rewrite-appender:
      type: rewrite
      appenders: [console, file] # name of "destination" appender(s)
      policy:
        # ...

RewriteAppender 最常见的用例是当你想要过滤或审查可能包含在日志条目中的敏感数据时。实际上，在默认配置下，Kibana 会在记录 http 请求和响应时自动编辑任何 authorization、cookie 或 set-cookie 标头。

要配置其他重写规则，你需要指定一个 RewritePolicy。

重写策略的存在是为了指示可以在重写附加器中修改日志记录的哪些部分。

元数据

meta 重写策略可以在将任何数据传递到目标附加器之前读取和修改 LogMeta 中包含的任何数据。

元数据策略必须指定三种模式之一，以指示对配置的属性执行的操作： - update 更新在提供的 path 处的现有属性。 - remove 删除在提供的 path 处的现有属性。

properties 以 path 和 value 对的形式列出，其中 path 是 LogMeta 对象中目标属性的点分隔路径，而 value 是要添加到目标属性或在其中更新的值。使用 remove 模式时，不需要 value。

以下是如何将任何 cookie 标头值替换为 [REDACTED] 的示例

logging:
  appenders:
    my-rewrite-appender:
      type: rewrite
      appenders: [console]
      policy:
        type: meta # indicates that we want to rewrite the LogMeta
        mode: update # will update an existing property only
        properties:
          - path: "http.request.headers.cookie" # path to property
            value: "[REDACTED]" # value to replace at path

重写附加器甚至可以传递给其他重写附加器以应用多个过滤策略/模式，只要它不创建循环引用即可。每个重写附加器都是按顺序应用的（一个接一个）。

logging:
  appenders:
    remove-request-headers:
      type: rewrite
      appenders: [censor-response-headers] # redirect to the next rewrite appender
      policy:
        type: meta
        mode: remove
        properties:
          - path: "http.request.headers" # remove all request headers
    censor-response-headers:
      type: rewrite
      appenders: [console] # output to console
      policy:
        type: meta
        mode: update
        properties:
          - path: "http.response.headers.set-cookie"
            value: "[REDACTED]"

logging:
  appenders:
    custom_console:
      type: console
      layout:
        type: pattern
        highlight: true
        pattern: "[%date][%level][%logger] %message %meta"
    file:
      type: file
      fileName: ./kibana.log
      layout:
        type: json
    censor:
      type: rewrite
      appenders: [custom_console, file]
      policy:
        type: meta
        mode: update
        properties:
          - path: "http.request.headers.cookie"
            value: "[REDACTED]"
  loggers:
    - name: http.server.response
      appenders: [censor] # pass these logs to our rewrite appender
      level: debug