anchor.diff:  Cloud Foundry gathers and stores logs in a best-effort manner.
   If a client is unable to consume log lines quickly enough, the Loggregator
   buffer may need to overwrite some lines before the client has consumed them.
  -A syslog drain or a CLI tail can usually keep up with the flow of application
  +A syslog drain or a CLI tail can usually keep up with the flow of app
   logs.
   
   ## <a id='types'></a>Contents of a Log Line ##
  
positive.code: Loggregator assigns the timestamp when it receives log data.
  The log data is opaque to Loggregator, which simply puts it in the message field
  of the log line.
  Applications or system components sending log data to Loggregator may include
  their own timestamps, which then appear in the message field.
  
  Origin codes distinguish the different log types.
  Origin codes from system components have three letters.
  The application origin code is `APP` followed by slash and a digit that
  indicates the application instance.
  
  Many frameworks write to an application log that is separate from STDOUT and
  STDERR.
  This is not supported by Loggregator.
  Your application must write to STDOUT or STDERR for its logs to be included in
  the Loggregator stream.
  Check the buildpack your application uses to determine whether it automatically
  insures that your application correctly writes logs to STDOUT and STDERR only.
  Some buildpacks do this, and some do not.
  
  ## <a id='format'></a>Log Types and Their Messages ##
  
  Different types of logs have different message formats, as shown in the examples
  below.
  
  ### <a id='api'></a>API ###
  
  Users make API calls to request changes in application state. Cloud Controller,
  the Cloud Foundry component responsible for the API, logs the actions that Cloud
  Controller takes in response.
  
  For example:
  
  <pre class="terminal">
  2014-02-13T11:44:52.11-0800 [API]     OUT Updated app with guid e1ca6390-cf78-4fc7-9d86-5b7ed01e9c28 ({"instances"=>2})
  </pre>
  
  ### <a id='stg'></a>STG ###
  
  The Droplet Execution Agent emits STG logs when staging or restaging an app.
  These actions implement the desired state requested by the user.
  Once the droplet has been uploaded, STG messages end and DEA messages begin.
  
  For example:
  
  <pre class="terminal">
  2014-02-07T10:54:36.80-0800 [STG]     OUT -----> Downloading and installing node
  </pre>
  
  ### <a id='dea'></a>DEA ###
  
  
negative.code: <strong><%= modified_date %></strong>
  
  Loggregator, the Cloud Foundry component responsible for logging, provides a
  stream of log output from your app and from Cloud Foundry system
  components that interact with your app during updates and execution.
  
  By default, Loggregator streams logs to your terminal.
  