Filebeat的架构分析、配置解释与示例

转载请注明出处:http://blog.csdn.net/gamer_gyt

博主微博:http://weibo.com/234654758

Github:https://github.com/thinkgamer


写在前边的话



在看filebeat之前我们先来看下Beats,Beats 平台是 Elastic.co 从 packetbeat 发展出来的数据收集器系统。beat 收集器可以直接写入 Elasticsearch,也可以传输给 Logstash。其中抽象出来的 libbeat,提供了统一的数据发送方法,输入配置解析,日志记录框架等功能。也就是说,所有的 beat 工具,在配置上,除了 input 以外,在output、filter、shipper、logging、run-options 上的配置规则都是完全一致的

而这里的filebeat就是beats 的一员,目前beat可以发送数据给Elasticsearch,Logstash,File,Console四个目的地址。filebeat 是基于原先 logstash-forwarder 的源码改造出来的。换句话说:filebeat 就是新版的 logstash-forwarder,也会是 ELK Stack 在 shipper 端的第一选择。

Filebeat的架构设计



当我们安装完filebeat之后,我们可以在filebeat的安装目录下看到两个文件

  • filebeat.template.json (输出的文件格式,在filebeat的template中指定,当服务启动时,会被加载)
  • filebeat.yml(所有的配置都在该文件下进行)

整体架构理解:

上边我们也说了filebeat是用来收集日志的,那么在filebeat.yml中会配置指定的监听文件,也就是上图中的一个个log,这个log的目录是在prospectors中设置,在看配置文件的时候便可以很明白的看出来,对于prospectors定位每个日志文件,Filebeat启动harvester。每个harvester读取新的内容一个日志文件,新的日志数据发送到spooler(后台处理程序),它汇集的事件和聚合数据发送到你已经配置了Filebeat输出。

环境准备



要开始使用自己的Filebeat设置,安装和配置这些相关产品:

  • Elasticsearch存储和索引数据。
  • Kibana为UI。
  • Logstash(可选)将数据插入到Elasticsearch。

具体配置可参考:http://blog.csdn.net/gamer_gyt/article/details/52654263

部署filebeat



deb:

curl -L -O https://download.elastic.co/beats/filebeat/filebeat_1.3.1_amd64.deb

sudo dpkg -i filebeat_1.3.1_amd64.deb

rpm:

curl -L -O https://download.elastic.co/beats/filebeat/filebeat-1.0.1-x86_64.rpm

sudo rpm -vi filebeat-1.0.1-x86_64.rpm

mac:

curl -L -O https://download.elastic.co/beats/filebeat/filebeat-1.3.1-darwin.tgz

tar xzvf filebeat-1.3.1-darwin.tgz

win:

  • 下载windows zip文件 点击下载.
  • 解压文件到 C:\Program Files.
  • 重命名为 Filebeat.
  • 打开PowerShell提示符作为管理员(右键单击PowerShell的图标,并选择以管理员身份运行)。如果您运行的是Windows XP,则可能需要下载并安装PowerShell
  • 运行以下命令来安装Filebeat作为Windows服务

    cd ‘C:\Program Files\Filebeat’

    C:\Program Files\Filebeat> .\install-service-filebeat.ps1

在启动filebeat服务之前,需要先修改配置文件,接下来我们看下配置文件

配置解析



上边我么也说了FileBeat的四种输出方式为输出到Elasticsearch,logstash,file和console,下面我们具体看下示例

PS:

  • 这里说的是需要修改的配置文件,没有提的就是不需要修改
  • 每次修改完配置文件都需要重启filebeat服务
  • 这里不要追究时间的问题,小主是测试,主要是为了方便记录

