Filebeat 是轻量采集器核心原则就近采集日志尽量在日志产生的机器上部署避免跨网络读取日志。一、物理机 / 传统虚拟机业务服务器最常用部署方式每台业务机器独立部署 FilebeatAgent 单机部署业务机器Java 应用、Nginx、Tomcat日志输出到本机磁盘/opt/app/logs/。 每台业务服务器单独安装一个 Filebeat只采集本机的日志文件。部署步骤简述在业务机器安装 filebeat rpm/deb 包修改filebeat.yml配置日志路径、输出Kafka / ES启动 systemd 托管systemctl start filebeat systemctl enable filebeatregistry 文件默认路径/var/lib/filebeat/registry保存文件读取 offset 断点。✅优点就近读取本地磁盘日志网络开销小轻量内存占用几十 MB几乎不抢占业务资源断点续传重启不丢、不重复采集横向扩展简单新增业务机器部署 Filebeat 即可。❌缺点机器数量很多时需要批量部署ansible / 脚本配置变更需要批量下发 yaml。适用物理机、ECS 云主机微服务业务大数据服务器YARN/Flink/spark 日志采集。二、Kubernetes 容器环境两种主流方案方案 1DaemonSet 方式生产首选在 K8s 集群每个 Node 节点运行一个 Filebeat Pod。 Filebeat Pod 挂载宿主机的容器日志目录/var/log/containers/读取宿主机上所有容器产生的日志。不管这个 Node 上跑多少业务 Pod只需要 1 个 Filebeat Pod。✅优点只需要部署一次 DaemonSet新增节点自动拉起 Filebeat不用给每个业务 Pod 单独部署运维成本低。❌缺点Filebeat 权限要求高需要挂载宿主机目录日志过滤逻辑写在 DaemonSet 的配置区分不同业务日志需要加标签过滤。方案 2Sidecar 边车模式每个业务 Pod 内部单独启动一个 Filebeat 容器和业务容器共享日志卷 emptyDir。业务容器写日志到共享卷同 Pod 内 Filebeat 读取日志。✅优点日志隔离每个业务 Pod 的采集配置独立不依赖宿主机目录权限更安全采集范围只属于当前 Pod。❌缺点Pod 数量多的时候Filebeat 实例数量非常多资源开销变大配置管理繁琐。对比K8s 绝大多数业务选择DaemonSet只有强隔离需求才用 Sidecar。DaemonSetDS解释说明一句话DaemonSet 保证集群里每一个或者指定一部分节点都运行一份相同的 Pod 副本。新节点加入集群会自动在该节点创建 Pod节点删除Pod 跟着回收。适用场景节点日志收集如 filebeat、fluentd每个节点都要采集容器日志节点监控node-exporter每个节点采集服务器指标网络插件calico、flannel每个节点网络代理安全代理、节点审计等每个机器都必须部署一个的组件❌ 不适合业务应用业务一般用 Deployment不需要每台节点都跑和 Deployment 区别DaemonSet每个节点最多 1 个 Pod不控制副本数由节点数量决定不支持扩缩副本是扩缩节点Deployment调度 Pod 到任意节点可以多个 Pod 跑在同一个节点用来部署业务服务简单 yaml 示例#资源所属 API 组Deployment、StatefulSet、DaemonSet 都在apps/v1K8s 1.9 之后稳定版本。 apiVersion: apps/v1 kind: DaemonSet #资源类型声明这是一个 DaemonSet作用是每个符合条件节点运行 1 个 Pod metadata: #metadata 元信息 name: filebeat-ds #DaemonSet 的名称执行 kubectl 操作时用这个名字 namespace: logging #资源放在logging命名空间不写默认是default spec: #spec.selector 标签选择器 selector: #selector.matchLabels**用来匹配 Pod 标签**。DaemonSet 控制器通过标签找到属于自己管理的 Pod matchLabels: app: filebeat template: #spec.template Pod 模板核心定义要创建的 Pod 长什么样。DaemonSet 会用这个模板在节点上创建 Pod metadata: labels: app: filebeat #metadata.labels给生成出来的 Pod 打上标签 appfilebeat和上面 selector 匹配 #spec.template.spec.containers 容器配置 spec: # nodeSelector / nodeAffinity 可以指定只在部分节点部署 # nodeSelector: # env: prod containers: #Pod 内容器列表一个 Pod 可以多个容器 - name: filebeat #name: filebeat容器名称Pod 内标识 image: elastic/filebeat:7.17.0 #image: elastic/filebeat:7.17.0镜像地址 版本拉取 filebeat 镜像用来收集日志 volumeMounts: #**挂载声明**把卷挂载到容器内部目录 - name: varlog #卷名字要和下面 volumes 的 name 对应 mountPath: /var/log #容器内路径容器里面/var/log就是挂载点 volumes: #volumes 卷定义在 Pod 级别定义卷 - name: varlog #卷名称和 volumeMounts 关联 hostPath: #宿主机卷类型**把节点宿主机上的目录挂载进容器** path: /var/log #宿主机node 节点的/var/log目录常用操作命令# 创建DaemonSet kubectl apply -f ds.yaml # 查看ds kubectl get daemonset -n logging kubectl get ds -n logging # 查看详情排查为什么Pod无法调度 kubectl describe ds filebeat-ds -n logging # 查看ds下的pod kubectl get pod -n logging -l appfilebeat -o wide # 更新镜像滚动更新默认策略RollingUpdate kubectl set image ds/filebeat-ds filebeatelastic/filebeat:8.11.0 -n logging # 删除DaemonSet会连带删除所有Pod kubectl delete ds filebeat-ds -n logging三、集中式部署不推荐了解即可单独找一台日志采集服务器远程读取其他机器日志例如 sftp、nfs 挂载远程日志目录在这一台机器上部署 Filebeat 采集多台机器日志。❌缺点跨网络读取日志网络延迟高网络抖动容易丢日志单点风险采集机挂掉所有机器日志无法采集无法正确监听 inode日志切割场景容易漏采。生产基本不用。不推荐集中式Filebeat 设计就是分布式 agent。四、容器Docker 非 K8s和物理机思路类似宿主机部署 Filebeat挂载 docker 日志目录/var/lib/docker/containers/采集本机所有容器 json 日志。五、Filebeat 输出目标和部署配套Filebeat 采集完日志可以输出到三类输出 Kafka大规模生产架构首选Filebeat - Kafka - Logstash - ES直接输出 ES小规模业务省去 Logstash输出 Logstash小型架构Filebeat - Logstash - ES最佳实践Filebeat 只负责采集不做复杂清洗复杂 grok 解析、脱敏放到 Logstash。六、精简版Filebeat 有 4 种部署方式物理机 / ECS单机 Agent 部署。每台业务机器部署 Filebeat采集本机磁盘日志就近采集轻量是传统业务最常用方式。K8s DaemonSet首选集群每个节点运行一个 Filebeat Pod读取宿主机所有容器日志运维简单不需要每个 Pod 单独部署。K8s Sidecar 边车每个业务 Pod 内附带 Filebeat 容器共享日志卷隔离性好但实例多、资源开销大。集中式远程采集不推荐。单台机器远程读取多台机器日志存在单点故障、网络问题容易丢日志。核心原则Filebeat 属于分布式采集 Agent就近采集本地日志尽量避免远程读取。七、高频QAQregistry 文件作用A保存每个日志文件的读取偏移量 offset、inode 信息Filebeat 重启后从上次位置继续采集防止重复采集或者漏日志。QDaemonSet 和 Sidecar 怎么选A集群规模大通用日志采集选 DaemonSet业务需要独立采集配置、强隔离场景才使用 Sidecar。QFilebeat 能不能部署在 Logstash 服务器上采集A不建议。Filebeat 尽量部署在日志产生端减少网络传输压力。