分布式之 elk 日志架构的演进

> 本文由 [简悦 SimpRead](http://ksria.com/simpread/) 转码， 原文地址 [www.tuicool.com](https://www.tuicool.com/articles/qQ3u6je)

引言
--

好久没写分布式系列的文章了，最近刚好有个朋友给我留言，想看这方面的知识。其实这方面的知识，网上各种技术峰会的资料一抓一大把。博主也是凑合着写写。感觉自己也写不出什么新意，大家也凑合看看。

### 日志系统的必要性?

我 15 年实习的时候那会，给某国企做开发。不怕大家笑话，生产上就两台机器。那会定位生产问题，就是连上一台机器，然后用使用 `grep / sed / awk` 等 Linux 脚本工具去日志里查找故障原因。如果发现不在这台机器上，就去另一台机器上查日志。有经历过上述步骤的童鞋们，请握个抓！

然而，当你的生产上是一个有几千台机器的集群呢？你要如何定位生产问题呢？又或者，你哪天有这么一个需求，你需要收集某个时间段内的应用日志，你应该如何做？

为了解决上述问题，我们就需要将日志集中化管理。这样做，可以提高我们的诊断效率。同时也有利于我们全面理解系统。

正文
--

### 组件简介

这里大概介绍一下 ELK 组件在搭建日志系统过程中所扮演的角色，这边了解一下即可，具体的会在后文进行说明。

大家应该都知道 ELK 指的是:（Elasticsearch＋Logstash＋Kibana）。其中

```
Logstash
Elasticsearch
Kibana
```

好了，知道上面的定义，可以开始讲演进过程了

### 实习版

OK，这版算是 Demo 版，各位开发可以在自己电脑上搭建练练手，如下图所示。

![](https://img2.tuicool.com/3yeQ7vb.png!web)

这种架构下我们把 Logstash 实例与 Elasticsearch 实例直接相连，主要就是图一个简单。我们的程序 App 将日志写入 Log，然后 **Logstash 将 Log 读出，进行过滤，写入 Elasticsearch** 。最后浏览器访问 Kibana，提供一个可视化输出。

缺点

该版的缺点主要是两个

*   在大并发情况下，日志传输峰值比较大。如果直接写入 ES,ES 的 HTTP API 处理能力有限，在日志写入频繁的情况下可能会超时、丢失，所以需要一个缓冲中间件。
*   注意了，Logstash 将 Log 读出、过滤、输出都是在应用服务器上进行的，这势必会造成服务器上占用系统资源较高，性能不佳，需要进行拆分。

于是，我们的初级版诞生了！

### 初级版

在这版中，加入一个缓冲中间件。另外对 Logstash 拆分为 Shipper 和 Indexer。先说一下，LogStash 自身没有什么角色，只是根据不同的功能、不同的配置给出不同的称呼而已。Shipper 来进行日志收集，Indexer 从缓冲中间件接收日志，过滤输出到 Elasticsearch。具体如下图所示

![](https://img1.tuicool.com/jAN36fF.png!web)

说一下，这个缓冲中间件的选择。

大家会发现，早期的博客，都是推荐使用 redis。因为这是 ELK Stack 官网建议使用 Redis 来做消息队列，但是很多大佬已经通过实践证明使用 Kafka 更加优秀。原因如下:

*   `Redis` 无法保证消息的可靠性，这点 `Kafka` 可以做到
*   `Kafka` 的吞吐量和集群模式都比 `Redis` 更优秀
*   `Redis` 受限于机器内存，当内存达到 Max，数据就会抛弃。当然，你可以说我们可以加大内存啊？但是，在 `Redis` 中内存越大，触发持久化的操作阻塞主线程的时间越长。相比之下， `Kafka` 的数据是堆积在硬盘中，不存在这个问题。

因此，综上所述，这个缓存中间件，我们选择使用 `Kafka` 。

缺点

主要缺点还是两个

*   `Logstash Shipper` 是 jvm 跑的，非常占用 `JAVA` 内存！ 。据 [《ELK 系统使用 filebeat 替代 logstash 进行日志采集》](https://blog.csdn.net/u010871982/article/details/79035317) 这篇文章说明，8 线程 8GB 内存下， `Logstash` 常驻内存 660M（ `JAVA` ）。因此，这么一个巨无霸部署在应用服务器端就不大合适了，我们需要一个更加轻量级的日志采集组件。
*   上述架构如果部署成集群，所有业务放在一个大集群中相互影响。一个业务系统出问题了，就会拖垮整个日志系统。因此，需要进行业务隔离！

### 中级版

这版呢，引入组件 Filebeat。当年，Logstash 的作者用 golang 写了一个功能较少但是资源消耗也小的轻量级的 Logstash-forwarder。后来加入 Elasticsearch 后，以 logstash-forwarder 为基础，研发了一个新项目就叫 Filebeat。

相比于 Logstash，Filebeat 更轻量，占用资源更少，所占系统的 CPU 和内存几乎可以忽略不计。毕竟人家只是一个二进制文件。那么，这一版的架构图如下，我直接画集群版

![](https://img1.tuicool.com/eiiaeqM.png!web)

从上图可以看到，Elasticsearch 根据业务部了 3 个集群，他们之间相互独立。避免出现，一个业务拖垮了 Elasticsearch 集群，整个日志系统就一起宕机的情况。而且，从运维角度来说，这种架构运维起来也更加方便。

至于这个 **Tribe Node** ，中文翻译为部落结点，它是一个特殊的客户端，它可以连接多个集群，在所有连接的集群上执行搜索和其他操作。在这里呢，负责将请求路由到正确的后端 ES 集群上。

缺点

这套架构的缺点在于对日志没有进行冷热分离。因为我们一般来说，对一个礼拜内的日志，查询的最多。以 7 天作为界限，区分冷热数据，可以大大的优化查询速度。

### 高级版

这一版，我们对数据进行冷热分离。每个业务准备两个 Elasticsearch 集群，可以理解为冷热集群。7 天以内的数据，存入热集群，以 SSD 存储索引。超过 7 天，就进入冷集群，以 SATA 存储索引。这么一改动，性能又得到提升，这一版架构图如下 (为了方便画图，我只画了两个业务 Elasticsearch 集群)

![](https://img0.tuicool.com/yimaUvJ.png!web)

隐患

这个高级版，非要说有什么隐患，就是敏感数据没有进行处理，就直接写入日志了。关于这点，其实现在 JAVA 这边，现成的日志组件，比如 `log4j` 都有提供这种日志过滤功能，可以将敏感信息进行脱敏后，再记录日志。