日志的收集，处理和储存

Logstash负责日志的收集，处理和储存：

性能：Logstash 致命的问题是它的性能以及资源消耗（默认的堆大小是 1GB），它在大数据量的情况下会是个问题。
另一个问题是它目前不支持缓存，目前的典型替代方案是将 Redis 或 Kafka 作为中心缓冲池：

因为 Logstash 自身的灵活性以及网络上丰富的资料，Logstash 适用于原型验证阶段使用，或者解析非常的复杂的时候。在不考虑服务器资源的情况下，如果服务器的性能足够好，我们也可以为每台服务器安装 Logstash 。我们也不需要使用缓冲，因为文件自身就有缓冲的行为，而 Logstash 也会记住上次处理的位置。

如果服务器性能较差，并不推荐为每个服务器安装 Logstash ，这样就需要一个轻量的日志传输工具，将数据从服务器端经由一个或多个 Logstash 中心服务器传输到 Elasticsearch：

Collect：数据输入input

常用的input有：
file：从文件系统中读取文件，类似于[Linux]下的tail -0F。
syslog：监听在514端口的系统日志信息，并解析成RFC3164格式。
[redis]：从redis服务器读取，同时使用redis channel和redis list。

如果在程序方法中埋点，可以重写父类Exception，统一加上写入redis的操作

beats: 通过Filebeat发送事件。

Enrich：数据加工，如过滤，改写等

filter
filter是logstash管道中间处理的设备。可以结合条件语句对符合标准的事件进行处理。
一些有用的过滤器如下：
grok: 解析和结构化任何文本。Grok 目前是logstash最好的方式对非结构化日志数据解析成结构化和可查询化。logstash内置了120个匹配模式，满足大部分需求。
mutate: 在事件字段执行一般的转换。可以重命名、删除、替换和修改事件字段。
drop: 完全丢弃事件，如debug事件。
clone: 复制事件，可能添加或者删除字段。
geoip: 添加有关IP地址地理位置信息。

output：数据输出

output是logstash管道的最后一个阶段。一个事件可以经过多个output。但是一旦所有输出处理完，该事件已经执行完。
常用的output有：
elasticsearch: 发送事件数据到 Elasticsearch。如果要将数据保存在一个高效、便捷、易于查询的格式，elasticsearch将是不二人选。
file: 将事件数据写入到磁盘文件上。
graphite: 发送事件数据到graphite。http://graphite.wikidot.com/
statsd: 发送事件数据到 statsd。

Paste_Image.png

Shipper：日志收集者。负责监控本地日志文件的变化，及时把日志文件的最新内容收集起来，输出到Redis暂存。
Indexer：日志存储者。负责从Redis接收日志，写入到本地文件。
Broker：日志Hub，用来连接多个Shipper和多个Indexer。
无论是Shipper还是Indexer，Logstash始终只做前面提到的3件事：

Shipper从日志文件读取最新的行文本，经过处理（这里我们会改写部分元数据），输出到Redis，
Indexer从Redis读取文本，经过处理（这里我们会format文本），输出到文件。

文／怡文圣美（作者）
原文链接：http://www.jianshu.com/p/6575041b597d
著作权归作者所有，转载请联系作者获得授权，并标注“作者”。