百亿数据查询秒级响应，观测体系之日志中心该如何玩转？

日志是处理生产故障、性能优化、业务分析的重要参考依据，是系统稳定运行不可或缺的一部分。随着业务系统规模急剧膨胀增大，尤其是是微服务架构逐渐普及，一个系统可能涉及多个应用模块与服务实例，传统模式下运维人员去定位问题显得异常困难，效率低下。

当服务器资源增加时，各种类型的系统日志、业务日志、组件日志、容器日志等散落在不同设备上，故障排查异常艰难，因此构建高效且统一的日志中心能力尤为必要。本文主要研究基于ELK架构实时日志分析平台。

1、架构设计

ELK是三个组件缩写，分别表示Elasticsearch，Logstash，Kibana。Elasticsearch是个开源分布式搜索引擎，提供搜集、分析、存储数据三大功能。Logstash 主要是用来日志的采集、过滤日志的工具，缺点是性能损耗较大。

Kibana 可以为 Logstash 和 ElasticSearch 提供的日志分析的可视化界面，可以帮助汇总、分析和搜索重要数据日志。同时随着 ELK 生态发展，涉及 Beats 日志采集工具，其中轻量化日志采集工具 FileBeat 使用居多。

此架构适用于生产级别高并发日志采集需求

• 采集端：使用轻量化的 filebeat 组件进行日志采集，收集服务器、容器、应用成等各种数据源生成的实时数据。

• 消息队列：引入 Kafka 消息队列机制用于解决高并发大规模场景下日志读取引发的 IO 性能瓶颈问题和扩展性问题。

• 处理端：Logstash 消费 Kafka 消息队列中的数据，经过日志过滤、分析后，将数据传递给ES集群存储。

• 存储：Elasticsearch 用于日志存储服务，接收 logstash 日志格式处理后的数据，常用索引模板存储不同类型日志，将数据以分片形式压缩存储并提供多种API 供用户查询和操作。

• 展示端：使用 Kibana 检索 Elastisearch 中的日志数据，通过视图、表格、仪表盘、地图等形式可视化呈现日志信息，提供日志分析检索服务。

2、日志采集

日志采集类型主要分为三种类型

1. 系统日志：系统运行日志包含 message 和 secure 等

2. 服务日志：如数据库的普通运行日志、错误日志、慢查询日志等

3. 业务日志：应用运行核心日志以 Java 日志 Log4j 居多

日志采集的方式主要有两种类型：⬇️

1）文件方式

filebeat.yml核心配置实例

filebeat.inputs:- type: log  enabled: false  paths:    - /tmp/*.log  tags: ["sit","uat"]  fields:    role: "云原生运维"    date: "202308"  - type: log  enabled: true  paths:    - /var/log/*.log  tags: ["SRE","team"]---------------------------output.elasticsearch:  enabled: true  hosts: ["192.168.0.1:9200","192.168.0.2:9200","192.168.0.3:9200"]  index: "cmdi-linux-sys-%{+yyyy.MM.dd}"setup.ilm.enabled: falsesetup.template.name: "dev-linux"setup.template.pattern: "dev-linux*"setup.template.overwrite: falsesetup.template.settings:  index.number_of_shards: 3  index.number_of_replicas: 2

配置说明：⬇️

type 用于标识日志类型
enabled 用于标识该项采集是否启动生效
path 用于配置采集日志路径，通过模糊匹配模式适配日志文件
tag 用于标识标签
output.elasticsearch 该部分为日志存储服务配置，此处采用副本和分片机制的索引模板来接收不同类型日志存储需求，同时根据需要可添加 elasticsearch 存储认证服务。

2）Kubernetes集群方式

为适配 Kubernetes 环境下 Pod 服务随时变化的日志采集需求，需要设计动态化日志采集。

步骤1）创建sa

apiVersion: v1kind: ServiceAccountmetadata:  name: filebeat  namespace: kube-system  labels:    app: filebeat

步骤2）基于RBAC的角色控制设定​​​​​​​

apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata:  name: filebeatsubjects:- kind: ServiceAccount  name: filebeat  namespace: kube-systemroleRef:  kind: ClusterRole  name: filebeat  apiGroup: rbac.authorization.k8s.io---apiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata:  name: filebeat  namespace: kube-systemsubjects:  - kind: ServiceAccount    name: filebeat    namespace: kube-systemroleRef:  kind: Role  name: filebeat  apiGroup: rbac.authorization.k8s.io

步骤3）采集服务的cm文件设定​​​​​​​

data:  filebeat.yml: |-    filebeat.inputs:    - type: container      paths:        - /var/log/containers/*.log      processors:        - add_kubernetes_metadata:            in_cluster: true            matchers:            - logs_path:                logs_path: "/log/containers/"        - drop_event.when.not:            or:              - equals.kubernetes.namespace: sit-dev    output.elasticsearch:      hosts: ['192.168.0.1:9200', '192.168.0.2:9200', '192.168.0.3:9200']      index: "sit-%{[kubernetes.container.name]:default}-%{+yyyy.MM.dd}"    setup.template.name: "sit"    setup.template.pattern: "sit-*"

步骤4）部署daemonset采集服务

​​​​​​​

containers:- name: filebeat  image: elastic/filebeat:v8.6.2  args: [    "-c", "/etc/filebeat.yml",    "-e",  ]  env:  - name: ELASTICSEARCH_HOST    value: 192.168.0.1  - name: ELASTICSEARCH_PORT    value: "9200"  securityContext:    runAsUser: 0    # If using Red Hat OpenShift uncomment this:    #privileged: true  resources:    limits:      memory: 200Mi    requests:      cpu: 100m      memory: 100Mi

按照以上配置启动容器化采集服务，即可将相关日志采集入库

3.可视化呈现

采集服务启动后，通过 Kibana 对接 Elasticsearch 服务可以查询到日志索引服务，同一类型日志通过不同时间日期索引来区分。⬇️

创建数据视图，为不同类型索引创建对应的可视化视图信息。
名称部分为视图名称，自行定义

索引模式通过正则表达式匹配特定索引源，完成特定数据视图查看。

可视化呈现数据视图 ⬇️

支持不同灵活的选定日志字段进行组合呈现
支持KQL语法的日志检索服务，可以满足关键核心日志查询需求
支持历史日志检索需求
支持自定义刷新频率

多种类型的仪表盘模板和自定义仪表盘 ⬇️

4、总结

ELK日志体系提供日志收集、存储、分析和可视化呈现能力，借助于 Elasticsearch的全文索引功能，具备强大的搜索能力，支持百亿级数据的查询秒级响应，同时局别灵活的集群现行扩展能力为生产级别集中化日志中心提供良好的解决方案。

但是它对日志格式处理能力有限，部分场景日志格式需要借助于其它组件完成预处理和转换，同时在告警、权限管理和关联分析等方面有一定局限性，需要不断优化。

随着开源社区的发展，相信ELK体系会更加成熟和完善，能够满足更多场景化需求。