logstash pipeline 模式说明

Multiple Pipelines

# 当要在一个实例中运行多个管道时可通过 pipelines.yml 实现（采用 logstash -f 方式运行的实例是一个管道实例）
# 为更方便管理，配置文件中使用一个 *.conf (input->filter->output) 文件对应一个pipeline（即path.config字段）
# 在不带参数情况下启动Logstash时默认读取 pipelines.yml 并实例化其中指定的所有管道
# 当使用 -e 或 -f 启动时将忽略 pipelines.yml 并记录警告，并且每个Logstash的实例也意味着一个独立的JVM ...

# ------------------------------------------------------------------------------------

- pipeline.id: nginx_local      # 唯一标识，用于区分不同pipeline （Kibana端monitor也会使用此ID进行区分）
  pipeline.workers: 4           # 建议该值=CPU核心数/管道数
  pipeline.batch.size: 512      #
  path.config: "/usr/local/pkg/logstash/conf.d/nginx_local.conf"    # 每个不同id位的conf生效文件。使用绝对路径
  queue.type: persisted

- pipeline.id: nignx_kibana     # 若所有conf文件都使用相同id则input流就会流进各个output。从而导致所有Index数据一致
  pipeline.workers: 4           #
  pipeline.batch.size: 256      #
  path.config: "/usr/local/pkg/logstash/conf.d/kibana_nginx.conf"   # 每个不同id位的conf生效文件。使用绝对路径
  queue.type: persisted

# 说明：
# 上例中nginx_local和nignx_kibana作为独立的管道执行，且配置也可以独立设置，互不干扰


# 测试：
bin/logstash --config.reload.automatic
# 若当前配置的事件流不共享相同的输入、过滤器、输出，并且使用标记和条件将它们彼此分离，那么使用多个管道尤其有用
# 在一个实例中有多个管道还允许这些事件流具有不同的性能和持久性参数（例如管道woker和持久队列的不同设置）
# 这种分离意味着一个管道中的阻塞输出不会对另一个管道产生反压力
# 也就是说考虑管道之间的资源竞争是很重要的，因为默认值是为单个管道调优的
# 因此考虑减少每个管道使用的管道worker数是很重要的，因为默认每个管道每个CPU核心将使用1个worker
# 每个管道都隔离了持久队列和死信队列，它们位置的命名空间为pipeline.id值

Example

# ------------------------------------------------------------------------------  管道到管道

# 在同一个Logstash实例中的管道和管道之间使用pipeline输入和pipeline输出连接在一起
# 当事件通过管道发送时其数据被完全复制。下游管道中事件的修改不会影响任何上游管道中的事件
# 注：数据的复制会增加额外的性能消耗，例如会增大JVM Heap的使用
- pipeline.id: upstream
  config.string: input { stdin {} } output { pipeline { send_to => VirtualAddress } }     # 唯一的虚拟地址
- pipeline.id: downstream
  config.string: input { pipeline { address => VirtualAddress } }

# ------------------------------------------------------------------------------ 多个管道使用同一个输入管道

# 在一个管道处理输入，然后根据不同的数据类型再分配到对应的管道去处理
# 此模式优点在于统一输入端口，隔离不同类型的处理配置文件，减少通过配置文件混合在一起带来的维护成本
- pipeline.id: beats-server
  config.string: |
    input {
        beats {
            port => 5044
        }
    }
    output {
        if [type] == apache {                           # 判断
            pipeline { send_to => weblogs }             # 发送到监听在weblogs的管道
        } else if [type] == system {                    # 判断
            pipeline { send_to => syslog }              # 发送到监听在syslog的管道
        } else {                                        # 默认
            pipeline { send_to => fallback }            # 发送到监听在fallback的管道
        }
    }
- pipeline.id: weblog-processing
  config.string: |
    input { pipeline { address => weblogs } }
    filter {
        # Weblog filter statements here...
    }
    output {
        elasticsearch { hosts => [es_cluster_a_host] }
    }
- pipeline.id: syslog-processing
  config.string: |
    input { pipeline { address => syslog } }
    filter {
        # Syslog filter statements here...
    }
    output {
        elasticsearch { hosts => [es_cluster_b_host] }
    }
- pipeline.id: fallback-processing
    config.string: |
    input { pipeline { address => fallback } }
    output {
        elasticsearch { hosts => [es_cluster_b_host] }
    }

# ------------------------------------------------------------------------------ 输出隔离器模式

# 虽然Logstash的一个管道可配置多个输出，但这多个输出会相依为命
# 一旦某个输出有问题会导致另一个输出也无法接收新数据，而通过这种模式可以完美解决这个问题

- pipeline.id: intake
  queue.type: persisted                     # 持久队列
  config.string: |
    input {
        beats {
            port => 5044
        }
    }
    output {
        pipeline {
            send_to => [es, http]           # 通过输出到两个独立的管道来解除相互之间的影响 !
        }
    }
- pipeline.id: buffered-es
  queue.type: persisted                     # 
  config.string: |
    input { pipeline { address => es } }
    filter {
        mutate { remove_field => 'sens..' }   # Remove the sensitive data
    }
    output {
        elasticsearch { }
    }
- pipeline.id: buffered-http
  queue.type: persisted                     # 
  config.string: |
    input { pipeline { address => http } }
    output {
        http { }
    }

# ------------------------------------------------------------------------------ 收集者模式

# 该模式是将所有管道汇集于一处的处理模式（使用同一个output）
- pipeline.id: beats
  config.string: |
    input { beats { port => 5044 } }
    output { pipeline { send_to => [commonOut] } }
- pipeline.id: kafka
  config.string: |
    input { kafka { ... } }
    output { pipeline { send_to => [commonOut] } }
- pipeline.id: partner
  # This common pipeline enforces the same logic whether data comes from Kafka or Beats
  config.string: |
    input { pipeline { address => commonOut } }
    filter {
      # Always remove sensitive data from all input sources
      mutate { remove_field => 'sensitive-data' }
    }
    output { elasticsearch { } }