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: For example:
  
  <pre class="terminal">
  $ cf logs nifty-gui
  	Connected, tailing logs for app nifty-gui in org janclouduser / space jancloudspace as admin...
  	2014-02-06T12:00:19.44-0800 [API]
  		OUT Updated app with guid c8612fc2-85b1-464c-92f5-d4a1156eacbf
  		({"route"=>"2ef5796b-475a-4615-9c71-75bbe277022e"})
  	2014-02-06T12:00:27.54-0800 [DEA]
  		OUT Got staging request for app with id
  		c8612fc2-85b1-464c-92f5-d4a1156eacbf
  	2014-02-06T12:00:28.51-0800 [API]
  		OUT Updated app with guid c8612fc2-85b1-464c-92f5-d4a1156eacbf
  		({"state"=>"STARTED"})
  	...
  </pre>
  
  
negative.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.
  Apps 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 app origin code is `APP` followed by slash and a digit that
  indicates the app instance.
  
  Many frameworks write to an app log that is separate from STDOUT and
  STDERR.
  This is not supported by Loggregator.
  Your app must write to STDOUT or STDERR for its logs to be included in
  the Loggregator stream.
  Check the buildpack your app uses to determine whether it automatically
  insures that your app 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.
  The digit appended to the code indicates the instance index: 0 is the first instance, 1 is the second, and so on.
  
  ### <a id='api'></a>API ###
  
  Users make API calls to request changes in app 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">
  2016-06-14T14:10:05.36-0700 [API/0]      OUT Updated app with guid cdabc600-0b73-48e1-b7d2-26af2c63f933 ({"name"=>"spring-music", "instances"=>1, "memory"=>512, "environment_json"=>"PRIVATE DATA HIDDEN"})
  </pre>
  
  ### <a id='stg'></a>STG ###
  
  The Diego cell or the Droplet Execution Agent emits STG logs when staging or restaging an app.
  These actions implement the desired state requested by the user.
  After the droplet has been uploaded, STG messages end and CELL or DEA messages begin.
  For STG, the instance index is almost always 0.
  
  For example:
  
  <pre class="terminal">
  2016-06-14T14:10:27.91-0700 [STG/0]      OUT Staging...
  </pre>
  
  ### <a id='rtr'></a>RTR ###
  
  The Router emits RTR logs when it routes HTTP requests to the app.
  Router messages include the app name followed by a Router timestamp and
  then selections from the HTTP request.
  
  For example:
  
  <pre class="terminal">
  2016-06-14T10:51:32.51-0700 [RTR/1]      OUT www.example.com - [14/06/2016:17:51:32.459 +0000] "GET /user/ HTTP/1.1" 200 0 103455 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.123 Safari/537.30" 10.10.60.132:46359 x_forwarded_for:"5.101.69.120" x_forwarded_proto:"http" vcap_request_id:9365d216-623a-45cb-6ef6-eba495c19fa8 response_time:0.059468637 app_id:79cc58aa-3737-43ae-ac71-39a2843b5178
  </pre>
  
  ### <a id='lgr'></a>LGR ###
  
  Loggregator emits LGR to indicate problems with the logging process.
  Examples include "can't reach syslog drain url" and "dropped log messages due to high rate."
  
  ### <a id='app'></a>APP ###
  
  Every app emits logs according to choices by the developer.
  
  For example:
  
  <pre class="terminal">
  2016-06-14T14:10:15.18-0700 [APP/0]      OUT Exit status 0
  </pre>
  
  ### <a id="ssh"></a>SSH ###
  
  The Diego cell emits SSH logs when a user accesses an application container through SSH by using the `cf ssh APP-NAME` command.
  
  For example:
  
  <pre class="terminal">
  2016-06-14T14:16:11.49-0700 [SSH/0]      OUT Successful remote access by 10.11.1.33:7856
  </pre>
  
  ### <a id='cell'></a>CELL ###
  
  The Diego cell emits CELL logs when it starts or stops the
  app. These actions implement the desired state requested by the user.
  The Diego cell also emits messages when an app crashes.
  
  For example:
  
  <pre class="terminal">
  2016-06-14T13:44:38.14-0700 [CELL/0]     OUT Successfully created container
  </pre>
  
  
  ### <a id='dea'></a>DEA ###
  
  