anchor.diff:  |*_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. It may take several minutes for {product-title}
  -to retrieve the deployer image from the registry.
  -+
  -[NOTE]
  -====
  -The logs for the *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.
  -====
  -+
  -You can watch its progress with:
  -+
  +
  +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
  
positive.code: ----
  endif::openshift-enterprise[]
  ====
  +
  [cols="3,7",options="header"]
  |===
  |Parameter Name
  
negative.code: $ oc scale --replicas=1 dc/logging-es-<suffix>
  ----
  
  [[aggregated-fluentd]]
  === Fluentd
  
  Fluentd is deployed as a DaemonSet that deploys replicas according
  to a node label selector (which you can specify with the deployer parameter
  `*fluentd-nodeselector*`; the default is `logging-infra-fluentd`).
  Once you have ElasticSearch running as
  desired, label the nodes intended for Fluentd deployment to feed
  their logs into ES. The example below would label a node named
  `node.example.com` using the default Fluentd node selector.
  
      $ oc label node/node.example.com logging-infra-fluentd=true
  
  Alternatively, you can label all nodes with the following:
  
      $ oc label node --all logging-infra-fluentd=true
  
  Note: Labeling nodes requires cluster-admin capability.
  
  [[fluentd-use-journald]]
  *Having Fluentd use the systemd journal as the log source*
  
  By default, Fluentd reads from *_/var/log/messages_* and
  *_/var/log/containers/<container>.log_* for system logs and container logs, respectively.
  You can instead use the systemd journal as the log source.  There are three
  deployer configuration parameters available in the deployer configmap:
  
  [cols="3,7",options="header"]
  |===
  |Parameter
  |Description
  
  | `*use-journal*`
  | The default is empty, which tells the deployer to have Fluentd check which
  log driver Docker is using. If docker is using `--log-driver=journald`, Fluentd reads
  from the systemd journal, otherwise, it assumes docker is using the
  `json-file` log driver and reads from the *_/var/log_* file sources. You can
  specify the `*use-journal*` option as `true` or `false` to be explicit about which log source to use. Using the
  systemd journal requires `docker-1.10` or later, and Docker must be configured to
  use `--log-driver=journald`.
  
  | `*journal-source*`
  | The default is empty, so that when using the systemd journal, Fluentd first looks for
  *_/var/log/journal_*, and if that is not available, uses *_/run/log/journal_*
  as the journal source. You can specify `*journal-source*` with an explicit
  journal path.  For example, if you want fluentd to always read logs
  from the transient in-memory journal, set `*journal-source*`=*_/run/log/journal_*.
  
  | `*journal-read-from-head*`
  | If this setting is `false`, Fluentd
  starts reading from the end of the journal, ignoring historical logs.  If this
  setting is `true`, fluentd starts reading logs from the beginning of the journal.
  |===
  
  [NOTE]
  ====
  It may require several minutes, or hours, depending on the size of your
  journal, before any new log entries are available in Elasticsearch, when using
  `journal-read-from-head=true`.
  ====
  
  [[fluentd-log-external-elasticsearch]]
  *Having Fluentd send logs to another Elasticsearch*
  
  You can configure Fluentd to send a copy of each log message to both the
  Elasticsearch instance included with OpenShift aggregated logging, *and* to an
  external Elasticsearch instance. For example, if you already have an
  Elasticsearch instance set up for auditing purposes, or data warehousing, you
  can send a copy of each log message to that Elasticsearch.
  
  This feature is controlled via environment variables on Fluentd, which can be
  modified as described below.
  If its environment variable `*ES_COPY*` is `true`, Fluentd sends a copy of
  the logs to another Elasticsearch. The names for the copy variables are just like the
  current `*ES_HOST*`, `*OPS_HOST*`, etc. variables, except that they add
  `_COPY`: `*ES_COPY_HOST*`, `*OPS_COPY_HOST*`, etc.  There are some additional
  parameters added:
  * `*ES_COPY_SCHEME*`, `*OPS_COPY_SCHEME*` - can use either `http` or `https` - defaults
    to `https`
  * `*ES_COPY_USERNAME*`, `*OPS_COPY_USERNAME*` - user name to use to authenticate to
    Elasticsearch using username/password auth
  * `*ES_COPY_PASSWORD*`, `*OPS_COPY_PASSWORD*` - password to use to authenticate to
    Elasticsearch using username/password auth
  
  To set the parameters:
  
  . Edit the template for the Fluentd daemonset:
  +
  ----
  $ oc edit -n logging template logging-fluentd-template
  ----
  +
  Add or edit the environment variable `*ES_COPY*` to have the value `"true"` (with the quotes),
  and add or edit the COPY variables listed above.
  
  . Recreate the Fluentd daemonset from the template:
  +
  ----
  $ oc delete daemonset logging-fluentd
  $ oc new-app logging-fluentd-template
  ----
  
  [[fluentd-throttling]]
  *Throttling logs in Fluentd*
  
  For projects that are especially verbose, an administrator can throttle
  down the rate at which the logs are read in by Fluentd before being
  processed. 
  
  [WARNING]
  ====
  Throttling may contribute to log aggregation falling behind
  for the configured projects; log entries could be lost if a pod were deleted
  before Fluentd caught up.
  ====
  
  [NOTE]
  ====
  Throttling does not work when using the systemd journal as the log
  source.  The throttling implementation depends on being able to throttle the
  reading of the individual log files for each project.  When reading from the
  journal, there is only a single log source, no log files, so no file-based
  throttling is available, and there isn't a method of restricting which log
  entries are read into the Fluentd process.
  ====
  
  To tell Fluentd which projects it should be restricting you will need
  to edit the throttle configuration in its configmap after deployment:
  
      $ oc edit configmap/logging-fluentd
  
  The format of the throttle-config.yaml key is a yaml file that contains
  project names and the desired rate at which logs are read in on each
  node. The default is 1000 lines at a time per node. For example:
  
  ```
  logging:
    read_lines_limit: 500
  
  test-project:
    read_lines_limit: 10
  
  .operations:
    read_lines_limit: 100
  ```
  
  === Kibana
  
  