ELK Stack权威指南(txt+pdf+epub+mobi电子书下载)

作者：饶琛琳

出版社：机械工业出版社

格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT

ELK Stack权威指南试读：

前言

对于并不精通ELK Stack技术及其发展历史的人来说，过去复杂的版本对应是新手的第一道门槛。最近全新更新的ELK Stack各组件，统一使用5.x系列版本号，大大方便了新手入门。而5.x系列同样携带了大量崭新的特性，在日志分析、监控告警等场景，带来性能提升、管理简化、功能丰富等诸多好处。推荐广大读者积极尝试和升级。

IT运维模式正在向数据驱动、精细化、智能化发展。这个过程中，ELK Stack恰好是运维人员达成这个目的最方便的工具和平台。基于ELK Stack平台，越来越多的周边开源项目在涌现。这次再版，也进一步丰富了这些周边项目的介绍。

与第1版相比，第2版修订、删补了180多页内容，接近全书的一半。修改期间，怀孕的妻子一直默默陪伴左右，时不时叮嘱我注意保存。谨以此书献给她和刚出生的启舟宝贝，我爱你们！

本书章节内容

本书包括三大部分共19章，各部分可以独立阅读。但对于还没有大规模应用经验的新手，建议按顺序阅读全文。第一部分　Logstash

第1章：入门示例。该章介绍Logstash及其插件的配置安装方法，自定义配置语言的设计用途，并为不熟悉Linux系统管理的开发人员介绍了多种后台运行方式。

第2章：插件配置。该章列举Logstash最常用的几十种插件，通过实际示例和效果，讲解各插件的配置细节和用途。

第3章：场景示例。该章以最常见的运维、网络、开发和数据库场景，介绍Logstash处理Nginx、Postfix、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功能项等细节。

第8章：Beats。该章讲述ELK Stack家族新成员Beats生态圈各组件的使用，包括Filebeat、packetbeat、metricbeat、winlogbeat等内容。第二部分　Elasticsearch

第9章：架构原理。该章从更高级的架构层面，介绍Elasticsearch分布式设计中涉及稳定性和高性能的部分原理，并由此引发相关的优化配置介绍。另外，还提供了一种针对时序数据索引的读写分离方案，适用于拥有少部分SSD设备的用户。

第10章：数据接口用例。该章介绍Elasticsearch的RESTful接口的基础知识，并针对常见的重建索引需求提供两种快速实现方案，为有Spark经验的读者介绍通过Spark Streaming接口读写Elasticsearch的方法。

第11章：性能优化。该章介绍Elasticsearch在日志处理场景下的读写优化知识和官方推荐的curator工具，其中重点介绍了Elasticsearch中几种不同cache的区别和有效场景。

第12章：测试和扩展方案。该章介绍Elasticsearch在生产环境中需要的一些周边工具，比如Puppet配置管理、Shield权限管理、版本升级操作、别名切换流程设计等。新增了快照与恢复功能。

第13章：映射与模板的定制。该章详细介绍Elasticsearch中的核心类型及其对应的常见映射设置，以及如何通过动态模板简化映射定制操作的复杂度。

第14章：监控方案。Elasticsearch作为一个分布式系统，也是有一定的运维难度的，因此其本身的监控也相当重要。该章介绍Elasticsearch自带的一系列监控接口，以及由此衍生的多种实时或长期的监控方案。

第15章：Elasticsearch在运维监控领域的其他应用。该章介绍Elasticsearch在运维方面的其他运用方式，包括实时过滤接口、定时报警系统设计、时序数据存储和相关性排序等。第三部分　Kibana

第16章：Kibana的产品对比。该章介绍Kibana 3与Kibana 5之间，以及它们与Hadoop、Splunk之间的差异，方便读者在不同场景需求下选择更正确的工具。

