docker安装filebeat、k8s安装filebeat、通过k8s ConfigMap配置filebeat，k8s DaemonSet安装filebeat采集日志到es

目录

前言

日志架构

 使用节点级日志代理

 使用 sidecar 容器运行日志代理

具有日志代理功能的边车容器

从应用中直接暴露日志目录

解决方案

部署应用

通过DaemonSet运行filebeat

通过ConfinMap创建filebeat配置文件

编写yaml脚本运行filebeat

查看日志

参考文档

---

---

前言

        本博文中涉及解决方案通过参考k8s官方手册和filebeat手册得出，整体通过k8s DaemonSet部署elastic/filebeat采集应用日志写入到es中。

        查阅k8s官方手册，集群级日志架构整体有4种，如下一章节所示（该章节内容摘子K8S官方文档，链接于文末），这里我们采用第一种方案来实现K8S中应用日志的采集。

日志架构

 使用节点级日志代理

        你可以通过在每个节点上使用 节点级的日志记录代理 来实现群集级日志记录。 日志记录代理是一种用于暴露日志或将日志推送到后端的专用工具。 通常，日志记录代理程序是一个容器，它可以访问包含该节点上所有应用程序容器的日志文件的目录。

        由于日志记录代理必须在每个节点上运行，通常可以用 DaemonSet 的形式运行该代理。 节点级日志在每个节点上仅创建一个代理，不需要对节点上的应用做修改。

        容器向标准输出和标准错误输出写出数据，但在格式上并不统一。 节点级代理 收集这些日志并将其进行转发以完成汇总。

 使用 sidecar 容器运行日志代理

        利用边车容器向自己的 stdout 和 stderr 传输流的方式， 你就可以利用每个节点上的 kubelet 和日志代理来处理日志。 边车容器从文件、套接字或 journald 读取日志。 每个边车容器向自己的 stdout 和 stderr 流中输出日志。

        这种方法允许你将日志流从应用程序的不同部分分离开，其中一些可能缺乏对写入 stdout 或 stderr 的支持。重定向日志背后的逻辑是最小的，因此它的开销几乎可以忽略不计。 另外，因为 stdout、stderr 由 kubelet 处理，你可以使用内置的工具 kubectl logs。

具有日志代理功能的边车容器

        如果节点级日志记录代理程序对于你的场景来说不够灵活，你可以创建一个 带有单独日志记录代理的边车容器，将代理程序专门配置为与你的应用程序一起运行。

从应用中直接暴露日志目录

        从各个应用中直接暴露和推送日志数据的集群日志机制 已超出 Kubernetes 的范围。 

解决方案

部署应用

这里不再赘述应用是如何部署的，但需要注意一点应用的日志输出挂载路径需要和filebeat的日志采集路径一致。

通过DaemonSet运行filebeat

通过ConfinMap创建filebeat配置文件

创建配置文件filebeat-config.yaml并运行（运行操作省略）

apiVersion: v1
kind: ConfigMap
metadata:
  name: filebeat-config
  namespace: k8s-demo
data:
  config: |
    filebeat.prospectors:
    - input_type: log
      paths:
        - /var/log/*
      json:
        keys_under_root: true

    processors:
    - drop_fields:
        fields: ["input_type", "offset", "beat", "type"]

    output.elasticsearch:
      hosts: ['elasticsearch_host:9200']
      username: username
      password: pwd
      indices:
        - index: "filebeat-k8s-demo-log-%{+yyyyMMdd}"

 Tips：此处es相关配置请各位查看个人项目修改

注意事项：

1. json.keys_under_root=true,是为了将JSON格式的日志key拆分到file顶层，若不加该配置则会统一写入到message属性下
2. drop_fields中配置部分属性，是为了写入es是删除filebeat自带的一些属性

编写yaml脚本运行filebeat

创建配置文件elastic-filebeat.yaml并运行（运行操作省略）

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: elastic-filebeat
  namespace: k8s-demo
  labels:
    server: filebeat-5.6.16
spec:
  selector:
    matchLabels:
      name: elastic-filebeat
  template:
    metadata:
      labels:
        name: elastic-filebeat
    spec:
      containers:
      - image: elastic/filebeat:5.6.16
        name: honeypot-filebeat
        securityContext:
          runAsUser: 0
          runAsGroup: 0
          fsGroup: 0
        volumeMounts:
        - mountPath: /usr/share/filebeat/data
          name: fb-data
        - mountPath: /var/log
          name: fb-log
        - mountPath: /usr/share/filebeat/filebeat.yml
          subPath: filebeat.yml
          name: cfg
          readOnly: true
      volumes:
      - name: fb-data
        hostPath:
          path: /usr/share/filebeat/data
      - name: fb-log
        hostPath:
          path: /var/application-logs
      - name: cfg
        configMap:
          name: filebeat-config
          items:
          - key: config
            path: filebeat.yml

注意事项

1. 示例中该容器以root用户运行，避免卷挂载出现权限问题
2. filebeat.yml配置载入使用subPath这一点十分重要,因为/usr/share/filebeat是一个目录而K8S官方文档明确说明如果mountPath如果挂载一个目录指向configMap会将该目录清空并使用configMap中的配置内容，这里但/usr/share/filebeat目录下包含了filebeat的其他我们不需要修改的内容，而我们只需要修改filebeat.yml文件
3. 使用daemonSet运行filebeat需要挂载/usr/share/filebeat/data，该目录下有一个registry文件，里面记录了filebeat采集日志位置的相关内容，比如文件offset、source、timestamp等，如果Pod发生异常后K8S自动将Pod进行重启，不挂载的情况下registry会被重置，将导致日志文件又从offset=0开始采集，结果就是es中日志重复一份，这点非常重要

查看日志

运行DaemonSet后，检查DaemonSet是否正常运行：

可以看到正常运行，各位可以进入Pod容器内查看ConfigMap、data是否挂载成功，这里不再赘述。

当我们的应用将日志写入我们filebeat挂载的/var/log目录下后，登录Kibana查看指定索引是否有日志文件。

 可以看到日志已经成功写入es中。

参考文档

日志架构 | Kubernetes

elastic/filebeat - Docker Image | Docker Hub