从零开始搭建Kubernetes集群(七、如何监控K8S集群日志)

上一文《从零开始搭建Kubernetes集群(六、在K8S上部署Redis
集群)》主要介绍了如何在K8S上部署一套基于StatefulSet的Redis集群。本篇将介绍一下如何在K8S上进行日志的监控。

日志统一采集

我们首先介绍一下传统的日志监控方案。其中,ELK Stack
是我们最熟悉不过的架构。所谓ELK,分别指Elastic公司的Elasticsearch、Logstash、Kibana。在比较旧的ELK架构中,Logstash身兼日志的采集、过滤两职。但由于Logstash基于JVM,性能有一定限制,因此,目前业界更推荐使用Go语言开发FIiebeat代替Logstash的采集功能,Logstash只作为了日志过滤的中间件。

Google+用电子邮件发送本页面

日志管理主要包括采集、存储及展示分析功能部分,开源的日志汇总方案以ELK
(Elasticsearch, Logstash, Kibana)的应用最为广泛。

最常见的ELK架构如下:

ELK Stack 简介

ELK 不是一款软件,而是 Elasticsearch、Logstash 和 Kibana
三种软件产品的首字母缩写。这三者都是开源软件,通常配合使用,而且又先后归于
Elastic.co 公司名下,所以被简称为 ELK Stack。根据 Google Trend
的信息显示,ELK Stack 已经成为目前最流行的集中式日志解决方案。

  • Elasticsearch:分布式搜索和分析引擎,具有高可伸缩、高可靠和易管理等特点。基于
    Apache Lucene
    构建,能对大容量的数据进行接近实时的存储、搜索和分析操作。通常被用作某些应用的基础搜索引擎,使其具有复杂的搜索功能;
  • Logstash:数据收集引擎。它支持动态的从各种数据源搜集数据,并对数据进行过滤、分析、丰富、统一格式等操作,然后存储到用户指定的位置;
  • Kibana:数据分析和可视化平台。通常与 Elasticsearch
    配合使用,对其中数据进行搜索、分析和以统计图表的方式展示;
  • Filebeat:ELK 协议栈的新成员,一个轻量级开源日志文件数据搜集器,基于
    Logstash-Forwarder 源代码开发,是对它的替代。在需要采集日志数据的
    server 上安装 Filebeat,并指定日志目录或日志文件后,Filebeat
    就能读取数据,迅速发送到 Logstash 进行解析,亦或直接发送到
    Elasticsearch 进行集中式存储和分析。

如果您对 ELK Stack 还尚不了解,或是想了解更多,请点击集中式日志系统 ELK
协议栈详解,查看具体介绍。

Fluentd
因其更易用、资源消耗更少、性能更高、数据处理更可靠、高效,受到了更多企业的青睐,成为了Logstash
的可替代方案,Elasticsearch、Fluentd、Kibana软件栈也被简称为 EFK。

图片 1image.png

ELK 常用架构及使用场景介绍

在这个章节中,我们将介绍几种常用架构及使用场景。

图片 2

如上图所示,各角色功能如下:

最简单架构

在这种架构中,只有一个 Logstash、Elasticsearch 和 Kibana 实例。Logstash
通过输入插件从多种数据源(比如日志文件、标准输入 Stdin
等)获取数据,再经过滤插件加工数据,然后经 Elasticsearch 输出插件输出到
Elasticsearch,通过 Kibana 展示。详见图 1。

Fluentd — 开源数据采集工具,提供统一的日志层;

  • 多个Filebeat在各个业务端进行日志采集,然后上传至Logstash
  • 多个Logstash节点并行(负载均衡,不作为集群),对日志记录进行过滤处理,然后上传至Elasticsearch集群
  • 多个Elasticsearch构成集群服务,提供日志的索引和存储能力
  • Kibana负责对Elasticsearch中的日志数据进行检索、分析
图 1. 最简单架构

图片 3

这种架构非常简单,使用场景也有限。初学者可以搭建这个架构,了解 ELK
如何工作。

可以在每个集群节点Node 部署一个Fluentd
容器应用实例,以采集该节点上的主机系统日志、容器日志、Kubernetes组件日志、容器应用的数据等,然后将其发送至
Elasticsearch 进行存储。Elasticsearch —
开源的全文本查询和分析引擎;Kibana — 提供基于Elasticsearch
存储数据的可视化界面和支持快速分析任务。

