配置日志记录

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

记录器、追加器和布局编辑

记录器 定义应应用于特定记录器的日志记录设置。

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

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

日志级别编辑

目前，我们支持以下日志级别：全部、致命、错误、警告、信息、调试、跟踪、关闭。

级别是有序的，因此 全部 > 致命 > 错误 > 警告 > 信息 > 调试 > 跟踪 > 关闭。

如果日志记录的级别高于或等于其记录器的级别，则记录器将记录该记录。否则，将忽略该日志记录。

全部 和 关闭 级别只能在配置中使用，并且是方便的快捷方式，允许您记录每个日志记录或完全禁用特定记录器的日志记录。也可以使用 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 以 json 格式输出 meta 对象数据的条目（如果事件中存在）。%meta 输出的示例

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

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

pid 输出进程 ID。

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

JSON 布局编辑

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

记录器层次结构编辑

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

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

例如，如果 modulate 为 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