关于kubernetes:Rancher-26-全新-Logging-快速入门

作者简介
袁振，SUSE Rancher 技术支持经理，负责订阅客户售后技术支持团队，为订阅客户提供技术支持服务。2016 年开始接触容器、Kubernetes 技术，对自动化运维、Devops、Kubernetes、prometheus 和其余云原生相干技术具备较深刻的钻研，对 SRE 运维体系建设、SRE 运维零碎架构设计有着丰盛的实践经验。

背景概述

在 SUSE Rancher 2.5 以前，日志收集的架构是应用 Fluentd 收集指定目录日志或者容器规范输入流后，再通过 UI 日志性能页面的配置发送到指定的后端。如 Elasticsearch、splunk、kafka、syslog、fluentd 等常见的后端工具，能够自动化地收集 kubernetes 集群和运行于集群之上的工作负载日志。这种形式无疑是非常简单、易用、不便的，然而随着用户对云原生了解的加深，对业务日志剖析颗粒度要求的进步，之前的日志收集形式有些太过死板，灵活性十分差，曾经无奈满足对日志收集具备更高要求的用户了。

于是从 SUSE Rancher 2.5 版本开始，BanzaiCloud 公司的开源产品 Logging Operator 成为了新一代 SUSE Rancher 容器云平台日志采集性能的组成组件。SUSE Rancher 2.5 版本作为新日志组件的过渡版本，保留了老版本的日志收集形式，并将全新的 Logging Operator 作为试验性功能应用；SUSE Rancher 2.6 版本则曾经齐全应用了 Logging Operator 作为日志收集工具。

本文将由浅到深地摸索全新的 SUSE Rancher 2.6 Logging Operator 性能和它的应用形式。

什么是 Logging Operator

Logging Operator 是 BanzaiCloud 基于云原生场景的开源日志采集计划，SUSE Rancher 2.6 版本在整合了该产品之后，将会在用户的操作下主动部署 Logging Operator 并主动配置 kuberletes logging pipeline。

Logging Operator 架构

以上是 Logging Operator 官网架构图。Logging Operator 应用 CRD 的形式决定了日志采集、规定路由、输入这三个阶段的配置，它应用 Daemonset 在集群节点上部署 Fluentbit 组件，应用 StatefulSet 部署 Fluentd 组件。首先由 Fluentbit 组件进行日志收集并初步解决之后，发送到 Fluentd 组件进行进一步的解析解决，最终由 Fluentd 组件发送到不同的后端工具上。

Logging Operator CRD

上文提到，Logging Operator 应用 CRD 的形式决定了日志采集、规定路由、输入这三个阶段的配置，其应用的 CRD 次要有以下 5 种类型：

• logging：用于定义一个日志采集端 (FleuntBit) 和传输端 (Fleuntd) 服务的根底配置，在 SUSE Rancher 2.6 版本中，曾经由 Rancher 自动化部署实现；
• flow：用于定义一个 namespaces (命名空间)级别的日志过滤、解析和路由等规定;
• clusterflow：用于定义一个集群级别的日志过滤、解析和路由等规定;
• output：用于定义 namespace (命名空间)级别的日志的输入和参数，它只能被同命名空间内的 flow 关联；
• clusteroutput：用于定义集群级别的日志输入和参数，它能把被其余命名空间内的 flow 关联。

以上 5 个 CRD 类型十分重要，决定了一个 Kubernetes 集群内每个命名空间甚至每个容器的日志输入到哪里。

启用 SUSE Rancher 2.6 Logging

SUSE Rancher 2.6 胜利创立上游 Kubernetes 集群后，能够在集群工具页面找到 Logging 工具的部署入口，如下图所示：

点击装置按钮后，抉择组件装置的我的项目，个别抉择为 System 我的项目，在该我的项目中运行与集群运行相干的组件；点击下一步后，UI 会要求输出配置 Docker 根目录和 System Log Path；

