Merge pull request openshift#2361 from bfallonf/followup_1950

Followup edits to PR 1950

Author: Brice Fallon-Freeman

install_config/aggregate_logging.adoc

@@ -741,37 +741,45 @@ $ oc get route  --all-namespaces --selector logging-infra=support
 ----
 ====
 
-== External Elasticsearch instance with Fluentd
+[[sending-logs-to-an-external-elasticsearch-instance]]
+== Sending Logs to an External Elasticsearch instance
 
-It is possible to configure the Fluentd pod created with aggregated logging to
-connect to an externally hosted Elasticsearch instance.
+Fluentd sends logs to the value of the `ES_HOST`, `ES_PORT`, `OPS_HOST`, and
+`OPS_PORT` environment variables of the Elasticsearch deployment configuration.
+The application logs are directed to the `ES_HOST` destination, and operations
+logs to `OPS_HOST`.
 
-Fluentd knows where to send its logs to based on the `ES_HOST`, `ES_PORT`,
-`OPS_HOST` and `OPS_PORT` environment variables.  If you have an external
-Elasticsearch instance that will contain both application and operations logs,
-ensure that `ES_HOST` and `OPS_HOST` are the same and that `ES_PORT` and
-`OPS_PORT` are also the same.  Fluentd is configured to send its application logs
-to the `ES_HOST` destination and all of its operations logs to `OPS_HOST`.
+To direct logs to a specific Elasticsearch instance, edit the deployment
+configuration and replace the value of the above variables with the desired
+instance:
 
-If your externally hosted Elasticsearch does not make use of TLS you will need to
-update the `*_CLIENT_CERT`, `*_CLIENT_KEY` and `*_CA` variables to be empty. If
-it uses TLS but not Mutual TLS, update the `*_CLIENT_CERT` and `*_CLIENT_KEY`
+----
+$ oc edit dc/<deployment_configuration>
+----
+
+For an external Elasticsearch instance to contain both application and
+operations logs, you can set `ES_HOST` and `OPS_HOST` to the same destination,
+while ensuring that `ES_PORT` and `OPS_PORT` also have the same value.
+
+If your externally hosted Elasticsearch instance does not use TLS, update the
+`*_CLIENT_CERT`, `*_CLIENT_KEY`, and `*_CA` variables to be empty. If it does
+use TLS, but not mutual TLS, update the `*_CLIENT_CERT` and `*_CLIENT_KEY`
 variables to be empty and patch or recreate the `logging-fluentd` secret with
-the appropriate `*_CA` for communicating with your Elasticsearch.  If it uses
-Mutual TLS as the provided Elasticsearch does, you will just need to patch or
+the appropriate `*_CA` value for communicating with your Elasticsearch instance.
+If it uses Mutual TLS as the provided Elasticsearch instance does, patch or
 recreate the `logging-fluentd` secret with your client key, client cert, and CA.
 
 ifdef::openshift-origin[]
-Since Fluentd is deployed by means of a DaemonSet you will need to update the
-`logging-fluentd-template` template, delete your current DaemonSet and recreate
+Since Fluentd is deployed by a DaemonSet, update the
+`logging-fluentd-template` template, delete your current DaemonSet, and recreate
 it with `oc new-app logging-fluentd-template` after seeing all previous Fluentd
 pods have terminated.
 endif::openshift-origin[]
 
 ifdef::openshift-enterprise[]
-You can use `oc edit dc/logging-fluentd` to update your Fluentd configuration.
-It is advised that you first scale down your number of replicas to 0 before
-editing the DeploymentConfig.
+You can use `oc edit dc/logging-fluentd` to update your Fluentd configuration,
+making sure to first scale down your number of replicas to zero before editing
+the deployment configuration.
 enddef::openshift-enterprise[]
 
 [NOTE]