1. 为什么我要自己搭一套日志系统容器化环境里最让人头疼的事排第一的绝对是日志。业务跑在几十个 Pod 里出问题的时候第一反应是kubectl logs但那个只能看当前容器的标准输出Pod 一重启啥都没了。更别说想按关键字跨服务检索、想统计某个接口的报错率、想追溯一次请求在多个服务之间的完整链路——靠kubectl logs一个个翻纯属自虐。我这次接手的是一套中等规模的微服务集群大概三十多个服务、上百个 Pod跑在自建机房的一套 K8S 集群上。之前团队用的是最土的办法每个服务自己往本地文件写日志运维定时上去捞。结果就是磁盘三天两头爆捞上来的日志格式五花八门查一个问题要在五六个文件里来回 grep。痛定思痛决定上一套完整的日志采集、存储、检索方案。选型上其实没太多纠结。Fluentd做采集Elasticsearch做存储和检索Kibana做可视化这套组合在容器日志领域算是久经考验的老三样了。为什么不用 Fluent Bit因为 Fluentd 的插件生态更成熟尤其是对多行日志、字段解析这块配置起来更顺手虽然资源占用高一点但对我们的规模来说完全能接受。为什么不用 LokiLoki 确实轻但它的强项是标签检索全文检索能力跟 ES 比还是差一截我们这种需要按堆栈信息、错误码做复杂查询的场景ES 更合适。网上关于这套方案的教程一抓一大把但我实际搭下来发现坑是真的多。大部分文章要么只讲了个 Demo 级别的部署要么版本对不上要么关键配置一笔带过。我前后折腾了整整三天踩了无数坑才把整套链路跑通并且稳定运行。这篇文章就把我踩过的坑、验证过的配置、以及那些教程里不会写的细节一次性讲清楚。不管你是刚接触 K8S 日志的新手还是搭过但没跑通的老手应该都能从里面找到有用的东西。2. 整体架构设计与核心思路拆解2.1 数据流向与组件职责划分先把整个链路的数据流向理清楚不然后面配置起来容易晕。日志从产生到能查中间要经过这么几个环节日志产生业务容器往 stdout/stderr 输出这是容器日志的标准做法也是 K8S 推荐的方式。Docker 或者 containerd 会把这些输出写到节点上的 JSON 文件里。日志采集Fluentd 以 DaemonSet 的形式跑在每个节点上挂载节点的日志目录实时读取这些 JSON 文件。日志处理Fluentd 对读到的原始日志做解析、过滤、富化。比如把 JSON 里的log字段提取出来把 K8S 的元数据Pod 名、Namespace、Label附加进去把多行日志比如 Java 的堆栈合并成一条。日志转发处理完的日志通过 output 插件发到 Elasticsearch。日志存储与索引ES 接收日志按天或者按服务建索引提供全文检索能力。日志查询与展示Kibana 连上 ES提供搜索界面和可视化面板。这个链路里Fluentd 是最关键也最容易出问题的一环。它要处理的东西太多了读文件、解析 JSON、合并多行、附加元数据、缓冲、重试、转发。任何一个环节配置不对日志就断了。2.2 为什么选择 Fluentd 而不是其他采集器市面上做日志采集的组件不少我简单对比一下我考虑过的几个组件优势劣势适用场景Fluentd插件丰富配置灵活多行处理强资源占用较高Ruby 写的性能一般中大规模需要复杂处理Fluent Bit轻量性能好C 写的插件少复杂配置能力弱边缘计算资源受限环境Filebeat轻量ES 官方集成好多行处理弱K8S 元数据支持一般简单采集ES 生态Logstash处理能力强插件多太重JVM 吃内存传统虚拟机环境我最终选 Fluentd核心原因是多行日志处理。我们的 Java 服务报错的时候堆栈信息是几十行如果每行都当成独立日志查起来根本没法看。Fluentd 的concat插件能根据正则把多行合并成一条这个功能对我来说是刚需。Filebeat 虽然也有多行配置但灵活度差不少。Fluent Bit 的多行支持是后来才加的当时还不够成熟。另一个原因是K8S 元数据富化。Fluentd 的kubernetes_metadata插件能自动把 Pod 名、Namespace、容器名、Label 这些信息附加到日志里这样在 Kibana 里就能按服务、按环境过滤。这个插件用起来很省心配置几行就搞定。2.3 索引设计按天还是按服务ES 的索引设计是个绕不开的问题。常见的方案有两种按天建索引或者按服务建索引。按天建索引的好处是管理简单每天一个索引配合 ILM索引生命周期管理可以自动滚动删除老数据。坏处是如果某天某个服务日志量特别大会把当天的索引撑得很大影响查询性能。按服务建索引的好处是查询隔离每个服务的日志独立查起来快。坏处是索引数量会随着服务数量增长如果服务多索引管理会很麻烦。我最后选的是按天 按 Namespace 组合的方案。索引名格式是k8s-logs-namespace-date比如k8s-logs-production-2024.01.15。这样既能把不同环境的日志分开又能按天滚动。对于日志量特别大的服务后续可以再单独拆索引。索引的 mapping 也要提前设计好。默认的动态 mapping 会把所有字符串字段都建成textkeyword双字段虽然灵活但浪费空间。我手动指定了 mapping把log字段设成text并指定分词器把kubernetes.pod_name、kubernetes.namespace_name这些设成keyword这样聚合和过滤都快。3. 核心细节解析与实操要点3.1 Fluentd 配置文件的整体结构Fluentd 的配置文件是整个方案的核心也是最容易出错的地方。它的结构其实不复杂主要分几大块source # 定义日志来源比如读文件、收 HTTP 请求 /source filter # 定义过滤规则比如解析、富化、丢弃 /filter match # 定义输出目标比如发到 ES /match看起来简单但每个块里面的配置项非常多而且不同插件的配置项还不一样。我建议配置的时候分步来先配 source确认能读到日志再加 filter确认解析正确最后配 match确认能发到 ES。不要一次性全写完出了问题很难定位。3.2 读取容器日志的关键配置Fluentd 读容器日志用的是tail类型的 source。核心配置项有这么几个source type tail id in_tail_container_logs path /var/log/containers/*.log pos_file /var/log/fluentd-containers.log.pos tag kubernetes.* read_from_head true parse type json time_key time time_format %Y-%m-%dT%H:%M:%S.%N%Z keep_time_key true /parse /source这里有几个坑我要重点说一下第一个坑是path的写法。/var/log/containers/*.log这个路径下是软链接指向/var/log/pods/下面的实际文件。Fluentd 默认不跟随软链接需要确认你的版本是否支持。我用的版本是支持的但如果你用的是老版本可能需要改成/var/log/pods/**/*.log。第二个坑是pos_file的位置。这个文件记录每个日志文件的读取位置Fluentd 重启后从这里继续读。如果这个文件丢了Fluentd 会从头读导致日志重复。所以这个文件必须放在持久化的目录里不能放在容器临时目录。我一开始没注意Pod 重启后日志重复了一大堆查了半天才发现是 pos_file 没持久化。第三个坑是时间格式。容器日志的 JSON 里时间字段是time格式是 RFC3339 带纳秒的比如2024-01-15T10:30:45.123456789Z。time_format必须跟这个格式匹配否则解析会失败。我一开始写的是%Y-%m-%dT%H:%M:%S.%N%z结果因为时区是Z不是00:00解析一直报错。后来改成%Y-%m-%dT%H:%M:%S.%N%Z才对。3.3 多行日志合并的配置技巧多行日志合并是 Fluentd 最实用的功能之一但配置起来也有讲究。我用的是concat插件配置大概是这样filter kubernetes.** type concat key log multiline_start_regexp /^\d{4}-\d{2}-\d{2}/ flush_interval 5s timeout_label NORMAL /filter这个配置的意思是如果某行日志以日期开头比如2024-01-15就认为是一条新日志的开始否则就拼接到上一条日志后面。flush_interval是 5 秒意思是如果 5 秒内没有新行进来就把当前缓冲的日志发出去。这里的关键是multiline_start_regexp要写对。不同的日志框架输出的格式不一样有的是日期开头有的是日志级别开头有的是时间戳开头。你得根据自己服务的实际日志格式来写。我一开始写的是/^\d{4}/结果把一些以数字开头的正常日志也当成了新日志的开始导致堆栈被拆散了。后来改成完整的日期格式才正常。还有一个坑是timeout_label。这个配置项指定了超时后的日志打什么标签。如果不配超时的日志可能会被丢弃。我配的是NORMAL然后在 match 里处理这个标签的日志。3.4 K8S 元数据富化的正确姿势kubernetes_metadata插件能把 Pod 的信息附加到日志里配置很简单filter kubernetes.** type kubernetes_metadata id filter_kube_metadata kubernetes_url #{ENV[KUBERNETES_SERVICE_HOST]}:#{ENV[KUBERNETES_SERVICE_PORT]} verify_ssl #{ENV[KUBERNETES_VERIFY_SSL] || true} ca_file #{ENV[KUBERNETES_CA_FILE]} skip_labels false skip_container_metadata false skip_master_url false skip_namespace_metadata false /filter这个插件会连 K8S 的 API Server 获取 Pod 的元数据然后根据日志里的容器 ID 匹配到对应的 Pod。匹配上之后日志里会多出kubernetes字段包含pod_name、namespace_name、container_name、labels等信息。这里最大的坑是权限。Fluentd 的 DaemonSet 需要访问 K8S API 的权限如果 RBAC 没配好插件会一直报 403。我一开始用的是默认的 ServiceAccount结果一直拿不到元数据。后来手动创建了 ClusterRole 和 ClusterRoleBinding给了get、list、watchPods 和 Namespaces 的权限才正常。另一个坑是API Server 的地址。在 Pod 里K8S API 的地址是环境变量KUBERNETES_SERVICE_HOST和KUBERNETES_SERVICE_PORT但这两个变量不一定在所有环境里都有。如果没有就得手动指定。我用的方案是直接用环境变量如果取不到就 fallback 到默认的kubernetes.default.svc。4. 实操过程与核心环节实现4.1 部署 Elasticsearch 集群ES 的部署我建议用 Helm Chart省事而且配置规范。我用的是官方的elasticsearchChart版本是 8.x。部署的时候有几个关键参数要调helm install elasticsearch elastic/elasticsearch \ --namespace logging \ --set replicas3 \ --set minimumMasterNodes2 \ --set resources.requests.memory4Gi \ --set resources.limits.memory4Gi \ --set volumeClaimTemplate.resources.requests.storage100Gi \ --set esJavaOpts-Xmx2g -Xms2g堆内存的设置是个关键点。ES 的 JVM 堆内存不能超过物理内存的 50%也不能超过 32GB压缩指针的限制。我给每个节点 4GB 内存堆设成 2GB剩下 2GB 留给文件系统缓存。这个比例比较合理既能保证 ES 的性能又不会因为内存不足被 OOM Kill。存储的选择也很重要。ES 对磁盘 IO 很敏感一定要用 SSD。我用的是本地 SSD通过volumeClaimTemplate动态分配。如果你用的是网络存储延迟会高很多查询性能会明显下降。部署完之后用curl检查一下集群状态curl -X GET localhost:9200/_cluster/health?pretty返回的status应该是green或者yellow。如果是red说明有主分片没分配得赶紧排查。4.2 部署 Kibana 并连接 ESKibana 的部署更简单也是用 Helmhelm install kibana elastic/kibana \ --namespace logging \ --set elasticsearchHostshttp://elasticsearch-master:9200 \ --set resources.requests.memory1Gi \ --set resources.limits.memory1GiKibana 本身不怎么吃资源1GB 内存足够了。关键是elasticsearchHosts要写对指向 ES 的 Service 地址。部署完之后通过kubectl port-forward把 Kibana 的端口映射出来浏览器访问http://localhost:5601就能看到界面了。第一次进去需要创建 Index Pattern也就是告诉 Kibana 要查哪些索引。我创建的是k8s-logs-*这样所有以这个开头的索引都能被检索到。4.3 部署 Fluentd DaemonSetFluentd 的部署是整个方案里最复杂的部分。我用的是自定义的 DaemonSet而不是 Helm Chart因为需要改的配置太多Chart 的默认值不够灵活。DaemonSet 的 YAML 大概长这样apiVersion: apps/v1 kind: DaemonSet metadata: name: fluentd namespace: logging spec: selector: matchLabels: app: fluentd template: metadata: labels: app: fluentd spec: serviceAccountName: fluentd tolerations: - key: node-role.kubernetes.io/master effect: NoSchedule containers: - name: fluentd image: fluent/fluentd-kubernetes-daemonset:v1.16-debian-elasticsearch8-1 env: - name: FLUENT_ELASTICSEARCH_HOST value: elasticsearch-master.logging.svc.cluster.local - name: FLUENT_ELASTICSEARCH_PORT value: 9200 - name: FLUENT_ELASTICSEARCH_SCHEME value: http resources: limits: memory: 1Gi requests: memory: 512Mi volumeMounts: - name: varlog mountPath: /var/log - name: varlibdockercontainers mountPath: /var/lib/docker/containers readOnly: true - name: fluentd-config mountPath: /fluentd/etc - name: pos-files mountPath: /var/log/fluentd-buffers volumes: - name: varlog hostPath: path: /var/log - name: varlibdockercontainers hostPath: path: /var/lib/docker/containers - name: fluentd-config configMap: name: fluentd-config - name: pos-files hostPath: path: /var/log/fluentd-buffers type: DirectoryOrCreate这里有几个关键点镜像选择我用的是fluent/fluentd-kubernetes-daemonset的 ES8 版本这个镜像里已经预装了elasticsearch插件和kubernetes_metadata插件省得自己装。挂载点/var/log和/var/lib/docker/containers必须挂载前者是容器日志的软链接目录后者是实际日志文件的位置。pos_file 持久化我把/var/log/fluentd-buffers挂载到了宿主机的目录这样 pos_file 和缓冲文件在 Pod 重启后不会丢。资源限制Fluentd 的内存限制我设的是 1GB实际用下来大概在 500MB 左右留点余量防止突发流量。4.4 完整的 Fluentd 配置把前面讲的各个部分拼起来完整的fluent.conf大概是这样source type tail id in_tail_container_logs path /var/log/containers/*.log pos_file /var/log/fluentd-buffers/containers.log.pos tag kubernetes.* read_from_head true parse type json time_key time time_format %Y-%m-%dT%H:%M:%S.%N%Z keep_time_key true /parse /source filter kubernetes.** type kubernetes_metadata id filter_kube_metadata kubernetes_url #{ENV[KUBERNETES_SERVICE_HOST]}:#{ENV[KUBERNETES_SERVICE_PORT]} verify_ssl #{ENV[KUBERNETES_VERIFY_SSL] || true} ca_file #{ENV[KUBERNETES_CA_FILE]} /filter filter kubernetes.** type concat key log multiline_start_regexp /^\d{4}-\d{2}-\d{2}/ flush_interval 5s timeout_label NORMAL /filter filter kubernetes.** type record_transformer enable_ruby true record hostname #{Socket.gethostname} tag ${tag} /record /filter match kubernetes.** type elasticsearch id out_es host #{ENV[FLUENT_ELASTICSEARCH_HOST]} port #{ENV[FLUENT_ELASTICSEARCH_PORT]} scheme #{ENV[FLUENT_ELASTICSEARCH_SCHEME]} ssl_verify false index_name k8s-logs-${record.dig(kubernetes, namespace_name)}-${Time.now.strftime(%Y.%m.%d)} type_name _doc include_tag_key true tag_key log_name flush_interval 5s buffer_chunk_limit 5m buffer_queue_limit 64 num_threads 4 reload_connections false reconnect_on_error true reload_on_failure true buffer type file path /var/log/fluentd-buffers/kubernetes.system.buffer flush_mode interval retry_type exponential_backoff flush_thread_count 2 flush_interval 5s retry_forever retry_max_interval 30 chunk_limit_size 5M queue_limit_length 64 overflow_action block /buffer /match这个配置里索引名的动态生成是个亮点。${record.dig(kubernetes, namespace_name)}会取日志里的 Namespace 名${Time.now.strftime(%Y.%m.%d)}会取当前日期拼起来就是k8s-logs-production-2024.01.15这样的索引名。这样不同环境、不同天的日志自动分开管理起来很方便。缓冲区的配置也很关键。buffer块里我配了文件类型的缓冲retry_forever表示如果 ES 挂了Fluentd 会一直重试不会丢日志。overflow_action block表示如果缓冲队列满了就阻塞写入而不是丢弃。这些配置保证了日志的可靠性但也要注意如果 ES 长时间不可用缓冲文件会占满磁盘所以得监控磁盘使用率。5. 常见问题与排查技巧实录5.1 日志丢失的排查思路日志丢失是最常见也最让人头疼的问题。我遇到过的原因有好几种排查的时候可以按这个顺序来第一步确认 Fluentd 有没有读到日志。看 Fluentd 的日志如果有tail相关的报错说明读文件就有问题。常见原因是路径不对、权限不够、或者 pos_file 损坏。第二步确认解析有没有成功。如果 Fluentd 读到了日志但解析失败日志会被打上fluentd.warn标签然后被丢弃。可以在 Fluentd 的日志里搜parse关键字看看有没有解析错误。第三步确认有没有发到 ES。如果解析成功但发送失败Fluentd 会重试。如果重试一直失败日志会积压在缓冲里。可以看缓冲目录的大小如果一直在增长说明发送有问题。第四步确认 ES 有没有收到。如果 Fluentd 显示发送成功但 ES 里查不到可能是索引名不对、mapping 冲突、或者 ES 的写入被拒绝。可以查 ES 的日志看看有没有reject相关的报错。我整理了一个速查表方便对照排查现象可能原因排查方法解决方案Fluentd 日志无输出路径不对/权限不够检查挂载和权限修正 path 和 volumeMounts解析失败时间格式不匹配看 Fluentd 日志的 parse 错误调整 time_format发送失败ES 地址不对/网络不通检查环境变量和网络策略修正 ES 地址ES 查不到索引名不对/mapping 冲突查 ES 的索引列表和 mapping调整索引名和 mapping日志重复pos_file 丢失检查 pos_file 是否持久化挂载持久化目录5.2 性能问题的调优经验Fluentd 和 ES 都是吃资源的组件规模上来之后性能问题很常见。我遇到过的性能瓶颈主要有两个一个是 Fluentd 的 CPU 占用高。Fluentd 是 Ruby 写的单线程处理能力有限。如果日志量很大CPU 会跑满。解决办法是增加flush_thread_count和num_threads让多个线程并行处理。我把这两个值都调到了 4CPU 占用明显下降。另一个是 ES 的写入延迟高。ES 默认的刷新间隔是 1 秒也就是说日志写入后 1 秒才能被搜到。如果写入量很大刷新操作会很频繁影响性能。我把refresh_interval调成了 30 秒写入性能提升了不少。代价是日志有 30 秒的延迟才能被搜到但对我们的场景来说可以接受。还有一个调优点是ES 的批量写入。Fluentd 的 ES 插件支持批量发送flush_interval控制批量的大小。我设的是 5 秒每次发一批。如果设得太小请求太频繁设得太大延迟高。5 秒是个比较平衡的值。5.3 那些教程里不会写的坑坑一时区问题。容器日志的时间是 UTC但我们在 Kibana 里看的时候想按本地时间看。如果不在 Fluentd 里做时区转换Kibana 里显示的时间会差 8 小时。解决办法是在record_transformer里加一个字段把时间转成本地时间。或者直接在 Kibana 里设置时区但这样索引里的时间还是 UTC做聚合的时候会乱。坑二多行日志的边界。concat插件的multiline_start_regexp如果写得太宽会把不该合并的日志合并写得太窄该合并的没合并。我建议先用几条真实的日志测试一下正则确认能正确匹配再上线。坑三ES 的 mapping 冲突。如果同一个索引里某个字段第一次是字符串第二次是数字ES 会报 mapping 冲突拒绝写入。解决办法是提前定义好 mapping把所有可能出现的字段都定义好类型。或者用索引模板让 ES 自动应用。坑四Fluentd 的内存泄漏。Fluentd 长时间运行后内存会慢慢增长最后被 OOM Kill。这是 Ruby 的 GC 机制导致的很难完全避免。我的做法是设置一个内存限制让 K8S 在内存超限时自动重启 Pod。虽然会短暂中断日志采集但比整个节点挂掉好。坑五Kibana 的索引模式。如果索引名是动态生成的Kibana 的 Index Pattern 要写成通配符形式比如k8s-logs-*。如果写成具体的索引名新建的索引就查不到。这个坑我踩过明明 ES 里有数据Kibana 就是查不到折腾了半天才发现是 Index Pattern 写死了。5.4 监控与告警的配置建议日志系统本身也需要监控不然它挂了都不知道。我配了几个关键的监控项Fluentd 的缓冲队列长度如果队列持续增长说明 ES 写入有问题需要告警。ES 的集群状态如果是red或者yellow说明有分片没分配需要处理。ES 的磁盘使用率超过 85% 会触发 ES 的只读模式日志就写不进去了。Kibana 的可用性如果 Kibana 挂了虽然不影响日志采集但查不了日志。这些监控项可以用 Prometheus 采集然后在 Grafana 里做面板。Fluentd 和 ES 都有 Prometheus 的 exporter配置起来不难。6. 一些实操后的个人体会这套方案我跑了大概半年中间经历过几次 ES 集群扩容、Fluentd 配置调整整体还算稳定。有几个体会比较深第一配置一定要版本化。Fluentd 的配置、ES 的 mapping、Kibana 的 Index Pattern这些都要用 Git 管理起来。每次改动都提交出问题了可以快速回滚。我一开始是直接在服务器上改改出问题后忘了改了什么排查了很久。第二日志的规范化很重要。如果业务输出的日志格式五花八门Fluentd 的解析规则会非常复杂维护成本很高。我后来推动团队统一了日志格式都用 JSON 输出字段名也统一了Fluentd 的配置一下子简单了很多。第三不要追求一步到位。我一开始想的是把所有功能都配上多行合并、字段提取、告警规则结果配置太复杂出了问题根本不知道是哪里的问题。后来我简化了配置先保证日志能采上来、能查到然后再逐步加功能。这样每一步都可控出问题也好定位。第四留好扩展空间。日志量是会增长的一开始可能每天几个 GB半年后可能就几十个 GB 了。ES 的集群规模、Fluentd 的资源限制、索引的滚动策略都要提前考虑扩展性。我一开始只部署了一个 ES 节点后来日志量上来后不得不停机扩容很麻烦。最后再分享一个小技巧如果日志量特别大可以在 Fluentd 里做采样。比如只采集 ERROR 级别的日志或者按比例采样。这样能大幅减少 ES 的存储压力同时保留最关键的信息。当然采样规则要根据业务需求来定不能一刀切。