ELK+Filebeat 集中式日志解决方案详解

时间  2019-11-14
标签 elk+filebeat elk filebeat 集中 日志 解决 方案 详解 繁體版
原文   原文链接

连接：https://www.ibm.com/developerworks/cn/opensource/os-cn-elk-filebeat/index.html?ca=drs-html

ELK Stack 简介

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

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

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

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

在这个章节中，咱们将介绍几种经常使用架构及使用场景。git

最简单架构

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

图 1. 最简单架构

 

这种架构很是简单，使用场景也有限。初学者能够搭建这个架构，了解 ELK 如何工做。正则表达式

Logstash 做为日志搜集器

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

图 2. Logstash 做为日志搜索器

 

这种结构由于须要在各个服务器上部署 Logstash，而它比较消耗 CPU 和内存资源，因此比较适合计算资源丰富的服务器，不然容易形成服务器性能降低，甚至可能致使没法正常工做。vim

Beats 做为日志搜集器

这种架构引入 Beats 做为日志搜集器。目前 Beats 包括四种：数组

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

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

图 3. Beats 做为日志搜集器

 

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

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

引入消息队列机制的架构

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

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

 

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

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

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

图 5. 基于 Filebeat 的 ELK 集群架构

 

由于免费的 ELK 没有任何安全机制，因此这里使用了 Nginx 做反向代理，避免用户直接访问 Kibana 服务器。加上配置 Nginx 实现简单的用户认证，必定程度上提升安全性。另外，Nginx 自己具备负载均衡的做用，可以提升系统访问性能。

系统信息

平台

笔者试验平台为 RHEL 6.x。注意，目前 ELK（包括 Beats）不支持 AIX。具体对平台的支持请查看这里。

JDK

JDK 是 IBM Java 8。ELK 须要 Oracle 1.7(或者是 OpenJDK 1.7) 及以上，若是是 IBM Java，则须要 8 及以上的版本。具体信息。

浏览器

Kibana 4.x 不支持 IE9 及如下；Kibana 3.1 虽然支持 IE9，可是不支持 Safari(iOS)和 Chrome(Android)。具体对浏览器的支持，请看这里。

软件版本

  • Filebeat：1.2.3；
  • Logstash：2.3.4；
  • Elasticsearch：2.3.4；
  • Kibana：4.5.4；
  • Nginx：1.8.1。

Filebeat + ELK 安装

安装步骤

ELK 官网对于每种软件提供了多种格式的安装包（zip/tar/rpm/DEB），以 Linux 系列系统为例，若是直接下载 RPM，能够经过 rpm -ivh path_of_your_rpm_file 直接安装成系统 service。之后就可使用 service 命令启停。好比 service elasticsearch start/stop/status。很简单，但缺点也很明显，就是不能自定义安装目录，相关文件放置比较分散。

实际使用中更经常使用是使用 tar 包安装。每种软件产品的安装过程很是类似，因此下面仅以 Elasticsearch 为例简述安装过程。

  • 建立 elk 用户和用户组；
    groupadd elk          # 添加用户组
    useradd -g elk elk    # 添加用户到指定用户组
    passwd elk            # 为指定用户设置密码

    切换到新建立的 elk 用户作以下操做。

  • 下载安装包；

    若是待安装机器能访问外网，能够直接用如下命令下载安装包。

    wget https://download.elastic.co/elasticsearch/release/org/elasticsearch/distribution/tar/elasticsearch/2.3.4/elasticsearch-2.3.4.tar.gz

    不然下载好后用 ftp 客户端等工具把包传过去。

  • 解压到指定目录；
    tar xzvf elasticsearch-2.3.4.tar.gz -C /opt

    这时就能在/opt 下看到刚才解压出来的 elasticsearch-2.3.4 文件夹。

  • 运行；
    ./Path_of_elasticsearch/bin/elasticsearch
  • 验证是否启动；
    curl 'http://localhost:9200'

    若是看到以下相似信息，就说明 Elasticsearch 正常启动了。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
       {
           "name" : "node-235",
           "cluster_name" : "elasticsearch_cms",
           "version" : {
                   "number" : "2.3.4",
               "build_hash" : "e455fd0c13dceca8dbbdbb1665d068ae55dabe3f",
                    "build_timestamp" : "2016-06-30T11:24:31Z",
               "build_snapshot" : false,
               "lucene_version" : "5.5.0"
            },
           "tagline" : "You Know, for Search"
    }
  • 配置 Elasticsearch service；

    上面的运行命令是在前台启动 Elasticsearch。实际使用中更可能是在后台运行，或者是把 Elasticsearch 配置成 service。

    Github 上有以 service 形式运行 Elasticsearch 的脚本，下载后放到/etc/init.d 目录下，而后用 vim 打开，根据实际状况修改好比用户名、log 路径、数据保存路径等信息。图 6 是笔者试验用的变量值。

    图 6. Elasticsearch service 脚本中的变量定义
     
  • 以 service 形式启/停/查看状态；
    service elasticsearch start/stop/status

