个人专题目录
Logstash介绍
Logstash是一个开源的数据收集引擎，具有实时管道传输功能。Logstash可以动态地统一来自各种数据源的数据，并将数据正常化(normalize)后存入你所选择的目的地。整理并民主化(democratize)你的所有数据，用于各种高级的下游分析和可视化显示。
Logstash的威力
- Elasticsearch的摄入主力
- 可水平扩展的数据处理管道，能够与Elasticsearch和Kibana高度协同。
- 可插入管道架构
- 混合、匹配和协调各种不同的输入、过滤器和输出插件，让它们在管道之内和谐地运行。
- 社区扩展插件以及开发者友好插件组成的生态系统。
- 有200个插件可供使用，此外，你可以灵活地创建和共享自己的插件。
日志和测量数据(Metrics)
-
处理各种日志数据
- 轻易地摄入各种网页日志，比如Apache，以及应用程序日志，比如用Java实现的log4j
- 捕获许多其它日志格式，比如 syslog, Windows event logs, 网络传输和防火墙日志，等等
-
通过Filebeat，你能获取额外的安全的日志转发功能
-
通过TCP 和 UDP从Ganglia、collectd测量数据(Metrics)。 NetFlow、 JMX和许多其它软件基础设施以及应用程序平台 over TCP and UDP
-
Logstash携带了许多汇聚和转换插件，具有模式匹配、地理位置映射、以及动态查询功能。
-
Grok是Logstash过滤器的面包与黄油，广泛地用于将非结构型数据转换成结构性数据。拥有大量的、集成好的匹配模式(patterns)，用于快速地帮助解析网页、系统、网络流量以及其它类型的事件格式。
-
通过从IP地址解析出地理位置坐标、正常化日期、简化key-value pairs和CSV数据、藏匿敏感信息 以及通过本地查询或Elasticsearch 查询， 来扩展你的视野。
要想测试你的Logstash安装是否正常，请运行下面这个最基本的Logstash管道:
cd logstash-{logstash_version} bin/logstash -e 'input { stdin { } } output { stdout {} }'
Logstash处理管道
Logstash的事件处理管道有三个阶段: 输入阶段(inputs) → 过滤器阶段(filters) → 输出阶段(outputs)。inputs产生事件，filters修改事件，outputs将事件搬运到其它地方。inputs和outputs都支持编解码操作(codecs)，它让你能够对进入管道或离开管道的数据进行编码或解码，而不用使用一个单独的过滤器。
容错
Logstash利用内部的、用Ruby实现的队列，SizedQueue，将事件逐个阶段传递。SizedQueue有最大容量。当该队列达到其最大容量时，所有对该队列的写操作都会被阻塞。
Logstash将每个队列的大小设置为20。这意味着，等待进入下一个阶段的事件，最多允许20个，这么做有助于防止数据丢失，而且让Logstash扮演着数据存储系统的角色。这些内部队列并不是用于长久地存储消息的。
小的队列大小 意味着 Logstash在遇到高负载或者临时性管道问题时，简单地阻塞队列，并安全地暂停。另外一个选择是，让队列大小无限制，这样，在遇到问题时，就会丢弃一些消息。无限队列可能导致该队列无限地增长，最终超过内存容量，导致程序崩溃，因此丢失所有排队中的消息。在大多数情况下，彻底丢弃消息同样是不可取的。
output可能会由于下游问题而失败或者遇到故障，比如磁盘满了，权限问题，临时网络故障或者服务中断。大多数outputs都会不断地重试搬运 那些受故障影响的事件。
如果某个 output 失败，那么该output的线程就会等待，直到该output能够成功地发送该消息。该output会停止从output队列中读取事件，这意味着该队列会被塞满事件。
当 output队列满了时，过滤器就会被阻塞，因为它们不能将新的消息写入该output队列。filters由于阻塞无法写入output队列，因此它们停止从filter队列读取。最终，这会导致 filter queue (input → filter)被塞满。
被塞满的filter队列 会阻塞住inputs，让inputs无法写入filters。这会导致所有的 inputs 停止处理来自数据源的数据。
在理想的情况下，这种表现行为类似于tcp时间窗口接近0的情形。不会在发送新的数据了，因为接收机还没有处理完当前队列中的数据，但是，一旦下游(output)问题被解决，消息又可以开始流动了。
线程模型
目前，Logstash中的线程模型如下:
input threads | filter worker threads | output worker
Filters是可选的，因此，如果你没有定义filters的话，该模型就很简单了：
input threads | output worker
每个input都在它自己的线程中运行。这么做可以防止繁忙的inputs被其它缓慢的inputs阻塞。此外，也便于管理，因为每个input都有一个线程。
filter线程模型是一个worker模型，在该模型中，worker接收事件，在将事件发送到output队列之前，将该事件按顺序地应用于所有过滤器。 这么做可以通过CPUs来扩容，因为许多filters是CPU密集型(允许我们提供线程安全)。
过滤器workers的默认数量是1，但是你可以通过在启动Logstash agent时 使用-w参数标记 来提高该数字。
目前，output worker模型，是一个单线程。Outputs按照配置文件中指定的outputs的顺序来接收事件。
Outputs在发布事件之前，可以临时性地缓存一下。这样的例子之一是： elasticsearch output，它会缓存多个事件，然后用一个单独的线程一次性地将它们清洗出去。这种机制(缓存许多事件，然后用一个单独的线程写出去)可以增强性能，因为因为这么做可以防止 Logstash管道被"等待来自elasticsearch的响应"所延迟。
资源使用
通常情况下，Logstash至少有3个线程(如果没有过滤器的话，就是2个)。一个input线程，一个filter worker线程，以及一个output thread线程。如果你明白Logstash是如何使用多个CPU的，那么这就是至少3个线程的原因。如果你想要知道关于每个线程正在做什么的更多信息，你应该阅读这篇文章: 调试Java性能。在Java中，线程都有名字，你可以使用jstack 和 top 来找出谁在使用什么样的资源。
在Linux平台上，Logstash会尽力 用一些描述性信息 将所有线程打上标签。比如，inputs显示成<inputname，filter workers显示成|worker，而outputs显示成>outputworker。如果可能，其它线程也会被打上标签，帮助你标识它们的目的，你可能想知道为什么它们正在消耗资源!
示例
71.141.244.242 - kurt [18/May/2011:01:48:10 -0700] "GET /admin HTTP/1.1" 301 566 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3"
134.39.72.245 - - [18/May/2011:12:40:18 -0700] "GET /favicon.ico HTTP/1.1" 200 1189 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2; .NET4.0C; .NET4.0E)"
input {
file {
path => "/tmp/access_log"
start_position => "beginning"
}
}
filter {
if [path] =~ "access" {
mutate { replace => { "type" => "apache_access" } }
grok {
match => { "message" => "%{COMBINEDAPACHELOG}" }
}
}
date {
match => [ "timestamp" , "dd/MMM/yyyy:HH:mm:ss Z" ]
}
}
output {
elasticsearch {
hosts => ["localhost:9200"]
}
stdout { codec => rubydebug }
}
bin/logstash -f logstash-apache.conf
网友评论