anchor.diff:  
       `CF_TRACE=PATH-TO-TRACE.LOG cf push APP-NAME`
   
  -These examples enable HTTP tracing for a single command only.
  -To enable it for an entire shell session, set the variable first:
  +These examples enable HTTP tracing for a single command only. To enable it for an entire shell session, set the variable first:
   
     `export CF_TRACE=true`
   
     `export CF_TRACE=PATH-TO-TRACE.LOG`
   
  -<p class="note"><strong>Note</strong>: <code>CF_TRACE</code> is a local environment variable that modifies the behavior of the cf CLI.
  -Do not confuse <code>CF_TRACE</code> with the <a href="#env">variables in the container environment</a> where your apps run.</p>
  -
  -### <a id='zipkin_trace'></a>Analyze Zipkin Trace IDs
  +<p class="note"><strong>Note:</strong> <code>CF_TRACE</code> is a local environment variable that modifies the behavior of the cf CLI. Do not confuse <code>CF_TRACE</code> with the <a href="#env">variables in the container environment</a> where your apps run.</p>
  +
  +### <a id='zipkin_trace'></a> Analyze Zipkin Trace IDs
   
   When the Zipkin feature is enabled in Cloud Foundry, the Gorouter adds or forwards Zipkin trace IDs and span IDs to HTTP headers. For more information about what the Gorouter provides in the HTTP header, see the [HTTP Headers](../../concepts/http-routing.html#http-headers) section of the _HTTP Routing_ topic.
   
  -After adding Zipkin HTTP headers to app logs, developers can use `cf logs myapp` to correlate the trace and span ids logged by the Gorouter with the trace ids logged by their app. To correlate trace ids for a request through multiple apps, each app must forward appropriate values for the headers with requests to other apps.
  -
  -## <a id='cf-commands'></a>Use Troubleshooting Commands ##
  +After adding Zipkin HTTP headers to app logs, developers can use `cf logs myapp` to correlate the trace and span IDs logged by the Gorouter with the trace IDs logged by their app. To correlate trace IDs for a request through multiple apps, each app must forward appropriate values for the headers with requests to other apps.
  +
  +
  +## <a id='cf-commands'></a> Use Troubleshooting Commands
   
   You can investigate app deployment and health using the cf CLI.
   
  -Some cf CLI commands may return connection credentials.
  -Remove credentials and other sensitive information from command output before you post the output a public forum.
  -
  -* `cf apps`: Returns a list of the apps deployed to the current space
  -with deployment options, including the name, current state, number of instances,
  -memory and disk allocations, and URLs of each app.
  -
  -* `cf app APP-NAME`: Returns the health and status of each instance of a specific app in the current space, including instance ID number, current
  -state, how long it has been running, and how much CPU, memory, and disk it is using.
  -<p class="note"><strong>Note</strong>: CPU values returned by <code>cf app</code> show the total usage of each app instance on all CPU cores on a host VM, where each core contributes 100%. For example, the CPU of a single-threaded app instance on a Diego cell with one core cannot exceed 100%, and four instances sharing the cell cannot exceed an average CPU of 25%. A multi-threaded app instance running alone on a cell with eight cores can draw up to 800% CPU.</p>
  +Some cf CLI commands may return connection credentials. Remove credentials and other sensitive information from command output before you post the output a public forum.
  +
  +* `cf apps`: Returns a list of the apps deployed to the current space with deployment options, including the name, current state, number of instances, memory and disk allocations, and URLs of each app.
  +
  +* `cf app APP-NAME`: Returns the health and status of each instance of a specific app in the current space, including instance ID number, current state, how long it has been running, and how much CPU, memory, and disk it is using.
  +    <p class="note"><strong>Note:</strong> CPU values returned by <code>cf app</code> show the total usage of each app instance on all CPU cores on a host VM, where each core contributes 100%. For example, the CPU of a single-threaded app instance on a Diego cell with one core cannot exceed 100%, and four instances sharing the cell cannot exceed an average CPU of 25%. A multi-threaded app instance running alone on a cell with eight cores can draw up to 800% CPU.</p>
   
   * `cf env APP-NAME`: Returns environment variables set using `cf set-env` and variables existing in the container environment.
   
  -* `cf events APP-NAME`: Returns information about app crashes, including error codes. Shows that an app instance exited. For more detail, look in the app logs. See [https://github.com/cloudfoundry/errors](https://github.com/cloudfoundry/errors) for a list of Cloud Foundry errors.
  -
  -* `cf logs APP-NAME --recent`: Dumps recent logs.
  -See [Viewing Logs in the Command Line Interface](./streaming-logs.html#view).
  -
  -* `cf logs APP-NAME`: Returns a real-time stream of the app STDOUT and
  -STDERR. Use **Ctrl-C** (^C) to exit the real-time stream.
  -
  -* `cf files APP-NAME`: Lists the files in an app directory.
  -Given a path to a file, outputs the contents of that file. Given a path to a
  -subdirectory, lists the files within. Use this to [explore](#logs) individual
  -logs.
  -
  -<p class="note"><strong>Note</strong>: Your app should direct its logs to STDOUT and STDERR.
  +* `cf events APP-NAME`: Returns information about app crashes, including error codes. Shows that an app instance exited. For more detail, look in the app logs. For a list of Cloud Foundry errors, see [https://github.com/cloudfoundry/errors](https://github.com/cloudfoundry/errors).
  +
  +* `cf logs APP-NAME --recent`: Dumps recent logs. For more information, see [Viewing Logs in the Command Line Interface](./streaming-logs.html#view).
  +
  +* `cf logs APP-NAME`: Returns a real-time stream of the app STDOUT and STDERR. Use **Ctrl-C** (^C) to exit the real-time stream.
  +
  +* `cf files APP-NAME`: Lists the files in an app directory. Given a path to a file, outputs the contents of that file. Given a path to a subdirectory, lists the files within. Use this to [explore](#logs) individual logs.
  +
  +<p class="note"><strong>Note:</strong> Your app should direct its logs to STDOUT and STDERR.
   The <code>cf logs</code> command also returns messages from any <a href="http://logging.apache.org/log4j/">log4j</a> facility that you configure to send logs to STDOUT.</p>
   
  -## <a id='ssh'></a>Access Apps with SSH ##
  -
  -If you need to troubleshoot an instance of an app, you can gain SSH access to the app with the SSH proxy and daemon. See the [app SSH Overview](./app-ssh-overview.html) topic for more information.
  -
  -## <a id='request-to-instance'></a>Send Requests to App Instance ##
  -
  -To obtain debug data without SSH, you can make HTTP requests to a specific instance of an app by using the `X-CF-APP-INSTANCE` HTTP header. See the [App Instance Routing](../../concepts/http-routing.html#app-instance-routing) section of the <em>HTTP Routing</em> topic for more information.
  +
  +## <a id='ssh'></a> Access Apps with SSH
  +
  +If you need to troubleshoot an instance of an app, you can gain SSH access to the app with the SSH proxy and daemon. For more information, see [App SSH Overview](./app-ssh-overview.html).
  +
  +
  +## <a id='request-to-instance'></a> Send Requests to App Instance
  +
  +To obtain debug data without SSH, you can make HTTP requests to a specific instance of an app by using the `X-CF-APP-INSTANCE` HTTP header. For more information, see [App Instance Routing](../../concepts/http-routing.html#app-instance-routing) section of the _HTTP Routing_.
  
positive.code: 
  1. Run `cf map-route YOUR-APP-NAME NEW-ROUTE` to map the app to a new, unique route.
  
  ## <a id='info'></a>Gather Diagnostic Information ##
  
  Use the techniques in this section to gather diagnostic information and troubleshoot app deployment issues.
  
  ### <a id='env'></a>Examine Environment Variables ###
  
  `cf push` deploys your app to a container on the server.
  The environment variables in the container govern your app.
  
  You can set environment variables in a manifest created before you deploy.
  See [Deploying with app Manifests](./manifest.html).
  
  You can also set an environment variable with a `cf set-env` command followed
  by a `cf push` command.
  You must run `cf push` for the variable to take effect in the container
  environment.
  
  Use the `cf env` command to view the environment variables that you have set using the `cf set-env` command and the variables in the container environment:
  
  
negative.code: 2017-01-30T14:08:25.41-0800 [CELL/0]     OUT Starting health monitoring of container
      </pre>
  
  ### <a id='out-of-memory'></a> App Consumes Too Much Memory, Then Crashes
  
  An app that `cf push` has uploaded and started can crash later if it uses too much memory.
  
  **Make sure your app is not consuming more memory than it should.** When you ran `cf push` and `cf scale`, that configured a limit on the amount of memory your app should use. Check your app's actual memory usage. If it exceeds the limit, modify the app to use less memory.
  
  ### <a id='routing-conflict'></a> Routing Conflict
  
  <%= partial 'routing_conflict' %>
  
  