• 留神：如果底层容器运行时 (Runtime)为 Docker，默认为：/var/lib/docker。如果自定义过，请填写正确的 Docker Root Dir 目录，能够通过 docker info | grep Docker Root Dir 命令查看；
• 留神：System Log Path 用于收集主机操作系统 Journal 日志，如果填写谬误会导致主机操作系统日志无奈收集，确认该门路的办法如下：

## 确认 Journal Log Path 查看形式，在节点上执行以下命令

cat /etc/systemd/journald.conf | grep -E ^\#?Storage | cut -d"=" -f2

1、如果返回 persistent，则 systemdLogPath 应该是 /var/log/journal；2、如果返回 volatile，则 systemdLogPath 应该是 /run/log/journal；3、如果返回 auto，则查看 /var/log/journal 是否存在；- 如果 /var/log/journal 存在，则应用 /var/log/journal；- 如果 /var/log/journal 不存在，则应用 /run/log/journal；

输出正确的 Docker 根目录和 systemdLogPath 后，点击装置，SUSE Rancher 2.6 会主动部署 Logging Operator

执行以下命令查看部署是否胜利

kubectl get pod -n cattle-logging-system

NAME                                           READY   STATUS      RESTARTS   AGE
rancher-logging-96b68cc4b-vqxnd                1/1     Running     0          9m54s
rancher-logging-fluentbit-cntgb                1/1     Running     0          69s
rancher-logging-fluentbit-hwmdx                1/1     Running     0          71s
rancher-logging-fluentbit-nw7rw                1/1     Running     0          71s
rancher-logging-fluentd-0                      2/2     Running     0          9m34s
rancher-logging-fluentd-configcheck-ac2d4553   0/1     Completed   0          9m48s

部署实现后，SUSE Rancher 2.6 集群 UI 上多了一个日志选项卡，能够由此配置上文提到的 flow、clusterflow、output、clusteroutput 资源对象，从而实现整个日志采集、过滤路由、输入的全流程配置。

从 SUSE Rancher 2.6 UI 上间接进行日志采集流程的配置诚然不便，然而对 Logging Operator 比拟相熟的“大神”或者常常应用的“大佬”，能够应用 SUSE Rancher 2.6 UI 间接进行配置，从而实现整个日志采集、过滤路由、输入的全流程配置；对于刚刚降级为 SUSE Rancher 2.6 或者刚刚接触 Logging Operator 的“小白”敌人们，咱们还是不要焦急上手了，深入浅出、循序渐进，持续往下读完，看看这些 CRD 是怎么配置和工作的。

Flow 和 ClusterFlow

从本文最开始的架构流程图能够看出，整个 Logging Operator 最为外围的两个概念就是 flow 和 output，其中 flow 就是用来解决日志流的，决定了从哪里采集、怎么过滤、如何路由散发；clusterflow 具备雷同的性能，是个全局 flow。

在理解 flow CRD 的定义之前，先用一个简略的 flow 示例来进行以下剖析：

apiVersion: logging.banzaicloud.io/v1beta1
kind: Flow  
metadata:
  name: default-flow
  namespace: default ## 定义收集日志的命名空间
spec:
  filters:  ## 定义过滤器，一个 flow 能够定义一个或者多个
    - parser:
        remove_key_name_field: true
        parse: ##parse 反对 apache2, apache_error, nginx, syslog, csv, tsv, ltsv, json, multiline, none, logfmt 类型解析
          type: nginx ## 采集日志依照 Nginx 格局进行解决
    - tag_normaliser:
        format: ${namespace_name}.${pod_name}.${container_name} ## 在 fluentd 外面应用 ${namespace_name}.${pod_name}.${container_name}的格局
  localOutputRefs:
    - "elasticsearch-output" ## 定义 Output
  match:  ## Kubernetes 标签来定义哪些日志须要被采集 
    - select:
        labels: ## 应用标签匹配采集日志
          app: nginx

这个 flow 的意思是，只会采集 default 命名空间内标签 app=nginx 的容器日志，采集日志后依照 nginx 格局进行解析，并且将这个日志流的 tag 在 fluentd 最终汇总时重定向为 ${namespace_name}.${pod_name}.${container_name} 格局。

