关于云计算:深入解读云原生可观测性之日志与告警通知

2次阅读

共计 5382 个字符，预计需要花费 14 分钟才能阅读完成。

作者：雷万钧，KubeSphere 可观测性研发工程师

作为可观测性的重要组成部分，告警告诉能够帮忙咱们及时发现问题，日志能够帮忙咱们疾速定位问题。作为一款开源的容器编排平台，KubeSphere 提供了弱小的日志收集和查问性能，以及灵便的告警告诉能力。

本文将为大家介绍 KubeSphere 的日志和告诉性能是如何实现的。

KubeSphere 的日志收集是通过 Fluent Bit 实现的，Fluent Bit 将 Pod 日志收集到 ElasticSearch 集群，KubeSphere 通过查问 ElasticSearch 集群实现日志检索。

Fluent Bit 是一个开源的日志处理器和转发器，它能够从不同起源收集任何数据，如指标和日志，用过滤器解决它们并将它们发送到多个目的地。它是 Kubernetes 等容器化环境的首选。

Fluent Bit 的设计思考到了性能：高吞吐量、低 CPU 和内存使用率。它是用 C 语言编写的，具备可插拔架构，反对 70 多种输出、过滤器和输入扩大。

日志通过数据管道从数据源发送到目的地，一个数据管道通常由 Input、Parser、Filter、Buffer、Routing 和 Output 组成。

Input：用于从数据源抽取数据，一个数据管道中能够蕴含多个 Input。
Parser：负责将 Input 抽取的非结构化数据转化为规范的结构化数据，每个 Input 均能够定义本人的 Parser。
Filter：负责对格式化数据进行过滤和批改。一个数据管道中能够蕴含多个 Filter，Filter 会程序执行，其执行程序与配置文件中的程序统一。
Buffer：用户缓存通过 Filter 解决的数据。
Routing：将 Buffer 中缓存的数据路由到不同的 Output。
Output：负责将数据发送到不同的目的地，一个数据管道中能够蕴含多个 Output。

Fluent Bit 反对多种类型的 Input、Parser、Filter、Output 插件，能够应答各种场景。

Fluent Bit 作为容器平台下首选的日志收集工具，有着高效、轻量的劣势，然而其部署形式却不够便捷。

首先，应用传统的形式部署 Fluent Bit，须要手动创立一个 DaemonSet，须要对 Fluent Bit 进行批改时，也须要手动批改此 DaemonSet，不够便捷且容易出错。
其次，Fluent Bit 的配置文件不是云原生畛域罕用的 yaml 或 json 格局，配置较为繁琐且容易出错。
再次，Fluent Bit 不反对动静加载配置文件，每次更新配置文件须要重启 DaemonSet。

基于以上问题，KubeSphere 可观测性团队开发了 FluentBit Operator 用于部署和治理 Fluent Bit。

FluentBit Operator 是一款开源的 Fluent Bit 管理工具，能够实现 Fluent Bit 的疾速部署，能够实现 Fluent Bit 配置文件的动静批改和加载。

治理：主动部署和销毁 Fluent Bit DaemonSet。
自定义配置：通过 CRD 定义 Fluent Bit 的配置。
动静加载：无需重新启动 Fluent Bit pod 即可更新配置。

FluentBit Operator 通过 CRD 创立和治理 Fluent Bit Pod，通过监听 CRD 的变动动静更新 Fluent Bit Pod 和 Fluent Bit 配置。

FluentBit Operator CRDS

FluentBit Operator 定义的 CRD 包含：

FluentBit：用于创立 Fluent Bit DaemonSet。
FluentBitConfig：用于抉择 FluentBit Operator 须要治理的插件。
Input：用于定义 Fluent Bit Input 插件。
Parser：用于定义 Fluent Bit Parser 插件。
Filter：用于定义 Fluent Bit Filter 插件。
Output：用于定义 Fluent Bit Output 插件。

FluentBit Operator 通过监听 FluentBitConfig、Input、Parser、Filter、Output CRD，生成 Fluent Bit 的配置文件，并将配置文件写入到 Secret 中。当 CRD 产生变更时，配置文件会自动更新。

FluentBit Operator 监听 FluenBit CRD，当 FluenBit CRD 的实例创立时，FluentBit Operator 会创立 Fluent Bit DaemonSet，并将配置文件挂载到 Fluent Bit DaemonSet 中。当配置文件发生变化时，Fluent Bit Pod 中的配置文件也会同步更新。那么 FluentBit Operator 是如何实现 Fluent Bit 动静加载配置文件的呢？

Fluent Bit Watcher

Fluent Bit Pod 中不是间接运行的 Fluent Bit，而是运行了一个名为 fluent-bit-watcher 的过程，fluent-bit-watcher 在启动后会启动 Fluent Bit，同时监听配置文件。当配置文件发生变化时，fluent-bit-watcher 会重启 Fluent Bit 以从新加载配置文件。

Fluent Bit 会将日志收集到 ElasticSearch 集群中进行长久化，日志会依照每天一个分片进行存储，KubeSphere 反对配置日志的保留周期，超过保留周期的日志会被主动删除。

同时 KubeSphere 反对将日志输入到 Kafka 和 Fluentd。

Fluent Bit 在收集日志时，会将容器的元数据信息增加到日志，因而 KubeSphere 能够为用户提供了丰盛的日志查问形式。

多租户日志治理，实现不同租户日志分权分域。每个租户只能查问本人有权限拜访的 Namespace 下的容器的日志。
多层次日志查问按我的项目、工作负载、容器组、容器和关键字查问日志，从多层次定位问题。