第17章：Kibana 5。该章介绍Kibana 5的安装部署和界面操作方式，重点介绍Kibana 5提供的几种可视化图表的配置细节和效果，并以几种场景的日志分析需求演示了Kibana 5全新的子聚合功能的效果。最后还介绍了一种采用phantom.js截图方式记录长期报表数据的方案。

第18章：Kibana 5源码解析。该章介绍Kibana 4的界面实现，重点包括其内部ORM实现的Counrier类、可视化绘图的Vislib类等。

第19章：Kibana插件开发示例。该章讲述Kibana最常用的插件类型二次开发实例，包括可视化效果、服务器段进程、完整App演示等内容。

致谢

我本人虽然接触ELK较早，但本身专于Web和App应用数据方面，动笔以来得到诸多朋友的帮助，在此深表感谢。此外，还要特别感谢Elastic.co公司的曾勇（medcl）和吴晓刚（Wood），曾勇完成Elasticsearch在国内的启蒙式分享，并主办Elasticsearch中国用户大会，吴晓刚积极帮助新用户，并最早分享了携程的ELK日亿级规模的实例。第一部分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包形式发布。

下载官方软件包的方式有以下几种：

·压缩包方式

https://artifacts.elastic.co/downloads/logstash/logstash-5.1.1.tar.gz

·Debian平台

https://artifacts.elastic.co/downloads/logstash/logstash-5.1.1.deb

·Redhat平台

https://artifacts.elastic.co/downloads/logstash/logstash-5.1.1.rpm2.安装

在上面这些包中，你可能更偏向使用rpm、dpkg等软件包管理工具来安装Logstash，开发者在软件包里预定义了一些依赖。比如，logstash-5.0.2就依赖于jre包。

另外，软件包里还包含有一些很有用的脚本程序，比如/etc/init.d/logstash。

如果你必须在一些很老的操作系统上运行Logstash，那你只能用源代码包部署了，记住要自己提前安装好Java：yum install openjdk-jreexport JAVA_HOME=/usr/javatar zxvf logstash-5.0.2.tar.gz3.最佳实践

但是真正的建议是：如果可以，请用Elasticsearch官方仓库来直接安装Logstash！

·Debian平台wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -sudo apt-get install apt-transport-httpsecho "deb https://artifacts.elastic.co/packages/5.x/apt stable main" | sudo tee -a /etc/apt/sources.list.d/elastic-5.x.listsudo apt-get update && sudo apt-get install logstash

·Redhat平台sudo rpm --importhttps://artifacts.elastic.co/GPG-KEY-elasticsearchsudo cat > /etc/yum.repos.d/elk.repo <

与绝大多数IT技术介绍一样，我们也以一个输出“Hello World”的形式开始学习Logstash。1.命令行运行

在终端中，像下面这样运行命令来启动Logstash进程：# bin/logstash -e 'input{stdin{}}output{stdout{codec=>rubydebug}}'

首先看到终端输出一段进程启动过程的提示输出。提示以“Successfully started Logstash API endpoint{：port=>9600}”结束。

然后你会发现终端在等待你的输入。没问题，敲入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 { Rost=>["127.0.0.1"] }}

因为在5.0版本中，Elasticsearch和Kibana都是独立服务。如果你按照上一节的最佳实践配置好了yum的话，通过如下命令启动服务即可：# service elasticsearch start && service kibana start

然后在终端上这样运行：# 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"}}]}}

这时候你打开浏览器，访问http://127.0.0.1：5601地址，按照提示完成index pattern配置（正常的话只需要点击一下Create按钮），即可点击Discover页面看到如图1-1所示的效果。你在终端上输入的数据，可以从这个页面上任意搜索了。图1-1　Kibana上搜索的hello world提示　对index pattern配置有疑惑的读者，可以阅读本书第三部分关于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+ COMMAND21401 root 16 0 1249m 303m 10m S 18.6 0.2 866:25.46 |worker21467 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 output21470 root 15 0 1249m 303m 10m S 1.0 0.2 56:24.24 >elasticsearch.