match

下面的例子里有一个十分重要的定义 match，它定义了哪些日志须要被采集，依据 Logging Operato 官网文档给出的阐明，以后能够应用的字段有以下几种：

• namespaces 应用命名空间进行匹配；
• labels 应用标签进行匹配；
• hosts 应用主机进行匹配；
• container_names 应用容器名称进行匹配。

构想一个场景，在一个 Kubernetes 集群中，咱们只想不采集某些容器的日志，应用匹配须要写无数个匹配规定，这显然是不合理的，所以官网给了 exclude 字段，应用排除。例子如下：

apiVersion: logging.banzaicloud.io/v1beta1
kind: Flow  
metadata:
  name: default-flow
  namespace: default ## 定义收集日志的命名空间
spec:
  filters:  ## 定义过滤器，一个 flow 能够定义一个或者多个
    - parser:
        remove_key_name_field: true
        parse: ##parse 反对 apache2, apache_error, nginx, syslog, csv, tsv, ltsv, json, multiline, none, logfmt 类型解析
          type: nginx ## 采集日志依照 Nginx 格局进行解决
    - tag_normaliser:
        format: ${namespace_name}.${pod_name}.${container_name} ## 在 fluentd 外面应用 ${namespace_name}.${pod_name}.${container_name}的格局
  localOutputRefs:
    - "es-output" ## 定义 Output
  match:  ## Kubernetes 标签来定义哪些日志须要被采集 
    - exclude: ## 排除所有标签是 app:nginx 的容器
        labels:  
          app: nginx

下面这个例子会排除采集所有标签是 app:nginx 的容器日志；exclude 和 select 能够同时存在，也能够有多个 exclude 和 select 存在，更灵便的定义须要采集哪些容器日志。

除了 flow 以外还有 clusterflow。构想一个场景，咱们有 N 个 namespaces，然而咱们须要采集除了某一个 namespaces 以外的所有 namespaces 的容器日志。这个时候，每个 namespaces 设定一条 flow 显著是不合理的，这就须要应用 clusterflow 设置规定来进行采集，示例如下：

apiVersion: logging.banzaicloud.io/v1beta1
kind: ClusterFlow  ## 定义为 clusterflow
metadata:
  name: default-cluster-flow
spec:
  filters:  ## 定义过滤器，一个 flow 能够定义一个或者多个
    - parser:
        remove_key_name_field: true
        parse: ##parse 反对 apache2, apache_error, nginx, syslog, csv, tsv, ltsv, json, multiline, none, logfmt 类型解析
          type: nginx ## 采集日志依照 Nginx 格局进行解决
    - tag_normaliser:
        format: ${namespace_name}.${pod_name}.${container_name} ## 在 fluentd 外面应用 ${namespace_name}.${pod_name}.${container_name}的格局
  localOutputRefs:
    - "es-output" ## 定义 Output
  match:  ## Kubernetes 标签来定义哪些日志须要被采集 
    - exclude: ## 排除不想要采集的 namespaces
        namespaces:  
          - default
          - kube-system

下面的示例示意这是一个 cluster 级别的 flow，依据 match 定义，将采集除了 default 和 kube-system 命名空间以外的所有命名空间日志；与 flow 雷同的是，clusterflow 中的 match 定义的 exclude 和 select 能够同时存在，也能够有多个 exclude 和 select 同时存在，从而制订更粗疏的规定。

filters

filters 是 Logging Operator 中的日志解决插件，目前官网反对的日志解决插件如下：

