ELK Filebeat 部署- 惊觉

Filebeat 是轻量采集器，核心原则：就近采集日志，尽量在日志产生的机器上部署，避免跨网络读取日志。

一、物理机 / 传统虚拟机（业务服务器，最常用）

部署方式：每台业务机器独立部署 Filebeat（Agent 单机部署）

业务机器：Java 应用、Nginx、Tomcat，日志输出到本机磁盘 /opt/app/logs/。每台业务服务器单独安装一个 Filebeat，只采集本机的日志文件。

部署步骤简述：

在业务机器安装 filebeat rpm/deb 包；
修改 filebeat.yml：配置日志路径、输出（Kafka / ES）；
启动 systemd 托管：systemctl start filebeat && systemctl enable filebeat
registry 文件默认路径：/var/lib/filebeat/registry，保存文件读取 offset 断点。

✅优点

就近读取本地磁盘日志，网络开销小；
轻量，内存占用几十 MB，几乎不抢占业务资源；
断点续传，重启不丢、不重复采集；
横向扩展简单：新增业务机器，部署 Filebeat 即可。

❌缺点

机器数量很多时，需要批量部署（ansible / 脚本）；
配置变更需要批量下发 yaml。

适用：物理机、ECS 云主机，微服务业务，大数据服务器（YARN/Flink/spark 日志采集）。

二、Kubernetes 容器环境（两种主流方案）

方案 1：DaemonSet 方式（生产首选）

在 K8s 集群每个 Node 节点，运行一个 Filebeat Pod。 Filebeat Pod 挂载宿主机的容器日志目录 /var/log/containers/，读取宿主机上所有容器产生的日志。

不管这个 Node 上跑多少业务 Pod，只需要 1 个 Filebeat Pod。

✅优点

只需要部署一次 DaemonSet，新增节点自动拉起 Filebeat；不用给每个业务 Pod 单独部署；
运维成本低。

❌缺点

Filebeat 权限要求高，需要挂载宿主机目录；
日志过滤逻辑写在 DaemonSet 的配置，区分不同业务日志需要加标签过滤。

方案 2：Sidecar 边车模式

每个业务 Pod 内部，单独启动一个 Filebeat 容器，和业务容器共享日志卷 emptyDir。业务容器写日志到共享卷，同 Pod 内 Filebeat 读取日志。

✅优点

日志隔离：每个业务 Pod 的采集配置独立；
不依赖宿主机目录，权限更安全；
采集范围只属于当前 Pod。

❌缺点

Pod 数量多的时候，Filebeat 实例数量非常多，资源开销变大；
配置管理繁琐。

对比：K8s 绝大多数业务选择 DaemonSet；只有强隔离需求才用 Sidecar。

DaemonSet（DS）解释说明

一句话：DaemonSet 保证集群里每一个（或者指定一部分）节点，都运行一份相同的 Pod 副本。新节点加入集群，会自动在该节点创建 Pod；节点删除，Pod 跟着回收。

适用场景

节点日志收集：如 filebeat、fluentd，每个节点都要采集容器日志
节点监控：node-exporter，每个节点采集服务器指标
网络插件：calico、flannel，每个节点网络代理
安全代理、节点审计等每个机器都必须部署一个的组件

❌ 不适合业务应用（业务一般用 Deployment，不需要每台节点都跑）

和 Deployment 区别

DaemonSet：每个节点最多 1 个 Pod，不控制副本数，由节点数量决定；不支持扩缩副本（是扩缩节点）
Deployment：调度 Pod 到任意节点，可以多个 Pod 跑在同一个节点，用来部署业务服务

简单 yaml 示例

#资源所属 API 组，Deployment、StatefulSet、DaemonSet 都在`apps/v1`，K8s 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 打上标签 `app=filebeat`，和上面 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 app=filebeat -o wide

# 更新镜像（滚动更新，默认策略RollingUpdate）
kubectl set image ds/filebeat-ds filebeat=elastic/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，就近采集本地日志，尽量避免远程读取。

七、高频Q&A

Q：registry 文件作用？

A：保存每个日志文件的读取偏移量 offset、inode 信息，Filebeat 重启后从上次位置继续采集，防止重复采集或者漏日志。

Q：DaemonSet 和 Sidecar 怎么选？

A：集群规模大，通用日志采集，选 DaemonSet；业务需要独立采集配置、强隔离场景，才使用 Sidecar。

Q：Filebeat 能不能部署在 Logstash 服务器上采集？

A：不建议。Filebeat 尽量部署在日志产生端，减少网络传输压力。

转载自 CSDN-专业IT技术社区

原文链接：https://blog.csdn.net/weixin_47157956/article/details/164745172

ELK Filebeat 部署