如上例所示，Logstash很温馨地给每类线程都取了名字，输入的叫xx。

数据在线程之间以事件的形式流传。不要叫行，因为Logstash可以处理多行事件。

Logstash会给事件添加一些额外信息。最重要的就是@timestamp，用来标记事件的发生时间。因为这个字段涉及Logstash的内部流转，所以必须是一个joda对象，如果你尝试自己给一个字符串字段重命名为@timestamp的话，Logstash会直接报错。所以，请使用logstash-filter-date插件来管理这个特殊字段。

此外，大多数时候，还可以见到另外几个：

·host标记事件发生在哪里。

·type标记事件的唯一类型。

·tags标记事件的某方面属性。这是一个数组，一个事件可以有多个标签。

你可以随意给事件添加字段或者从事件里删除字段。事实上事件就是一个Ruby对象，或者更简单地理解为就是一个哈希也行。

每个Logstash过滤插件，都会有四个方法叫add_tag、remove_tag、add_field和remove_field，它们在插件过滤匹配成功时生效。推荐阅读·官网上“the life of an event”文档：http://logstash.net/docs/1.4.2/life-of-an-event·Elastic{ON}上《life of a logstash event》演讲：https://speakerdeck.com/elastic/life-of-a-logstash-event1.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 => [ "field1", "pattern1", "field2", "pattern2" ]3.字段引用（field 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.--config或-f

意即“文件”。真实运用中，我们会写很长的配置，甚至可能超过shell所能支持的1024个字符长度。所以我们必把配置固化到文件里，然后通过bin/logstash-f agent.conf这样的形式来运行。

此外，Logstash还提供一个方便我们规划和书写配置的小功能。你可以直接用bin/logstash-f/etc/logstash.d/来运行。Logstash会自动读取/etc/logstash.d/目录下所有的文本文件，然后在自己内存里拼接成一个完整的大配置文件，再去执行。注意　Logstash列出目录下所有文件时是字母排序的。而Logstash配置段的filter和output都是顺序执行的，所以顺序非常重要。采用多文件管理的用户，推荐采用数字编号方式命名配置文件，同时在配置中严谨采用if判断限定不同日志的动作。3.--configtest或-t

意即“测试”。用来测试Logstash读取到的配置文件语法是否能正常解析。Logstash配置语法是用grammar.treetop定义的。尤其是使用了上一条提到的读取目录方式的读者，尤其要提前测试。4.--log或-l

意即“日志”。Logstash默认输出日志到标准错误。生产环境下你可以通过bin/logstash-l logs/logstash.log命令来统一存储日志。5.--pipeline-workers或-w

运行filter和output的pipeline线程数量，默认是CPU核数。6.--pipeline-batch-size或-b

每个Logstash pipeline线程，在执行具体的filter和output函数之前，最多能累积的日志条数，默认是125条。越大性能越好，同样也会消耗越多的JVM内存。7.--pipeline-batch-delay或-u

每个Logstash pipeline线程，在打包批量日志的时候，最多等待几毫秒，默认是5 ms。8.--pluginpath或-P

可以写自己的插件，然后用bin/logstash--pluginpath/path/to/own/plugins加载它们。警告　如果你使用的Logstash版本在1.5.0-rc3到1.5.3之间，该参数一度被取消，请改用本地gem插件安装形式。9.--verbose

输出一定的调试日志。如果你使用的Logstash版本低于1.3.0，则用bin/logstash-v来代替。10.--debug

输出更多的调试日志。如果你使用的Logstash版本低于1.3.0，则用bin/logstash-vv来代替。1.3.3　设置文件示例

从Logstash 5.0开始，新增了$LS_HOME/config/logstash.yml文件，可以将所有的命令行参数都通过YAML文件方式设置。同时为了反映命令行配置参数的层级关系，参数也都改成用.而不用-了。

上小节的pipeline相关命令行参数，改用YAML文件的写法如下：pipeline: workers: 24 batch: size: 125 delay: 51.4　插件安装

