ELK+filebeat+metricbeat+heartbeat+auditbeat安装配置及汉化

一、基础环境介绍

Centos 7.5 x64

ElasticSearch 6.5.1

Logstash 6.5.1

Kibana 6.5.1

filebeat 6.5.1

metricbeat 6.5.1

heartbeat 6.5.1

auditbeat 6.5.1

Kibana_Hanization 6.5.1

二、ElasticSearch安装

1. 安装JDK，配置JAVA_HOME环境变量

2. 编辑/etc/sysctl.conf文件

    vm.max_map_count=262144

3. 编辑/etc/security/limits.conf，然后重启操作系统

    * soft nofile 65536

4. 编辑elasticsearch配置文件

    network.host: ipaddr
    http.port: 9200

5. 启动elasticsearch

    ./bin/elasticsearch&

6. 关闭防火墙

    systemctl status firewalld
    systemctl disable firewalld
    systemctl stop firewalld

7. 验证elasticsearch安装

    curl http://192.168.65.243:9200

三、Kibana安装配置

1. 解压kibana压缩包

2. 编辑kibana配置文件config/kibana.yml

    server.port: 5601
    server.host: "192.168.65.243"
    elasticsearch.url: "http://192.168.65.243:9200"

3. 启动kibana

    ./bin/kibana&

4. 访问http://192.168.65.243:5601 访问kibana

四、filebeat安装配置

1. 编辑filebeat.yml文件

    filebeat.prospectors:
    - type: log
      paths:
        - /path/to/file/logstash-tutorial.log 
    output.logstash:
      hosts: ["192.168.65.243:5044"]

2. 启动命令

   考虑到读取日志文件的权限，filebeat应运行在root用户下

    sudo /usr/local/filebeat/filebeat -e -c filebeat.yml

   此处可使用的测试日志文件地址为

    

   重新读取log文件的方法

   关闭filebeat文件，删除注册信息

   rm data/registry

五、Logstash安装配置

Logstash与beat的区别

logstash 和filebeat都具有日志收集功能，filebeat更轻量，占用资源更少，但logstash 具有filter功能，能过滤分析日志。一般结构都是filebeat采集日志，然后发送到消息队列，redis，kafaka。然后logstash去获取，利用filter功能过滤分析，然后存储到elasticsearch中。

5.1 安装配置

1. 生成Logstash配置文件

    cp config/logstash-sample.conf config/logstash-elk.conf

   编辑logstash-elk.conf文件

    input {
        beats {
            port => 5044
        }
    }
    ​
    filter {
        grok {
            match => {"message" => "%{COMBINEDAPACHELOG}"}
        }
        geoip {
            source => "clientip"
        }
    }
    output {
        elasticsearch {
            hosts => [ "192.168.65.243:9200" ]
            index => "apachelog"
        }
    }   

    

2. 启动logstash

    bin/logstash -f config/logstash-elk.conf --config.reload.automatic

   grok在线调试工具

   kibana集成的grok调试工具

   logstash 支持的grok正则模式

5.2 支持的输入

• file: 从文件系统读取文件。

• syslog: 监听syslog消息的514端口并根据RFC3164格式进行解析。

• redis: 使用redis channels和redis lists 从redis server读取数据。 Redis通常用作Logstash的“代理”，将Logstash事件排队。

• beats: 处理beats发送的事件。

5.3 过滤器

过滤器是Logstash管道中的中间处理设备。 您可以将过滤器与条件组合，以便在事件满足特定条件时对其执行操作。 一些有用的过滤包括：

• grok: 解析并构造任意文本。 Grok是目前Logstash中将非结构化日志数据解析为结构化和可查询内容的最佳方式。 Logstash内置120种模式。

• mutate: 对事件字段执行常规转换。 您可以重命名，删除，替换和修改事件中的字段。

• drop: 完全删除事件，例如调试事件。

• clone: 制作事件的副本，可添加或删除字段。

• geoip: 添加有关IP地址地理位置的信息 (可对应为Kibana中的图表)

5.4 输出

