企业官网建设流程全解析

• 云原生
• 虚拟化
• 存储
• 后端
• 高可用

本篇技术指南围绕 Harvester 开源超融合基础设施（HCI）中的System Logging（系统日志）增强方案展开，讲解如何把 K8s 集群日志（Pod 日志）与各节点主机系统日志（/var/log/journal）聚合到cattle-logging-system命名空间下的日志栈，并通过ClusterFlow/ClusterOutput将日志导出到 Graylog、Loki 等外部接收端。读者将掌握 Harvester 内置日志链路的组件职责、journald 主机日志的过滤采集细节、自定义日志输出的完整 YAML 写法，以及 Loki 可视化查询的部署与操作步骤。

方案背景与目标

在 Harvester 中，故障排查往往需要在集群里逐个kubectl检查异常 Pod 与服务，且每次只能查看单个容器日志，既繁琐又难以覆盖主机层面的系统日志（如rke2-server.service的 journald 输出）。该增强方案的目标是：

• 集中聚合：将 K8s 集群日志与主机系统日志（/var/log下）统一收集到一个中心位置；
• 外部导出：把聚合后的日志导出到集群外部（例如 Rancher 或独立的日志平台），便于集中分析、辅助排障与日常运维。

一个明确的非目标：本方案不覆盖 Harvester/Rancher UI 内的日志配置集成（UI 集成属于后续演进方向）。

总体方案：以 rancher-logging 为核心安装日志栈

方案的核心是在 Harvester 集群中安装rancher-logging作为日志采集与转发的基础组件（最初以ManagedChart形式由 Harvester Installer 安装，后续版本演进为内置 Addon）。当前仓库中，该组件已作为内置 Addon 固化在 addons/built-in/rancher-logging/addon-template.yaml，元信息（命名空间cattle-logging-system、成熟度ga）见 metadata.yaml，并配套了 ISO 打包时的图表补丁脚本 patch-rancher-logging。

核心组件与职责

安装完成后，日志栈由以下主要组件组成：

安装后的 Pod 形态

安装成功后，cattle-logging-system命名空间下应出现如下 Pod：

NAME READY STATUS RESTARTS AGE rancher-logging-685cf9664-w4wl2 1/1 Running 0 17m rancher-logging-rke2-journald-aggregator-6zfsp 1/1 Running 0 17m rancher-logging-root-fluentbit-hj72q 1/1 Running 0 15m rancher-logging-root-fluentd-0 2/2 Running 0 15m rancher-logging-root-fluentd-configcheck-ac2d4553 0/1 Completed 0 17m

其中rancher-logging-root-fluentd-configcheck-*是一次性完成的配置校验任务，Completed状态属正常现象。

从 Addon 模板的valuesContent可以看到 Harvester 对日志栈的关键取值：addon-template.yaml：

systemdLogPath: /var/log/journal disablePvc: true additionalLoggingSources: rke2: enabled: true kubeAudit: enabled: true auditFilename: "audit.log" pathPrefix: "/var/lib/rancher/rke2/server/logs/" loggingRef: "harvester-kube-audit-log-ref"

这些取值决定了：主机日志从/var/log/journal读取、日志栈不依赖 PVC 持久化、默认启用 rke2 与 kube-audit 两类附加日志源，并且对 fluentd/fluent-bit 设置了明确的 CPU/内存资源上限（例如 fluentd 限制 1000m/800Mi，请求 100m/200Mi），避免日志组件在管理节点上占用过多资源。

主机系统日志采集：journald-aggregator 与 systemd 过滤

为了采集每个节点的主机系统日志，方案会启用并修补rancher-logging的rke2日志源，部署一个DaemonSet形态的journald-aggregator，将每个节点的/var/log/journal以只读方式挂载进fluent-bitPod，再通过 systemd 输入插件按日志字段（_SYSTEMD_UNIT、_TRANSPORT等）进行过滤。

Systemd_Filter 过滤规则

全部采集/var/log/journal会产生海量数据，因此只选择内核与关键服务日志，过滤规则如下：

Systemd_Filter _SYSTEMD_UNIT=rke2-server.service Systemd_Filter _SYSTEMD_UNIT=rke2-agent.service Systemd_Filter _SYSTEMD_UNIT=rancherd.service Systemd_Filter _SYSTEMD_UNIT=rancher-system-agent.service Systemd_Filter _SYSTEMD_UNIT=wicked.service Systemd_Filter _SYSTEMD_UNIT=iscsid.service Systemd_Filter _TRANSPORT=kernel