从Logstash 1.5.0版本开始，Logstash将所有的插件都独立拆分成gem包。这样，每个插件都可以独立更新，不用等待Logstash自身做整体更新的时候才能使用了。

为了达到这个目标，Logstash配置了专门的plugin管理命令。

plugin命令用法说明如下：Usage: bin/logstash-plugin [OPTIONS] SUBCOMMAND [ARG] ...Parameters: SUBCOMMAND subcommand [ARG] ... subcommand argumentsSubcommands: install Install a plugin uninstall Uninstall a plugin update Install a plugin list List all installed pluginsOptions: -h, --help print help

首先，你可以通过bin/logstash-plugin list查看本机现在有多少插件可用。（其实就在vendor/bundle/jruby/1.9/gems/目录下。）

然后，假如你看到https://github.com/logstash-plugins/下新发布了一个logstash-output-webhdfs模块（当然目前还没有）。打算试试，就只需运行如下命令：bin/logstash-plugin install logstash-output-webhdfs

同样，假如是升级，只需运行如下命令即可：bin/logstash-plugin update logstash-input-tcp

bin/logstash-plugin不但可以通过rubygems平台安装插件，还可以读取本地路径的gem文件，这对自定义插件或者无外接网络的环境都非常有效：bin/logstash_plugin install /path/to/logstash-filter-crash.gem

执行成功以后。你会发现，logstash-5.0.2目录下的Gemfile文件最后会多出一段内容：gem "logstash-filter-crash", "1.1.0", :path =>"vendor/local_gems/d354312c/logstash-filter-mweibocrash-1.1.0"

同时Gemfile.jruby-1.9.lock文件开头也会多出一段内容，如下所示：PATH remote: vendor/local_gems/d354312c/logstash-filter-crash-1.1.0 specs: logstash-filter-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新手们很容易搞混淆的一个经典问题：commandcommand > /dev/nullcommand > /dev/null 2>&1command &command > /dev/null &command > /dev/null 2>&1 &command &> /dev/nullnohup 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 -list4.最推荐的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=5000mdirectory=/opt/logstashcommand=/opt/logstash/bin/logstash -f /etc/logstash/pro1.conf -w 10 -l /var/log/logstash/pro1.log[program:elkpro_2]environment=LS_HEAP_SIZE=5000mdirectory=/opt/logstashcommand=/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里最简单和基础的插件了。所以，在这段中，我们先介绍一些未来每个插件都会有的一些方法。

配置示例如下：input { stdin { add_field => {"key" =>"value"} codec =>"plain" tags => ["add"] type =>"std" }}

用上面的新stdin设置重新运行一次最开始的Hello World示例。我建议大家把整段配置都写入一个文本文件，然后运行命令：bin/logstash-f stdin.conf。输入“Hello World”并回车后，你会在终端看到如下输出：{"message" =>"hello world","@version" =>"1","@timestamp" =>"2014-08-08T06:48:47.789Z","type" =>"std","tags" => [ [0] "add" ],"key" =>"value","host" =>"raochenlindeMacBook-Air.local"}

type和tags是Logstash事件中两个特殊的字段。通常来说，我们会在“输入区段”中通过type来标记事件类型——我们肯定是提前能知道这个事件属于什么类型的。而tags则是在数据处理过程中，由具体的插件来添加或者删除的。

最常见的用法是像下面这样：input { stdin { type =>"web" }}filter { if [type] == "web" { grok { match => ["message", %{COMBINEDAPACHELOG}] } }}output { if "_grokparsefailure" in [tags] { nagios_nsca { nagios_status =>"1" } } else { elasticsearch { } }}

看起来蛮复杂的，对吧？

继续学习，你也可以写出来的。2.1.2　文件输入

分析网站访问日志应该是一个运维工程师最常见的工作了。所以我们先学习一下怎么用Logstash来处理日志文件。