• Concat: 用于 fluentd 解决日志多行的插件;
• Dedot: 解决带. 的字段替换插件，通常用于输入到 elaticsearch 前的字段转化;
• Exception Detector: Exception 日志捕捉器，反对 java, js, csharp, python, go, ruby, php;
• Enhance K8s Metadata: banzaicloud 开发的 k8s 扩大元数据;
• Geo IP: fluentd 的 GeoIP 地址库;
• Grep: fluentd 的 grep 过滤器;
• Parser: fluentd 的 Parser 解析器,parse 反对 apache2, apache_error, nginx, syslog, csv, tsv, ltsv, json, multiline, none;
• Prometheus:  Prometheus 插件，可用于对日志做计数;
• Record Modifier: fluentd  字段批改插件;
• Record Transformer: Mutates/transforms incoming event streams;
• Stdout: 规范输入插件;
• SumoLogic: Sumo Logic 公司的日志解决插件;
• Tag Normaliser: fluentd 中的 tag 修改器。

Parser 插件

Parser 插件最罕用、最简略，反对解析持 apache2, apache_error, nginx, syslog, csv, tsv, ltsv, json, multiline, none 格局的日志。如果须要解析 nginx 的日志，能够间接用 Parser 插件进行解决，示例如下：

apiVersion: logging.banzaicloud.io/v1beta1
kind: Flow  
metadata:
  name: default-nginx-flow
  namespace: default ## 定义收集日志的命名空间
spec:
  filters:  ## 定义过滤器，一个 flow 能够定义一个或者多个
    - parser:
        remove_key_name_field: true
        parse: ##parse 反对 apache2, apache_error, nginx, syslog, csv, tsv, ltsv, json, multiline, none, logfmt 类型解析
          type: nginx ## 采集日志依照 Nginx 格局进行解决

如果须要解析 json 格局的日志，示例如下：

apiVersion: logging.banzaicloud.io/v1beta1
kind: Flow  
metadata:
  name: default-flow
  namespace: default ## 定义收集日志的命名空间
spec:
  filters:  ## 定义过滤器，一个 flow 能够定义一个或者多个
    - parser:
        remove_key_name_field: true
        parse: 
          type: json ## 解析为 json 格局
          time_key: time ## 自定义 key
          time_format: "%Y-%m-%dT%H:%M:%S"

咱们能够在 Parser 插件指定多种类型的日志解析格局，示例如下：

apiVersion: logging.banzaicloud.io/v1beta1
kind: Flow  
metadata:
  name: default-flow
  namespace: default ## 定义收集日志的命名空间
spec:
  filters:  ## 定义过滤器，一个 flow 能够定义一个或者多个
    - parser:
        remove_key_name_field: true
        parse:
          type: multi_format
          patterns:
            - format: nginx ## 解析 Nginx 格局
            - format: json  ## 解析 json 格局
              time_key: time
              time_format: "%Y-%m-%dT%H:%M:%S"

从下面的几个例子能够看进去，解决解析日志格局是非常灵活的，能够搭配不同的插件和解析格局来应答不同类型的日志格局。

介绍完罕用的 Parser 插件后，再给大家介绍一个以往可能都没有遇到过或者配置起来比较复杂的场景：如果须要统计业务日志在肯定时间段内打印了多少总数，用于剖析业务经营指标，怎么办呢？可能大家第一工夫想到的是，反正都曾经解决完丢到相似 Kibana 的工具上了，间接过滤一下不就出数据了？这个办法是能够的，然而假如一下，想要通过日志条目数量继续剖析业务经营指标怎么办？接下来分享另外一个插件。

Prometheus 插件

Prometheus 作为云原生时代的监控利器，弱小的时序型数据库，配合 PromQL 和 Grafana 还有泛滥的 Exporter，根本能够监控咱们须要的任何指标；Logging Operator 中也引入了 Prometheus 插件，用于统计裸露收集的指定日志条目。示例如下：

apiVersion: logging.banzaicloud.io/v1beta1
kind: Flow  
metadata:
  name: default-flow
  namespace: default ## 定义收集日志的命名空间
