您当前的位置：
＞ 一共81个，开源大数据处理工具汇总（下），包括日志收集系统
总文章数：33572总点阅数：1818846当月点阅：522154
数据正在载入中…
数据正在载入中…
一共81个，开源大数据处理工具汇总（下），包括日志收集系统
数据正在载入中…
接上一部分：一共81个，大（上），第二部分主要整理的内容主要有收集、消息系统、分布式服务、集群管理、RPC、基础设施、搜索引擎、Iaas和监控管理等大数据开源工具。日志收集系统一、FacebookScribe贡献者：Facebook简介：Scribe是Facebook开源的日志收集系统，在Facebook内部已经得到大量的应用。它能够从各种日志源上收集日志，存储到一个中央存储系统（可以是NFS，分布式文件系统等）上，以便于进行集中统计分析处理。它为日志的“分布式收集，统一处理”提供了一个可扩展的，高容错的方案。当中央存储系统的网络或者机器出现故障时，scribe会将日志转存到本地或者另一个位置，当中央存储系统恢复后，scribe会将转存的日志重新传输给中央存储系统。其通常与Hadoop结合使用，scribe用于向HDFS中push日志，而Hadoop通过MapReduce作业进行定期处理。Scribe的系统架构代码托管：/facebook/scribe二、Cloudera Flume贡献者：Cloudera简介：Flume是Cloudera提供的一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统，Flume支持在日志系统中定制各类数据发送方，用于收集数据；同时，Flume提供对数据进行简单处理，并写到各种数据接受方（可定制）的能力。Flume提供了从console（控制台）、RPC（Thrift-RPC）、text（文件）、tail（UNIX tail）、syslog（syslog日志系统，支持TCP和UDP等2种模式），exec（命令执行）等数据源上收集数据的能力。当前Flume有两个版本Flume 0.9X版本的统称Flume-og，Flume1.X版本的统称Flume-ng。由于Flume-ng经过重大重构，与Flume-og有很大不同，使用时请注意区分。Cloudera Flume构架：官网：http://flume.apache.org/三、logstash简介：logstash 是一个应用程序日志、事件的传输、处理、管理和搜索的平台。你可以用它来统一对应用程序日志进行收集管理，提供 Web 接口用于查询和统计。他可以对你的日志进行收集、分析，并将其存储供以后使用（如，搜索），您可以使用它。说到搜索，logstash带有一个web界面，搜索和展示所有日志。官网：http://www.logstash.net/四、kibana简介：Kibana 是一个为 Logstash 和 ElasticSearch 提供的日志分析的 Web 接口。可使用它对日志进行高效的搜索、可视化、分析等各种操作。kibana 也是一个开源和免费的工具，他可以帮助您汇总、分析和搜索重要数据日志并提供友好的web界面。他可以为 Logstash 和 ElasticSearch 提供的日志分析的 Web 界面。主页：http://kibana.org/代码托管：/rashidkpc/Kibana/downloads消息系统一、StormMQ简介：MQMessageQueue消息队列产品 StormMQ，是一种服务程序。官网：/二、ZeroMQ简介：这是个类似于Socket的一系列接口，他跟Socket的区别是：普通的socket是端到端的（1:1的关系），而ZMQ却是可以N：M 的关系，人们对BSD套接字的了解较多的是点对点的连接，点对点连接需要显式地建立连接、销毁连接、选择协议（TCP/UDP）和处理错误等，而ZMQ屏蔽了这些细节，让你的网络编程更为简单。ZMQ用于node与node间的通信，node可以是主机或者是进程。引用官方的说法： “ZMQ(以下ZeroMQ简称ZMQ)是一个简单好用的传输层，像框架一样的一个socket library，他使得Socket编程更加简单、简洁和性能更高。是一个消息处理队列库，可在多个线程、内核和主机盒之间弹性伸缩。ZMQ的明确目标是“成为标准网络协议栈的一部分，之后进入Linux内核”。现在还未看到它们的成功。但是，它无疑是极具前景的、并且是人们更加需要的“传统”BSD套接字之上的一 层封装。ZMQ让编写高性能网络应用程序极为简单和有趣。”官网：http://zeromq.org/三、RabbitMQ简介：RabbitMQ是一个受欢迎的消息代理，通常用于应用程序之间或者程序的不同组件之间通过消息来进行集成。本文简单介绍了如何使用 RabbitMQ，假定你已经配置好了rabbitmq服务器。RabbitMQ是用Erlang，对于主要的编程语言都有驱动或者客户端。我们这里要用的是Java，所以先要获得Java客户端。像RabbitMQ这样的消息代理可用来模拟不同的场景，例如点对点的消息分发或者订阅/推送。我们的程序足够简单，有两个基本的组件，一个生产者用于产生消息，还有一个消费者用来使用产生的消息。官网：/四、ApacheActiveMQ简介：ActiveMQ 是Apache出品，最流行的，能力强劲的开源消息总线。ActiveMQ 是一个完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现，尽管JMS规范出台已经是很久的事情了，但是JMS在当今的J2EE应用中间仍然扮演着特殊的地位。特性：⒈ 多种语言和协议编写客户端。语言: Java,C,C++,C#,Ruby,Perl,Python,PHP。应用协议： OpenWire,Stomp REST,WS Notification,XMPP,AMQP⒉ 完全支持JMS1.1和J2EE 1.4规范 （持久化，XA消息，事务)⒊ 对Spring的支持，ActiveMQ可以很容易内嵌到使用Spring的系统里面去，而且也支持Spring2.0的特性⒋ 通过了常见J2EE服务器（如 Geronimo,JBoss 4,GlassFish,WebLogic)的测试，其中通过JCA 1.5 resource adaptors的配置，可以让ActiveMQ可以自动的部署到任何兼容J2EE 1.4 商业服务器上⒌ 支持多种传送协议：in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA⒍ 支持通过JDBC和journal提供高速的消息持久化⒎ 从设计上保证了高性能的集群，客户端-服务器，点对点⒏ 支持Ajax⒐ 支持与Axis的整合⒑ 可以很容易得调用内嵌JMS provider，进行测试官网：http://activemq.apache.org/五、Jafka贡献者：LinkedIn简介：Jafka 是一个开源的、高性能的、跨语言分布式消息系统，使用GitHub托管。Jafka 最早是由Apache孵化的Kafka（由LinkedIn捐助给Apache）克隆而来。由于是一个开放式的数据传输协议，因此除了Java开发语言受到支持，Python、Ruby、C、C++等其他语言也能够很好的得到支持。特性：1、消息持久化非常快，服务端存储消息的开销为O(1)，并且基于文件系统，能够持久化TB级的消息而不损失性能。2、吞吐量取决于网络带宽。3、完全的分布式系统，broker、producer、consumer都原生自动支持分布式。自动实现复杂均衡。4、内核非常小，整个系统（服务端和客户端）只有一个272KB的jar包，内部机制也不复杂，适合进行内嵌或者二次开发 。整个服务端加上依赖组件共3.5MB。5、消息格式以及通信机制非常简单，适合进行跨语言开发。目前自带的Python3.x的客户端支持发送消息和接收消息。官网：http://kafka.apache.org/六、ApacheKafka贡献者：LinkedIn简介：Apache Kafka是由Apache软件基金会开发的一个开源消息系统项目，由Scala写成。Kafka最初是由LinkedIn开发，并于2011年初开源。2012年10月从Apache Incubator毕业。该项目的目标是为处理实时数据提供一个统一、高通量、低等待的平台。Kafka是一个分布式的、分区的、多复本的日志提交服务。它通过一种独一无二的设计提供了一个消息系统的功能。Kafka集群可以在一个指定的时间内保持所有发布上来的消息，不管这些消息有没有被消费。打个比方，如果这个时间设置为两天，那么在消息发布的两天以内，这条消息都是可以被消费的，但是在两天后，这条消息就会被系统丢弃以释放空间。Kafka的性能不会受数据量的大小影响，因此保持大量的数据不是一个问题。更多请百度“36大数据”到36大数据查看。
来源：36大数据
数据正载入中…
重要声明：本站所有文章由会员即时发表，本站对所有文章的真实性、完整性及立场等，不负任何法律责任。所有文章内容只代表发文者个人意见，并非本网站之立场，用户不应信赖内容，并应自行判断内容之真实性。发文者拥有在秀客网发布的文章。 由于本站是受到「即时发表」运作方式所规限，故不能完全监察所有即时文章，如有不适当或对于文章出处有疑虑，请联系我们告知，我们将在最短时间内进行撤除。本站有权删除任何留言及拒绝任何人士发文，同时亦有不删除文章的权利。切勿撰写粗言秽语、诽谤、渲染色情暴力或人身攻击的言论，敬请自律。本网站保留一切法律权利。
COPYRIGHT (C)
秀客网 ALL RIGHTS RESERVED (C)版权所有海量游戏日志收集与分析
海量游戏日志收集与分析
摘要：&6月29日2016云栖大会成都峰会拉开帷幕，阿里云高级专家简志带来了“海量游戏日志的存储与分析”的重要演讲。从数据、云计算改变游戏行业，再谈到日志服务的整个过程，包括日志的作用、日志处理的挑战，以及日志通道的原理、模型，最后分析了日志服务的部分功能和典型应用场景。让我们一起先睹为快吧——
游戏与日志分析
数据、云计算改变游戏行业
我们先看一张图，这种图是国外应用市场的一个报告：统计了最近4年中，一款游戏从上架到达到90%下载量持续的时间长度，横轴代表的是年份，纵轴代表的是持续的周数。在2012年，一款游戏平均可以持续180周（也就是说到了2014年仍有人下载），但这个比例每年在持续下滑，到2015年该区间已经到了24周，进入快餐式消费时代。
不管背后原因是什么，从整个趋势来看游戏行业已经从卖方市场（20年前游戏卡带相互借阅，一卡难求），到现在的买方市场。
第二个趋势是：云计算改变了行业，一个显著特征是游戏部署、上线时间缩短了。原先繁重运维工作进一步地减轻，传统意义上运维转向了运营。这是时代的挑战，也是全栈工程师的幸运。
刚才两点更多是共同面对的问题，第三点就是大数据制造的机遇了。我们把2015年24周打开看一下，机会在哪里？从图表中可以看到，游戏一般有4个阶段：研发、增长、成熟、衰退。在增长阶段我们会遇到模仿者，抢占市场份额。怎么去应对模仿者？少犯错、离用户更近一些，实时更改自己的运营策略。
游戏行业变化激烈，但用户始终不变
虽然市场很激烈，但20多年来用户的习惯仍然不变。我们可以看下ongamesdata在的一副漫画。面对一款新的游戏时：
客观上看游戏用户并没有因为市场竞争激烈而减少，相反移动互联网的出现让用户在闲暇时间可以享受游戏，社交媒体使得好的游戏更容易传播，用户也越来越舍得花钱，市场的机会还是存在的。
为了获取用户，游戏团队需要关注什么?
为了能够让用户一步步爱上我们的游戏，团队中不同的人在不同方面进行合力。让我们来看一些例子，不同的人会关注什么。
这里有一些关注的例子：
3.FPS游戏统计各道具的平衡性，以及关卡的难度设定
收集用户行为、并优化游戏的整个过程
为了拿到以上结果，游戏团队需要做什么事情？我们可以大致拆分成三个过程：
在整个过程中串起用户端和服务端最重要的点就是数据。
游戏中的两种状态：切片(Snapshot)状态和增量日志
为了更好理解日志和游戏的关系，让我们来看下什么是日志数据，和游戏之间是什么关系：
游戏在用户端看起来是两个行为的交替：行动、绘图。当移动鼠标、点击键盘时我们改变了主人公位置和状态，之后渲染引擎进行了绘图。我们可以在一个时间点上对游戏的状态进行采样，例如10：06分，游戏中所有主人公的位置、金钱和手持武器如下，状态反映一个时间点下系统的全貌。
日志是状态与状态之间的变化量。例如10点-10点06分这个时间上用户做了哪些操作？日志相比状态最大的好处是，能够记录整个细节。
除了刚才提到的帮助运营、渠道更高效地运作，日志对游戏还有什么作用？
日志处理面临的多种挑战
日志有那么多的作用，那处理起来有哪些挑战呢？
第一个挑战和产生相关，游戏涉及到方方面面的合作。例如涉及游戏发行商、移动端、网页端、服务器端等。因此要从多个维度、多个渠道来收集日志，对于每一种日志有独特处理方法：例如为了分析渠道我们需要在网页埋点；为了拿到用户的行为，我们需要从移动设备、服务端等记录玩家轨迹；为了分析服务的稳定性，我们需要观察请求的延时等特点。
在这里我们需要使用一个统一的数据模型，支持各个渠道的数据通道来完成统一大事。
第二个挑战来自规模、性能和稳定性：举一个直观例子，假设每秒钟我们需要收集一个用户1KB数据，在100W玩家同时在线的情况下，这个数字就是100MB/S处理流量，这个量挑战不小。如何在数据规模增长的情况下，保持性能的稳定性，是工程师需要关注的。
第三个挑战来自于需求，在之前我们提到了游戏团队中不同人对于需求的产出是不同的。比如对访问日志，运营的需求是统计活跃人数比例，运维关系的是延迟和访问状态，开发关心的点是哪些资源是热点，需要进行优化。因此我们需要对一份数据，支持多种处理、统计的方法。
阿里云日志服务
我们来看看阿里云怎么帮助解决这类问题。在开放在阿里云官网之前，日志服务已经在阿里巴巴内部经历了3年多的历练，达到行业领先的水平。在游戏日志分析的场景中也能够发挥巨大作用。
日志服务主要提供三个主要功能：
LogHub是日志服务最核心的功能，他将日志源与日志消费者通过统一数据模型串联起来。最大好处是把数据管道化，标准化。这根管道是大容量、高可靠、并且弹性伸缩的，用户不用去关心数据量、如何接上等问题，就能直接使用。LogHub有10+种语言SDK，提供Agent并支持第三方Agent、Syslog，WebTracking等协议。在消费端对接了10+种下游，包括开源界非常火的Spark、Storm等流处理框架。
LogShipper提供了LogHub管道数据落地到存储的功能。目前与OSS、ODPS、OTS等海量存储系统打通。可以通过MapReduce、Hive等方式进行数据处理与分析。
LogSearch是一个附加功能，可以选择将LogHub中数据索引并查询，例如我们对App、Error等日志进行索引，可以在发生问题时进行快速定位于查询。在阿里内部我们将关键日志从几千台机器中集中式收集并索引，达到百TB规模。
LogHub（日志通道）与日志基础概念
日志是一个单调递增，完全按照时间排序的一系列记录。看起来如下：
日志顺序由“时间”来确定，从图上可以看到日志从右到左的时间顺序，新产生的事件被记录，过去的事件渐渐远去，但它记录了什么时间发生了什么事情，这无论对于计算机、人类、还是整个世界而言，是认知与推理的基础。
日志通道（LogHub）基本概念和数据模型如下：
LogHub有哪些优势？
除LogHub外，简单提下LogShipper和LogSearch功能
LogShipper是LogHub产品附加功能，支持将实时日志数据投递至存储类服务（OSS，ODPS， OTS），以进行离线分析与计算。最大的好处是0成本、便捷、可靠、高吞吐率。
LogSearch（原SLS） 能够实时索引日志数据，规模可达一天百TB水平，提供便捷、海量的查询能力。它主要弥补LogHub实时性与LogShipper投递数仓之间的空缺，既提供一种轻量级的准实时查询能力。
例如在游戏开发过程中我们会有非常多的系统，分布在不同的机器上。我们只需要把这些系统日志收集、索引起来。通过搜索用户的ID、状态等就能够快速定位到用户的行为特征。
在数字世界乘风破浪
最后，让我们来看一下游戏中日志方案的一个典型架构，以及总结下游戏场景日志分析的过程：
更多感兴趣内容可以关注，谢谢大家！
扫我，和云栖在线交流
【云栖快讯】首届阿里巴巴在线技术峰会，将于7月19日-21日20:00-21:30在线举办。峰会邀请到阿里集团9位技术大V，分享电商架构、安全、数据处理、数据库、多应用部署、互动技术、Docker持续交付与微服务等一线实战经验，解读最新技术在阿里集团的应用实践。&&
我的热门文章
即使是一小步也想与你分享从零开始搭建一个ELKB日志收集系统 - 推酷
从零开始搭建一个ELKB日志收集系统
当今的软件开发 多核 以及 分布 已经成为了常态，基本上稍大型的应用都是多台机器分布式部署。分布式在提高性能的同时也带来了很多问题，今天我们只讨论一点，那就是如何处理多台机器线上系统的日志。
以我司的某个应用T为例，部署在了百度云5台机子上，其中一台拥有公网IP，使用了百度云提供的负载均衡服务。每次想要在日志中检索某个关键字时，基本步骤如下：
打开五个shell，登陆拥有公网IP的那台机器
在另外四个shell中分别登陆其他的内网机器
对日志文件进行检索
当然，我们可以写脚本来简化这个过程，或者使用类似 cssh 这样的工具。但是成功登陆到五台机器上只是任务的开始，接下来我们要手动选择我们希望检索的日志（日志按照日期进行存储），使用grep进行检索，然后还要在五个shell上一个一个地看结果。如果有一个稍微高级的需求，比如检查某个关键词是否在昨天和今天的日志中都出现过，任务会变得十分麻烦，而且使用shell非常容易出错。
从这个过程中就可以总结出分布式系统日志处理的需求，我希望有这么个日志处理系统，有以下几个功能：
将多台机器上的日志收集到一台机器上。这样我在一个地方就可以看到所有的日志。
按照我指定的格式分析日志。日志肯定要解析的，最基本的日志也都要分为时间戳和内容。
有一个漂亮的界面能够让我查看日志和搜索日志。现在是21世纪了，谁也不想一天到晚看shell。
幸运地是，
提供了一套非常高级的工具 ELKB 来满足以上这几个需求。 ELKB 指的是用于日志分析或者说数据分析的四个软件，各自拥有独立的功能又可以组合在一起。先来简单介绍一下这四个软件。
Elastic Search : 从名称可以看出，Elastic Search 是用来进行搜索的，提供数据以及相应的配置信息（什么字段是什么数据类型，哪些字段可以检索等），然后你就可以自由地使用API搜索你的数据。
Logstash ：。日志文件基本上都是每行一条，每一条里面有各种信息，这个软件的功能是将每条日志解析为各个字段。
Kibana ：提供一套Web界面用来和 Elastic Search 进行交互，这样我们不用使用API来检索数据了，可以直接在 Kibana 中输入关键字，Kibana 会将返回的数据呈现给我们，当然，有很多漂亮的数据可视化图表可供选择。
Beats ：安装在每台需要收集日志的服务器上，将日志发送给Logstash进行处理，所以Beats是一个“搬运工”，将你的日志搬运到日志收集服务器上。
这里使用CentOS 7为例来说明怎么装这几个软件。其中ELK只需要安装在进行日志收集分析的服务器（server）上，而Beats是每一台产生日志的机器（client）都需要安装，当然也可能包括日志收集服务器本身。
$ yum install java-1.8.0
Ealstic Search
$ rpm --import http://packages.elastic.co/GPG-KEY-elasticsearch
$ echo '[elasticsearch-2.x]
name=Elasticsearch repository for 2.x packages
baseurl=http://packages.elastic.co/elasticsearch/2.x/centos
gpgcheck=1
gpgkey=http://packages.elastic.co/GPG-KEY-elasticsearch
' | tee /etc/yum.repos.d/elasticsearch.repo
$ yum install elasticsearch
$ vim /etc/yum.repos.d/logstash.repo
# 添加以下内容
[logstash-2.4]
name=logstash repository for 2.2 packages
baseurl=http://packages.elasticsearch.org/logstash/2.2/centos
gpgcheck=1
gpgkey=http://packages.elasticsearch.org/GPG-KEY-elasticsearch
$ yum install logstash
$ vim /etc/yum.repos.d/kibana.repo
# 添加以下内容
[kibana-4.6]
name=Kibana repository for 4.4.x packages
baseurl=http://packages.elastic.co/kibana/4.4/centos
gpgcheck=1
gpgkey=http://packages.elastic.co/GPG-KEY-elasticsearch
$ yum install kibana
Beats分为很多种，每一种收集特定的信息。常用的是 Filebeat ，监听文件变化，传送文件内容。一般日志系统使用Filebeat就够了。
我们切换到client上。首先同样需要导入 GPG KEY 。
$ rpm --import http://packages.elastic.co/GPG-KEY-elasticsearch
创建新的repo并安装。
$ vim /etc/yum.repos.d/elastic-beats.repo
# 添加以下内容
name=Elastic Beats Repository
baseurl=https://packages.elastic.co/beats/yum/el/$basearch
gpgkey=https://packages.elastic.co/GPG-KEY-elasticsearch
gpgcheck=1
$ yum install filebeat
Elastic Search
elasticsearch不需要太多配置，只需要阻止一下外网访问即可。修改配置文件 /etc/elasticsearch/elasticsearch.yml 。
network.host: localhost
启动elasticsearch， service elasticsearch start 。
elasticsearch本身可以认为是一个NoSQL数据库，通过REST API来操作。数据存储在 index 中，index在elastcisearch中就相当于SQL中的表。因为elasticsearch主要是用来对数据进行检索，所以index有一个配置叫做 mapping 。我们使用mapping来告诉elasticsearch数据的一些相关信息，比如，某个字段是什么数据类型，是否创建索引等。我们先来玩玩elasticsearch，使用官方提供的
数据集为例。
$ curl localhost:9200/_cat/indices?v # 查看当前所有的index
health status index pri rep docs.count docs.deleted store.size pri.store.size # 没有任何index
# 创建shakespeare索引，并设置mapping信息
# speaker字段和play_name不需要分析，elasticsearch默认会拆分字符串中的每个词并进行索引
$ curl -XPUT http://localhost:9200/shakespeare -d '
&mappings& : {
&_default_& : {
&properties& : {
&speaker& : {&type&: &string&, &index& : &not_analyzed& },
&play_name& : {&type&: &string&, &index& : &not_analyzed& },
&line_id& : { &type& : &integer& },
&speech_number& : { &type& : &integer& }
$ curl localhost:9200/_cat/indices?v # 查看索引
health status index
pri rep docs.count docs.deleted store.size pri.store.size
yellow open
shakespeare
# 下载数据，并将数据集load进索引中
$ wget https://www.elastic.co/guide/en/kibana/3.0/snippets/shakespeare.json
$ curl -XPOST 'localhost:9200/shakespeare/_bulk?pretty' --data-binary @shakespeare.json
# 以上操作完成后，elasticsearch中就已经有了我们load的所有数据，并建立好了索引，我们可以开始查询了
# 查询一下含有'man'这个词的text_entry
$ curl -s 'localhost:9200/shakespeare/_search?q=text_entry:man&pretty=1&size=20' | jq '.hits.hits | .[]._source.text_entry'
&Why, man?&
&Worthy man!&
&Every man,&
&complete man.&
&married man?&
&melancholy man.&
&Speak, man.&
&Why, man?&
&What, man?&
&prave man.&
&Speak, man.&
&Why, man?&
&O, the difference of man and man!&
&The young man is an honest man.&
&A gross fat man.&
&plain-dealing man?&
下面我们通过解析nginx的访问日志来说明怎么配合使用ELKB。
解析Nginx访问日志
整个过程的流程比较简单，Filebeat收集日志传送给Logstash，logstash解析好了以后，写入到ealsticsearch中，最后我们使用kibana来查看这些日志并进行检索。
首先切换到client上，我们来配置filebeat。
$ vim /etc/filebeat/filebeat.yml
prospectors:
- /var/log/nginx/access.log
# 找到document_type字段，取消注释，这个字段会告诉logstash日志的类型，对应logstash中的type字段
document_type: nginx
# 默认输出为elasticsearch，注释掉，使用logstash
hosts: [&IP:5044&] # 注意更改这里的IP
logstash的配置相对麻烦一下，因为logstash需要接受输入，进行处理然后产生输出。logstash采用 input , filter , output 的三段配置法。input配置输入源，filter配置对输入源中的信息怎样进行处理，而output配置输出位置。
一般情况下，input为beat，filter中我们解析input获取到的日志，得到我们想要的字段，而output为elasticsearch。这里我们以nginx的访问日志为例。filter中有一个关键的东西叫做 grok ，我们使用这个东西来解析日志结构。logstash提供了一些默认的
，方便我们解析用。当然，我们也可以自己用正则来自定义pattern匹配日志内容。
$ vim /etc/logstash/conf.d/nginx.conf
port =& 5044
if [type] == &nginx& { # 这里的type是日志类型，我们在后面的filebeat中设定
match =& { &message& =& &%{COMBINEDAPACHELOG} %{QS:gzip_ratio}& } # 使用自带的pattern即可，注意空格
remove_field =& [&beat&, &input_type&, &message&, &offset&, &tags&] # filebeat添加的字段，我们不需要
# 更改匹配到的字段的数据类型
convert =& [&response&, &integer&]
convert =& [&bytes&, &integer&]
convert =& [&responsetime&, &float&]
# 指定时间戳字段以及具体的格式
match =& [&timestamp&, &dd/MMM/YYYY:HH:mm:ss Z&]
remove_field =& [&timestamp&]
outpugst {
elasticsearch {
hosts =& [ &localhost:9200& ]
index =& &%{type}-%{+YYYY.MM.dd}& # index中含有时间戳
service logstash start 启动logstash即可，注意，他的启动速度很慢。
Elastcisearch
上面的logstash配置中，我们可以看到最终写入elasticsearch的index含有时间戳，这是比较推荐的做法。因为可以方便我们按天对数据进行分析。关于elasticsearch我们只要配置一下index的Mapping信息即可。因为我们的index是按天生成的，每天都是一个新的index，那当然不可能每天都配置一次index的Mapping。这里需要使用elasticsearch的一个功能， Index Template ，我们可以创建一个index的配置模板，使用这个模板来配置所有匹配的index。
curl -XPUT localhost:9200/_template/nginx -d '
&template&: &nginx*&,
&mappings&: {
&_default_&: {
&properties&: {
&clientip&: {
&type&: &string&,
&index&: &not_analyzed&
&ident&: {
&type&: &string&
&type&: &string&
&type&: &string&
&request&: {
&type&: &string&
&httpversion&: {
&type&: &string&
&rawrequest&: {
&type&: &string&
&response&: {
&type&: &string&
&bytes&: {
&type&: &integer&
&referrer&: {
&type&: &string&
&agent&: {
&type&: &string&
&gzip_ratio&: {
&type&: &string&
上面的代码创建了一个名为 nginx 的模板，匹配所有以nginx开头的index。
kibana不需要什么配置，直接启动即可。 service kibana start ，默认运行在5601端口。如果考虑到安全性，也可以将kibana配置为只监听本机，然后使用nginx进行反向代理并控制权限，这里就不再赘述了。
接下来我们需要产生点日志，然后在kibana中能查看到就说明系统工作正常了。我们用curl随便请求一下client上的nginx来产生一点日志。然后，打开kibana， http://[server ip]:5601 。刚进去的时候，我们先要配置一下Kibana的 Index Pattern ，告诉kibana我们想看哪个Index的数据，输入 nginx* 即可，然后点击 Discover 浏览数据。
最终效果如下，我们可以在kibana中浏览我们的nginx日志，并进行任意搜索。
已发表评论数()
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
标题不准确
排版有问题
主题不准确
没有分页内容
图片无法显示
视频无法显示
与原文不一致