即只保留：RKE2 服务端/Agent、rancherd 引导服务、rancher-system-agent、网络配置服务wicked、iSCSI 服务iscsid以及内核（_TRANSPORT=kernel）日志。

fluent-bit 采集配置源码级解析

当前仓库中实际生效的 fluent-bit 配置由 ISO 打包补丁 configmap.yaml 定义，比早期增强文档多了更完整的输入与解析器：

[INPUT] Name systemd Tag rke2_journald Path {{ .Values.systemdLogPath }} # 默认 /var/log/journal Systemd_Filter _SYSTEMD_UNIT=rke2-server.service Systemd_Filter _SYSTEMD_UNIT=rke2-agent.service Systemd_Filter _SYSTEMD_UNIT=rancherd.service Systemd_Filter _SYSTEMD_UNIT=rancher-system-agent.service Systemd_Filter _SYSTEMD_UNIT=NetworkManager.service Systemd_Filter _SYSTEMD_UNIT=iscsid.service Systemd_Filter _TRANSPORT=kernel [INPUT] Name tail Tag rke2_kubelet Path /var/lib/rancher/rke2/agent/logs/kubelet.log [INPUT] Name tail Tag rke2_audit Path /var/log/audit/audit.log [FILTER] Name parser Match rke2_journald Key_Name MESSAGE Parser klog Reserve_Data On

关键点说明：

• 除 journal 输入外，还通过tail采集 kubelet 日志（/var/lib/rancher/rke2/agent/logs/kubelet.log）与系统审计日志（/var/log/audit/audit.log）；
• 对 journal 消息使用klog、rancher、etcd三种解析器做结构化解析（解析器正则定义见补丁中的 _helpers.tpl）；
• 最终[OUTPUT]通过 forward 协议将全部匹配日志发送到rancher-logging-root-fluentd.<namespace>.svc:24240，汇入中央 fluentd。

DaemonSet 的挂载与安全约束

对应补丁 daemonset.yaml 展示了采集 Pod 的挂载布局：

同时 Pod 设置了严格的安全上下文（allowPrivilegeEscalation: false、readOnlyRootFilesystem: true、丢弃全部 capabilities），并带有 control-plane 与 etcd 的 tolerations，确保能调度并稳定运行在管理节点上。

日志路由：ClusterFlow 与 ClusterOutput

日志栈默认不配置任何输出，用户需要自行通过ClusterFlow与ClusterOutput决定日志去向。这是 logging-operator 的核心用法：ClusterOutput声明"日志发到哪里"，ClusterFlow声明"哪些日志走哪条路由"。输出端支持日志平台常用的各类插件（Graylog/GELF、Splunk、ElasticSearch、Webhook、Loki 等）。

发送日志到 Graylog 实战

以把全部日志发送到 Graylog 为例，需要两个 YAML 文件：

# graylog-cluster-flow.yaml apiVersion: logging.banzaicloud.io/v1beta1 kind: ClusterFlow metadata: name: "all-logs-gelf-hs" namespace: "cattle-logging-system" spec: globalOutputRefs: - "example-gelf-hs"

# graylog-cluster-output.yaml apiVersion: logging.banzaicloud.io/v1beta1 kind: ClusterOutput metadata: name: "example-gelf-hs" namespace: "cattle-logging-system" spec: gelf: host: "192.168.122.159" port: 12202 protocol: "udp"

应用后可通过kubectl校验安装是否成功（注意命名空间为单数cattle-logging-system）：

kubectl get clusteroutputs -n cattle-logging-system example-gelf-hs NAME ACTIVE PROBLEMS example-gelf-hs true kubectl get clusterflows -n cattle-logging-system all-logs-gelf-hs NAME ACTIVE PROBLEMS all-logs-gelf-hs true

ACTIVE=true表示路由已被 logging-operator 成功装载。需要特别注意的是，目标日志服务器必须与 Harvester 集群 VIP 网络可达。

手动部署 Loki 并可视化查询

Loki默认不会随集群安装，需要时可手动部署，与日志栈打通后即可在 Grafana 中可视化查询全集群日志。

安装 loki-stack

仓库提供了适配 Harvester 场景的 Helm values：loki-values.yaml，其要点为：

grafana: enabled: true promtail: enabled: false

即：开启内置 Grafana、关闭 promtail（因为日志已由日志栈的 fluentd 转发，不再需要 promtail 采集）。执行安装（示例为当时验证过的版本 2.7.0）：

helm install --repo https://grafana.github.io/helm-charts \ --values enhancements/20220525-system-logging/loki-values.yaml \ --version 2.7.0 \ --namespace cattle-logging-system \ loki-stack loki-stack

