anchor.diff:      ...
   </pre>
   
  -### <a id=‘log-ordering’></a> Log Ordering
  -
  -Ensuring log ordering in drains can be an important for both operators and developers. However, the Loggregator Firehose does not offer a deterministic routing mechanism for ordering.  
  -
  -For operators configuring syslog drains, it is useful to note that:
  -
  -* Diego uses a nanosecond-based timestamp that can be ingested properly by Splunk. For more information, see [these instructions](https://answers.splunk.com/answers/1946/time-format-and-subseconds.html).
  -* The Elastic Stack can ingest the nanosecond timestamps but only supports millisecond precision, so timestamps are truncated. For more information, see [ELK's date type](https://www.elastic.co/guide/en/elasticsearch/reference/current/date.html) and the relevant [issue](https://github.com/elastic/elasticsearch/issues/10005).
  -
  -If you are developing a client that displays a stream of Cloud Foundry logs to users, consider ordering the logs to improve the debugging experience for your user. The following are general tips for ordering logs:
  -
  -* Batch the logs and display whatever logs you have in that timeframe sorted by timestamp. This technique is good for CLIs. 
  -* For web clients you can use dynamic HTML to insert older logs into the sorting as they appear. This is nice because by the time a user grabs the content for a copy paste, the logs will likely be both complete and in order. 
  -* 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 make your app reformat your stack trace messages so any newline characters are replaced with a token. Then, you can make your log parsing code replace that token with newline characters again to display the logs properly in Kibana.
  +### <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.
  
positive.code: 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
  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 ##
  
negative.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 cannot 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.
  