Merge pull request #23485 from mburke5678/logging-fix-topic-forwarding

Log forwarding assembly called wrong module

Author: mburke5678

logging/config/cluster-logging-external.adoc

@@ -28,7 +28,7 @@ The methods for forwarding logs using a ConfigMap are deprecated and will be rep
 include::modules/cluster-logging-collector-fluentd.adoc[leveloffset=+1]
 include::modules/cluster-logging-collector-syslog.adoc[leveloffset=+1]
 include::modules/cluster-logging-collector-log-forward.adoc[leveloffset=+1]
-include::modules/cluster-logging-collector-log-forward-about.adoc[leveloffset=+2]
+include::modules/cluster-logging-log-forwarding-about.adoc[leveloffset=+2]
 include::modules/cluster-logging-collector-log-forward-enable.adoc[leveloffset=+2]
 include::modules/cluster-logging-collector-log-forward-configure.adoc[leveloffset=+2]
 include::modules/cluster-logging-collector-log-forwarding-disable.adoc[leveloffset=+2]

modules/cluster-logging-collector-log-forward-about.adoc

@@ -3,9 +3,9 @@
 // * logging/cluster-logging-external.adoc
 
 [id="cluster-logging-log-forwarding-about_{context}"]
-= Understanding cluster log forwarding
+= Understanding the Log Forwarding API
 
-The {product-title} cluster log forwarding feature uses a combination of _outputs_ and _pipelines_ defined in the Log Forwarding Custom Resource to send logs to specific endpoints inside and outside of your {product-title} cluster. 
+Forwarding cluster logs using the Log Forwarding API requires a combination of _outputs_ and _pipelines_ to send logs to specific endpoints inside and outside of your {product-title} cluster. 
 
 [NOTE]
 ====
@@ -19,7 +19,7 @@ An _output_ is the destination for log data and a _pipeline_ defines simple rout
 An output can be either:
 
 * `elasticsearch` to forward logs to an external Elasticsearch v5.x cluster and/or the internal {product-title} Elasticsearch instance. 
-* `forward` to forward logs to an external log aggregation solution. This option uses the Fluentd *forward* plug-ins. 
+* `forward` to forward logs to an external log aggregation solution. This option uses the Fluentd *forward* protocols. 
 
 [NOTE]
 ====
@@ -29,7 +29,7 @@ The endpoint must be a server name or FQDN, not an IP Address, if the cluster-wi
 A _pipeline_ associates the source of the data to an output. The source of the data is one of the following:
 
 * `logs.app` - Container logs generated by user applications running in the cluster, except infrastructure container applications.
-* `logs.infra` - Logs generated by both infrastructure components running in the cluster and {product-title} nodes, such as journal logs. Infrastructure components are pods that run in the `openshift*`, `kube*`, or `default` projects.
+* `logs.infra` - Logs generated by infrastructure components running in the cluster and {product-title} nodes, such as journal logs. Infrastructure components are pods that run in the `openshift*`, `kube*`, or `default` projects.
 * `logs.audit` - Logs generated by the node audit system (auditd), which are stored in the  */var/log/audit/audit.log* file, and the audit logs from the Kubernetes apiserver and the OpenShift apiserver. 
 
 Note the following:
@@ -44,13 +44,13 @@ The following example creates three outputs:
 
 * the internal {product-title} Elasticsearch instance, 
 * an unsecured externally-managed Elasticsearch instance, 
-* a secured external log aggregator using the *forward* plug-in. 
+* a secured external log aggregator using the *forward* protocols. 
 
 Three pipelines send:
 
 * the application logs to the internal {product-title} Elasticsearch, 
 * the infrastructure logs to an external Elasticsearch instance,
-* the audit logs to the secured device over the *forward* plug-in.
+* the audit logs to the secured device over the *forward* protocols.
 
 .Sample log forwarding outputs and pipelines
 [source,yaml]
@@ -97,7 +97,7 @@ spec:
 <3> Configuration for the outputs.
 <4> A name to describe the output.
 <5> The type of output, either `elasticsearch` or `forward`.
-* Enter the endpoint, either the server name, FQDN, or IP address. If the cluster-wide proxy using the CIDR annotation is enabled, the endpoint must be a server name or FQDN, not an IP Address. For the internal {product-title} Elasticsearch instance, specify `elasticsearch.openshift-logging.svc:9200`.
+<6> Enter the endpoint, either the server name, FQDN, or IP address. If the cluster-wide proxy using the CIDR annotation is enabled, the endpoint must be a server name or FQDN, not an IP Address. For the internal {product-title} Elasticsearch instance, specify `elasticsearch.openshift-logging.svc:9200`.
 <7> Optional name of the secret required by the endpoint for TLS communication. The secret must exist in the `openshift-logging` project.
 <8> Optional setting if the endpoint does not use a secret, resulting in insecure communication. 
 <9> Configuration for the pipelines.