以上就是如何以 service 形式安装 Elasticsearch，对于 Filebeat、Logstash 和 Kibana 还有 Nginx 都能以相同方式安装，这里就不赘述。

Filebeat + ELK 配置

Filebeat 和 ELK 的安装很简单，比较难的是如何根据需求进行配置。这个章节选取了几个比较典型且重要的配置需求和配置方法。

Filebeat 与 Logstash 安全通讯

用户可使用 TLS 双向认证加密 Filebeat 和 Logstash 的链接，保证 Filebeat 只向可信的 Logstash 发送加密的数据。一样的，Logstash 也只接收可信的 Filebeat 发送的数据。

这个功能默认是关闭的。可经过以下步骤在配置文件中打开：

  • 生成 Filebeat 自签名证书和 key 文件

    由于试验用，因此这里使用的都是自签名证书。如何使用 openssl 生成自签名证书，网上有不少教程，Elastic github 上也直接提供了参考指令。

    openssl req -subj '/CN=hostname/' -x509 -days $((100*365)) -batch -nodes -newkeys rsa:2048 -keyout ./pki/tlk/provate/filebeat.key -out ./pki/tls/certs/filebeat.crt

    这条指令生成自签名证书和 key 文件。读者须要把 hostname 部分改为实际环境的 hostname，或者是 IP 地址。

  • 生成 Logstash 自签名证书和 key 文件

    命令相似。

  • Filebeat 配置

    首先把 Logstash 的自签名证书传送到 Filebeat 所在服务器。而后，对 logstash output 部分的 tls 配置做以下修改：

    tls:
          ## logstash server 的自签名证书。
          certificate_authorities: ["/etc/pki/tls/certs/logstash.crt"]
          certificate: "/etc/pki/tls/certs/filebeat.crt"
          certificate_key: "/etc/pki/tls/private/filebeat.key"

    其中：

    • certificate_authorities：CA 证书，即用来签署证书的证书。这里表示配置 Filebeat 使其信任全部由该 CA 证书发行的证书。由于自签名证书的发行者和证书主体相同，因此这里直接使用 Logstash 证书使 Filebeat 信任使用该证书的 Logstash server；
    • certificate & certificate_key：Filebeat 证书和 key 文件。Filebeat 将使用它们向 Logstash server 证实本身的可信身份。
  • Logstash 配置

    同 Filebeat 配置相似，首先把 Filebeat client 上的证书复制到 Logstash server 上，而后做以下修改。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    input {
       beats {
         port => 5044
         ssl => true
         ssl_certificate_authorities => ["/etc/pki/tls/certs/filebeat.crt"]
         ssl_certificate => "/etc/pki/tls/certs/logstash.crt"
         ssl_key => "/etc/pki/tls/private/logstash.key"
         ssl_verify_mode => "force_peer"
       }
    }

    其中：

    • ssl：true 表示开启 Logstash 的 SSL/TLS 安全通讯功能；
    • ssl_certificate_authorities：配置 Logstash 使其信任全部由该 CA 证书发行的证书；
    • ssl_certificate & ssl_key：Logstash server 证书和 key 文件。Logstash 使用它们向 Filebeat client 证实本身的可信身份；
    • ssl_verify_mode：代表 Logstash server 是否验证 Filebeat client 证书。有效值有 peer 或 force_peer。若是是 force_peer，表示若是 Filebeat 没有提供证书，Logstash server 就会关闭链接。

Filebeat 实现 log rotation

通俗的说，log rotation 是指当日志文件达到指定大小后，把随后的日志写到新的日志文件中，原来的日志文件重命名，加上日志的起止时间，以实现日志归档的目的。