当然,在该架构中,根据业务特点,还可以加入某些中间件,如Redis、Kafak等:

Logstash 作为日志搜集器

这种架构是对上面架构的扩展,把一个 Logstash
数据搜集节点扩展到多个,分布于多台机器,将解析好的数据发送到
Elasticsearch server 进行存储,最后在 Kibana
查询、生成日志报表等。详见图 2。

图片 4image.png

图 2. Logstash 作为日志搜索器

图片 5

这种结构因为需要在各个服务器上部署 Logstash,而它比较消耗 CPU
和内存资源,所以比较适合计算资源丰富的服务器,否则容易造成服务器性能下降,甚至可能导致无法正常工作。

如上图所示,Kafka集群作为消息缓冲队列,可以降低大量FIlebeat对Logstash的并发访问压力。

Beats 作为日志搜集器

这种架构引入 Beats 作为日志搜集器。目前 Beats 包括四种:

  • Packetbeat(搜集网络流量数据);
  • Topbeat(搜集系统、进程和文件系统级别的 CPU 和内存使用情况等数据);
  • Filebeat(搜集文件数据);
  • Winlogbeat(搜集 Windows 事件日志数据)。

Beats 将搜集到的数据发送到 Logstash,经 Logstash
解析、过滤后,将其发送到 Elasticsearch 存储,并由 Kibana
呈现给用户。详见图 3。

目前,在K8S的日志监控解决方案中,EFK也是较常用的架构。所谓的EFK,即Elasticsearch

图 3. Beats 作为日志搜集器

图片 6

这种架构解决了 Logstash 在各服务器节点上占用系统资源高的问题。相比
Logstash,Beats 所占系统的 CPU 和内存几乎可以忽略不计。另外,Beats 和
Logstash 之间支持 SSL/TLS
加密传输,客户端和服务器双向认证,保证了通信安全。

因此这种架构适合对数据安全性要求较高,同时各服务器性能比较敏感的场景。

  • Fluentd +
    Kibana。在该架构中,Fluentd作为日志采集客户端。但我个人认为,相对于Filebeat,Fluentd并没有突出的优势。并且,由于同属于Elastic公司,Filebeat可以更好的兼容其产品栈。因此,在K8S上,我仍然推荐ELK架构。

引入消息队列机制的架构

到笔者整理本文时,Beats
还不支持输出到消息队列,所以在消息队列前后两端只能是 Logstash
实例。这种架构使用 Logstash
从各个数据源搜集数据,然后经消息队列输出插件输出到消息队列中。目前
Logstash 支持 Kafka、Redis、RabbitMQ 等常见消息队列。然后 Logstash
通过消息队列输入插件从队列中获取数据,分析过滤后经输出插件发送到
Elasticsearch,最后通过 Kibana 展示。详见图 4。

确定使用ELK+Filebeat作为架构后,我们还需要明确Filebeat采集K8S集群日志的方式,这也是本文的重点。官方文档中提到了三种采集方式,这里简单介绍一下:

图 4. 引入消息队列机制的架构

图片 7

这种架构适合于日志规模比较庞大的情况。但由于 Logstash 日志解析节点和
Elasticsearch
的负荷比较重,可将他们配置为集群模式,以分担负荷。引入消息队列,均衡了网络传输,从而降低了网络闭塞,尤其是丢失数据的可能性,但依然存在
Logstash 占用系统资源过多的问题。

在每个节点上可以独立运行一个Node级日志代理,通常的实现方式为DaemonSet。用户应用只需要将日志写到标准输出,Docker
的日志驱动会将每个容器的标准输出收集并写入到主机文件系统,这样Node级日志代理就可以将日志统一收集并上传。另外,可以使用K8S的logrotate或Docker
的log-opt 选项负责日志的轮转。

基于 Filebeat 架构的配置部署详解

前面提到 Filebeat 已经完全替代了 Logstash-Forwarder
成为新一代的日志采集器,同时鉴于它轻量、安全等特点,越来越多人开始使用它。这个章节将详细讲解如何部署基于
Filebeat 的 ELK 集中式日志解决方案,具体架构见图 5。

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注

*
*
Website