K8S日志采集与监控方案介绍
需求背景
在 Kubernetes 集群中，需要全面了解各个 pod 应用运行状态、故障排查和性能分析。但由于 Pod 是动态创建和销毁的，其日志分散且存储不持久，因此需要通过集中式日志采集方案，将日志收集到统一的平台并配置日志可视化分析和监控告警，以实现日志的可追溯性、实时监控和高效分析，从而提升运维效率和系统可靠性。
但目前日志采集与监控方案众多，经常有小伙伴咨询应该使用哪种技术方案可以更好的实现这些功能，接下来就以本人实际项目经验为例，向大家介绍几种常见的日志采集与监控方案。
技术选型
部署方案
DaemonSet
DaemonSet 是 Kubernetes 的一种控制器，用于确保每个节点上运行一个特定的 Pod 实例运行，通常情况下使用DaemonSet方式采集宿主机/var/log/containers/路径下日志，从 k8s 节点上收集所有容器的日志。
以下业务场景推荐优先选择 DaemonSet：
- 集群规模较大。
- 日志采集需求一致，日志格式标准化。
- 需要高效的资源利用率。
Sidecar
Sidecar 是将日志采集容器作为 Pod 的辅助容器，与业务容器运行在同一个 Pod 中，从业务容器共享的日志路径采集日志。
以下业务场景推荐优先选择 Sidecar:
- 单个应用需要定制化日志采集逻辑。
- 应用日志复杂，需要解析特定格式或关联上下文，添加其他自定义元数据信息。
- 部署环境多变，需要避免节点级路径依赖。
- 单个 pod 日志量巨大，需要更高的性能和实时性要求。
采集方案
Elastic Agent
遵循all in on的设计理念，配合Fleet Server 可以集中管理 所有的 agent，且官方内置了 400 多种日志采集策略和解析规则，通过web页面简单设置即可实现绝大多数种类的日志采集和解析，无需配置复杂的采集策略和数据清洗规则。具体可参考文档：https://www.cuiliangblog.cn/detail/section/162609367
以下业务场景推荐优先选择 Elastic Agent：
- 日志种类复杂。
- 需要统一集中管理所有采集工具，简化运维配置与维护工作。
- 希望通过一个 Agent 采集所有日志、指标数据。
Fluent-bit
Fluent Bit 是 Fluentd 的轻量级版本，专注于高性能、低资源占用的日志收集和转发。但内置插件较少，不善于对日志进行复杂的解析和处理。具体可参考文档：https://www.cuiliangblog.cn/detail/section/162609331
以下业务场景推荐优先选择 Fluent-bit：
- Kubernetes 或容器化环境中需要高性能、轻量化日志采集。
- 多元化日志输出需求（如 Kafka、Splunk、ElasticSearch等）。
- 资源受限的环境，如边缘设备或小型容器集群。
Filebeat
Filebeat 是 Elastic Stack 的轻量级日志采集工具，专为将日志从各种源传输到 Elasticsearch、Logstash 或其他输出端而设计，日志采集性能最好。具体可参考文档：https://www.cuiliangblog.cn/detail/section/162609278
以下业务场景推荐优先选择 Filebeat：
- 单个 pod 日志量巨大，对性能和实时性要求较高，配合 Sidecar 采集 pod 日志。
- 环境中日志类型多样化，需要快速解析和转发。
解析方案
Logstash
Logstash 是 Elastic Stack 的官方组件，专注于日志和事件数据处理。并且经过多年的发展，具备了丰富的插件生态，支持复杂的过滤、转换和条件逻辑。具体可参考文档：https://www.cuiliangblog.cn/detail/section/31174923
以下业务场景推荐优先选择 Logstash
- 需要复杂的解析、数据清洗和格式转换。
- 资源充足的环境，Logstash对CPU 和内存有较高要求。
Vector
Vector 是一款以高性能、低资源占用的新兴日志解析工具，它使用Rust 编写，具备提供强大的日志和指标采集、转换和传输功能。支持一体化设计，支持收集、处理、转发日志和指标。具体可参考文档：https://www.cuiliangblog.cn/detail/section/162609248
- 以下业务场景推荐优先选择 Vector
- 日志解析量巨大，需要高性能解析日志并且希望减少资源占用。
- 日志解析需求简单。
Fluentd
Fluentd 是 CNCF 托管项目，提供高性能和灵活的数据采集、处理和转发。通常与 Fluent-bit 配合接收转发的日志进行进一步解析处理。具体可参考文档：https://www.cuiliangblog.cn/detail/section/162609248
以下业务场景推荐优先选择 Fluentd：
- 日志处理需求简单和性能需求适中的绝大部分场景。
- 在 Kubernetes 中广泛使用，与 Fluent Bit 配合使用。
Ingest Pipeline
Ingest Pipeline 是直接在 Elasticsearch 中运行的内置解析工具，无需部署单独的中间处理工具，它提供了提供简单的数据处理功能。具体可参考文档：https://www.cuiliangblog.cn/detail/section/76304999
以下业务场景推荐优先选择 ES Pipeline
- 日志处理需求简单且对性能要求不高的场景。
- 日志采集后直接写入 ES，简化架构并减少运维开销，通常与 Elastic Agent 一起配合使用。
存储方案
ElasticSearch
Elasticsearch 是一个基于 Apache Lucene 构建的分布式搜索和分析引擎，能够高效地处理结构化和非结构化数据。
Loki
Loki 是由 Grafana Labs 开发的一种日志聚合系统，与 Prometheus 类似，但更专注于日志管理。它强调轻量化设计，并通过标签对日志进行管理，而非索引。
Graylog
Graylog 是一个集中的日志管理平台，提供简单易用的界面和集成工具，用于收集、存储、分析和展示日志数据。它常与 Elasticsearch 一起使用来增强存储能力。
ClickHouse
ClickHouse 是一个开源的列式数据库，专为大规模实时数据分析设计，能够高效地处理时序数据和日志分析。
以下是几种存储方案的对比，比较有意思的是虽然每种方案曾经都被誉为挑战 ES 日志存储地位的新兴技术，但是就目前来说 ES 仍然是主流的技术方案。
| 特性 | Elasticsearch | Loki | Graylog | ClickHouse |
|---|---|---|---|---|
| 主要功能 | 全文检索和数据分析 | 日志聚合与标签查询 | 日志收集与实时报警 | 时序和日志数据分析 |
| 架构特点 | 分布式、支持副本 | 无索引、轻量化设计 | 集成化管理工具 | 列式存储、高压缩率 |
| 性能 | 优秀，适合大规模查询 | 高效，但功能较弱 | 一般，不适合高负载 | 优秀，适合复杂查询 |
| 学习成本 | 较高 | 较低 | 较低 | 较高 |
| 优点 | 强大的全文检索能力；可扩展性强；生态丰富；支持复杂聚合分析和可视化工具（如 Kibana） | 轻量级，无索引设计降低存储和计算开销；与云原生工具集成度高；成本优化友好 | 部署简单；界面友好，非技术用户易上手；支持多种日志来源；内置流处理和报警功能 | 查询性能优异，尤其适合大数据量；存储高效；支持复杂 SQL 分析；低成本存储大规模数据 |
| 缺点 | 存储和资源开销大；集群维护复杂；复杂查询性能在极大量数据下可能下降 | 查询功能有限，无法支持复杂分析；对高并发和大规模数据管理支持不足 | 数据处理能力有限；性能不如其他方案；不适合处理海量数据或高复杂度查询 | 由于是列式数据库，且只支持稀疏索引，不具备倒排索引功能，无法像ES一样提供同样的全文检索能力；无法动态添加字段，需要提前定义好表schema。 |
方案推荐
了解各个技术的优缺点和适用场景后，日志采集方案就是将上面的技术组合起来既可。目前以 ES 为日志存储告警的方案有很多，各种方案各有优劣和最适合适用场景，并不是说哪种方案就是最好的，只能说哪个方案更适，还是得看具体的业务场景，考虑业务需求、资源成本、维护难度等综合分析。不过目前来看EFK方案（DaemonsSet方式部署Fluent-bit采集容器日志，由Fluentd解析处理，最后写入 ElasticSearch 存储，通过 Grafana 查询和告警）较为主流。
多日志种类场景
如果日志种类较为多，但每种类型的日志量较少，且日志源分别在不同环境需要统一维护管理时，可以优先考虑Elastic Agent+Fleet Server方案。
例如之前做的银行日志采集项目就是采用此方案实现，日志采集需求特点如下：
- 采集日志种类包括操作系统、中间件、数据库、第三方应用 API 接口、网络设备syslog 、公有云操作日志等采集解析需求。
- 由于安全权限管控，无法直接登录服务器进行 Agent 配置更改、版本升级等操作。
- 单个类型日志量较小，使用 Ingest Pipeline 完全可以满足性能需求。
Elastic Agent+Fleet Server 方案就特别适合这种场景使用，因为官方内置大超过 400 种采集策略可以一键应用，省去了配置采集端和日志内容解析以及 dashboard 制作，同时也提供了大量的 custom 类型集成策略，可以灵活根据不同的需求场景进行自定义配置。
具体可参考文档：https://www.cuiliangblog.cn/detail/section/162609367
小规模日志采集场景
目前我们集群的节点数仅几十台，且每天日志量不足 1T，日志内容大部分都是 json 格式，只需要简单的 json 解析既可，针对此场景，推荐使用 EFK 方案，具体方案如下：
- daemonset 部署：通过DaemonSet方式在每个kubernetes集群节点上运行fluent bit服务。以容器运行时containerd为例，配置fluent bit输入路径为/var/log/containers/<kubernetes.container.id>.log，可以轻松实现 pod 终端日志采集。
- fluent bit采集：相较于fluentd而言，fluent bit更加轻量，且内置了pod日志解析插件和service日志采集功能无需编写复杂的日志处理配置，可以最大程度减少资源占用。
- fluentd 解析处理：虽然fluent bit足够轻量，但日志解析处理能力弱于fluentd。fluentd支持更多的过滤处理插件，对于常用的数据处理操作，fluentd可以直接通过ruby语法处理。使用Fluentd充当日志聚合层，接收fluent-bit日志后统一进行处理操作，最后批量写入elasticsearch集群。这样做的好处是当k8s集群规模过大时，避免了过多的fluent-bit连接ES写入数据，导致ES连接资源消耗过高、网络拥堵、连接资源竞争等问题。
EFK 方案可以将日志采集与日志处理拆后分别交由不同的组件负责，最大程度发挥各个组件的优势，使得配置文件更加清晰易读，便于后期维护管理。具体可参考文档：https://www.cuiliangblog.cn/detail/section/162609303，如果集群规模比较小，且不需要复杂的日志解析处理需求，可以考虑使用 Ingest pipeline 替代 Fluentd 组件。
大规模日志采集场景
之前做过较大的国内互联网业务日志采集，业务特点就是采集端节点数量较多，主要收集 access 、metrics等运行日志，但每种日志量巨大，单以 access 日志为例，每天就可产生有几十亿条访问日志，每天写入十几 T 的日志数据，针对此场景，推荐使用ELK 方案，具体方案如下：
- Sidecar 部署 filebeat 采集：如果单个 pod 日志量巨大，可以考虑通过sidecar方式运行filebeat日志采集容器，使用emptyDir 或持久化卷让主容器和 Filebeat 容器共享日志目录。
- Kafka 消息中间件： 通过 kafka 日志中间件实现日志的削峰填谷的作用，缓解后端日志处理的压力。同时 kafka 支持持久化存储，避免后端日志处理异常时日志丢失问题。
- Logstash 解析处理：借助Kafka的Consumer Group技术可部署多个logstash副本，提升数据处理能力和高可用性。需要注意的是每个consumer最多只能使用一个partition，当一个Group内consumer的数量大于partition的数量时，只有等于partition个数的consumer能同时消费，其他的consumer处于等待状态。因此想要增加logstash的消费性能，可以适当的增加topic的partition数量，但kafka中partition数量过多也会导致kafka集群故障恢复时间过长。
ELK 方案在应对大规模复杂日志解析场景下比 EFK 方案更为合适，具体可参考文档：https://www.cuiliangblog.cn/detail/section/162609278。如果集群规模较大但单个 pod 日志量较小，可以更换为 Daemonset 方案采集每个节点日志，如果日志解析需求不复杂或追求更低的资源占用，可以更换为 vector 解析日志。
查看更多
崔亮的博客-专注devops自动化运维，传播优秀it运维技术文章。更多原创运维开发相关文章，欢迎访问https://www.cuiliangblog.cn