Logstash使用一个名叫FileWatch的Ruby Gem库来监听文件变化。这个库支持glob展开文件路径，而且会记录一个叫.sincedb的数据库文件来跟踪被监听日志文件的当前读取位置。所以，不要担心Logstash会漏过你的数据。提示　sincedb文件中记录了每个被监听的文件的inode，major number，minor number和pos。

配置示例如下：input { file { path => ["/var/log/*.log", "/var/log/message"] type =>"system" start_position =>"beginning" }}

有一些比较有用的配置项，可以用来指定FileWatch库的行为：

·discover_interval：Logstash每隔多久去检查一次被监听的path下是否有新文件，默认值是15秒。

·exclude：不想被监听的文件可以排除出去，这里跟path一样支持glob展开。

·sincedb_path：如果你不想用默认的$HOME/.sincedb（Windows平台上为%USERPROFILE%\.sincedb，该变量默认值是：C：\Windows\System32\config\systemprofile），可以通过这个配置定义sincedb文件到其他位置。

·sincedb_write_interval：Logstash每隔多久写一次sincedb文件，默认是15秒。

·stat_interval：Logstash每隔多久检查一次被监听文件状态（是否有更新），默认是1秒。

·start_position：Logstash从什么位置开始读取文件数据，默认是结束位置，也就是说，Logstash进程会以类似tail-F的形式运行。如果你是要导入原有数据，把这个设定改成“beginning”，Logstash进程就从头开始读取，有点类似于less+F命令的形式运行。

·close_older：一个已经监听中的文件，如果超过这个值的时间内没有更新内容，就关闭监听它的文件句柄。默认是3600秒，即一小时。

·ignore_older：在每次检查文件列表的时候，如果一个文件的最后修改时间超过这个值，就忽略这个文件。默认是86400秒，即一天。

注意事项如下：

1）通常你要导入原有数据进Elasticsearch的话，你还需要filter/date插件来修改默认的“@timestamp”字段值。稍后会学习这方面的知识。

2）FileWatch只支持文件的绝对路径，而且会不自动递归目录。所以有需要的话，请用数组方式都写明具体哪些文件。

3）LogStash：：Inputs：：File只是在进程运行的注册阶段初始化一个FileWatch对象。所以它不能支持类似fluentd那样的path=>“/path/to/%{+yyyy/MM/dd/hh}.log”写法。达到相同目的，你只能写成path=>“/path/to/*/*/*/*.log”。FileWatch模块提供了一个稍微简单一点的写法：/path/to/**/*.log，用**来缩写表示递归全部子目录。

4）start_position仅在该文件从未被监听过的时候起作用。如果sincedb文件中已经有这个文件的inode记录了，那么Logstash依然会从记录过的pos开始读取数据。所以重复测试的时候每回需要删除sincedb文件。此外，官方博客上提供了另一个巧妙的思路：https://www.elastic.co/blog/logstash-configuration-tuning。把sincedb_path定义为/dev/null，则每次重启自动从头开始读。

5）因为Windows平台上没有inode的概念，Logstash某些版本在Windows平台上监听文件不是很靠谱。Windows平台上，推荐考虑使用nxlog作为收集端，参见后面5.5节。2.1.3　TCP输入

未来你可能会用Redis服务器或者其他的消息队列系统来作为Logstash Broker的角色。不过Logstash其实也有自己的TCP/UDP插件，在临时任务的时候，也算能用，尤其是测试环境。注意　虽然LogStash：：Inputs：：TCP用Ruby的Socket和OpenSSL库实现了高级的SSL功能，但Logstash本身只能在SizedQueue中缓存20个事件。这就是我们建议在生产环境中换用其他消息队列的原因。

配置示例如下：input { tcp { port => 8888 mode =>"server" ssl_enable => false }}

目前来看，LogStash：：Inputs：：TCP最常见的用法就是配合nc命令导入旧数据。在启动Logstash进程后，在另一个终端运行如下命令即可导入数据：# nc 127.0.0.1 8888 < olddata

