作者：饶琛琳
出版社：机械工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
ELKstack权威指南试读：
前言
操作系统、应用服务和业务逻辑，都在不停地产生日志数据。过去，日志数据基本都存在单机磁盘上，只能用来做临时的事后分析和审计；有Hadoop以后，大家渐渐习惯将日志收集到HDFS中，然后每天运行MapReduce任务做统计报表。但是，面对诸如“新上线的版本过去几分钟在各地反馈如何”“昨天23:40左右这个投诉用户有没有异常”这种即时的开放性问题，传统的日志处理方案显得非常笨拙和低效，因为解答没有唯一套路，需要尝试下钻挖掘才能得出答案。复杂多变的实时数据分析需求，需要的是灵活快捷的响应处理。Splunk公司正是凭借着自己在这个大数据细分领域的一枝独秀，成为百亿美元级的明星公司。但是Splunk每GB高达4500美元的报价，又让人望而却步。直到ELK stack出现后，大家才有了可选择的开源产品。
ELK stack是以Elasticsearch、Logstash、Kibana三个开源软件为主的数据处理工具链，在实时数据检索和分析场合，三者通常是配合使用，而且又先后归于Elastic.co公司名下，故有此简称。
ELK stack具有如下几个优点：
处理方式灵活。Elasticsearch是实时全文索引，不需要像Storm那样预先编程才能使用。
配置简易上手。Elasticsearch全部采用JSON接口，Logstash是Ruby DSL设计，都是目前业界最通用的配置语法设计。
检索性能高效。虽然每次查询都是实时计算，但是优秀的设计和实现基本可以达到百亿级数据查询的秒级响应。
集群线性扩展。不管是Elasticsearch集群还是Logstash集群都是可以线性扩展的。
前端操作炫丽。Kibana界面上，只需点击鼠标，就可以完成搜索、聚合功能，生成炫丽的仪表盘。
当然，ELK stack并不是实时数据分析的灵丹妙药，使用不恰当，反而会事倍功半。我自2014年年初开QQ群交流ELK stack，发现网友们对ELK stack的原理常有误解误用，对实现的效果也多有不能理解或者因过多期望而失望之处。更令我惊奇的是，网友们分布之广，遍及传统企业和互联网公司、开发和运维领域、Linux和Windows平台，大家对非专精领域的知识，一般都缺乏了解，这也成为使用ELK stack的一个障碍。
为此，我决定写一本ELK stack技术指南，帮助大家厘清技术细节，分享一些实战案例。本书并不会逐一介绍ELK stack的全部聚合语法或者分词特性，而是从日志数据处理的角度介绍数据的解析、导入、可视化方式，讲解集群的稳定性和性能优化原理，剖析代码要点并提供ELK stack二次开发实例。
本书包括三大部分共19章，各部分可以独立阅读。但对于还没有大规模应用经验的新手，建议按顺序阅读全文。
第一部分 Logstash
第1章：入门示例。该章介绍Logstash及其插件的配置安装方法，自定义配置语言的设计用途，并为不熟悉Linux系统管理的开发人员介绍了多种后台运行方式。
第2章：插件配置。该章列举Logstash最常用的几十种插件，通过实际示例和效果，讲解各插件的配置细节和用途。
第3章：场景示例。该章以最常见的运维、网络、开发和数据库场景，介绍Logstash处理Nginx、Post？x、Ossec、Log4J、MySQL、Docker等日志的最佳实践。
第4章：性能与监控。了解Logstash的性能情况一直是个难题，该章从Logstash设计原理和JVM平台本质出发，介绍几种行之有效的检测和监控方案。
第5章：扩展方案。该章介绍采用Redis和Kafka完成Logstash水平扩展的方案，同时也介绍其他几种日志收集系统与Logstash的配合方式。
第6章：Logstash源码解析。该章解析Logstash源码中最重要的Pipeline设计，以及Logstash::Event的来龙去脉。
第7章：插件开发。该章以最常见的用户登录记录和地址库解析、Consul数据更新等需求，实际演示Logstash 的自定义Filter、Input和Output插件的编写，同时还涉及了插件打包的RubyGems规范共有HttpClient功能项等细节。
第二部分 Elasticsearch
第8章：架构原理。该章从更高级的架构层面，介绍Elasticsearch分布式设计中涉及稳定性和高性能的部分原理，并由此引发相关的优化配置介绍。另外，还提供了一种针对时序数据索引的读写分离方案，适用于拥有少部分SSD设备的用户。
第9章：数据接口用例。该章介绍Elasticsearch的RESTful接口的基础知识，并针对常见的重建索引需求提供两种快速实现方案，为有Spark经验的读者介绍通过Spark Streaming接口读写Elasticsearch的方法。
第10章：性能优化。该章介绍Elasticsearch在日志处理场景下的读写优化知识和官方推荐的curator工具，其中重点介绍了Elasticsearch中几种不同的cache的区别和有效场景。
第11章：测试和扩展方案。该章介绍Elasticsearch在生产环境中需要的一些周边工具，比如Puppet配置管理、Shield权限管理、版本升级操作、别名切换流程设计等。
第12章：映射与模板的定制。该章详细介绍Elasticsearch中的核心类型及其对应的常见映射设置，以及如何通过动态模板简化映射定制操作的复杂度。
第13章：监控方案。Elasticsearch作为一个分布式系统，也是有一定的运维难度的，因此其本身的监控也相当重要。该章介绍Elasticsearch自带的一系列监控接口，以及由此衍生的多种实时或长期的监控方案。
第14章：Elasticsearch在运维监控领域的其他应用。该章介绍Elasticsearch在运维方面的其他运用方式，包括实时过滤接口、定时报警系统设计、时序数据存储和相关性排序等。
第三部分 Kibana
第15章：Kibana的产品对比。该章介绍Kibana 3与Kibana 4之间，以及它们与Hadoop、Splunk之间的差异，方便读者在不同场景需求下选择更正确的工具。
第16章：Kibana 3。该章介绍Kibana 3的界面操作方式、面板的配置细节及其效果、动态仪表盘的高级用法，并提供了几种额外权限控制的部署方案。
第17章：Kibana 3源码解析。该章以index.html为入口，介绍Kibana 3如何利用angular.js、elastic.js和jquery.？ot.js三大框架实现单页应用。重点解析面板的实现过程，并分别演示了采用facet和agg接口开发一个Kibana 3面板的过程。
第18章：Kibana 4。该章介绍Kibana 4的安装部署和界面操作方式，重点介绍Kibana4提供的几种可视化图表的配置细节和效果，并以几种场景的日志分析需求演示了Kibana 4全新的子聚合功能的效果。最后还介绍了一种采用phantom.js截图方式记录长期报表数据的方案。
第19章：Kibana 4源码解析。该章介绍Kibana 4的界面实现，重点包括其内部ORM实现的Counrier类、可视化绘图的Vislib类等。
致谢
我本人虽然接触ELK stack较早，但本身专于Web和App应用数据方面，动笔以来得到诸多朋友的帮助，详见后面“贡献者名单”。此外，还要特别感谢Elastic.co公司的曾勇(medcl)和吴晓刚(Wood)，曾勇完成Elasticsearch在国内的启蒙式分享，并主办Elasticsearch中国用户大会，吴晓刚积极帮助新用户，并最早分享了携程的ELK stack日亿级规模的实例。
贡献者名单
感谢 crazw 完成 collectd 插件介绍章节。
感谢 松涛 完成 nxlog 场景介绍章节。
感谢 LeiTu 完成 logstash-forwarder 介绍章节。
感谢 jingbli 完成 kafka 插件介绍章节。
感谢 林鹏 完成 ossec 场景介绍章节。
感谢 cameluo 完成 shield 介绍章节。
感谢 tuxknight 指出 hdfs 章节笔误。
感谢 lemontree 完成 marvel 介绍章节。
感谢 childe 完成 Kibana的CAS认证介绍、Elasticsearch的读写分离和别名应用章节。
感谢gnuhpc 完善 logstash-output-elasticsearch 配置细节和logstash-forwarder-java在AIX系统上的介绍。
第一部分 Logstash
Logstash is a tool for managing events and logs. You can use it to collect logs, parse them, and store them for later use (like, for searching). -- http://logstash.net
Logstash项目诞生于2009年8月2日。其作者是世界著名的运维工程师乔丹·西塞(Jordan Sissel)，乔丹·西塞当时是著名虚拟主机托管商DreamHost的员工，还发布过非常棒的软件打包工具fpm，并主办着一年一度的Sysadmin Advent Calendar(advent calendar文化源自基督教氛围浓厚的Perl社区，在每年圣诞来临的12月举办，从12月1日起至12月24日止，每天发布一篇小短文介绍主题相关技术)。
Logstash动手很早，对比一下，Scribed诞生于2008年，Flume诞生于2010年，Graylog2诞生于2010年，Fluentd诞生于2011年。Scribed在2011年进入半死不活的状态，大大激发了其他各种开源日志收集处理框架的蓬勃发展，Logstash也从2011年开始进入commit密集期并延续至今。
作为一个系出名门的产品，Logstash的身影多次出现在Sysadmin Weekly上，它和小伙伴们Elasticsearch、Kibana直接成为了和商业产品Splunk做比较的开源项目(乔丹·西塞曾经在博客上承认设计想法来自AWS平台上最大的第三方日志服务商Loggly，而Loggly两位创始人都曾是Splunk员工)。
2013年，Logstash被Elasticsearch公司收购，ELK stack正式成为官方用语。Elasticsearch本身也是近两年最受关注的大数据项目之一，三次融资已经超过一亿美元。在Elasticsearch开发人员的共同努力下，Logstash的发布机制、插件架构也愈发科学和合理。
社区文化
日志收集处理框架很多，如Scribe是Facebook出品，Flume是Apache基金会项目，都算声名赫赫。但Logstash因乔丹·西塞的个人性格，形成了一套独特的社区文化。每一个在Google Groups的Logstash-users组里问答的人都会看到这么一句话：
Remember: if a new user has a bad time, it’s a bug in Logstash.
所以，Logstash是一个开放的、极其互助和友好的大家庭。如有问题，仅管在Github Issue、Google Groups、Freenode#logstash Channel上发问就好!
第1章 入门示例
什么是Logstash？为什么要用Logstash？怎么用Logstash？这是本章将要介绍的内容。本章从最基础的知识着手，从以下几步介绍Logstash的必备知识。1)下载安装。介绍Logstash软件的多种安装部署方式，并给出推荐的方式。2)初次运行。通过Hello World示例，演示Logstash最简单的运用，解释其逻辑上的基础原理。3)配置语法。介绍Logstash的DSL设计，Logstash命令的运行参数。4)插件安装。灵活和丰富的插件是Logstash最重要的优势。本节会介绍Logstash插件的安装方式。5)长期运行方式。从初次终端测试到长期后台稳定运行，本节会介绍几种不同方案，供读者根据实际场景选择。
1.1 下载安装
1. 下载
Logstash从1.5版本开始，将核心代码和插件代码完全剥离，并重构了插件架构逻辑，所有插件都以标准的Ruby Gem包形式发布。不过，为了方便大家从1.4版本过渡，目前，官方依然发布打包有所有官方维护插件在内的软件包。只是不再发布类似原先1.4时代的logstash-contrib.tar.gz这样的软件包了。依然要使用社区插件的读者，请阅读稍后1.4节“插件安装”。
下载官方软件包的方式有以下几种：
压缩包方式
Debian平台
wget https://download. elastic. co/logstash/logstash/logstash-1.5.1. tar. gz wget https://download. elastic. co/logstash/logstash/packages/debian/logstash_1.5.1-1_all. deb
Redhat平台
wget https://download. elastic. co/logstash/logstash/packages/centos/logstash-1.5.1-1.noarch.rpm
2. 安装
在上面这些包中，你可能更偏向使用rpm、dpkg等软件包管理工具来安装Logstash，开发者在软件包里预定义了一些依赖。比如，logstash-1.5.1-1.narch就依赖于jre包。
另外，软件包里还包含有一些很有用的脚本程序，比如/etc/init.d/logstash。
如果你必须在一些很老的操作系统上运行Logstash，那你只能用源代码包部署了，记住要自己提前安装好Java：
yum install openj dk-j re
export JAVA_HOME=/usr/j ava
tar zxvf logstash-1.5.1. tar. gz
3. 最佳实践
但是真正的建议是：如果可以，请用Elasticsearch官方仓库来直接安装Logstash!
Debian平台
wget -O - http://packages. elasticsearch. org/GPG-KEY-elasticsearch | apt-key add -
cat ＞＞ /etc/apt/sources. list 〈〈EOF
deb http://packages. elasticsearch. org/logstash/1.5/debian stable main
EOF
apt-get update
apt-get install logstash
Redhat平台
rpm --import http://packages. elasticsearch. org/GPG-KEY-elasticsearch
cat ＞ /etc/yum. repos. d/logstash. repo EOF
[logstash-1.5]
name=logstash repository for 1.5. x packages
baseurl=http://packages. elasticsearch. org/logstash/1.5/centos
gpgcheck=1
gpgkey=http://packages. elasticsearch. org/GPG-KEY-elasticsearch
enabled=1
EOF
yum clean all
yum install logstash
1.2 Hello World
与绝大多数IT技术介绍一样，我们也以一个输出“Hello World”的形式开始学习Logstash。
1. 命令行运行
在终端中，像下面这样运行命令来启动 Logstash 进程：
# bin/logstash -e ’input{stdin{}}output{stdout{codec=＞rubydebug}}’
然后你会发现终端在等待你的输入。没问题，敲入 Hello World，回车，看看会返回什么结果!
{“message” =＞“Hello World”,
“@version“ =＞“1“,
“@timestamp” =＞“2014-08-07T10:30:59.937Z”,
“host“ =＞”raochenlindeMacBook-Air. local”,}
没错!就是这么简单。
2. 完整示例
命令行运行当然不是什么特别方便的用法，所以绝大多数情况下，我们都是采用额外定义一个logstash.conf配置文件的方式来启动Logstash。下面是我们的第一个完整版logstash.conf的示例：
input {
stdin { }
}
output {
stdout {
codec =＞ rubydebug {}
}
elasticsearch {
embedded =＞ true
}
}
然后在终端上这样运行：
# bin/logstash -f logstash. conf
同样，还是输入一次Hello World。你会看到和上一次一样的一段Ruby对象输出。但事实上，这个完整示例可不止如此。打开另一个终端，输入下面一行命令：
# curl http://127.0.0.1:9200/_search？q=hello
你会看到终端上输出下面这么一段内容：
{“took“:15,“timed_out“:false,“_shards“:{“total“:27,“successful“:27,“failed“:0},“hits“:{“total“:1,“max_score“:0.095891505,“hits“:[{“_index“:“logstash-2015.08.22“,“_type“:“logs“,“_id“:“AU90s1eNgg_P5-w7SB32“,“_score“:0.095891505,“_source“:{“message“:“Hello World“,“@version“:“1“,“@timestamp“:“2014-08-07T10:30:59.937Z“,“host“:“raochenlindeMacBook-Air.local“}}]}}
如果你使用的是Logstash-1.5以下的版本，你还可以直接通过 bin/logstash web命令，启动Kibana应用，然后在浏览器上访问http://127.0.0.1:9292/地址，可以看到如图1-1所示的效果。我们在终端上输入的数据，就可以从页面上任意搜索了。图1-1 Kibana上搜索的hello world
如果你使用的是Logstash-1.5以上版本，Logstash已经不再自带Kibana代码，你就只能自己安装部署一套Kibana程序了，相关内容，可以稍后阅读本书第三部分的介绍。
3. 解释
每位系统管理员都肯定写过很多类似这样的命令：cat randdata | awk ’{print $2}’ | sort |uniq -c | tee sortdata。这个管道符|可以算是Linux世界最伟大的发明之一(另一个是“一切皆文件”)。
Logstash就像管道符一样!
你输入(就像命令行的cat)数据，然后处理过滤(就像awk或者uniq之类)数据，最后输出(就像tee)到其他地方。
当然实际上，Logstash是用不同的线程来实现这些的。如果你运行top命令然后按下H键，你就可以看到下面这样的输出：
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
21401 root 16 0 1249m 303m 10m S 18.6 0.2 866:25.46 |worker
21467 root 15 0 1249m 303m 10m S 3.7 0.2 129:25.59 〉elasticsearch.
21468 root 15 0 1249m 303m 10m S 3.7 0.2 128:53.39 〉elasticsearch.
21400 root 15 0 1249m 303m 10m S 2.7 0.2 108:35.80〈f ile
21403 root 15 0 1249m 303m 10m S 1.3 0.2 49:31.89 〉output
21470 root 15 0 1249m 303m 10m S 1.0 0.2 56:24.24 〉elasticsearch.
如上例所示，Logstash很温馨地给每类线程都取了名字，输入的叫〈xx，过滤的叫|xx，输出的叫〉xx。
数据在线程之间以事件的形式流传。不要叫行，因为Logstash可以处理多行事件。
Logstash会给事件添加一些额外信息。最重要的就是@timestamp，用来标记事件的发生时间。因为这个字段涉及Logstash的内部流转，所以必须是一个joda对象，如果你尝试自己给一个字符串字段重命名为@timestamp的话，Logstash会直接报错。所以，请使用logstash-f ilter-date插件来管理这个特殊字段。
此外，大多数时候，还可以见到另外几个：
host标记事件发生在哪里。
type标记事件的唯一类型。
tags标记事件的某方面属性。这是一个数组，一个事件可以有多个标签。
你可以随意给事件添加字段或者从事件里删除字段。事实上事件就是一个Ruby对象，或者更简单地理解为就是一个哈希也行。
每个Logstash过滤插件，都会有四个方法叫add_tag、remove_tag、add_f ield和remove_f ield，它们在插件过滤匹配成功时生效。推荐阅读官网上“the life of an event”文档：http://logstash.net/docs/1.4.2/life-of-an-eventElastic{ON}上《life of a logstash event》演讲：https://speakerdeck.com/elastic/life-ofa-logstash-event
1.3 配置语法
Logstash社区通常习惯用Shipper、Broker和Indexer来描述数据流中不同进程各自的角色。如图1-2所示。图1-2 Logstash角色说明
不过我见过很多运用场景里都没有用Logstash作为Shipper，或者说没有用Elasticsearch作为数据存储，也就是说也没有Indexer。所以，我们其实不需要这些概念。只需要学好怎么使用和配置Logstash进程，然后把它运用到你的日志管理架构中最合适它的位置就够了。
1.3.1 语法
Logstash设计了自己的DSL——有点像Puppet的DSL，或许因为都是用Ruby语言写的吧——包括区域、注释、数据类型(布尔值、字符串数值、数组、哈希)，条件判断、字段引用等。
1. 区段(section)
Logstash用{}来定义区域。区域内可以包括插件区域定义，你可以在一个区域内定义多个插件。插件区域内则可以定义键值对设置。示例如下：
input {
stdin {}
syslog {}
}
2. 数据类型
Logstash支持少量的数据值类型：
希尔值(bool)
debug =〉 true
字符串(string)
host =〉“hostname”
数值(number)
port =〉 514
数组(array)
match =〉 [“datetime”, “UNIX”, “ISO8601”]
哈希(hash)
options =〉 {
key1 =〉“value1”,
key2 =〉“value2”
}
如果你用的版本低于1.2.0，哈希的语法跟数组是一样的，像下面这样写：
match =〉 [ “f ield1“, “pattern1“, “f ield2“, “pattern2“ ]
3. 字段引用(f ield reference)
字段是 Logstash::Event对象的属性。我们之前提过事件就像一个哈希一样，所以你可以想象字段就像一个键值对。
如果你想在Logstash配置中使用字段的值，只需把字段的名字写在中括号[ ]里就行了，这就叫“字段引用”。
对于“嵌套字段”(也就是多维哈希表，或者叫哈希的哈希)，每层的字段名都写在[ ]里就可以了。比如，你可以从geoip里这样获取longitude值(是的，这是个笨办法，实际上有单独的字段专门存这个数据的)：
[geoip][location][0]小知识Logstash的数组也支持倒序下标，即[geoip][location][-1]可以获取数组最后一个元素的值。
Logstash还支持变量内插，在字符串里使用字段引用的方法是这样：
“the longitude is %{[geoip][location][0]}“
4. 条件判断(condition)
Logstash从1.3.0版开始支持条件判断和表达式。
表达式支持下面这些操作符：
·equality, etc: ==, !=, 〈, 〉, 〈=, 〉=
·regexp: =~, !~
·inclusion: in, not in
·boolean: and, or, nand, xor
·unary: !()
通常来说，你都会在表达式里用到字段引用。比如：
if “_grokparsefailure“ not in [tags] {
} else if [status] !~ /^2\d\d/ and [url] == “/noc. gif“ {
} else {
}
1.3.2 命令行参数
Logstash提供了一个shell脚本叫logstash方便快速运行，下面介绍它支持的参数：
1. -e
意即“执行”。我们在“Hello World”的时候已经用过这个参数了。事实上你可以不写任何具体配置，直接运行bin/logstash -e ’’可达到相同效果。这个参数的默认值是下面这样：
input {
stdin { }
}
output {
stdout { }
}
2. --conf ig或-f
意即“文件”。真实运用中，我们会写很长的配置，甚至可能超过shell所能支持的1024个字符长度。所以我们必把配置固化到文件里，然后通过bin/logstash -f agent.conf这样的形式来运行。
此外，Logstash还提供一个方便我们规划和书写配置的小功能。你可以直接用bin/logstash -f /etc/logstash.d/来运行。Logstash会自动读取/etc/logstash.d/目录下所有的文本文件，然后在自己内存里拼接成一个完整的大配置文件，再去执行。
3. --conf igtest或-t
意即“测试”。用来测试Logstash读取到的配置文件语法是否能正常解析。Logstash配置语法是用grammar.treetop定义的。尤其是使用了上一条提到的读取目录方式的读者，尤其要提前测试。
4. --log或-l
意即“日志”。Logstash默认输出日志到标准错误。生产环境下你可以通过bin/logstash-l logs/logstash.log命令来统一存储日志。
5. --f ilterworkers或-w
意即“工作线程”。Logstash会运行多个线程。你可以用bin/logstash -w 5这样的方式强制Logstash为“过滤插件”(Logstash目前还不支持输入插件的多线程，输出插件的多线程则是在配置内设置)运行5个线程。警告Logstash目前不支持对过滤器线程的监测管理。如果f ilterworker挂掉，Logstash会处于一个无f ilter的僵死状态。这种情况在使用f ilter/ruby自己写代码时非常需要，很容易碰上NoMethodError: undef ined method ’*’ for nil:NilClass错误。需要妥善处理，提前判断。
6. --plug inpath或-P
可以写自己的插件，然后用bin/logstash --pluginpath /path/to/own/plugins加载它们。警告如果你使用的Logstash版本在1.5.0-rc3到1.5.3之间，该参数一度被取消，请阅读本书稍后插件开发章节，改用本地gem插件安装形式。
7. --verbose
输出一定的调试日志。如果你使用的Logstash版本低于1.3.0，则用bin/logstash -v来代替。
8. --debug
输出更多的调试日志。如果你使用的Logstash版本低于1.3.0，则用bin/logstash -vv来代替。
1.4 插件安装
从Logstash 1.5.0版本开始，Logstash将所有的插件都独立拆分成gem包。这样，每个插件都可以独立更新，不用等待Logstash自身做整体更新的时候才能使用了。
为了达到这个目标，Logstash配置了专门的plugin管理命令。
plugin命令用法说明如下：
Usage:
bin/plugin [OPTIONS] SUBCOMMAND [ARG] ...
Parameters:
SUBCOMMAND subcommand
[ARG] ... subcommand arguments
Subcommands:
install Install a plugin
uninstall Uninstall a plugin
update Install a plugin
list List all installed plugins
Options:
-h, --help print help
首先，你可以通过bin/plugin list查看本机现在有多少插件可用。(其实就在vendor/bundle/jruby/1.9/gems/目录下。)
然后，假如你看到https://github.com/logstash-plugins/下新发布了一个logstash-outputwebhdfs模块(当然目前还没有)。打算试试，就只需运行如下命令：
bin/plugin install logstash-output-webhdfs
同样，假如是升级，只需运行如下命令即可：
bin/plugin update logstash-input-tcp
bin/plugin不但可以通过 rubygems平台安装插件，还可以读取本地路径的gem文件，这对自定义插件或者无外接网络的环境都非常有效：
bin/plugin install /path/to/logstash-f ilter-crash. gem
执行成功以后。你会发现，logstash-1.5.0 目录下的 Gemf ile文件最后会多出一段内容：
gem “logstash-f ilter-crash”, “1.1.0”, :path =〉“vendor/local_gems/d354312c/
logstash-f ilter-mweibocrash-1.1.0“
同时 Gemf ile.jruby-1.9.lock文件开头也会多出一段内容，如下所示：
PATH
remote: vendor/local_gems/d354312c/logstash-f ilter-crash-1.1.0
specs:
logstash-f ilter-crash (1.1.0)
logstash-core (〉= 1.4.0, 〈 2.0.0)
1.5 长期运行方式
完成上一节的初次运行后，你肯定会发现一点：一旦你按下Ctrl+C，停下标准输入输出，Logstash进程也就随之停止了。作为一个肯定要长期运行的程序，应该怎么处理呢？提示本章节问题对于一个运维来说应该属于基础知识，鉴于ELK用户很多其实不是运维，添加这段内容。
办法有很多种，下面介绍四种最常用的办法。
1. 标准的service方式
采用RPM、DEB发行包安装的读者，推荐采用这种方式。发行包内，都自带有sysV或者systemd风格的启动程序/配置，你只需要直接使用即可。以RPM为例，/etc/init.d/logstash脚本中，会加载/etc/init.d/functions库文件，利用其中的daemon函数，将Logstash进程作为后台程序运行。
所以，你只需把自己写好的配置文件统一放在/etc/logstash/目录下(注意目录下所有配置文件都应该是.conf结尾，且不能有其他文本文件存在，因为logstash agent启动的时候是读取全文件夹的)，然后运行service logstash start命令即可。
2. 最基础的nohup方式
这是最简单的方式，也是Linux新手们很容易搞混淆的一个经典问题：
command
command 〉 /dev/null
command 〉 /dev/null 2〉&1
command &
command 〉 /dev/null &
command 〉 /dev/null 2〉&1 &
command &〉 /dev/null
nohup command &〉 /dev/null
请回答以上命令的异同……
具体不一一解释了。直接说答案，想要维持一个长期后台运行的Logstash，你需要同时在命令前面加nohup，后面加&。
3. 更优雅的screen方式
screen算是Linux运维一个中高级技巧。通过screen命令创建的环境下运行的终端命令，其父进程不是sshd登录会话，而是screen。这样就可以既避免用户退出进程消失的问题，又随时能重新接管回终端继续操作。
创建独立的screen命令如下：
screen -dmS elkscreen_1
连接进入已创建的elkscreen_1的命令如下：
screen -r elkscreen_1
然后你可以看到一个一模一样的终端，运行Logstash之后，不要按Ctrl+C，而是按Ctrl+A+D键，断开环境。想重新接管，依然用screen -r elkscreen_1即可。
如果创建了多个screen，查看列表命令如下：
screen -list
4. 最推荐的daemontools方式
不管是nohup还是screen，都不是可以很方便管理的方式，在运维管理一个ELK集群的时候，必须寻找一种尽可能简洁的办法。所以，对于需要长期后台运行的大量程序(注意大量，如果就一个进程，还是学习一下怎么写init脚本吧)，推荐大家使用一款daemontools工具。
daemontools是一个软件名称，不过配置略复杂。所以这里我其实是用其名称来指代整个同类产品，包括但不限于Python实现的supervisord， Perl实现的ubic， Ruby实现的god等。
以supervisord为例，因为这个出来得比较早，可以直接通过EPEL仓库安装。
yum -y install supervisord --enablerepo=epel
在 /etc/supervisord.conf配置文件里添加内容，定义你要启动的程序，如下所示：
[program:elkpro_1]
environment=LS_HEAP_SIZE=5000m
directory=/opt/logstash
command=/opt/logstash/bin/logstash -f /etc/logstash/pro1. conf -w 10 -l /var/
log/logstash/pro1. log
[program:elkpro_2]
environment=LS_HEAP_SIZE=5000m
directory=/opt/logstash
command=/opt/logstash/bin/logstash -f /etc/logstash/pro2. conf -w 10 -l /var/
log/logstash/pro2. log
然后启动service supervisord start 即可。
Logstash会以supervisord子进程的身份运行，你还可以使用supervisorctl命令，单独控制一系列 Logstash 子进程中某一个进程的启停操作：
supervisorctl stop elkpro 2
第2章 插件配置
插件是Logstash最大的特色。各种不同的插件源源不断地被创造出来，发布到社区中供大家使用。本章会按照插件的类别，对一般场景下的一些常用插件做详细的配置和用例介绍。本章介绍的插件包括：1)输入插件。基于shipper端场景，主要介绍STDIN、TCP、File等插件。2)编解码插件。编解码通常是会被遗忘的环节，但是运用好了，会大大提高工作效率，本节介绍最常用的JSON和multiline插件。3)过滤器插件。名为过滤器，其实各种数据裁剪和计算都可以在这类插件里完成，是Logstash最强大的一环。本节会详细介绍grok、date、mutate、ruby、metrics等插件的妙用。4)输出插件。Logstash虽然经常跟Elasticsearch并称，但是作为一个日志传输框架，它其实可以输出数据到各种不同的地方。比如Graphite、HDFS、Nagios等等。本节会介绍这些常用的输出插件用法。
2.1 输入插件
在“Hello World”示例中，我们已经见到并介绍了Logstash的运行流程和配置的基础语法。从这章开始，我们就要逐一介绍Logstash流程中比较常用的一些插件，并在介绍中针对其主要适用的场景、推荐的配置，作一些说明。
限于篇幅，接下来内容中，配置示例不一定能贴完整。请记住一个原则：Logstash配置一定要有一个input和一个output。在演示过程中，如果没有写明input，默认就会使用“Hello World”里我们已经演示过的logstash-input-stdin，同理，没有写明的output就是logstash-output-stdout。
以上请读者自明。
2.1.1 标准输入
我们已经见过好几个示例使用stdin了。这也应该是Logstash里最简单和基础的插件了。所以，在这段中，我们先介绍一些未来每个插件都会有的一些方法。
配置示例如下：
用上面的新stdin设置重新运行一次最开始的Hello World示例。我建议大家把整段配置都写入一个文本文件，然后运行命令：bin/logstash -f stdin.conf。输入“Hello World”并回车后，你会在终端看到如下输出：
type 和tags是Logstash事件中两个特殊的字段。通常来说，我们会在“输入区段”中通过type来标记事件类型——我们肯定是提前能知道这个事件属于什么类型的。而tags则是在数据处理过程中，由具体的插件来添加或者删除的。
最常见的用法是像下面这样：
看起来蛮复杂的，对吧？
继续学习，你也可以写出来的。
2.1.2 文件输入
分析网站访问日志应该是一个运维工程师最常见的工作了。所以我们先学习一下怎么用Logstash来处理日志文件。
Logstash使用一个名叫FileWatch的Ruby Gem库来监听文件变化。这个库支持glob展开文件路径，而且会记录一个叫.sincedb的数据库文件来跟踪被监听日志文件的当前读取位置。所以，不要担心Logstash会漏过你的数据。
提示sincedb文件中记录了每个被监听的文件的inode, major number, minor number和pos。
配置示例如下：
有一些比较有用的配置项，可以用来指定FileWatch库的行为：
discover_interval：Logstash每隔多久去检查一次被监听的path下是否有新文件，默认值是15秒。
exclude：不想被监听的文件可以排除出去，这里跟path一样支持glob展开。
sincedb_path：如果你不想用默认的$HOME/.sincedb(Windows平台上为%USERPROFILE%\.sincedb，该变量默认值是：C:\Windows\System32\conf ig\systemprof ile)，可以通过这个配置定义sincedb文件到其他位置。
sincedb_write_interval：Logstash每隔多久写一次sincedb文件，默认是15秒。
stat_interval：Logstash每隔多久检查一次被监听文件状态(是否有更新)，默认是1秒。
start_position：Logstash从什么位置开始读取文件数据，默认是结束位置，也就是说，
Logstash进程会以类似tail-F的形式运行。如果你是要导入原有数据，把这个设定改成“beginning”， Logstash进程就从头开始读取，有点类似于cat，但是读到最后一行不会终止，而是继续变成tail -F。
注意事项如下：
1)通常你要导入原有数据进Elasticsearch的话，你还需要f ilter/date插件来修改默认的“@timestamp“字段值。稍后会学习这方面的知识。
2)FileWatch只支持文件的绝对路径，而且会不自动递归目录。所以有需要的话，请用数组方式都写明具体哪些文件。
3)LogStash::Inputs::File只是在进程运行的注册阶段初始化一个FileWatch对象。所以它不能支持类似f luentd那样的path =〉“/path/to/%{+yyyy/MM/dd/hh}.log“写法。达到相同目的，你只能写成path =〉“/path/to/*/*/*/*.log”。FileWatch模块提供了一个稍微简单一点的写法：/path/to/**/*.log，用**来缩写表示递归全部子目录。
4)start_position仅在该文件从未被监听过的时候起作用。如果sincedb文件中已经有这个文件的inode记录了，那么Logstash依然会从记录过的pos开始读取数据。所以重复测试的时候每回需要删除sincedb文件。
5)因为Windows平台上没有inode的概念，Logstash某些版本在Windows平台上监听文件不是很靠谱。Windows平台上，推荐考虑使用nxlog作为收集端，参阅本书稍后章节。
2.1.3 TCP输入
未来你可能会用Redis服务器或者其他的消息队列系统来作为Logstash Broker的角色。不过Logstash其实也有自己的TCP/UDP插件，在临时任务的时候，也算能用，尤其是测试环境。注意虽然LogStash::Inputs::TCP用Ruby的Socket和OpenSSL库实现了高级的SSL功能，但Logstash本身只能在SizedQueue中缓存20个事件。这就是我们建议在生产环境中换用其他消息队列的原因。
配置示例如下：
目前来看，LogStash::Inputs::TCP最常见的用法就是配合nc命令导入旧数据。在启动Logstash进程后，在另一个终端运行如下命令即可导入数据：
# nc 127.0.0.1 8888 〈 olddata
这种做法比用LogStash::Inputs::File好，因为当nc命令结束，我们就知道数据导入完毕了。而用input/f ile方式，Logstash进程还会一直等待新数据输入被监听的文件，不能直接看出是否任务完成了。
2.1.4 syslog输入
syslog可能是运维领域最流行的数据传输协议了。当你想从设备上收集系统日志的时候，syslog应该会是你的第一选择。尤其是网络设备，比如思科中syslog几乎是唯一可行的办法。
我们这里不解释如何配置你的syslog.conf、rsyslog.conf或者syslog-ng.conf来发送数据，而只讲如何把Logstash配置成一个syslog服务器来接收数据。
有关rsyslog的用法，稍后的类型项目一节中，会有更详细的介绍。
配置示例如下：
作为最简单的测试，我们先暂停一下本机的syslogd(或rsyslogd)进程，然后启动Logstash进程(这样就不会有端口冲突问题)。现在，本机的syslog就会默认发送到Logstash里了。我们可以用自带的logger命令行工具发送一条“Hello World”信息到syslog里(即Logstash里)。看到的Logstash输出像下面这样：
{
“message“ =〉“Hello World“,
“@version“ =〉“1“,
“@timestamp“ =〉“2014-08-08T09:01:15.911Z“,
“host“ =〉“127.0.0.1“,
“priority“ =〉31,“timestamp“ =〉“Aug 8 17:01:15“,
“logsource“ =〉“raochenlindeMacBook-Air. local“,
“program“ =〉“com. apple. metadata. mdf lagwriter“,
“pid“ =〉“381“,
“severity“ =〉7,
“facility“ =〉3,
“facility_label“ =〉“system“,
“severity_label“ =〉“Debug“
}
Logstash是用UDPSocket、TCPServer和LogStash::Filters::Grok来实现LogStash::Inputs::Syslog的。所以你其实可以直接用Logstash配置实现一样的效果，如下所示：
建议在使用LogStash::Inputs::Syslog的时候走TCP协议来传输数据。
因为具体实现中，UDP监听器只用了一个线程，而TCP监听器会在接收每个连接的时候都启动新的线程来处理后续步骤。
如果你已经在使用UDP监听器收集日志，用下行命令检查你的UDP接收队列大小：
# netstat -plnu | awk ‘NR==1 || $4~/:514$/{print $2}’
Recv-Q
228096
228096是UDP接收队列的默认最大大小，这时候linux内核开始丢弃数据包了!
强烈建议使用LogStash::Inputs::TCP和LogStash::Filters::Grok配合实现同样的syslog功能!
虽然LogStash::Inputs::Syslog在使用TCPServer的时候可以采用多线程处理数据的接收，但是在同一个客户端数据的处理中，其grok和date是一直在该线程中完成的，这会导致总体上的处理性能几何级的下降——经过测试，TCPServer每秒可以接收50000条数据，而在同一线程中启用grok后每秒只能处理5000条，再加上date只能达到500条!
才将这两步拆分到f ilters阶段后，Logstash支持对该阶段插件单独设置多线程运行，大大提高了总体处理性能。在相同环境下，logstash -f tcp.conf -w 20的测试中，总体处理性能可以达到每秒30 000条数据!注意测试采用Logstash作者提供的命令：
yes “〈44〉May 19 18:30:17 snack j ls: foo bar 32” | nc localhost 3000
出处见：https:// github.com/jordansissel/experiments/blob/master/ruby/jruby-netty/syslogserver/Makef ile
如果你实在没法切换到TCP协议，可以自己写程序，或者使用其他基于异步I/O框架(比如libev)的项目。下面是一个简单的异步I/O实现UDP监听数据输入Elasticsearch的示例：https://gist.github.com/chenryn/7c922ac424324ee0d695。
2.1.5 collectd输入
collectd是一个守护(daemon)进程，用来收集系统性能和提供各种存储方式来存储不同值的机制。它会在系统运行和存储信息时周期性的统计系统的相关统计信息。利用这些信息有助于查找当前系统性能瓶颈(如作为性能分析performance analysis)和预测系统未来的load(如能力部署capacity planning)等
下面简单介绍一下:collectd的部署以及与Logstash对接的相关配置实例。
1. collectd的安装
解决依赖如下：
rpm -ivh “http://dl. fedoraproj ect. org/pub/epel/6/i386/epel-release-6-8. noarch. rpm“
yum -y install libcurl libcurl-devel rrdtool rrdtool-devel perl-rrdtool
rrdtool-prel libgcrypt-devel gcc make gcc-c++ liboping liboping-
试读结束[说明：试读内容隐藏了图片]