打通日志流：应用 ClusterFlow 与 ClusterOutput

仓库提供了现成的路由定义 loki.yaml，将全部日志送往cattle-logging-system内的 Loki 服务：

apiVersion: logging.banzaicloud.io/v1beta1 kind: ClusterFlow metadata: name: harvester-loki namespace: cattle-logging-system spec: match: - select: {} globalOutputRefs: - harvester-loki --- apiVersion: logging.banzaicloud.io/v1beta1 kind: ClusterOutput metadata: name: harvester-loki namespace: cattle-logging-system spec: loki: url: http://loki-stack.cattle-logging-system.svc:3100 extra_labels: logOutput: harvester-loki

应用即可：

kubectl apply -f enhancements/20220525-system-logging/loki.yaml

等待 logging-operator 装载ClusterFlow/ClusterOutput后，日志便会流入 Loki。

访问与认证

将本地localhost:3000映射到loki-stack-grafana服务的 80 端口：

kubectl port-forward --namespace cattle-logging-system service/loki-stack-grafana 3000:80

默认用户名为admin，密码从 Secret 中取出：

kubectl get secret --namespace cattle-logging-system loki-stack-grafana \ --output jsonpath="{.data.admin-password}" | base64 --decode

LogQL 查询示例

打开 Grafana 后，在左侧菜单选择Explore进入手动查询页面，即可输入 LogQL 查询感兴趣的日志：

查询cattle-logging-system命名空间内的全部 Pod 日志：

查询rke2-server.service服务对应的 Harvester 主机日志：

LogQL 支持基于标签（label）的过滤组合，例如按命名空间、_SYSTEMD_UNIT、logOutput等字段精确筛选，从而做到"一次查询、全集群过滤"，彻底摆脱单容器日志查看的限制。

日志存储与默认行为

• 默认启用且不可禁用：受限于ManagedChart启用/禁用的已知问题，该日志特性默认启用，且用户后期无法自行关闭；
• 无 PVC 持久化：日志本身不由 PVC 承载。用户必须按上文方式配置一个日志接收端（Graylog、Loki、Splunk 等），才能查看与留存日志。这意味着日志栈本身是"转发型"而非"存储型"组件，持久化完全取决于外部接收端。

后续演进：Kubernetes 审计日志与事件日志

在 v1.0.3 → v1.1.0 的演进中，Harvester 在日志栈基础上进一步默认开启了kube-audit 审计日志与Kubernetes 事件日志（详见 20220822-event-and-audit.md）：

• 审计日志：通过 RKE2 server 启用--audit-policy-file生成审计日志，由专用的rancher-logging-kube-audit-fluentbit以tail方式读取/kube-audit-logs/audit.log，转发到独立的rancher-logging-kube-audit-fluentd-0。其 fluent-bit 采集定义见补丁 fluentbitagent.yaml，关键点是使用loggingRef: harvester-kube-audit-log-ref将审计日志流与通用日志流区分开；
• 事件日志：通过logging-extensions.banzaicloud.io/v1alpha1的EventTailer扩展部署harvester-default-event-tailer-0，监听全集群事件并输出为 JSON，再由通用 fluent-bit 采集汇入 root fluentd。EventTailer 的模板与资源覆盖见 eventtailer.yaml。

升级路径上，迁移脚本 v1.0.3.sh 中的create_logging_audit与create_event会分别在升级时注入logging-audit-v1.0.3.yaml与event-v1.0.3.yaml（见 logging-audit-v1.0.3.yaml 与 event-v1.0.3.yaml），确保审计与事件日志在升级后默认开启。

测试计划与升级策略

按原增强方案的验收路径，可在测试集群上依序验证：

1. 安装 Harvester 集群；
2. 确认相关 Pod 已创建：rancher-logging、rancher-logging-rke2-journald-aggregator、rancher-logging-root-fluentbit、rancher-logging-root-fluentd-0、rancher-logging-root-fluentd-configcheck；
3. 搭建日志服务器（Graylog、Splunk、ElasticSearch、Webhook 等），确保其与 Harvester 集群 VIP 网络可达；
4. 配置ClusterFlow与ClusterOutput将日志路由到该服务器；
5. 验证日志被正确转发到所配置的ClusterOutput；
6. 验证 K8s Pod 日志被接收；
7. 验证主机内核（kernel）与 systemd 日志被接收。

升级策略：升级过程无需用户介入，升级完成后日志功能即处于已安装且已启用状态（包含后续版本默认开启的审计与事件日志）。

源码速查

• 云原生
• 虚拟化
• 存储
• 后端
• 高可用