anchor.diff:   my-drain: http://drain.example.com
   </pre>
   
  -### <a id='logs'></a>View Logs ###
  +### <a id='logs'></a> View Logs
   
   To view app logs streamed in real-time, use the `cf logs APP-NAME` command.
   
   To aggregate your app logs to view log history, bind your app to a syslog drain service. For more information, see [Streaming app Logs to Log Management Services](./../services/log-management.html).
   
  -<p class="note"><strong>Note</strong>: The Diego architecture does not support the <code>cf files</code> command.</p>
  -
  -### <a id='trace'></a>Trace Cloud Controller REST API Calls ###
  -
  -If a command fails or produces unexpected results, re-run it with HTTP tracing
  -enabled to view requests and responses between the Cloud Foundry Command Line Interface (cf CLI) and the Cloud Controller REST API.
  +<p class="note"><strong>Note:</strong> The Diego architecture does not support the <code>cf files</code> command.</p>
  +
  +### <a id='trace'></a> Trace Cloud Controller REST API Calls
  +
  +If a command fails or produces unexpected results, re-run it with HTTP tracing enabled to view requests and responses between the Cloud Foundry Command Line Interface (cf CLI) and the Cloud Controller REST API.
   
   For example:
   
  
positive.code: * `Error uploading application`
  * `Timed out waiting for async job JOB-NAME to finish`
  
  If this happens, do the following:
  
    * **Check your network speed.**
    Depending on the size of your app, your `cf push` could be timing out because the upload is taking too long.
  We recommended an Internet connection speed of at least 768 KB/s (6 Mb/s) for uploads.
  
    * **Make sure you are pushing only needed files.**
    By default, `cf push` will push all the contents of the current working directory.
  Make sure you are pushing only the directory for your app.
  If your app is too large, or if it has many small files, Cloud Foundry may time out during the upload.
  To reduce the number of files you are pushing, ensure that you push only the directory for your app, and remove unneeded files or use the `.cfignore` file to [specify excluded files](prepare-to-deploy.html#exclude).
  
    * **Set the CF\_STAGING\_TIMEOUT and CF\_STARTUP\_TIMEOUT environment variables.**
    By default your app has 15 minutes to stage and 5 minutes to start.
  You can increase these times by setting `CF_STAGING_TIMEOUT` and `CF_STARTUP_TIMEOUT`.
  Type `cf push -h` at the command line for more information.
  
    * **If your app contains a large number of files, try pushing the app repeatedly.**
    Each push uploads a few more files.
  Eventually, all files have uploaded and the push succeeds.
  This is less likely to work if your app has many small files.
  
  ### <a id='upload'></a>App Too Large ###
  
  If your app is too large, you may receive one of the following error messages on `cf push`:
  
  * `413 Request Entity Too Large`
  * `You have exceeded your organization's memory limit`
  
  If this happens, do the following:
  
    * **Make sure your org has enough memory for all instances of your app.**
    You will not be able to use more memory than is allocated for your
  organization.
    To view the memory quota for your org, use `cf org ORG_NAME`.
  
      Your total memory usage is the sum of the memory used by all apps in all spaces within the org.
      Each app's memory usage is the memory allocated to it
  multiplied by the number of instances.
    To view the memory usage of all the apps in a space, use `cf apps`.
  
    * **Make sure your app is less than 1 GB.**
    By default, Cloud Foundry deploys all the contents of the current working directory.
    To reduce the number of files you are pushing, ensure that you push only the directory for your app, and remove unneeded files or use the `.cfignore` file to [specify excluded files](prepare-to-deploy.html#exclude).
    The following limits apply:
  
      * The app files to push cannot exceed 1 GB.
  
      * The droplet that results from compiling those files cannot exceed 1.5 GB.
      Droplets are typically a third larger than the pushed files.
  
      * The combined size of the app files, compiled droplet, and buildpack cache cannot total more than 4 GB of space during staging.
  
  ### <a id='detect'></a>Unable to Detect a Supported App Type ###
  
  If Cloud Foundry cannot [identify an appropriate buildpack](../../buildpacks/detection.html) for your app, you will see an error message that states `Unable to detect a supported app type`.
  
  You can view what buildpacks are available with the `cf buildpacks` command.
  
  If you see a buildpack that you believe should support your app, refer to the [buildpack documentation](../../buildpacks/) for details about how that buildpack detects apps it supports.
  
  If you do not see a buildpack for your app, you may still be able to push your app with a [custom buildpack](../../buildpacks/custom.html) using `cf push -b` with a path to your buildpack.
  
  ### <a id='deploy_fail'></a> App Deploy Fails ###
  
  Even when the deploy fails, the app might exist on <%=vars.product_short%>.
  Run `cf apps` to review the apps in the currently targeted org and space. You might be able to correct the issue using the <%=vars.dev_console_2%>, or you might have to delete the app and redeploy.
  
  If you push multiple apps using a manifest and one fails to deploy, CF does not attempt to push apps specified after the app that failed. 
  
  Common reasons deploying an app fails include the following:
  
  * The app does not successfully bind to a service, such as a PostgreSQL or MongoDB. The service may not exist, may be down, or may reject the binding.  
  * The app does not have a unique URL. Refer to the troubleshooting tip App Requires Unique URL.
  
  ### <a id='unique_url'></a> App Requires Unique URL ###
  <%=vars.product_short%> requires that each app that you deploy has a unique URL. Otherwise, the new app URL collides with an existing app URL and <%=vars.product_short%> cannot successfully deploy the app. You can resolve this issue by running `cf push` with either of the following flags to create a unique URL:
  
  * `-n` to assign a different HOST name for the app.
  * `--random-route` to create a URL that includes the app name and random words. Using this option might create a long URL, depending on the number of words that the app name includes.
  
  ### <a id='start'></a>App Fails to Start ###
  
  After `cf push` stages the app and uploads the droplet, the app may fail to start, commonly with a pattern of starting and crashing similar to the following example:
  
  
negative.code: 
      `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:
  
    `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
  
  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
  
  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>
  
  * `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. 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. 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_.
  