Logstash：日志分析整合利器-logstash pipeline

【2013年9月5日 51CTO外电头条】要是系统上哪里出现了什么岔子，日志文件是寻找线索以便排除故障的头一个地方。Logstash是内置有分析工具的日志服务，它可以整合来自许多服务器的日志，甚至让这些数据易于搜索。

要是企业网络上任何环节出现了什么岔子，管理员就得马上找出问题，并解决问题。找到出错信息通常不是问题，毕竟大多数IT系统给出了源源不断的系统日志条目和出错消息，但要在包括众多设备、系统和服务器的复杂网络中正确地评估这些信息，却常常是说起来容易做起来难。

一个问题是生成的大量信息。一方面，诸如Pacemaker集群管理器这些工具特别啰嗦，显示的信息要比实际需要的信息多好多倍。另一方面，就Apache而言，要是管理员对它进行了设置，分开记录每个虚拟主机的日志，数据最后有可能跑到好多个地方。在为许多客户提供服务的Web服务器上，大量的日志文件会日积月累，这就意味着为某个用户排除具体问题可能是一项没完没了的任务。

依赖OpenStack、CloudStack或其他云平台的云计算环境拥有的服务器很少是少于20台的，服务器日志的数量会激增，与服务器系统的数量成正比。

通常采用的解决办法就是，在中央系统上由日志服务器收集日志，而不是任由日志散布于整个网络上。这个做法可以帮助你通过SSH在多台服务器之间浏览查找时，无需过于频繁地敲键。有些日志文件甚至为日志编制索引，以便搜索起来既快速又方便。像Splunk这些商用工具就提供了这种增值类型的日志服务。

面对这些商用日志工具，开源社区祭出的利器就是Logstash，这项中央日志服务提供了一种选择，可以通过Web界面来搜索现有的日志条目。

Logstash及其助手

严格来说，光凭Logstash无力确保对日志文件实行合理化、集中式的管理。执行任务时想取得预期的效果，Logstash就需要得到一些帮助。Logstash本身是个Java应用程序，尽管好多管理员对Java怀有种种偏见——无论这些偏见有没有道理，Logstash开发人员决定支持Java有其充分的事实根据。因为Java还安装在Windows上——这是理所当然的事，Logstash可以在日志文件库里面加入Windows日志文件；在许多情况下，换成其他的Rsyslog服务，就很难做到这一点。

Logstash的安装牵涉不止一台服务器，它由至少五个不同的服务组成。核心角色由Logstash的自有组件shipper来扮演：shipper基本上是在每个目标系统上运行的客户端，负责收集日志消息。下一步，shipper把日志消息发送给indexer，该组件负责按管理员指定的方式，解读和处理日志信息。indexer所在的主机通常还运行Logstash Web服务器，这为管理员提供了查找日志文件的搜索框。在后台，并不直接属于Logstash，但对其功能而言很重要的另外两个服务负责各自的任务，它们是Redis消息代理和ElasticSearch存储及搜索环境。

Redis为shipper与indexer之间的通信起到了关键作用。每台服务器上的Logstash实例将其消息传送到Redis服务器；在该服务器上，Logstash indexer在下一步中检索这些消息。ElasticSearch也是个Java应用程序，它在后台编制索引，并提供界面，以便Logstash Web服务器将来自Web界面的搜索请求转发至该界面。

模块化设计

Logstash的一大优点在于其多样性，这源自其模块化设计，因而让这个工具显得非常灵活：比如说就在几个月前，安装的Logstash使用AMQP代理来取代Redis还很常见——RabbitMQ是通常的选择。

不过，Logstash的amqp模块没有得到非常好的维护，也不是特别受Logstash开发者的欢迎。很容易实现改用另一种不同代理的决定，那是由于只需要为消息代理编写接口。与此同时，Redis连接器可以顺畅地工作，RabbitMQ遂成了明日黄花。

没有限制

在其他地方，Logstash对管理员的创造力几乎没有什么限制：这款工具不仅提供了通过已定义过滤器存档日志条目的功能，还提供了解读日志条目的功能，因为每一个日志条件都编入索引、易于搜索。

比如说，一接到请求，Logstash会管理HTTP日志，以后可以在Web界面中进行有条理的搜索，查找已引起“内部错误”的所有可能的查询。比如说，如果应用到Pacemaker，这意味着管理员可以明确搜索带ERROR前缀的Pacemaker日志消息。

还可以设计过滤器，完全去除日志记录中的各个条目。比如说，如果你想让典型的系统日志MARK消息不出现在日志存档中，只要改动Logstash shipper配置。

测试安装

如果你想试一试Logstash，那么你很走运。与网站上的描述恰恰相反，安装工作绝不是什么极为艰巨的任务。只要确保事先明确你将哪个角色分配给了哪个主机。一旦明确了Redis服务器、ElasticSearch和 Logstash indexer将运行哪个主机，你就可以准备上路了。下面这个例子基于Ubuntu 12.04，但也适用于Debian。网上也有面向典型企业发行版的Redis和ElasticSearch的RPM程序包，包括红帽企业级Linux（RHEL）和SUSE Linux企业级服务器（SLES）等发行版。

安装Redis有多容易，这在很大程度上取决于有没有适用你系统的Redis服务器程序包。在Ubuntu上，一个简单的命令：

apt-get install redis-server

