生産者と消費者との間の中心的なコンポーネントのデータの流れ、流れを駆動するための並列複数のイベントが担当必要Logstash例として。この構成は使用シナリオがあまりにも幸せではありませんになり、デフォルトでは、ユーザーは地獄（条件付き地獄）と呼ばれる状態が発生します。複数のデータストリームを処理する場合、デフォルトLogstashの各個々のインスタンスは、入力から成る導管、およびフィルタ出力組成物の複数をサポートするので、完全な状態の判断を使用する必要があります。

条件地獄（条件付き地獄）

ストリームパイプで知られている複数の独立した方法は、利用条件判断です。イベント入力部主な方法は、ラベルによって識別され、その後、フィルタと出力段の条件分岐、イベントを貼付異なる標識、異なるプラグインのアプリケーションを作成しています。この方法で問題を解決できますが、実際の使用では非常に痛いです！以下は、簡単なデモ断片であります：

入力{ 
  ビート{ポート => 3444   タグ=> アパッチ} 
  TCP {ポート => 4222   タグ=> ファイアウォール} 
} 
フィルタ{ 
   もし " アパッチ"  で[タグ] {   
    {解剖...} 
   } そう であれば 、 " ファイアウォール"  で[タグ] {   
    {...}完全に理解
   }   
} 
出力を{ 
   場合 、 " アパッチ"  で[タグ] {   
    elasticsearch {...} 
   } 他に あれば 、「ファイアウォール"  で[タグ] {   
    TCP {...} 
   }   
}

条件文を対応するLogstashパイプライン構成は非常に肥大化したラップされており、彼らの唯一の目的は、ストリームの独立性を維持することです。
条件を達成するために、別々のストリームの複数の使用が可能であるが、それを見ることは容易であるが、単一のダクト及び処理の単一段階、複雑さが増すがあるため、構成が非常に面倒な管理が困難になります。次の図は、2つの流れを備えたシンプルなパイプラインを示しています。

残念ながら、これはプログラムの唯一の欠点ではありません。

混雑分離の欠如

あなたが作動原理Logstashに精通している場合は、パイプラインの出力部は、イベントの数を受け取っ知っているし、すべてのイベントと、すべての出力が完了する前にイベントの次のバッチに移動しません。これは、ターゲットが到達不能TCPソケットである場合、上記のパイプラインのために、LogstashはElasticsearchがイベントを受信しません意味イベントの他のバッチを扱っていますし、TCP入力とビートを入力するように適用されているだろう、ということを意味します背圧。

異なるデータストリームは、異なる方法で対処する必要があります

TCP場合 - > GROK - 小データを大量に処理> TCPデータストリーム、及びビート - >解剖 - > ES単一のデータストリームが、かさばるの少数。次いで、より平行と各ワーカーバッチイベントの所望の複数の第1のデータストリームは、第2のデータストリームは、各作業者の少量とイベントの小さなバッチを使用することが望ましいです。単一のチューブを使用して、独立して単一のデータストリームパイプを指定するように構成することができません。

複数のインスタンスを通じて問題を解決するために、Logstash

解決し、その後独立してこれらの例を管理することができる、同じマシン上で実行されている複数のインスタンスによって問題上記Logstash。しかし、そのような解決策は、他の問題を作成した場合でも：

（複数のバックオフィスサービスを管理することにより、initシステム）複数のインスタンスを管理する必要性
各Logstashインスタンスは、別個のJVMことを意味します
あなたは、各インスタンスを監視する必要がありLogstash

この方法は非常に悪いです！

複数の導管

从 Logstash 6.0 开始，引入了 Multiple Pipelines，才完美的解决了这个问题。Multiple Pipelines 的配置非常简单：在配置文件 pipelines.yml 中添加新的 pipeline 配置并指定其配置文件就可以了。下面是一个简单的 demo 配置：

- pipeline.id: apache
  pipeline.batch.size: 125
  queue.type: persisted
  path.config: "/path/to/config/apache.cfg"
  queue.page_capacity: 50mb
- pipeline.id: test
  pipeline.batch.size: 2
  pipeline.batch.delay: 1
  queue.type: memory
  config.string: "input { tcp { port => 3333 } } output { stdout {} }"

这个 YAML 文件包含一个散列(或字典)列表，其中每个散列表示一个管道，键和值为该管道设置名称。被省略的设置值返回到它们的默认值。

配置多个管道

下面来看一个真实点的例子，笔者在 Ubuntu 18.04 Server 中安装了 Logstash 6.2.4，除了在默认的配置文件目录(/etc/logstash/conf.d)中添加配置文件外，创建新的目录 /etc/logstash/myconf.d，并在 /etc/logstash/myconf.d 目录下创建 Logstash 配置文件 krtest.conf。然后在 /etc/logstash/pipelines.yml 文件中添加新的 pipeline 配置：

- pipeline.id: main
  path.config: "/etc/logstash/conf.d/*.conf"
- pipeline.id: krtest
  path.config: "/etc/logstash/myconf.d/krtest.conf"

其中 pipeline.id 为 main 的管道是默认的配置，我们新添加了 id 为 krtest 的管道并指定了对应的配置文件路径。启动 Logstash，如果你安装的 X-Pack 插件就可以在 Kibana->Monitoring->Logstash 中看到新添加的名称为 krtest 的管道：

使用 Multiple Pipelines 后，我们的 Logstash 配置文件就可以写得像下面的代码一样简练(不再需要那么多的条件语句)了：

input {
    beats {
        port => 5064
    }
}
filter {
    grok { ... }
}
output {
    elasticsearch { ... }
}

参考：
Multiple Pipelines
Introducing Multiple Pipelines in Logstash

Logstash複数のパイプライン