作者：雷萬鈞，KubeSphere 可觀測性研發工程師
前言
作為可觀測性的重要組成部分，告警通知可以幫助我們及時發現問題，日志可以幫助我們快速定位問題，作為一款開源的容器編排平臺， KubeSphere 提供了強大的日志收集和查詢功能，以及靈活的告警通知能力，
本文將為大家介紹 KubeSphere 的日志和通知功能是如何實作的，
日志
KubeSphere 的日志收集是通過 Fluent Bit 實作的，Fluent Bit 將 Pod 日志收集到 ElasticSearch 集群，KubeSphere 通過查詢 ElasticSearch 集群實作日志檢索，
Fluent Bit
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
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
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:
- [email protected]
- [email protected]
alertSelector:
matchExpressions:
- key: severity
operator: In
values:
- error
- critical
KubeSphere 通知的優勢
- 使用 CRD 管理，支持動態更新
- 支持豐富的通知渠道
- 支持通知訊息過濾
- 支持自定義通知訊息
本文由博客一文多發平臺 OpenWrite 發布！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/298016.html
標籤：其他