Logstash

Logstash

1、简介

          Logstash是一个用ruby写的收集日志的工具，通过部署在应用程序运行节点上的agent来收集、解析、过滤日志，然后将过滤出的日志分发到各个目的地，目的地可以是文件，甚至是一个系统，比如opentsdb、elasticsearch等。业界对于日志管理的方法通常是logstash+elasticsearch+kibana(ELK)，其中logstash收集日志，elasticsearch存储、索引日志数据，kibana对数据进行可视化。ELK方式使得日志管理变得非常简单。

2、主要概念

2.1、Input

         Input表示的是进入logstash数据处理流水线的数据的数据源，比如文件、命令行、ganglia、网络等，logstash并没有限制哪些可以作为数据源(只提供了一些较常用的数据源，但是已经能满足绝大部分场景了)，而是提供了一个插件的形式允许用户自己定义数据源，如果已存在的数据源实在不能满足你的要求，那你自己实现一个便是，只要满足特定的规范，使得从你的数据源来的数据能进入logstash内部的数据流水线便可。所以，理论上来说，logstash支持任意的数据源。

2.2、Filter

          Filte表示的是对从数据源来的数据进行过滤的逻辑，可以定义多个filter，运行时会将多filter组织成一个filter链，顺序过滤下来。Filter也是一种插件的形式，所以你可以定义自己的filter实现，以期对filter进行更加细粒度的控制，满足你刁钻的过滤逻辑。

2.3、Output

          Output表示的是过滤出的数据将要发往的目的地，比如Opentsdb。Output也是以插件的形式提供的，允许用户自定义，所以理论上来说，你可以将你的日志数据发往任何地方。不过，常用的就那么些，已经实现的output已经包含了很多可能，基本不需要用户去实现自己的output，除非目的地是你自己做的一个存储系统，比如necaso，呵呵，那你就只有自己去定义output了。

3、配置文件

         Logstash配置文件的上层逻辑很简单，但是深入到某个filter怎么配、正则表达式怎么写就比较烦了(通常要写正则来过滤)，如果你正则表达式写得很溜的话，相信会很喜欢logstash的配置方式。Logstash配置文件的顶层抽象如下：

       input{

              ……

       }

       filter{

……

}

output{

              ……

}

再附上我们项目的配置，供参考：

input {

  file {

 path=> ["/opt/app/datafeed/datafeedv2/logs/datafeedv2.log","/home/ECHVservice/datafeed-shec/fullexport-0.0.1/logs/export.log","/opt/app/datafeed/increment-0.0.1/logs/*"]

}

#stdin{}

}

 

filter {

 

  grok {

     patterns_dir => "patterns"

     match=>["message", "%{METRICS_PREFIX}%{METRICS_KEY:key}%{METRICS_EQUAL}%{METRICS_VALUE:value}%{METRICS_PROPERTY_SPLIT}%{METRICS_TAG_PREFIX}%{METRICS_TAG_VALUE:tag_value}%{METRICS_TAG_SUFFIX}%{METRICS_SUFFIX}" ]

                  add_field=>{"metrics_output"=>"%{key},%{value},%{tag_value}"}

  } 

}

 

output {

if "_grokparsefailure" not in [tags]{

 neweggOpentsdb {

    host => "10.16.40.36"

    metrics => ["%{metrics_output}"]

}

}

stdout { codec => rubydebug }

}

对于filter和output的配置，可以在其中加入一些判断逻辑，形如(以上给出的示例配置的output中也用到了这个语法)：

If  EXPRESSION {

  ...

} else if  EXPRESSION {

  ...

} else {

  ...

}

 

EXPRESSION表达式支持相等性、正则表达式以及in、not in语法。在output中使用这个语法就可以实现将不同类型的日志事件发到不同的目的地去了，比如你有这样的需求：app1的日志放到opentsdb，app2的日志放到elasticsearch。在filter中使用这样的语法就可以实现将满足某些特定条件的事件用特定的filter处理的场景。

Logstash中的事件其实是形如key-Value对的集合，说不定内部就是一个hash，每个key相当于一个field;在配置文件中是可以引用到这些field的，语法是[fieldname]，最外层的field不用写中括号直接写field的名称来引用，但是嵌套的field就必须写上中括号，当然在配置文件中可以用一些filter来添加、删除、修改field，默认有三个field从input传过来：message、timestamp、version，最主要的是message，之后的filter基本都是对这个message进行处理(其他input的message是怎样的不了解，但是file这个input的message就是一行文本，默认file input一次只读一行，当然可以设置读多行当做一个事件)。

4、事件的生命周期

       事件的生命周期也相当于前面提到的数据流水线，因为数据是绑定在事件上的。

4.1、事件流水线

      Logstash内部的事件通道有3个阶段：inputs→filters→outputs。其中inputs生成事件，将数据绑定在事件上；filters过滤、修改事件；outputs分发事件。每个阶段之间是一个存放事件的有界阻塞队列，默认的容量是20(为什么不能设得大一点？主要是为了避免logstash成为一个存储系统，所以不能长期存储事件)。

4.2、容错

         当下游某个output出错的时候，该出错的output不会再从filters与outputs之间的队列读事件，所以导致该队列会逐渐增大，等达到最大限制20后，filters不能再往队列中放事件，也不能再从inputs→filters的队列中取事件，进而导致这个队列也满了，最后使得inputs不再产生事件。此时，只有等到下游output恢复正常后，事件流水线才能再次流动起来。

4.4、线程模型

         简要画了一个Logstash的线程模型图：

 

     Logstash将每一个input当做一个线程来处理，有多少个input就会有多少个input thread。Filter worker可以有多个(默认一个)，每个filter worker线程处理所有的filter逻辑，上文提过，多个filter是组织成一个链式结构的，根据在配置文件里的顺序，依次过滤下来。Output worker线程只有一个，多个output之间也是根据配置文件的配置顺序链接起来的。

                                                          

5、总结

      以上，就是我目前对于logstash了解到的程度。感受就是，logstash是一个还算比较简单的系统，架构并不复杂；只可惜使用ruby实现的，不能随心所欲的读源码，以期了解更深入一点；但是了解了它的设计之后，觉得自己也可用擅长的java实现之(不过，想要在短期之内实现logstash已有的众多input、filter、output还是有一定难度，呵呵)。