Harvester 集群系统日志统一收集与外部导出实战：基于 rancher-logging 的日志聚合方案详解

Harvester 集群系统日志统一收集与外部导出实战：基于 rancher-logging 的日志聚合方案详解

发布时间：2026/10/13 1:50:40
Harvester 集群系统日志统一收集与外部导出实战：基于 rancher-logging 的日志聚合方案详解 云原生虚拟化存储后端高可用【免费下载链接】harvesterOpen source hyperconverged infrastructure (HCI) software项目地址https://gitcode.com/gh_mirrors/ha/harvester点击查看免费下载本篇技术指南围绕 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。核心组件与职责安装完成后日志栈由以下主要组件组成名称职责logging-operator管理定义日志路由的ClusterFlow与ClusterOutput自定义资源fluentd中央日志聚合器负责把日志转发到其他日志收集端root fluentdfluent-bit从集群各 Pod 采集日志的轻量采集器root fluentbitjournald-aggregator以 DaemonSet 形式在每个节点上收集 journal 主机日志安装后的 Pod 形态安装成功后cattle-logging-system命名空间下应出现如下 PodNAME 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.yamlsystemdLogPath: /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_UNITrke2-server.service Systemd_Filter _SYSTEMD_UNITrke2-agent.service Systemd_Filter _SYSTEMD_UNITrancherd.service Systemd_Filter _SYSTEMD_UNITrancher-system-agent.service Systemd_Filter _SYSTEMD_UNITwicked.service Systemd_Filter _SYSTEMD_UNITiscsid.service Systemd_Filter _TRANSPORTkernel即只保留RKE2 服务端/Agent、rancherd 引导服务、rancher-system-agent、网络配置服务wicked、iSCSI 服务iscsid以及内核_TRANSPORTkernel日志。fluent-bit 采集配置源码级解析当前仓库中实际生效的 fluent-bit 配置由 ISO 打包补丁 configmap.yaml 定义比早期增强文档多了更完整的输入与解析器[INPUT] Name systemd Tag rke2_journald Path {{ .Values.systemdLogPath }} # 默认 /var/log/journal Systemd_Filter _SYSTEMD_UNITrke2-server.service Systemd_Filter _SYSTEMD_UNITrke2-agent.service Systemd_Filter _SYSTEMD_UNITrancherd.service Systemd_Filter _SYSTEMD_UNITrancher-system-agent.service Systemd_Filter _SYSTEMD_UNITNetworkManager.service Systemd_Filter _SYSTEMD_UNITiscsid.service Systemd_Filter _TRANSPORTkernel [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 的挂载布局挂载路径宿主机路径用途/fluent-bit/etc/—配置与解析器文件/var/log/journal/var/log/journaljournald 日志只读/var/lib/rancher/rke2/agent/logs同左kubelet 日志只读/etc/machine-id同左机器标识只读/var/log/audit/audit.log同左审计日志文件只读同时 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-systemkubectl 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 trueACTIVEtrue表示路由已被 logging-operator 成功装载。需要特别注意的是目标日志服务器必须与 Harvester 集群 VIP 网络可达。手动部署 Loki 并可视化查询Loki默认不会随集群安装需要时可手动部署与日志栈打通后即可在 Grafana 中可视化查询全集群日志。安装 loki-stack仓库提供了适配 Harvester 场景的 Helm valuesloki-values.yaml其要点为grafana: enabled: true promtail: enabled: false即开启内置 Grafana、关闭 promtail因为日志已由日志栈的 fluentd 转发不再需要 promtail 采集。执行安装示例为当时验证过的版本 2.7.0helm 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 --decodeLogQL 查询示例打开 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确保审计与事件日志在升级后默认开启。测试计划与升级策略按原增强方案的验收路径可在测试集群上依序验证安装 Harvester 集群确认相关 Pod 已创建rancher-logging、rancher-logging-rke2-journald-aggregator、rancher-logging-root-fluentbit、rancher-logging-root-fluentd-0、rancher-logging-root-fluentd-configcheck搭建日志服务器Graylog、Splunk、ElasticSearch、Webhook 等确保其与 Harvester 集群 VIP 网络可达配置ClusterFlow与ClusterOutput将日志路由到该服务器验证日志被正确转发到所配置的ClusterOutput验证 K8s Pod 日志被接收验证主机内核kernel与 systemd 日志被接收。升级策略升级过程无需用户介入升级完成后日志功能即处于已安装且已启用状态包含后续版本默认开启的审计与事件日志。源码速查内容仓库路径内置 Addon 定义addons/built-in/rancher-logging/addon-template.yamlAddon 元信息addons/built-in/rancher-logging/metadata.yamlISO 图表补丁脚本addons/packaging/hack/patch-rancher-loggingjournald fluent-bit 配置补丁configmap.yamljournald DaemonSet 补丁daemonset.yamlkube-audit 采集补丁fluentbitagent.yamlLoki 路由定义enhancements/20220525-system-logging/loki.yamlLoki Helm valuesenhancements/20220525-system-logging/loki-values.yaml审计与事件日志设计enhancements/20220822-event-and-audit.md赞分享云原生虚拟化存储后端高可用【免费下载链接】harvesterOpen source hyperconverged infrastructure (HCI) software项目地址https://gitcode.com/gh_mirrors/ha/harvester点击查看免费下载相关推荐KubeEdge日志系统详解边缘节点日志收集与云端聚合方案KubeEdge日志系统详解边缘节点日志收集与云端聚合方案 1. 边缘日志挑战与KubeEdge解决方案 边缘计算环境中日志系统面临三大核心挑战 网络不稳云原生边缘计算物联网容器编排边缘网关Siamese-pytorch项目架构设计如何扩展和维护一个完整的深度学习项目Siamese pytorch项目架构设计如何扩展和维护一个完整的深度学习项目 孪生神经网络Siamese Network是一种强大的深度学习架构专门用猫抓浏览器扩展终极视频嗅探与M3U8下载解决方案猫抓浏览器扩展终极视频嗅探与M3U8下载解决方案 你是否经常遇到心仪的视频却无法保存或者面对复杂的流媒体链接束手无策猫抓浏览器扩展正是为你量身打造的一站式音视频上一篇GitHub Actions Runner镜像中Fable CLI执行失败问题终极解析下一篇BoxMOT 多目标跟踪选型手册7 种 SOTA 跟踪器按场景怎么选、怎么跑创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考