spec:
  filters:  ## 定义过滤器，一个 flow 能够定义一个或者多个
    - parser:
        remove_key_name_field: true
        parse: ##parse 反对 apache2, apache_error, nginx, syslog, csv, tsv, ltsv, json, multiline, none, logfmt 类型解析
          type: nginx ## 采集日志依照 Nginx 格局进行解决
    - prometheus: ##Pormetheus 插件
        metrics:
          - desc: The total number of nginx in log. ## 指标阐明
            name: nginx_log_total_counter  ## 指标名称
            type: counter ## 指标 Prometheus 类型
            labels: ## 指标标签
              app: nginx
        labels: ## 指标标签
          host: ${hostname}
          tag: ${tag}
          namespace: $.kubernetes.namespaces
    - tag_normaliser:
        format: ${namespace_name}.${pod_name}.${container_name} ## 在 fluentd 外面应用 ${namespace_name}.${pod_name}.${container_name}的格局
  localOutputRefs:
    - "es-output" ## 定义 Output
  match:  ## Kubernetes 标签来定义哪些日志须要被采集 
    - select:
        labels: ## 应用标签匹配采集日志
          app: nginx

以上例子应用了 Parser 插件对 Nginx 日志进行解决，应用了 Prometheus 插件对输入的 Nginx 日志进行统计。Prometheus 插件次要有以下几个字段：

• desc: 对该指标的形容；
• name: 指标的名称；
• type: 指标的 Prometheus 数据类型(理解更多请参考  Prometheus 数据类型文档)；
• labels: 指标的标签(理解更多请参考 Prometheus Label 文档)。

通过下面这个 Flow 就能够统计总共解决了多少行 Nginx 的日志，并应用 Prometheus 裸露 counter 类型指标以做监控剖析。

小结

通过以上两个插件的应用示例能够看出 Logging Operator 的灵便、弱小之处，此外，您还能够配合其余泛滥的插件，灵便地实现对日志采集解决的需要。对于更多 Logging Operator 的 filter 反对的插件阐明，请查看 https://banzaicloud.com/docs/…

Output 和 ClusterOutput

Output 和 ClusterOutput 两个 CRD 定义了解决实现的日志应该输入到哪个中央。与 flow 和 clusterflow 雷同的是，output 同样是 namespaces 级别的，它只能被同命名空间下的 flow 援用；clusterflow 是集群级别的，能够被不同命名空间的 flow 和 clusterflow 援用。

Output

Output 定义了日志的输入形式，目前 Logging Operator 反对输入插件如下：

• Alibaba Cloud
• Amazon CloudWatch
• Amazon Elasticsearch
• Amzon Kinesis
• Amazon S3
• Amzon Storage
• Buffer
• Datadog
• Elasticsearch
• File
• Format
• Format rfc5424
• Forward
• GELF
• Goole Cloud Storage
• Grafana Loki
• Http
• Kafka
• LogDNA
• LogZ
• NewRelic
• Splunk
• SumoLogic
• Syslog

能够看到 Logging Operator 反对输入的插件还是十分丰盛的，基本上涵盖了应用场景中的工具。上面咱们将以罕用的两种插件 Kafka 和 Elasticsearch 进行举例，配置 Output CRD。

Output-Kafka

apiVersion: logging.banzaicloud.io/v1beta1
kind: Output  
metadata:
  name: kafka-output
spec:
  kafka: 
    brokers: kafka-headless.kafka.svc.cluster.local:29092 ##kafka 地址
    default_topic: topic
    topic_key: kafka-output ##kafka topic 名称；sasl_over_ssl: false ## 是否应用 ssl
    format:
      type: json  ## 类型
    buffer: ## 发送 buff 配置
      tags: topic
      timekey: 1m
      timekey_wait: 30s
      timekey_use_utc: true

在下面这个简略例子中，咱们定义了一个输入到 kafka 的 output CRD，能够看到几个要害配置，kafka 的地址、topic 的名称、是否应用 ssl；上面的 buffer 指发送 buffer 配置，这样一个发送到 kafka 的 output CRD 就实现了。Buff 配置也能够依据理论状况进行调整。

Output-Elasticsearch

apiVersion: logging.banzaicloud.io/v1beta1
kind: Output  
metadata:
  name: elasticsearch-output
