anchor.diff:  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.
  +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
  +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
  -ensures that your app correctly writes logs to STDOUT and STDERR only.
  +ensures 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 ##
  
positive.code: See [Third-Party Log Management Services](../services/log-management.html).
  
  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 app
  logs.
  
negative.code:     ...
  </pre>
  
  ### <a id='log-ordering'></a> Log Ordering
  
  Ensuring log ordering in drains can be an important consideration for both operators and developers. 
  
  * Diego uses a nanosecond-based timestamp that can be ingested properly by Splunk. For more information, see [TIME_FORMAT and subseconds](https://answers.splunk.com/answers/1946/time-format-and-subseconds.html) in the Splunk documentation.
  * The Elastic Stack can ingest the nanosecond timestamps but only supports millisecond precision, so timestamps are truncated. For more information, see the [Date datatype](https://www.elastic.co/guide/en/elasticsearch/reference/current/date.html) in the Elasticsearch documentation and the [Date type has not enough precision for the logging use case](https://github.com/elastic/elasticsearch/issues/10005) GitHub issue.
  
  If you are developing a client that displays a stream of Cloud Foundry logs to users, you can order the logs to improve the debugging experience for your user. The following are general tips for ordering logs:
  
  * For CLIs, batch the logs and display the logs you have in that timeframe, sorted by timestamp.
  * For web clients, use dynamic HTML to insert older logs into the sorting as they appear. This creates complete, ordered logs.
  * Java app developers may want to convert stack traces into a single log entity. To simplify log ordering for Java apps, use the [multi-line Java message workaround](https://github.com/cloudfoundry/loggregator-release/blob/develop/docs/java-multi-line-work-around.md) to convert your multi-line stack traces into a single log entity.
  <br><br>By modifying the Java log output, you can force your app to reformat stack trace messages, replacing newline characters with a token. Set your log parsing code to replace that token with newline characters again to display the logs properly in Kibana.
  