Filebeat 默认支持 log rotation，但须要注意的是，Filebeat 不支持使用 NAS 或挂载磁盘保存日志的状况。由于在 Linux 系列的操做系统中，Filebeat 使用文件的 inode 信息判断当前文件是新文件仍是旧文件。若是是 NAS 或挂载盘，同一个文件的 inode 信息会变化，致使 Filebeat 没法完整读取 log。

虽然 Filebeat 默认支持 log rotation，可是有三个参数的设置须要留意。

  • registry_file：这个文件记录了当前打开的全部 log 文件，以及每一个文件的 inode、当前读取位置等信息。当 Filebeat 拿到一个 log 文件，首先查找 registry_file，若是是旧文件，就从记录的当前读取位置处开始读取；若是是新文件，则从开始位置读取；
  • close_older：若是某个日志文件通过 close_older 时间后没有修改操做，Filebeat 就关闭该文件的 handler。若是该值过长，则随着时间推移，Filebeat 打开的文件数量不少，耗费系统内存；
  • scan_frequency：Filebeat 每隔 scan_frequency 时间读取一次文件内容。对于关闭的文件，若是后续有更新，则通过 scan_frequency 时间后，Filebeat 将从新打开该文件，读取新增长的内容。

Elasticsearch 集群

Elasticsearch 启动时会根据配置文件中设置的集群名字（cluster.name）自动查找并加入集群。Elasctisearch 节点默认使用 9300 端口寻找集群，因此必须开启这个端口。

一个 Elasticsearch 集群中通常拥有三种角色的节点，master、data 和 client。

  • master：master 节点负责一些轻量级的集群操做，好比建立、删除数据索引、跟踪记录集群中节点的状态、决定数据分片（shards）在 data 节点之间的分布；
  • data：data 节点上保存了数据分片。它负责数据相关操做，好比分片的 CRUD，以及搜索和整合操做。这些操做都比较消耗 CPU、内存和 I/O 资源；
  • client：client 节点起到路由请求的做用，实际上能够看作负载均衡器。

配置文件中有两个与集群相关的配置：

  • node.master：默认 true。True 表示该节点是 master 节点；
  • node.data：默认 true。True 表示该节点时 data 节点。若是两个值都为 false，表示是 client 节点。

一个集群中不必定有 client 节点，可是确定有 master 和 data 节点。默认第一个启动的节点是 master。Master 节点也能起到路由请求和搜索结果整合的做用，因此在小规模的集群中，无需 client 节点。可是若是集群规模很大，则有必要设置专门的 client。

Logstash 使用 grok 过滤

日志数据通常都是非结构化数据，并且包含不少没必要要的信息，因此须要在 Logstash 中添加过滤插件对 Filebeat 发送的数据进行结构化处理。

使用 grok 正则匹配把那些看似毫无心义、非结构化的日志数据解析成可查询的结构化数据，是目前 Logstash 解析过滤的最好方式。

Grok 的用户不须要从头开始写正则。ELK github 上已经写好了不少有用的模式，好比日期、邮箱地址、IP4/六、URL 等。具体查看这里。除此以外，还有 grok 正则表达式的debug 工具，能方便快速检验所写表达式是否正确。

下面是一个 grok 的配置实例，读者能够适当修改知足你的需求。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
filter {
   grok {
     match => {
       "message" => [
                 "\[(?< Logtime >(%{MONTHNUM}/%{MONTHDAY}/%{YEAR})\s+%{TIME}\s+%{WORD})\]\s+%{BASE16NUM}\s+(?< LogSource >([\w|\S]+))\s+%{WORD:LogLevel}\s+(?< LogStr >[\w|\W]*)",
                 "\[(?< Logtime >(%{MONTHNUM}/%{MONTHDAY}/%{YEAR})\s+%{TIME}\s+%{WORD})\]\s+%{BASE16NUM}\s+%{WORD:LogLevel}\s+(?< LogStr >[\w|\W]*(\\n)+)"
             ]
       }
     remove_field => ["message"]
   }
   if "_grokparsefailure" in [tags] {
     grok {
         match => ["message", "(?< LogStr >[\w|\W]+)"]
         remove_field => ["message"]
         remove_tag => ["_grokparsefailure"]
         add_field => {
             LogSource => "-"
             LogLevel => "-"
             LogTime => "-"
         }
     } 
   }
}