spec:
  elasticsearch:
    host: elasticsearch-elasticsearch-cluster.default.svc.cluster.local
    port: 9200
    scheme: https
    ssl_verify: false
    ssl_version: TLSv1_2
    buffer:
      timekey: 1m
      timekey_wait: 30s
      timekey_use_utc: true

在下面这个简略例子中，咱们定义了一个输入到 elasticsearch 的 output CRD，其实和 kafka 的 output 配置相似，须要定义 elasticsearch 的地址、端口、是否须要 ssl 认证；buffer 配置定义了发送时的 buff 配置。

对于更多配置项，查看文档：https://banzaicloud.com/docs/…

flow 和 output 相关联

在定义好了 flow 和 output 之后，须要在 flow 定义 localOutputRefs 来与 output 进行关联，以进行日志的发送解决。示例如下：

apiVersion: logging.banzaicloud.io/v1beta1
kind: Flow  
metadata:
  name: default-flow
  namespace: default ## 定义收集日志的命名空间
spec:
  filters:  ## 定义过滤器，一个 flow 能够定义一个或者多个
    - parser:
        remove_key_name_field: true
        parse: ##parse 反对 apache2, apache_error, nginx, syslog, csv, tsv, ltsv, json, multiline, none, logfmt 类型解析
          type: nginx ## 采集日志依照 Nginx 格局进行解决
    - tag_normaliser:
        format: ${namespace_name}.${pod_name}.${container_name} ## 在 fluentd 外面应用 ${namespace_name}.${pod_name}.${container_name}的格局
  localOutputRefs:
    - "elasticsearch-output" ## 输入到 elasticsearch-output
  match:  ## Kubernetes 标签来定义哪些日志须要被采集 
    - select:
        labels: ## 应用标签匹配采集日志
          app: nginx

在下面这个例子中，localOutputRefs 配置了 elasticsearch-output，这样就与咱们刚刚定义的名称为 elasticsearch-output 的 output 进行了关联，日志就能够从指定的 output 进行输入。值得一提的是，Logging Operator 充分考虑了雷同日志须要输入到不同地点的需要。比方上面这个例子，就能够将日志同时输入到 kafka 和 elasticsearch：

apiVersion: logging.banzaicloud.io/v1beta1
kind: Flow  
metadata:
  name: default-flow
  namespace: default ## 定义收集日志的命名空间
spec:
  filters:  ## 定义过滤器，一个 flow 能够定义一个或者多个
    - parser:
        remove_key_name_field: true
        parse: ##parse 反对 apache2, apache_error, nginx, syslog, csv, tsv, ltsv, json, multiline, none, logfmt 类型解析
          type: nginx ## 采集日志依照 Nginx 格局进行解决
    - tag_normaliser:
        format: ${namespace_name}.${pod_name}.${container_name} ## 在 fluentd 外面应用 ${namespace_name}.${pod_name}.${container_name}的格局
  localOutputRefs:
    - "elasticsearch-output" ## 输入到 elasticsearch-output
    - "kafka-output" ## 输入到 kafka-output
  match:  ## Kubernetes 标签来定义哪些日志须要被采集 
    - select:
        labels: ## 应用标签匹配采集日志
          app: nginx

小结

上文介绍的 flow、clusterflow 和 output、clusteroptput 性能都是灵便而弱小的。在 SUSE Rancher 2.6 版本部署完 Logging 后，能够通过 yaml 编写 CRD 并间接利用到集群中，也能够间接在 SUSE Rancher UI 上进行配置。下一章将会介绍如何在 SUSE Rancher UI 上对 flow 和 output 进行配置。

在 SUSE Rancher UI 上对 flow 和 output 进行配置

本章节内容将会形容在 SUSE Rancher UI 上进行日志采集配置。

创立 outputs/clusteroutputs

在 SUSE Rancher UI 上配置首先须要创立一个 flow 或者 clusterflow，进入日志页面抉择 outputs/clusteroutputs，抉择将要发送的后端工具，示例中以 es 为例，配置索引名称、主机地址、端口、outputs 名称，如果有 https 或者 ssl 须要先创立 secrets。

创立实现后的 CRD yaml 如下：