这种做法比用LogStash：：Inputs：：File好，因为当nc命令结束，我们就知道数据导入完毕了。而用input/file方式，Logstash进程还会一直等待新数据输入被监听的文件，不能直接看出是否任务完成了。2.1.4　syslog输入

syslog可能是运维领域最流行的数据传输协议了。当你想从设备上收集系统日志的时候，syslog应该会是你的第一选择。尤其是网络设备，比如思科中syslog几乎是唯一可行的办法。

我们这里不解释如何配置你的syslog.conf、rsyslog.conf或者syslog-ng.conf来发送数据，而只讲如何把Logstash配置成一个syslog服务器来接收数据。

有关rsyslog的用法，后面的5.4节会有更详细的介绍。

配置示例如下：input { syslog { port =>"514" }}

作为最简单的测试，我们先暂停一下本机的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.mdflagwriter","pid" =>"381","severity" =>7,"facility" =>3,"facility_label" =>"system","severity_label" =>"Debug"}

Logstash是用UDPSocket、TCPServer和LogStash：：Filters：：Grok来实现LogStash：：Inputs：：Syslog的。所以你其实可以直接用Logstash配置实现一样的效果，如下所示：input { tcp { port =>"8514" }}filter { grok { match => ["message", "%{SYSLOGLINE}" ] } syslog_pri { }}建议在使用LogStash：：Inputs：：Syslog的时候走TCP协议来传输数据。

因为具体实现中，UDP监听器只用了一个线程，而TCP监听器会在接收每个连接的时候都启动新的线程来处理后续步骤。

如果你已经在使用UDP监听器收集日志，用下行命令检查你的UDP接收队列大小：# netstat -plnu | awk 'NR==1 || $4~/:514$/{print $2}'Recv-Q228096

228096是UDP接收队列的默认最大大小，这时候linux内核开始丢弃数据包了！强烈建议使用LogStash：：Inputs：：TCP和LogStash：：Filters：：Grok配合实现同样的syslog功能！

虽然LogStash：：Inputs：：Syslog在使用TCPServer的时候可以采用多线程处理数据的接收，但是在同一个客户端数据的处理中，其grok和date是一直在该线程中完成的，这会导致总体上的处理性能几何级的下降——经过测试，TCPServer每秒可以接收50000条数据，而在同一线程中启用grok后每秒只能处理5000条，再加上date只能达到500条！

才将这两步拆分到filters阶段后，Logstash支持对该阶段插件单独设置多线程运行，大大提高了总体处理性能。在相同环境下，logstash-f tcp.conf-w 20的测试中，总体处理性能可以达到每秒30000条数据！

注意　测试采用Logstash作者提供的命令：yes "<44>May 19 18:30:17 snack jls: foo bar 32" | nc localhost 3000出处见：https:// github.com/jordansissel/experiments/blob/master/ruby/jruby-netty/syslog-server/Makefile

如果你实在没法切换到TCP协议，可以自己写程序，或者使用其他基于异步I/O框架（比如libev）的项目。下面是一个简单的异步I/O实现UDP监听数据输入Elasticsearch的示例：https://gist.github.com/chenryn/7c922ac424324ee0d695。2.1.5　http_poller抓取

Logstash作为数据采集系统，也支持自己作为一个HTTP客户端去抓取网页数据或者接口数据。这方面有一个很明显的IT运维应用场景：很多业务系统软件本身提供了RESTful的内部运行状态接口，可以直接通过接口采集这些监控信息。

更长期的方案应该是编写对应的metricbeat模块，但是直接采用logstash-input-http_poller显然更快捷。

比如Nginx的性能状态，社区有一个非常全面的性能状态监控模块：nginx-module-vts。在新浪微博，后端池分为核心接口、非核心接口两块，我们要分别监控的话，nginx-module-vts的配置如下：

试读结束[说明：试读内容隐藏了图片]

下载完整电子书