全方位立体监控之日志解决方案ELK（2）

Logstash详细介绍

下面我们将对ELK框架进行深入详细的了解，了解了其中的原理，才能选择更加高效可靠的配置方案。ElasticSearch的配置比较简单，主要性能瓶颈在于内存以及节点设置方面，Kibana的配置也较为简单，web应用无很大的优化改进空间，主要在于第三方插件的使用。下面我们主要介绍Logstash的方案设计。

Logstash使用Ruby语言编写，它编写了自己的一套DSL。Logstash在处理数据的时候，就像管道一样，每一个配置文件中都必须存在一个input插件和一个output插件，数据以流的形式在管道中进行传输。下面我通用一个图例来表示，日志数据就像是大小形状不同的图案，通过nput进入到管道内部，然后通过一个圆形的filter插件，这样从output出来的数据就都成为了圆形。所以一个标准的Logstash配置，应该同时存在一个nput，filter，output配置。

通过官方文档我们可以看到，由于开放的社区环境，logstash中存在大量的插件，功能丰富且强大。可以接受多种形式的数据，进行多样性的处理，最后传输到各种各样的环境中。下面我们结合实际情况，介绍一些常用的插件。

• 情景：需要监控Apache等生成的日志，可以动态监控文件内容。
  解决方案：
  监控文件内容，使用input:file插件。Logstash中使用一个名叫FileWatch的Ruby Gem库来监听文件变化，并且会生成一个${Home}/.sincedb的数据库文件来记录被监听的日志文件的当前读取位置。具体实现如下：

input {
    file {
            type => “apache”
            path => "apache_access.log"
            start_position => "beginning"
            sincedb_path => "/dev/null"
    }
}

type：通过type字段来表示这个日志的类型或者归属等特性，用来进行区分。
path：指定需要监控的文件，可以使用*号来表示某个路径下的所有满足条件的文件。
start_position：默认为”beginning”，表示每次Logstash重启后文件都从头开始加载，直到当前监控的位置。”end”选项表示，每次读取文件都从最后开始，接收当前传输的最新的文件。
sincedb_path：指定.sincedb文件的位置。每次logstash读取数据时会从since_db中记录的pos开始读取数据。如果在重复测试的时候，为了方便，可以将sincedb_path定义为/dev/null，这样logstash每次重启时都会从头开始读取文件。

• 情景：获取到日志文件后，需要对数据进行提取，最终以key-value字段的形式显示，便于Elasticsearch对数据进行索引，方便后期Kibana生成图表等。
  解决方案：
  使用filter:grok插件对数据进行提取。因为logstah会根据事件传输的当前时间自动给事件加上@timestamp字段，后续elasticsearch会根据该字段对事件进行排序。如果需要将日志中的事件抽取为@timestamp字段，还需用到filter:date插件。
  假设当前日志为log4j打印日志的格式为：

  %d [%p] [%c{1}] [%t] %30.30C.%M():%L - %m%n

  具体实现如下：

   filter {
    if [type] == "log4j" {
        grok {
            match=>["message",
"(?m)%{
    TIMESTAMP_ISO8601:timestamp}\[%{
    LOGLEVEL:logLevel}\] \[%{
    WORD:method}\] \[%{
    GREEDYDATA:thread}\] %{
    GREEDYDATA:javaClass}\(\)\:%{
    NUMBER:line} - {
    GREEDYDATA:message}"]
            remove_field => ["@version"]
            overwrite => [