apiVersion: logging.banzaicloud.io/v1beta1kind: Outputmetadata:  name: rancher26-es-output  namespace: defaultspec:  elasticsearch:    buffer:      timekey: 1m      timekey_use_utc: true      timekey_wait: 30s    host: 172.16.0.14    index_name: rancher26    port: 9200    scheme: http

创立 flow/clusterflow

Outputs 创立实现之后，开始创立 flow/clusterflow 规定：进入日志页面抉择 flows/clusterflows，点击创立，进行 flow 配置，示例中将采集标签为 app:nginx 的容器日志：

• 输出容器标签匹配规定、名称；如果有不想采集的主机或者容器，也能够进行抉择；页面上也能够增加多个标签匹配规定；

• 配置输入规定，这里抉择咱们刚刚创立的 outputs，这里能够抉择多个 outputs 和 clusteroutput，也能够同时抉择 output 和 clusteroptput；

• 配置过滤规定，这里咱们收集的是 nginx 日志，所以应用 parser 插件，主动格式化 nginx 规定；

创立实现后的 CRD yaml 如下：

apiVersion: logging.banzaicloud.io/v1beta1kind: Flowmetadata:  name: nginx-flow  namespace: default  fields:    - nginx-flowspec:  filters:    - parser:        parse:          type: nginx        remove_key_name_field: true  localOutputRefs:    - rancher26-es-output  match:    - select:        labels:          app: nginx

验证

配置实现后，如果集群中有合乎标签要求的容器，就会主动采集并发送到 es；

• 通过查看 fluentd 的配置，能够查看 outputs 是否失效

## 进入 rancher-logging-fluentd-0 Pod 命令行
cat fluentd/app-config/fluentd.conf
  <match **>
    @type elasticsearch
    @id flow:default:nginx-flow:output:default:rancher26-es-output
    exception_backup true
    fail_on_putting_template_retry_exceed true
    host 172.16.0.14
    index_name rancher26
    port 9200
    reload_connections true
    scheme http
    ssl_verify true
    utc_index true
    verify_es_version_at_startup true
    <buffer tag,time>
      @type file
      chunk_limit_size 8MB
      path /buffers/flow:default:nginx-flow:output:default:rancher26-es-output.*.buffer
      retry_forever true
      timekey 1m
      timekey_use_utc true
      timekey_wait 30s
    </buffer>
  </match>

• 查看 elasticsearch 中的索引

• 查看 kibana 中的日志详情

总结

至此，SUSE Rancher 2.6  全新的 Logging Operator 开箱应用就曾经全副完结了。比照之前的日志收集性能，确实弱小了不少，配置非常灵活，能够自定义多种过滤器，甚至应用 Prometheus 裸露自定义指标进行业务经营剖析等内容。然而与之前只须要输出指标端地址就能应用的场景绝对比，Logging Operator 的确也减少了肯定的学习老本，倡议“小白”敌人还是从零开始学习，搞清楚整体的运行架构和逻辑，这样有助于故障产生时的定位排查。

一些 Tips

• 整体架构是由 Daemonst 类型的 fluentbit 组件进行日志采集，fluentbit 组件日志中会有日志文件的打印输出，当发现某些日志未被采集的时候，能够查看 fluentbit 组件的日志是否发现了这些日志；
• Fluentd 组件负责汇总、解决、发送，当发现指标端没有收到日志，比如说 ES 没有创立索引的时候，能够看看 Fluentd 组件的日志。须要留神的是，截止文章发表时，Fluentd 的日志没有打印在规范输入中，须要进入 Pod 内执行命令查看：

tail -f fluentd/log/out

• 无论是 UI 还是 CRD 的 flow/outputs 配置，最终都会转化为 fluentbit 和 Fluentd 的配置，如果对这两个组件比拟相熟，出现异常的时候能够进入 Pod 中查看具体失效的配置是否正确；
• 因为过滤器的存在，谬误的过滤、匹配的条件可能会导致日志无奈发送进来，这个时候须要查看 flow 中配置的规定状况。