KubeSphere 反对多租户告诉性能，每个租户都能够定制本人的告诉渠道，用于接管租户有权限拜访的 Namespace 下的告诉音讯。同时能够设置全局的告诉渠道用于接管全副的告诉音讯，包含所有租户的告诉音讯和平台级的告诉音讯。

KubeSphere 的告诉性能是通过 Notification Manager 实现的。

Notification Manager 是 KubeSphere 可观测团队开源的一款 Kubernetes 平台上的多租户告诉管理系统，其从 Alertmanager 接管告警音讯，并依据告警音讯的租户标签（如 namespace）将告警音讯发送到对应的告诉渠道，DingTalk，Email，Slack，WeCom，Webhook，短信平台（阿里、腾讯，华为）等。

Notification Manager 由 Operator 和 Deployment 两局部组成，Operator 用于创立和治理 Deployment，Deployment 用于接管告警音讯，生成告诉音讯，并依据告警音讯的租户标签（如 namespace）将告诉音讯发送到对应的告诉渠道。

Notification Manager 通过 CRD 进行治理和配置，Operator 通过监听 NotificationManager CRD 创立和治理 Deployment，Deployment 会监听 NotificationManager、Config、Receiver CRD，当 CRD 产生变更时，会重载 CRD 以更新配置信息，实现了告诉渠道的动静更新。

Notification Manager 定义的 CRD 的作用如下：

NotificationManager：用于配置 Webhook，包含镜像、正本数、volumes、亲和性、污点、资源配额等。同时定义了发送告诉所需的配置，全局接收者和默认配置选择器、租户标签、租户级接收者选择器，以及告诉渠道的全局配置。
Config：用于定义告诉渠道的发送方的配置信息，例如邮件发送服务器设置、企业微信用于发送音讯的 APP 的信息等。
Receiver：用于定义告诉渠道的接管方的信息，例如邮件接收者、企业微信中的用户或部门，slack 的频道等。

Notification Manager 反对多租户告诉，那么 Notification Manager 是如何实现多租告诉治理的呢？

Notification Manager 采纳了发送配置和接管配置拆散的模式，即应用 Config 定义发送配置，应用 Receiver 定义接管配置，Receiver 通过标签抉择发送告诉须要应用的发送配置。Config 和 Receiver 分为全局和租户两种类型，通过以下标签进行辨别。

type: global // 全局 Receiver

type: default // 全局 Config

type: tenant // 租户 Receiver or Config

全局 Receiver 只能应用全局的 Config，租户 Receiver 通过标签选择器抉择租户定义的租户 Config，如果未定义标签选择器，或未找到 Config，则应用全局 Config。

应用此种模式，用户能够疾速实现简单多租户告诉场景的配置。例如对于邮件告诉，能够应用对立的发送方，管理员能够设置全局的 Email Config，租户只须要配置接管邮箱即可实现邮件告诉配置。

Notification Manager 会依据告诉音讯的 namespace 标签将告诉发送到相应的 Receiver。

所有告诉音讯都会发送到全局 Receiver。
若 namespace 为空，则只会发送到全局 Receiver。
若 namespace 非空，Notification Manager 会依据 namespace 查找待告诉租户列表，而后依据租户列表获取待发送 Receiver。对应原生 Kubernetes 集群，待告诉租户即为 namespace。对于其余集群，例如 KubeSphere，Notification Manager 反对通过 API 获取待告诉租户列表。用户能够本人实现获取待告诉租户列表的逻辑，通过 sidecar 的形式注入到 Notification Manager Deployment 供 Notification Manager 调用。

自定义告诉音讯

Notification Manager 反对自定义告诉音讯，用户能够通过编写音讯模板来自定义告诉音讯。Notification Manager 的告诉模板此采纳 Go template 编写。以下是一个简略的音讯模板。

{{define "__nm_alert_list"}}{{range .}}Labels:
{{range .Labels.SortedPairs}}{{if ne .Name "runbook_url"}}- {{.Name}} = {{.Value}}{{end}}
{{end}}Annotations:
{{range .Annotations.SortedPairs}}{{if ne .Name "runbook_url"}}- {{.Name}} = {{.Value}}{{end}}
{{end}}{{end}}{{end}}

{{define "nm.default.text"}}{{template "nm.default.subject" .}}
{{if gt (len .Alerts.Firing) 0 -}}
Alerts Firing:
{{template "__nm_alert_list" .Alerts.Firing}}
{{- end}}
{{if gt (len .Alerts.Resolved) 0 -}}
Alerts Resolved:
{{template "__nm_alert_list" .Alerts.Resolved}}
{{- end}}
{{- end}}

其输入的告诉音讯如下。

Notification Manager 反对多级别的模板设置。

Notification Manager 为每一种告诉渠道设置了默认的音讯模板，用户能够间接应用。
用户能够设置全局的模板，供所有 Receiver 应用。
用户能够为每种告诉渠道设置对立的模板。
用户能够为每一个 Receiver 设置独自的模板。

告诉音讯过滤

Notification Manager 反对对告诉音讯进行过滤，用户能够通过设置过滤器来过滤告诉音讯。Notification Manager 反对对每一个 Receiver 设置独自的过滤器。

一个简略的过滤器，过滤掉 warning 级别的告警。

apiVersion: notification.kubesphere.io/v2beta1
kind: Receiver
metadata:
  labels:
    app: notification-manager
    type: global
  name: global-email-receiver
spec:
  email:
    to:
    - receiver1@xyz.com
    - receiver2@xyz.com
    alertSelector:
      matchExpressions:
      - key: severity
        operator: In
        values:
        - error
        - critical