输出是Logstash管道的最后阶段。 事件可以通过多个输出，但是一旦所有输出处理完成，事件就完成了它的执行。 一些常用的输出包括：

• elasticsearch: 将事件数据发送到Elasticsearch。

• file: 将事件数据写入磁盘上的文件。

• graphite: 将事件数据发送到graphite，这是一种用于存储和绘制指标的流行开源工具。

  http://graphite.readthedocs.io/en/latest/

• statsd: 将事件数据发送到statsd，这是一种“侦听统计信息，如计数器和定时器，通过UDP发送并将聚合发送到一个或多个可插入后端服务”的服务。

5.5 编解码器

编解码器基本上是流过滤器，可以作为输入或输出的一部分。 使用编解码器可以轻松地将消息传输与序列化过程分开。 流行的编解码器包括json，msgpack和plain（text）。

• json: 以JSON格式编码或解码数据。

• multiline: 将多行文本事件（如java异常和堆栈跟踪消息）合并到一个事件中。

5.6 持久化队列

5.6.1 优缺点

默认情况下，Logstash在管道阶段（输入→管道工作者）之间使用内存中有界队列来缓冲事件。这些内存中队列的大小是固定的，不可配置。如果Logstash遇到机器故障，则内存中队列的内容将丢失。为了防止异常终止期间的数据丢失，Logstash具有持久队列功能，该功能将消息队列存储在磁盘上。持久队列提供Logstash中数据的持久性。

启用持久队列的好处如下：无需像Redis或Apache Kafka这样的外部缓冲机制即可吸收突发事件。在正常关闭期间以及Logstash异常终止时提供至少一次传递保证以防止消息丢失。如果在事件发生时重新启动Logstash，Logstash将尝试传递存储在持久队列中的消息，直到传递成功至少一次。

以下是持久队列功能无法解决的问题：不使用请求 - 响应协议的输入插件无法防止数据丢失。 例如：tcp，udp，zeromq push + pull，以及许多其他输入没有确认收件人的机制。 具有确认功能的插件（如beats和http）受此队列的良好保护。它不处理永久性机器故障，例如磁盘损坏，磁盘故障和机器丢失。 持久存储到磁盘的数据不会被复制。

5.6.2 工作原理

队列位于同一进程中的输入和过滤阶段之间：

输入→队列→过滤器+输出

当输入已准备好处理事件时，它会将它们写入队列。当对队列的写入成功时，输入可以向其数据源发送确认。处理队列中的事件时，只有在过滤器和输出完成后，Logstash才会在队列中确认已完成的事件。队列记录管道已处理的事件。当且仅当事件已由Logstash管道完全处理时，事件被记录为已处理（在本文档中，称为“已确认”或“已确认”）。

5.6.3 配置方法

要配置持久队列，可以在Logstash设置文件中指定以下选项：

• queue.type: 指定持久化以启用持久队列。默认情况下，禁用持久队列（默认值：queue.type：memory）。

• path.queue: 存储数据文件的目录路径。默认情况下，文件存储在path.data /queue中。

• queue.page_capacity: 队列页面的最大大小（以字节为单位）。队列数据由称为“pages”的附加文件组成。默认大小为64mb。更改此值不会带来性能改进。

• queue.drain: 如果希望Logstash在关闭之前等待持久队列耗尽，则指定true。耗尽队列所需的时间取决于队列中累积的事件数。因此，您应该避免使用此设置，除非队列（即使已满）相对较小并且可以快速耗尽。

• queue.max_events: 队列中允许的最大事件数。默认值为0（无限制）。

• queue.max_bytes: 队列的总容量，以字节数表示。默认值为1024mb（1Gb）。确保磁盘驱动器的容量大于此处指定的值。

5.6.4 处理反压

当队列已满时，Logstash会对输入施加压力，以阻止流入Logstash的数据。这种机制有助于Logstash控制输入阶段的数据流速率，而不会像Elasticsearch那样压倒性的输出。