第一个 grok 列了两种正则表达式，若是第一种不匹配，则自动使用第二种。若是第二种也没有匹配，则匹配失败，log 数据中添加一个"_grokparsefailure"域，代表 grok 匹配失败了。读者可根据实际需求决定如何处理匹配失败的数据。这里，对于匹配失败的，将再匹配一次，并给没有匹配上的域赋予默认值"-"，这样使得日志数据格式统一，都含有 4 个域：Logtime、LogSource、LogLevel、LogTime，便于后续数据搜索和展现。

配置 Nginx 实现用户认证

关于这部分配置的教程不少，这里就不赘述了。

遇到的典型问题

问题：Filebeat 如何读取多个日志目录？

若是 Filebeat 所在 server 上运行有多个 application servers，各自有不一样的日志目录，那 Filebeat 如何同时读取多个目录，这是一个很是典型的问题。

解决方案：经过配置多个 prospector 就能达到要求。在配置文件的 prospectors 下，每一个"-"表示一个 prospector，每一个 prospector 包含一些配置项，指明这个 prospector 所要读取的日志信息。以下所示：

1
2
3
4
5
6
7
8
9
prospectors:
     -
       paths:
          - /home/WLPLog/*.log
       # 其余配置项，具体参考 Elastic 官网
     -
       paths:
          - /home/ApacheLog/*.log
       # 其余配置项，具体参考 Elastic 官网

问题：Filebeat 如何区分不一样日志来源？

仍是上题中提到的场景，Filebeat 虽然能读取不一样的日志目录，可是在 Logstash 这边，或者是 Elasticsearch 这边，怎么区分不一样 application server 的日志数据呢？

解决方案：Filebeat 的配置项 fields 能够实现不一样日志来源的区分。用法以下：

1
2
3
4
5
6
7
8
9
10
11
prospectors:
     -
        paths:
           - /home/WLPLog/*.log
        fields:
          log_source: WLP
     -
        paths:
           - /home/ApacheLog/*.log
        fields:
          log_source: Apache

在 fields 配置项中，用户能够自定义域来标识不一样的 log。好比上例中的"log_source"就是笔者自定义的。如此，从 Filebeat 输出的 log 就有一个叫作 log_source 的域代表该 log 的实际来源。

问题：如何配置 Logstash 与 Elasticsearch 集群通讯？

咱们知道 Logstash 使用 Elasticsearch 输出插件就能把数据发送到 Elasticsearch 进行存储和搜索。Elasticsearch 插件中有个 hosts 配置项说明 Elasticsearch 信息。可是假如是一个 Elasticsearch 集群，应该怎么配置 hosts？

解决方案：最简单的作法是把集群中全部的 Elasticsearch 节点的 IP 或者是 hostname 信息都在 hosts 中配上（它支持数组）。可是若是集群比较大，或者是集群节点变更频繁的话，还须要维护这个 hosts 值，不太方便。比较推荐的作法是只配集群中某个节点的信息，能够是 client 节点，也能够是 master 节点或者是 data 节点。由于无论是哪一个节点，都知道该它所在集群的信息（集群规模，各节点角色）。这样，Logstash 与任意节点通讯时都会先拿到集群信息，而后再决定应该给哪一个节点发送数据输出请求。

问题：如何在 Kibana 显示日志数据？

解决方案：当数据存储在 Elasticsearch 端以后就能够在 Kibana 上清楚的展现了。首先在浏览器上打开 Kibana 页面。若是使用了 Nginx，就使用 Nginx 配置的 URL；不然就是http://yourhostname:5601。

建立日志索引。Logstash 发送的数据，默认使用 logstash 前缀做为数据索引。见图 7。

图 7. Kibana 建立索引页面

 

点击 Create，再选择 Discover 页面就能看见 Logstash 发送的数据了,如图 8 所示。

图 8. 数据展现页面

 

Kibana 具体的使用，好比如何建立日志 visualization，如何将 visualization 添加到 dashboard，如何在 Kibana 上搜索日志，这些能够参考官网。

结束语

本文首先简要介绍了 ELK 协议栈的几种典型的架构及其使用场景，而后针对 Filebeat 的架构，详细说明了如何安装和配置。限于篇幅，同时因为某些基本配置，官网有详尽的说明，因此本文只是选取了几个比较重要，同时官网上说得不是很明确的地方做说明，但愿对你们有帮助。

ELK 论坛上有很多内部人士热心帮忙解答用户的问题。若是读者在使用过程当中有不懂的，搜索了好久也找不到答案的问题，能够在 ELK 论坛寻求帮助。

参考资料

 

                        （--转载--）

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程