这里主要是自定义监听文件的路劲,我设置的是/opt/elk/log/*.log

然后在filebeat.yml中的prospectors路径设置如下(该配置为以下四种方式通用)

paths:

- /opt/elk/log/*.log

1:output of Elasticsearch

filebeat.yml中output的配置将除了es之外注释掉

output
  elasticsearch:
    hosts: ["192.168.197.128:9200"]  #es的ip地址和端口,如果有多个,中间用逗号分隔
    worker: 1             #对应es的个数
    index: "filebeat"     #索引根名称
    template:
      name: "filebeat"    #模板名字和对应的json文件
      path: "filebeat.template.json"
    max_retries: 3         #发送到特定logstash的最大尝试次数。如果达到该次数仍不成功,事件将被丢弃。默认是3,值0表示禁用重试。值小于0将无限重试知道事件已经发布。

    bulk_max_size: 20000   #单个elasticsearch批量API索引请求的最大事件数。默认是50
    timeout: 90          #elasticsearch请求超时事件。默认90秒
    flush_interval: 5    #新事件两个批量API索引请求之间需要等待的秒数。如果bulk_max_size在该值之前到达,额外的批量索引请求生效。

往log文件中追加日志

echo “123456789” >> test1.log

这个时候我们看一下效果:

2:output of logstash

filebeat.yml中output的配置将除了logstash之外注释掉

output:
    logstash:
        hosts: ["192.168.197.130:5044"]
        worker: 2
        loadbalance: true
        index: filebeat

这里  worker  的含义,是 beat 连到每个 host 的线程数。
在  loadbalance  开启的情况下,意味着有 4 个worker 轮训发送数据

则对应的logstash配置,编写一个配置文件

sudo vim filebeat_logstash_out.conf

beat 写入 Logstash 时,会配合 Logstash-1.5 后新增的 metadata 特性。将 beat 名和 type 名 记录在 metadata 里。所以对应的 Logstash 配置应该是这样:

input {
    beats {
        port => 5044
    }
}
output {
    elasticsearch {
        hosts => ["http://192.168.197.128:9200"]
        index => "%{[@metadata][beat]}-%{+YYYY.MM.dd}"
        document_type => "%{[@metadata][type]}"
    }
    stdout{
        codec=>rubydebug
    }
}

启动conf

bin/logstash -f config/filebeat_logstash_out.conf

往log文件中追加日志

echo “2222333344445555” >> test1.log

前往查看效果:

3:output of File

filebeat.yml中output的配置将除了file之外注释掉

output:
  file:
    path: "/opt/elk/log/filebeat_output_file"
    filename: filebeat
    rotate_every_kb: 10000
    number_of_files: 7

往log文件中追加日志:

echo “this is filebeat output of file” >> test1.log

查看效果:

4:output of Console

filebeat.yml中output的配置将除了cosnsole之外注释掉

output:
  console:
    pretty: true

重启启动服务:

sudo filebeat -e -c /etc/filebeat/filebeat.yml

往log文件中追加日志:

echo “this is filebeat output of console” >> test1.log

前往服务启动窗口查看效果:

ELK+Filebeat的Demo


1:在/opt/elk/log目录下有三个文件分别是test1.log,test2.log,test3.log**

2:通过python脚本往三个文件中追加内容,内容格式如下:

name age address company
aa 23 beijing alibaba

Python的脚本内容如下:

#-*-coding:utf-8-*-

name_list = [‘aa‘,‘bb‘,‘cc‘,‘dd‘,‘ee‘]
addr_list = [‘beijing‘,‘shanghai‘,‘guangzhou‘]
company_list =[‘baidu‘,‘tengxun‘,‘alibb‘]

import random
import time

def get_name():
    return name_list[random.randint(0,4)]

def get_age():
    return random.randint(20,25)

def get_addr():
    return addr_list[random.randint(0,2)]

def get_comp():
    return company_list[random.randint(0,2)]

if __name__=="__main__":
    while True:
        print("%s %s %s %s"%(get_name(),get_age(),get_addr(),get_comp()))
        str_line = get_name()+" "+str(get_age())+" "+get_addr()+" "+get_comp()
        import os
        os.system("echo %s >> test1.log" % str_line)
        time.sleep(1)

3:filebeat 的配置文件使用output=logstash

filebeat.yml

output:
    logstash:
        hosts: ["192.168.197.130:5044"]
        worker: 2
        loadbalance: true
        index: filebeat

4:filebeat_logstash_out.conf

input {
    beats {
        port => 5044
    }
}

filter{
  if [type] == ‘log‘{
    grok{
        match=>{
            "message"=>"%{WORD:username} %{WORD:age} %{WORD:address} %{WORD:company}"
            }
    }
  }
}

output {
    elasticsearch {
        hosts => ["http://192.168.197.128:9200"]
        index => "%{[@metadata][beat]}-%{+YYYY.MM}"
        document_type => "%{[@metadata][type]}"
    }
    stdout{
        codec=>rubydebug
    }
}

5:启动服务

  • 启动python脚本
  • 启动conf配置文件

6:web查看结果


END

推荐一篇讲解配置含义的文章:

http://www.ttlsa.com/elk/elk-beats-common-configure-section-describe/

时间: 2024-10-25 07:56:11

Filebeat的架构分析、配置解释与示例的相关文章

万字长文:ELK(V7)部署与架构分析

ELK(7版本)部署与架构分析 1.ELK的背景介绍与应用场景 在项目应用运行的过程中,往往会产生大量的日志,我们往往需要根据日志来定位分析我们的服务器项目运行情况与BUG产生位置.一般情况下直接在日志文件中tailf. grep.awk 就可以获得自己想要的信息.但在规模较大的场景中,此方法效率低下,面临问题包括日志量过大.文本搜索太慢.如何多维度查询.这就需要对服务器上的日志收集汇总.常见解决思路是建立集中式日志收集系统,将所有节点上的日志统一收集,管理,访问. 一般大型系统往往是一种分布式

ELK(V7)部署与架构分析

1.ELK的背景介绍与应用场景 在项目应用运行的过程中,往往会产生大量的日志,我们往往需要根据日志来定位分析我们的服务器项目运行情况与BUG产生位置.一般情况下直接在日志文件中tailf. grep.awk 就可以获得自己想要的信息.但在规模较大的场景中,此方法效率低下,面临问题包括日志量过大.文本搜索太慢.如何多维度查询.这就需要对服务器上的日志收集汇总.常见解决思路是建立集中式日志收集系统,将所有节点上的日志统一收集,管理,访问. 一般大型系统往往是一种分布式部署的架构,不同的服务模块部署在

秒杀系统架构分析与实战

0 系列目录 秒杀系统架构 秒杀系统架构分析与实战 1 秒杀业务分析 正常电子商务流程 (1)查询商品:(2)创建订单:(3)扣减库存:(4)更新订单:(5)付款:(6)卖家发货 秒杀业务的特性 (1)低廉价格:(2)大幅推广:(3)瞬时售空:(4)一般是定时上架:(5)时间短.瞬时并发量高: 2 秒杀技术挑战 假设某网站秒杀活动只推出一件商品,预计会吸引1万人参加活动,也就说最大并发请求数是10000,秒杀系统需要面对的技术挑战有: 对现有网站业务造成冲击 秒杀活动只是网站营销的一个附加活动,

秒杀系统架构分析与实战(参考、转载)

目录[-] 0 系列目录 1 秒杀业务分析 2 秒杀技术挑战 3 秒杀架构原则 4 秒杀架构设计 4.1 前端层设计 4.2 站点层设计 4.3 服务层设计 4.4 数据库设计 4.4.1 基本概念 4.4.2 设计思路 5 大并发带来的挑战 5.1 请求接口的合理设计 5.2 高并发的挑战:一定要“快” 5.3 重启与过载保护 6 作弊的手段:进攻与防守 6.1 同一个账号,一次性发出多个请求 6.2 多个账号,一次性发送多个请求 6.3 多个账号,不同IP发送不同请求 7 高并发下的数据安全

虚拟化技术研究及架构分析

什么是虚拟化 虚拟化是指计算机元件在虚拟的基础上而不是真实的基础上运行.虚拟化技术可以扩大硬件的容量,简化软件的重新配置过程.CPU的虚拟化技术可以单CPU模拟多CPU并行,允许一个平台同时运行多个操作系统,并且应用程序都可以在相互独立的空间内运行而互不影响,从而显著提高计算机的工作效率. 几种虚拟化软件介绍 RedHat KVM 虚拟化方式:完全虚拟化 架构:寄居架构(linux内核);祼金属架构RHEV-H 特点:祼金属架构RHEV-H或在关键的硬盘和网卡上支持半虚拟化VirtIO,达到最佳

【转载】秒杀系统架构分析与实战

本文转载自:http://my.oschina.net/xianggao/blog/524943 0 系列目录 秒杀系统架构 秒杀系统架构分析与实战 1 秒杀业务分析 正常电子商务流程 (1)查询商品:(2)创建订单:(3)扣减库存:(4)更新订单:(5)付款:(6)卖家发货 秒杀业务的特性 (1)低廉价格:(2)大幅推广:(3)瞬时售空:(4)一般是定时上架:(5)时间短.瞬时并发量高: 2 秒杀技术挑战 假设某网站秒杀活动只推出一件商品,预计会吸引1万人参加活动,也就说最大并发请求数是100

二、OpenStack入门 之 架构分析

OpenStack入门 之 架构分析 写在前面 学习目标: 了解 OpenStack 各组件的逻辑关系: 了解 OpenStack 的各组件的通信和部署关系: 了解 OpenStack 的工作流程: 接下来我会掌握: OpenStack 组件间的逻辑关系: OpenStack 的API: OpenStack 组件间的通信关系: OpenStack 中几种不同的存储: OpenStack 工作流程: OpenStack 的部署架构: OpenStack 各组件之间的关系有:逻辑关系,通信关系,部署

电商商品秒杀系统架构分析与实战

网址:http://my.oschina.net/xianggao/blog/524943 0 系列目录 1 秒杀业务分析 2 秒杀技术挑战 3 秒杀架构原则 4 秒杀架构设计 4.1 前端层设计 4.2 站点层设计 4.3 服务层设计 4.4 数据库设计 4.4.1 基本概念 4.4.2 设计思路 5 大并发带来的挑战 5.1 请求接口的合理设计 5.2 高并发的挑战:一定要“快” 5.3 重启与过载保护 6 作弊的手段:进攻与防守 6.1 同一个账号,一次性发出多个请求 6.2 多个账号,一

Magento架构分析,Magento MVC 设计分析

Magento架构分析,Magento MVC 设计分析 分类:Magento 标签:Magento MVC.Magento架构 669人浏览 Magento 采用类似 JAVA的架构,其扩展与稳定性非常突出,也是在开源电商平台最优秀的,下面我大概分析一下其内部架构 Magento系统请求响应流程图 下面是具体请求步骤分析 用户向浏览器发出请求(高级话题:What really happens when you navigate to a URL) 浏览器向magento所在的服务器发出请求,m