每个输入独立处理反压。例如，当beat输入遇到反压时，它不再接受新连接并等待持久队列有空间接受更多事件。在过滤器和输出阶段完成处理队列中的现有事件并确认它们之后，Logstash会自动开始接受新事件。

5.6.5 控制耐久性

持久性是存储写入的属性，可确保数据在写入后可用。启用持久队列功能后，Logstash会将事件存储在磁盘上。 Logstash在名为checkpointing的机制中提交到磁盘。

为了讨论持久性，我们需要介绍一些有关如何实现持久队列的细节。首先，队列本身是一组页面。有两种页面：头页和尾页。头页是写入新事件的地方。只有一个头页。当头页具有特定大小（请参阅queue.page_capacity）时，它将成为尾页，并创建新的头页。尾页是不可变的，头页是append-only的。其次，队列在称为检查点文件的单独文件中记录有关其自身的详细信息（页面，确认等）。

录制检查点时，Logstash将：在头页上调用fsync，原子地将磁盘写入队列的当前状态；检查点的过程是原子的，这意味着如果成功，将保存对文件的任何更新；如果Logstash终止，或者存在硬件级别故障，在永久队列中缓冲但尚未检查点的任何数据都将丢失。

可以通过设置queue.checkpoint.writes来更频繁地强制Logstash检查点。此设置指定在强制检查点之前可能写入磁盘的最大事件数。默认值为1024.要确保最大持久性并避免丢失持久队列中的数据，可以设置queue.checkpoint.writes：1以在写入每个事件后强制执行检查点。请记住，磁盘写入会产生资源成本。将此值设置为1会严重影响性能。

六、Metricbeat安装配置

Metricbeat是一个轻量级代理，在服务器上安装，以定期从操作系统和服务器上运行的服务收集指标。 Metricbeat获取它收集的指标和统计信息，并将它们发送到指定的输出，例如Elasticsearch或Logstash。

支持的服务包括：

• Apache

• HAProxy

• MongoDB

• MySQL

• Nginx

• PostgreSQL

• Redis

• System

• Zookeeper

6.1 安装配置

1. 修改配置文件metricbeat.yml，将输出指向Logstash

    #----------------------------- Logstash output --------------------------------
    output.logstash:
      hosts: ["127.0.0.1:5044"]

2. 修改logstash的配置 logstash-elk.conf

    input {
      beats {
        port => 5044
      }
    }
    ​
    output {
      elasticsearch {
        hosts => ["http://localhost:9200"]
        index => "%{[@metadata][beat]}-%{[@metadata][version]}-%{+YYYY.MM.dd}" 
      }
    }

    

3. 导出索引模板(手动方法)

    ./metricbeat export template > metricbeat.template.json

4. 安装索引模板（手动方法）

    curl -XPUT -H 'Content-Type: application/json' http://localhost:9200/_template/metricbeat-6.5.1 [email protected]

5. 设置Kibana仪表盘

    ./metricbeat setup --dashboards

    

    

6.x 安装错误

1、metricbeat setup --dashboards

Exiting: Error importing Kibana dashboards: fail to create the Kibana loader: Error creating Kibana client: fail to get the Kibana version:HTTP GET request to /api/status fails: fail to execute the HTTP GET request: Get http://localhost:5601/api/status: 1 dial tcp 127.0.0.1:5601: getsockopt: connection refused. Response: .

原因：

Metricbeat 不能直接连接localhost:5601的Kibana，需要修改metricbeat.yml 指向Kibana的运行地址:

 setup.kibana:
     host: "kibana_hostname:5601"

七、Heartbeat安装配置

Heartbeat是一个轻量级守护程序，可以安装在远程服务器上，定期检查服务状态并确定它们是否可用。与Metricbeat不同，Metricbeat仅确定服务器是启动还是关闭，Heartbeat会确认服务是否可访问。

当需要验证是否符合服务正常运行时的服务级别协议时，Heartbeat非常有用。在一些安全场景下，当您需要验证外部没有人可以访问您的私有企业服务器上的服务时，也很有用。

可以将Heartbeat配置为ping指定主机名的所有DNS可解析IP地址。这样，可以检查所有负载平衡的服务，以查看它们是否可用。

