anchor.diff:  $ oc edit configmap logging-deployer
   ----
   +
  -These and other parameters are available (you should read the ElasticSearch section below before choosing ElasticSearch parameters for the deployer):
  +These and other parameters are available (you should read the
  +xref:aggregate_logging.adoc#aggregated-elasticsearch[ElasticSearch
  +section] below before choosing ElasticSearch parameters for the deployer,
  +and the xref:aggregate_logging.adoc#aggregated-fluentd[Fluentd section]
  +for some possible parameters):
   +
   [cols="3,7",options="header"]
   |===
  
positive.code: $ oc scale --replicas=1 dc/logging-es-<suffix>
  ----
  
  === Fluentd
  
  Once Elasticsearch is running, label nodes to enable Fluentd to run on them
  and feed logs to Elasticsearch. Use the `*fluentd-nodeselector*` given to
  the deployer (if different) in the command below:
  
  ====
  ----
  $ oc label nodes --all logging-infra-fluentd=true
  ----
  ====
  
  === Kibana
  
  
negative.code: |*_MODE_* (default: *install*)
  | Mode to run the deployer in; one of `*install, uninstall, reinstall, upgrade, migrate, start, stop*`.
  |===
  
  Running the deployer creates a deployer pod and prints its name. Wait until the
  pod is running. This can take up to a few minutes for {product-title} to retrieve the deployer image
  from the registry. You can watch its process with:
  
  ----
  $ oc get pod/<pod_name> -w
  ----
  
  It should eventually enter Running status and end in Complete status.
  If it seems to be taking too long to start, you can retrieve more details about
  the pod and any associated events with:
  
  ----
  $ oc describe pod/<pod_name>
  ----
  
  You can also check the logs if the deployment does not complete successfully:
  
  ----
  $ oc logs -f <pod_name>
  ----
  
  Once deployment completes successfully, you will probably need to
  xref:aggregate_logging.adoc#aggregated-fluentd[label the nodes for
  Fluentd to deploy on], and may have other adjustments to make to the
  deployed components. These are described in the next section.
  
  == Understanding and Adjusting the Deployment
  
  [[aggregated-ops]]
  === Ops Cluster
  
  [NOTE]
  ====
  The logs for the *default*, *openshift*, and *openshift-infra* projects are automatically aggregated and grouped into the *.operations* item in the Kibana interface.
  
  The project where you have deployed the EFK stack (*logging*, as documented here) is _not_ aggregated into *.operations* and is found under its ID.
  ====
  
  If you set `*enable-ops-cluster*` to `true` for the deployer, Fluentd
  is configured to split logs between the main ElasticSearch cluster
  