即可安装相关组件。之后，建议修改/etc/redis/redis.conf中的127.0.0.1 bind条目，那样它含有该主机的IP地址。要不然，Redis只连接到本地主机，这会阻止其他主机将各自的Logstash消息直接发送到Redis。重视安全的那些管理员应该通过redis.conf里面的requirepass指令，设定一个访问密码。

安装ElasticSearch

ElasticSearch（见图1）是个类似Logstash的Java应用程序；遗憾的是，Ubuntu里面没有任何程序包。

图1：日志消息的组织和管理工作不是由Logstash来处理，而由在后台运行的ElasticSearch来处理。

幸好，可以从Upstream得到帮助，Upstream在其网站上为Ubuntu提供了预制的.deb程序包；它也可以通过dpkg –i来安装。由于未遇到依赖项，该命令起初返回了出错消息。执行了apt-get -f install命令后，ElasticSearch已准备就绪。

默认情况下，ElasticSearch还可以对127.0.0.1进行监听，所以indexer必须在同一个主机上运行。如果你想让ElasticSearch和Logstash索引服务在不同的主机上运行，就要在/etc/elasticsearch/elasticsearch.yml中找到必要的参数选项符；它们带有network.bind_host和network.host名称。

发送

下一步，你必须配置Logstash本身。Logstash并不以面向客户端和服务器的单个Java库这个方式出现，而是以涵盖所有服务的一个大文件这个方式出现，这很重要。下载了Logstash JAR文件（截至截稿为止，最新版本是1.1.9）后，你只要选择合适的参数就行了。

对shipper而言，你的shipper.conf file应该像是代码片段1中的那样。

代码片段1：shipper.conf

input{ 
file{ 
type=>"syslog" 
# 通配符在此适用：） 
path=>["/var/log/messages","/var/log/ 
syslog","/var/log/*.log"] 
} 
file{ 
type=>"apache-access" 
path=>"/var/log/apache2/access.log" 
} 
file{ 
type=>"apache-error" 
path=>"/var/log/apache2/error.log" 
} 
} 
output{ 
stdout{debug=>truedebug_format=>"json"} 
redis{host=>"192.168.122.165"data_type=> 
"list"key=>"logstash"} 
}

有了这种配置，Logstash会将来自系统日志文件和Apache的消息发送给“默认”虚拟域中的indexer。该示例中带indexer的主机是192.168.122.165。

第22行中的key可能让人觉得有点困惑；它不是指为验证身份而设置的密钥，而是指Redis所用的、作为Logstash队列名称的值。有了这个配置文件，

java -jar logstash-1.1.9-monolithic.jar agent -f shipper.conf

命令会启动Logstash。

索引

如果你从合适的配置开始入手，设置indexer也不复杂（代码片段2）。

代码片段2：Indexer.conf

input{ 
redis{ 
host=>"192.168.122.165" 
type=>"redis-input" 
data_type=>"list" 
key=>"logstash" 
format=>"json_event" 
} 
} 
output{ 
elasticsearch{ 
host=>"192.168.122.165" 
} 
}

Logstash配置因而分成了输入块和输出块——顾名思义，这两个块指明了某项服务如何得到消息、该服务在何处转发消息。

indexer用这个命令开始其日常工作：

java -jar logstash-1.1.9-monolithic.jar agent -f indexer.conf

较之shipper，indexer在标准输出通道中几乎不生成自己的任何输出，所以要是一切很平静，你用不着担心。

服务

最后，你需要Logstash Web服务器本身；它不需要自己的配置文件，可以用这个命令来开启：

java -jar logstash-1.1.9-monolithic.jar web --backend elasticsearch://192.168.122.165/

该命令运行后，你应该能够通过端口9292，立即登录到Logstash系统（见图2）。在这个例子中，完整的地址应该是：http://192.168.122.165:9292。

图2：在Logstash记录里面搜索“Network Manager”会显示按时间排序的消息。

在首次启动后，日志消息应该会立即开始出现（见图3）；此外，你可以通过搜索框来核实这个过程。这基本上算是Logstash安装过程的最后一个主要步骤。

图3：Logstash shipper的状态更新表明了软件在如何运行：它将收到的日志消息发送给Redis。

系统操作人员可以随意修改设置，以符合各自的需要。比如说，你通常希望启动时在所有系统上运行Logstash shipper，这意味着只要编写一个匹配的init脚本（如果你想避免自编脚本，可以在网上找到这方面的预定义脚本。）

还建议创建针对特定应用的过滤器，以便充分利用该解决方案的所有选项。供应商网站上概述了各种可能的Logstash过滤器选项（https://github.com/logstash/grok-patterns），它们也支持正则表达式，网站还有内容全面的说明文档。

结论

Logstash是一种非常精巧的中央日志解决方案。已经有Chef菜谱（Chef cookbook）和Puppet配方（Puppet recipe），这对平时维护庞大计算机集群，需要进行集中式配置文件管理的管理员来说特别有用。Logstash在这类环境下可以很容易地改动。不过，搜索日志时，Logstash确实可以大显身手。曾手动搜索成千上万行日志条目的管理员会发现，借助Logstash排除故障确实让人眼前一亮。只有对Java明显不感冒的管理员才无法认识到其真正的价值。

原文链接：http://www.linuxpromagazine.com/Online/Features/Consolidating-Logs-with-Logstash