配置Heartbeat时，指定用于标识要检查的主机名的监视器。每个监视器都根据您指定的计划运行。例如，您可以将一台监视器配置为每10分钟运行一次，将另一台监视器配置为在9:00到17:00之间运行。

Heartbeat目前支持通过以下方式检查主机的监视器：

• ICMP (v4 and v6) 回应请求. 当只检查服务是否可用时使用 icmp 监视器。这个监视器需要ROOT权限。

• TCP. tcp 监视器通过TCP协议连接，通过发送或者接受特定的负载来验证端点。

• HTTP. http 监视器使用HTTP协议连接，可以通过特定的状态码、响应头或者内容验证服务响应。

TCP和HTTP监视器都支持SSL / TLS和一些代理设置。

7.1 安装配置

与大多数需要安装在边缘节点的Beats不同，Heartbeat可以安装为在单独的计算机上，甚至可能在监视服务运行的网络之外。

1. 修改heartbeat配置文件heartbeat.yml

    #指定要监视的主机和端口
    heartbeat.monitors:
    - type: icmp
      schedule: '*/5 * * * * * *' 
      hosts: ["myhost"]
    - type: tcp
      schedule: '@every 5s' 
      hosts: ["myhost:12345"]
      mode: any 
      
     #将数据输出到Logstash
     #----------------------------- Logstash output --------------------------------
    output.logstash:
      hosts: ["192.168.65.243:5044"]

2. 手动装载模板

    ./heartbeat setup --template -E output.logstash.enabled=false -E 'output.elasticsearch.hosts=["localhost:9200"]'

3. 强制kibana查看新的文档

    curl -XDELETE 'http://localhost:9200/heartbeat-*'

    

4. 设置kibana仪表盘

    ./heartbeat setup --dashboards

5. 启动heartbeat

    sudo chown root heartbeat.yml 
    sudo ./heartbeat -e

八、Auditbeat安装配置

Auditbeat是一个轻量级代理，可以在审核服务器系统上用户和进程的活动。 例如，可以使用Auditbeat从Linux Audit Framework收集和集中审核事件，还可以使用Auditbeat检测关键文件（如二进制文件和配置文件）的更改，并识别潜在的安全策略违规。

• Auditd模块：auditd模块从Linux Audit Framework接收审计事件，该审计事件是Linux内核的一部分。

  此模块仅适用于Linux。

  Linux Audit Framework可以为单个可审计事件发送多条消息。 例如，重命名系统调用会导致内核发送八个单独的消息。 每条消息都描述了正在发生的活动的不同方面（系统调用本身，文件路径，当前工作目录，进程标题）。 该模块将来自每个消息的所有数据组合成单个事件。一个事件的消息可以与来自另一个事件的消息交错。 该模块将缓冲消息，以便将相关消息组合成单个事件，即使它们交错到达或无序。

• 文件完整性模块 file_integrity模块在磁盘上更改（创建，更新或删除）文件时发送事件。事件包含文件元数据和散列。该模块适用于Linux，macOS（Darwin）和Windows。

  此模块使用操作系统的功能来实时监视文件更改。当模块启动时，它会创建一个与OS的订阅，以接收有关指定文件或目录更改的通知。在收到更改通知后，模块将读取文件的元数据并计算文件内容的哈希值。

  启动时，此模块将对配置的文件和目录执行初始扫描，以生成受监视路径的基准数据，并检测自上次运行以来的更改。它使用本地持久化数据，以便仅为新文件或已修改文件发送事件。

  依赖的操作系统的功能如下所示：

  使用Linux - inotify，因此内核必须具有inotify支持。 Inotify最初合并到2.6.13 Linux内核中。 Windows - 使用ReadDirectoryChangesW。 文件完整性模块不应用于监视网络文件系统上的路径。

九、汉化

使用此工具，实际验证下来，主面板基本汉化了，但还有部分提示信息是英文，汉化只支持到6.5.1，这也是选择6.5.1版本的原因。