James Turnbull，通过对日志管理项目情境中的Logstash实施细节的介绍，给了读者信服的理由去使用Logstash进行集中化的日志管理。 《Logstash》一书通过一个双面案例（two side case）从不同方面进行介绍，其低准入门槛适合小企业使用，其扩展能力使其也能满足大企业的需求。今年二月，James在Hangops会议上谈到本书， “它主要面向那些以前没有见过LogStash的人，如系统管理员、开发人员、DevOps以及运维人员。我希望此书读者对Unix或Linux有一定了 解。”他继续说道，“另外，本书假定用户无任何关于LogStash的先验知识（Prior Knowledge）。”
日志管理简化过程中的问题
James本人具有系统管理员和安全的相关背景。他先阐述了计算环境是如何使日志管理进化成为无法扩展的方式。
他介绍到，通常日志管理是是逐渐崩溃的——当日志对于人们最重要的时候，也就是出现问题的时候，这个渐进的过程就开始了。在这时，新管理员将通过一 些传统工具对日志进行检查，如cat、tail、sed、awk、perl以及grep。这种做法有助于培养在常用工具方面的优秀技能，但它的适用范围仅 限于少量的主机和日志文件类型。考虑到现实中的可扩展性问题，团队也会逐步进化，使用如rsyslog和syslog-ng这样的工具进行集中化的日志管 理。
James介绍到，当用户通过这种方式着手处理扩展性问题时，其实并没有真正解决日志管理的问题——因为现在的日志事件仅仅考虑不同类型、不同格式 以及不同时区，其数量就已经相当可观，并且基本上都缺乏合适的情境以方便理解它们。团队最后通过日志管理相关技术改造他们的计算环境，从而处理大量存储、 搜索、过滤等等。不幸的是，最终，这种方式的问题凸显出来：不仅成本较高，而且造成了大量的浪费。和传统系统管理员使用的工具一样，LogStash通过 降低进入门槛，节省了大量时间，但其架构完全能够扩展以满足大型网络部署的要求。
LogStash架构概述
LogStash架构专为收集、分析和存储日志所设计。此外，LogStash所实现的主要交叉用例之一是对所管理的日志事件进行查看/搜索。 James建议通过开源项目Kibana对事件进行搜索操作。本月早些时候，Jordan Sissel，LogStash的创作者，在Twitter上发布了一条微博，内容为“LogStash每日构建的最新版本中附带了Kibana3：java -jar logstash.jar kibana”，James和Jordan都提到了Kibana，因为它提供了用户友好的搜索界面，并与Elasticstorage，即 LogStash的搜索引擎进行了集成。以下是一些Kibana的截图，它们摘自于《LogStash》一书的第3章，各位读者还可以访问在线演示：
（点击图片放大）
除了查看日志外，它自身的组件架构支持通过代理对不同服务器的日志流进行管理，并最终传送至存储中。James带领读者们，以LogStash开箱 即用的配置为基础，对默认配置中的各个组件进行探索。LogStash默认配置中使用的Redis是一个开源Key/Value数据库，用于在索引前队列 化日志。它同时还使用Elasticsearch存储日志，并作为查看系统的后端。下图摘自第3章，展示了架构中各种组件类型，包括Shipper、 Broker、Indexer以及Viewer。
在这本书中，James深入介绍了LogStash实例中的三个主要功能：事件输入、事件数据过滤以及事件输出。LogStash的这三个功能是根 据配置信息执行的，这些信息存储在简单易懂的“.conf”文件中。 “.conf”文件中有不同的配置节对应LogStash所使用的三种不同类型的插件 输入（input）、过滤器（filter）以及输出（output）。每个LogStash实例都是根据它在整体架构中的角色需求进行定制的。 比如下面是摘自本书第3章的某个Shipper的配置（包括一个输入和两个输出）：
input {
redis {
host => "10.0.0.1"
type => "redis-input"
data_type => "list"
key => "logstash"
}
}
output {
stdout {
debug => true
}
elasticsearch {
cluster => "logstash"
}
}
开源的LogStash符合DevOps文化
LogStash是个可自由使用的开源工具，适合在开源工具的生态系统中工作，它很有意义，因此James专门为它编写了一本书，因为他是一个自称 “开源极客”。LogStash生态系统中，在命令行下，所有的工具都是可安装的（Installable）、可配置以及可管理的管理的，是理想的自动化 方案。在整本书中，Jame明确地指出，在理想状况下，应当通过一套自动化配置管理系统来管理LogStash各个组件的安装、配置。然而，自动化配置的 主题超出了本书的范围，所以作者退而求其次，通过对LogStash组件的介绍使大家理解如何对其进行安装和配置。如果配合对自动化的理解，读者就能够无 缝构建出多种环境。通过这种方式，能够够灵活的适应项目不同阶段中各类环境的部署，如Q&A、故障排除等，并支持持续交付。
安装Java、LogStash、Redis以及Elasticsearch等
James逐步展示了安装LogStash的过程是多么的简单，它所依赖的组件也一样。同样，Jordan Sissel提出了LogStash项目原则中的一条：“社区：如果新手的日子不好过，那么这就是个Bug。”LogStash依赖于Java，所以要运 行LogStash，至少要安装OpenJDK。大部分Linux发行版中都包含了OpenJDK可以通过包管理系统启用。比如在Red Hat/CentOS中，使用命令“sudo yum install java-1.7.0-openjdk”进行安装，而在Debian/Ubuntu中，命令则是“sudo apt-get install openjdk-7-jdk”。Jordan Sissel以单一的Jar文件方式分发LogStash，可以从LogStash.net主页上 获取。在OpenJDK环境下，只需要在命令行上指定Jar文件地址以及配置文件地址就可以运行LogStash了。Redis的安装就更加容易了，使用 包管理系统安装，和OpenJDK安装类似，在Debian/Ubuntu系统中，使用命令“sudo apt-get install redis-server”，而在Red Hat/CentOS中则是“sudo yum install redis”。在Redis开始进行事件处理前，需要对“/etc/redis/redis.conf”中的一些配置设置进行修改，然后以服务的形式启动 Redis。Elasticsearch和LogStash类似，只需要预先安装Java。如需下载Elasticsearch， 对于Debian/Ubuntu等Linux系统，可以下载“.deb”安装包，而对于Red Hat/Centos等的Linux系统则是“.rpm”安装包。它也要对“/etc/elasticsearch /elasticsearch.yml”进行少量的配置后才能启动。
LogStash组件：Shipper、Broker、Indexer
本书涵盖了LogStash的三种插件类型，并介绍了它们在Shipper和Indexer中的使用方法。James展示了下述输入插件在 LogStash的使用方法：文件、标准输入（stdin）、Syslog、Lumberjack以及Redis。对于那些无法安装LogStash的环 境，也可以通过其他它选件发送事件，从而与LogStash集成，如Syslog、Lumberjack、Beaver以及Woodchuck。在 LogStash的输入输出插件之间，可能会存在交集，比如对于Redis，就同时具有输入和输出两个插件。除了介绍两个主要的输出Redis和和 Elasticsearch外，James还介绍了通过集成其他系统进行输出，包括Nagios、邮件告警、即时消息以及 StatsD/Graphite。这本书中介绍了grok、date、grep以及multiline等过滤器。James向读者展示了使用通过过滤插 件，实现对Postfix日志及Java应用程序日志的高效处理。在某些情况下，日志可以在输入到LogStash前进行过滤，比如Apache日志管理 能够自定义日志格式，可以以JSON格式的进行记录，这样LogStash就可以在不使用内部过滤器插件的情况下，方便的进行处理。Redis，就是我们 所指定的Broker，用于进行事件流管理，在该角色中，LogStash还支持其他的队列技术：AMPQ和ZeroMQ。搜索/存储的路由工作由 LogStash的Indexer实例负责执行。
LogStash的扩展
扩展LogStash要实现三个主要目标：弹性、性能和完整性。下图是摘自于本书第7章，它所描述的是对Redis、LogStash以及Elasticsearch的扩展：
LogStash不依赖Redis进行自身的故障转移管理，而是与此相反，LogStash将根据预先配置的两个Redis实例，将事件发送到其中 一个Redis实例中。如果该Redis实例变为不可用，LogStash就会开始将事件发送到已配置的另一个Redis实例中。作为 Indexer，LogStash可以轻松的实现扩展：通过创建多个实例，并不断地从所有可用的Broker拉取数据，并输出到 Elasticsearch。在这种设计中，事件只能传输到一个Broker，所以从LogStash的Indexer传输事件到 Elasticsearch的过程中，应当是没有重复事件的 。当用户安装多个实例并配置信息中设置有公用的配置时，Elasticsearch能够方便的自行建立群集。它采用组播、单播技术或使用EC2插件，根据 各个独立实例的配置设置自行建立群集。只要在网络允许的情况下，实例间将会自行通讯，将会自行建立群集，随后开始在群集节点之间分割数据。数据分区将会自 动提供弹性和性能。
InfoQ同时就LogStash对James Turnbull进行了采访。
InfoQ：在LogStash集中化日志管理系统的成功的商业案例中，您认为效益和成本应该是什么样的情况？
James：LogStash的好处和众多开源系统管理工具一样：较低的软件成本、开源、今后可扩展、快速的开发和Bug修复、拥有极好的社区开发 解决方案、互相帮助以及帮助用户形成解决自身问题的发展蓝图。所需成本也和大多数开源工具差不多：没有商业支持、并非功能齐全的商业替代品、可能有较高的 进入门槛，在实施时，同时要求用户有一定的技能并且官方提供了可用的文档（尽管现在用户有了一本很棒的书！）。
InfoQ的：以DevOps为导向的技术团队为什么要选择开源工具LogStash系统，而不是选择像Splunk这样的商业工具？
James：对于DevOps团队而言，这种选择的主要驱动力是成本。 虽然LogStash（及其控制面板Kibana）的（还）不是Splunk的对手，但它们都是免费的，并能够迅速的获得功能和特性。但是使用 Splunk需要支付一定的费用，很多规模较小的企业不一定能负担得起。当然，需要注意的是，虽然这个软件是免费的，但仍然会有实施成本，而与商业工具相 比，很难说成本有多少。
InfoQ：在日志管理方面，有什么最简单易懂而且有用的用例吗？ 如果对于企业中的不同角色有所不同，能请您介绍一些具体有哪些不同吗？
James：日志管理的最好用例是故障排除和监控。当用户的基础设施出现问题时，应用程序的日志数据往往是最好的信息来源。日志同时也是极好的数据 源，可以用于监控基础设施的状态和时间，还可以用于构建指标以展示应用程序的运行状态。 这就是说，在企业中的不同团队关心的是日志管理用例的不同方面。比如，运营团队专注于故障排除以及能够提供性能数据日志。应用程序开发人员则很有兴趣使用 日志输出来发现并修复错误。安全团队专注定位日志数据中突出显示的漏洞和安全事件。
关于书籍作者：
James Turnbull是6本有关开源软件的技术书籍作者，并且是开源社区的长期成员。 James编写了第一本（以及第二本）关于Puppet的书籍，并为Puppet Labs运营运维和专业服务。James经 常在OSCON、Linux.conf.au、FOSDEM、OpenSourceBridge、DevOpsDays和其他一些会议上发表演讲。 他是Linux Australia前任总裁，曾是Linux Victoria前委员会成员，负责2008年的Linux.conf.au大会，并担任Linux.conf.au和OSCON.Y的委员会职位。
查看英文原文：Interview and Book Review: The LogStash Book, Log Management Made Easy
