Doc for pipeline-to-pipeline communication (#9385)

* Doc for pipeline-to-pipeline

* Incorporate review comments

* Add link for collector pattern

docs/index-shared3.asciidoc

@@ -12,6 +12,9 @@ include::static/configuration.asciidoc[]
 :edit_url: https://github.com/elastic/logstash/edit/{branch}/docs/static/multiple-pipelines.asciidoc
 include::static/multiple-pipelines.asciidoc[]
 
+:edit_url: https://github.com/elastic/logstash/edit/{branch}/docs/static/pipeline-pipeline-config.asciidoc
+include::static/pipeline-pipeline-config.asciidoc[]
+
 :edit_url: https://github.com/elastic/logstash/edit/{branch}/docs/static/reloading-config.asciidoc
 include::static/reloading-config.asciidoc[]
 

docs/static/ls-ls-config.asciidoc

@@ -1,9 +1,11 @@
 [[ls-to-ls]]
-=== Configuring Logstash-to-Logstash Communication
+=== Logstash-to-Logstash Communication
 
 You can set up communication between two Logstash machines by connecting the Lumberjack output to the Beats input. You may need this configuration if the data path crosses network or firewall boundaries, for example. If you don't have a compelling need for Logstash-to-Logstash communication, then don't implement it.
 
-[[ls-to-ls-overview]]
+If you are looking for information on connecting multiple pipelines within one
+Logstash instance, see <<pipeline-to-pipeline>>.
+
 ==== Configuration overview
 
 Use the Lumberjack protocol to connect two Logstash machines.

docs/static/pipeline-pipeline-config.asciidoc

@@ -1,19 +1,19 @@
 [[pipeline-to-pipeline]]
-=== Configuring Pipeline-to-Pipeline Communication
+=== Pipeline-to-Pipeline Communication
 
-When using the multiple pipeline feature of Logstash you may want to connect multiple pipelines on the same Logstash instance together. This can be useful to isolate the execution of these pipelines, as well as to help break-up the logic of complex pipelines. The `pipeline` input / output enables a number of advanced architectural patterns discussed later in this document.
+When using the multiple pipeline feature of Logstash, you may want to connect multiple pipelines within the same Logstash instance. This configuration can be useful to isolate the execution of these pipelines, as well as to help break-up the logic of complex pipelines. The `pipeline` input/output enables a number of advanced architectural patterns discussed later in this document.
 
-Where communication is needed between Logstash instances you will need to use either {logstash-ref}/ls-to-ls.html[Logstash-to-Logstash] communications, or an intermediary queue, such as Kafka or Redis.
+If you need to set up communication _between_ Logstash instances, use either {logstash-ref}/ls-to-ls.html[Logstash-to-Logstash] communications, or an intermediary queue, such as Kafka or Redis.
 
 [[pipeline-to-pipeline-overview]]
 ==== Configuration overview
 
-Use the `pipeline` input and `pipeline` output to connect two Logstash pipelines running within the same instance. These inputs use a client / server approach, where the `pipeline` input registers a virtual address that a `pipeline` output can connect to.
+Use the `pipeline` input and `pipeline` output to connect two pipelines running within the same Logstash instance. These inputs use a client-server approach, where the `pipeline` input registers a virtual address that a `pipeline` output can connect to.
 
 . Create a 'downstream' pipeline that listens for events on a virtual address.
-. Create an 'upstream' pipeline that produces events, sending them through a `pipeline` output to one or more virtual addresses
+. Create an 'upstream' pipeline that produces events, sending them through a `pipeline` output to one or more virtual addresses.
 
-A simple example of this configuration can be seen in the below example.
+Here is a simple example of this configuration.
 
 [source,yaml]
 ----
@@ -24,43 +24,46 @@ A simple example of this configuration can be seen in the below example.
   config.string: input { pipeline { address => myVirtualAddress } }
 ----
 
-[[how-it-works]]
+[[how-pipeline-to-pipeline-works]]
 ===== How it works
 
-The `pipeline` input acts as a virtual server listening on a single virtual address in the local process. Only `pipeline` outputs running on the same local Logstash can send events to this address. Pipeline `outputs` can send events to a list of virtual addresses. A `pipeline` output will block if the downstream pipeline is either unavailable or blocked.
+The `pipeline` input acts as a virtual server listening on a single virtual address in the local process. Only `pipeline` outputs running on the same local Logstash can send events to this address. Pipeline `outputs` can send events to a list of virtual addresses. A `pipeline` output will be blocked if the downstream pipeline is blocked or unavailable.
 
-When events are sent across pipelines their data is fully copied. Modifications to an event in a downstream pipeline will not affect any other pipelines that event may be used within.
+When events are sent across pipelines, their data is fully copied. Modifications to an event in a downstream pipeline do not affect that event in any upstream pipelines.
 
-Copying events does, however incur a performance cost. While the `pipeline` plugin may be the most efficient way to communicate between pipelines it still does incur a cost. Logstash must duplicate each event in full on the Java heap for each downstream pipeline a `pipeline` output sends to. Beware that using this feature may affect the heap memory utilization of Logstash.
+The `pipeline` plugin may be the most efficient way to communicate between pipelines, but it still incurs a performance cost. Logstash must duplicate each event in full on the Java heap for each downstream pipeline. Using this feature may affect the heap memory utilization of Logstash.
 
 [[delivery-guarantees]]
 ===== Delivery Guarantees
-In its standard configuration the `pipeline` input/output have at-least-once delivery guarantees. The output wil block if the address is unavailable or blocked.
+In its standard configuration the `pipeline` input/output has at-least-once delivery guarantees. The output will be blocked if the address is blocked or unavailable.
 
-By default, the `ensure_delivery` option on the `pipeline` output is set to `true. If the `ensure_delivery` flag is set to `false`, an unavailable downstream pipeline will cause the sent message to be discarded. A blocked downstream pipeline will block the sending output/pipeline regardless of the value of the `ensure_delivery` flag.
+By default, the `ensure_delivery` option on the `pipeline` output is set to `true.` If you change the `ensure_delivery` flag to `false`, an unavailable downstream pipeline causes the sent message to be discarded. Use `ensure_delivery => false` when you want the ability to temporarily disable a downstream pipeline without the upstream one waiting for it.
+
+A blocked downstream pipeline blocks the sending output/pipeline regardless of the value of the `ensure_delivery` flag.
 
 [[avoid-cycles]]
 ===== Avoid cycles
 
-It is important when connecting pipelines that the data only flow in one direction. Looping data back around, or connecting the pipelines into a cyclic graph, can cause problems. Logstash waits for each pipeline's work to complete before shutting down. If the pipelines loop data between them this can prevent Logstash from cleanly shutting down.
+When you connect pipelines, keep the data flowing in one direction. Looping data or connecting the pipelines into a cyclic graph can cause problems. Logstash waits for each pipeline's work to complete before shutting down. Pipeline loops can prevent Logstash from shutting down cleanly.
 
 [[architectural-patterns]]
 ==== Architectural patterns
 
-You can use the `pipeline` input and output to better organize code, streamline control flow, and isolate the performance of complex configurations. There are an infinite number of ways to connect pipelines. The ones presented here are hardly comprehensive.
+You can use the `pipeline` input and output to better organize code, streamline control flow, and isolate the performance of complex configurations. There are infinite ways to connect pipelines. The ones presented here offer some ideas.
 
 * <<distributor-pattern>>
 * <<output-isolator-pattern>>
 * <<forked-path-pattern>>
+* <<collector-pattern>>
 
 [[distributor-pattern]]
-====== The distributor pattern
+===== The distributor pattern
 
-The Distributor pattern is used in situations where there are multiple types of data coming through a single input, each with its own complex set of processing rules. With the distributor pattern one pipeline is used to route data to other pipelines based on type. Each type is routed to a pipeline with only the logic for handling that type. In this way each type's logic can be isolated.
+You can use the distributor pattern in situations where there are multiple types of data coming through a single input, each with its own complex set of processing rules. With the distributor pattern one pipeline is used to route data to other pipelines based on type. Each type is routed to a pipeline with only the logic for handling that type. In this way each type's logic can be isolated.
 
-As an example, in many organizations a single beats input may be used to receive traffic from a variety of sources, each with its own processing logic. A common way of dealing with this type of data is to have a number of `if` conditions separating the traffic and processing each type differently. This approach can quickly get messy when configs are long and complex.
+As an example, in many organizations a single beats input may be used to receive traffic from a variety of sources, each with its own processing logic. A common way to deal with this type of data is to have a number of `if` conditions separating the traffic and processing each type differently. This approach can quickly get messy when configs are long and complex.
 
-An example distributor configuration is listed below:
+Here is an example distributor pattern configuration.
 
 [source,yaml]
 ----
@@ -104,15 +107,17 @@ An example distributor configuration is listed below:
 Notice how following the flow of data is a simple due to the fact that each pipeline only works on a single specific task.
 
 [[output-isolator-pattern]]
-==== The output isolator pattern
+===== The output isolator pattern
 
-The output isolator pattern is used to prevent Logstash from blocking in the case where there are multiple outputs and one output experiences a temporary failure. For example, a server might be configured to send log data to both Elasticsearch and an HTTP endpoint. It might be the case that the HTTP endpoint is frequently unavailable due to regular service or some other reason.
+You can use the output isolator pattern to prevent Logstash from becoming blocked if one of multiple outputs experiences a temporary failure. Logstash, by default, is blocked when any single output is down. This behavior is important in guaranteeing at-least-once delivery of data. 
 
-Logstash, by default, will block when any single output is down. This is an important behavior in guaranteeing at-least-once delivery of data. Unfortunately, in our above scenario this means that whenever the HTTP endpoint is down data is also paused from sending to Elasticsearch. Using the `pipeline` input and output, along with persistent queues, we can continue sending to Elasticsearch even when one output is down, by using the output isolator pattern.
+For example, a server might be configured to send log data to both Elasticsearch and an HTTP endpoint. The HTTP endpoint might be frequently unavailable due to regular service or other reasons. In this scenario, data would be paused from sending to Elasticsearch any time the HTTP endpoint is down. 
 
-We could employ this pattern for the scenario described above with the following config:
+Using the output isolator pattern and persistent queues, we can continue sending to Elasticsearch, even when one output is down.
 
-[[source,yaml]]
+Here is an example of this scenario using the output isolator pattern. 
+
+[source,yaml]
 ----
 # config/pipelines.yml
 - pipeline.id: intake
@@ -132,18 +137,18 @@ We could employ this pattern for the scenario described above with the following
     output { http { } }
 ----
 
-Please note, that in this architecture, each stage has its own queue, with its own tuning and settings. This would use up to three times as much disk space, and incur three times as much serialization / deserialization cost, as a single pipeline.
+In this architecture, each stage has its own queue with its own tuning and settings. Note that this approach uses up to three times as much disk space and incurs three times as much serialization/deserialization cost as a single pipeline.
 
 [[forked-path-pattern]]
-==== The forked path pattern
+===== The forked path pattern
 
-The forked path pattern is used in situations where a single event must be processed more than once according to different sets of rules. If not using the `pipeline` input and output this is commonly solved through creative use of the `clone` filter and `if/else` rules.
+You can use the forked path pattern for situations where a single event must be processed more than once according to different sets of rules. Before the `pipeline` input and output were available, this need was commonly addressed through creative use of the `clone` filter and `if/else` rules.
 
-As an example, let's imagine that we have a use case where we receive data, and index the full event in our own systems, but publish a redacted version of the data to a partner's S3 bucket. We might use the output isolator pattern described above to decouple our writes to either system. The distinguishing feature of the forked path pattern is the existence of additional rules in the downstream pipelines.
+Let's imagine a use case where we receive data and index the full event in our own systems, but publish a redacted version of the data to a partner's S3 bucket. We might use the output isolator pattern described above to decouple our writes to either system. The distinguishing feature of the forked path pattern is the existence of additional rules in the downstream pipelines.
 
-An example of this pattern is in the following config:
+Here is an example of the forked path configuration.
 
-[[source,yaml]]
+[source,yaml]
 ----
 # config/pipelines.yml
 - pipeline.id: intake
@@ -169,14 +174,13 @@ An example of this pattern is in the following config:
 ----
 
 [[collector-pattern]]
-==== The collector pattern
+===== The collector pattern
 
-The collector pattern is used in situations where you want to define a common set of outputs and pre-output filters that many disparate pipelines might use. This is the opposite of the distributor pattern. In this pattern many pipelines fan in to a single pipeline where outputs and other processing are shared. This pattern simplifies configuration at the cost of reducing isolation, since all data is sent through a single pipeline.
+You can use the collector pattern when you want to define a common set of outputs and pre-output filters that many disparate pipelines might use. This pattern is the opposite of the distributor pattern. In this pattern many pipelines flow in to a single pipeline where they share outputs and processing. This pattern simplifies configuration at the cost of reducing isolation, since all data is sent through a single pipeline.
 
-An example of this pattern can be seen below:
+Here is an example of the collector pattern.
 
-
-[[source,yaml]]
+[source,yaml]
 ----
 # config/pipelines.yml
 - pipeline.id: beats