anchor.diff:  
   1. Filter log messages by timestamp. The possibilities depend on your app. Our example filters for HTTP GET events only.
   
  -### <a id='bind'></a>Binding a Third-Party Log Management Service Instance ###
  +## <a id='use'></a>Using a Third-Party Log Management Service ##
   
  -Three-step process:
  -Configure the log management solution to treat your application as a source of data.
  -Create a user-provided service instance appropriate for the log management solution.
  -Bind the service instance to the application.
  -Binding configures a drain on the application. A drain is simply a place to find two pieces of information:
  -The URL and port number needed to communicate with the service. This is called a syslog URL.
  -Cloud Foundry uses the syslog URL to route messages to the service. The service uses the application instance identifier to identify the source of messages.
  +To drain logs to a third-party log management service from an application and the relevant Cloud Foundry components, you complete three steps.
  +In general terms, the process looks like this:
   
  +1. Configure the log management solution to treat your application as a source of data.
   
  -### <a id='types'></a> Types of Logs ###
  +1. Create a user-provided service instance appropriate for the log management solution.
   
  -We usually identify different types of logs by origin. Every <%=vars.cf_distro%> component that generates logs inserts a three-letter code to identify messages as originating from that component. Some components use more than one code because they emit more than one type of log. Applications use the code APP/0 (“app instance zero”) for the first instance and increment the digit for every instance after that. These codes appear in the second field, enclosed in square brackets, in logs you view in the CLI.
  +1. Bind the service instance to the application.
  +
  +Review the next three sections to learn critical details about each of these steps.
  +
  +### <a id='config'></a>Configure the service to accept traffic from Cloud Foundry ###
  +
  +You must configure the third-party log management service to accept traffic from your Cloud Foundry.
  +
  +To do this you need the external IP addresses of the two NAT boxes from which your Cloud Foundry will send log traffic to the service.
  +Ask your Cloud Foundry administrator for these IP addresses.
  +(NAT boxes are systems responsible for Network Address Translation, not to be confused with the NATS messaging protocol.)
  +
  +You also need to obtain the special URL, called a syslog URL, that the service makes available as an endpoint for incoming log data.
  +The URL is special because its protocol is `syslog`.
  +It also includes a port number.
  +For example:
  +
  + `syslog://logs.example.com:1234`
  +
  +Cloud Foundry uses the syslog URL to route messages to the service.
  +
  +Further configuration details may vary depending on service provider.
  +
  +### <a id='create'></a>Create a user-provided service instance with a syslog drain ###
  +
  +Now you need a service instance to bind to your app.
  +In this case, you create a user-provided service instance using the `cups` command with the `-l` option and the syslog URL you obtained earlier.
  +See [User-Provided Services] (./user-provided.html#user-cups).
  +
  +Now the service instance and the syslog drain exist, but the service install still needs to be bound to the app.
  +
  +### <a id='bind'></a>Bind the service instance to the application ###
  +
  +See [Binding User-Provided Service Instances to Applications](user-provided.html#cups-example).
  +
  +## <a id='types'></a> Types of Logs ##
  +
  +We identify different types of logs by origin. Every Cloud Foundry component that generates logs identifies itself with a three-letter code. Some components use more than one code because they emit more than one type of log. Applications use the code APP/0 (“app instance zero”) for the first instance and increment the digit for every instance after that. These codes appear in the second field, enclosed in square brackets, in logs you view in the CLI.
   The primary types of logs and their codes are as follows:
   
   <table border="1">
  
positive.code: 
  _This page assumes that you are using cf v6._
  
  Third-party solutions allow you to view and analyze logs from your application to satisfy compliance or other business requirements. Providers whose products or services work with Cloud Foundry include Logentries, logstash, Papertrail, and Splunk.
  To your application, the logging solution is a service. Their relationship can be described in terms of source, sink, and drain:
  
  * The application is an information source.
  * The logging service is an information sink.
  * A drain configured on the application helps the source communicate with the sink.
  
  Your notion of information source should include the system components that interact with the app, not just the app itself. For any one application, logs come from each instance of the app and also from <%=vars.cf_distro%> system components. For example, when a <%=vars.cf_distro%> Router routes an HTTP request to an app, the Router records that event in a log.  Logs tell you both what your app does and what the system does with your app.
  
  The Loggregator component of <%=vars.cf_distro%> consolidates all logs of actions that directly affect the app. In the Command Line Interface (CLI), you can view the entire Loggregator output or filter it to select a subset of logging information. Viewing logs in the CLI is essential preparation for working with a logging service.
  
  Loggregator keeps a limited amount of logging information in memory; the limit depends on the hardware where <%=vars.cf_distro%> is deployed. Eventually the newest logging information replaces the oldest. Loggregator keeps none of this logging information if its VM crashes and restarts. To persist larger amounts of logs, you should set up your application to drain logs to a third-party logging service.
  
  ## <a id='cli'></a>Preparation: Viewing Logs in the Command Line Interface ##
  
  The `cf logs <app_name>` command enables you to view logs in the CLI. You can view all the logging information that Loggregator receives or possesses, or filter its output using shell commands. The examples below provide excerpts from log output, edited for brevity.
  Note: The filtering examples use the Linux `grep` command. The filtering command to use and its syntax may differ, depending on your operating system and shell.
  
  1. cf logs <app_name> displays all of the logging information that Loggregator receives in (almost) real time.
  
  
negative.code: 	</colgroup>
  	<tbody>
  		<tr>
  			<th style="text-align: center;" class="confluenceTd">
  				Origin
  			</th>
  			<th style="text-align: center;" class="confluenceTd">
  				Code
  			</th>
  			<th style="text-align: center;" class="confluenceTd">
  				Notes
  			</th>
  		</tr>
  		<tr>
  			<td style="text-align: center;" class="confluenceTd">
  				Application and instance
  			</td>
  			<td style="text-align: center;" class="confluenceTd">
  				`APP/0`
  			</td>
  			<td style="text-align: center;" class="confluenceTd">
  				0 is the first instance, 1 is the second, and so on.
  			</td>
  		</tr>
  		<tr>
  			<td style="text-align: center;" class="confluenceTd">
  				Cloud Controller
  			</td>
  			<td style="text-align: center;" class="confluenceTd">
  				`API`
  			</td>
  			<td style="text-align: center;" class="confluenceTd">
  
  			</td>
  		</tr>
  		<tr>
  			<td style="text-align: center;" class="confluenceTd">
  				Staging
  			</td>
  			<td style="text-align: center;" class="confluenceTd">
  				`STG`
  			</td>
  			<td style="text-align: center;" class="confluenceTd">
  				The DEA emits these messages beginning when you deploy an app, and ending once the droplet has been uploaded.
  			</td>
  		</tr>
  		<tr>
  			<td style="text-align: center;" class="confluenceTd">
  				Droplet Execution Agent
  			</td>
  			<td style="text-align: center;" class="confluenceTd">
  				`DEA`
  			</td>
  			<td style="text-align: center;" class="confluenceTd">
  				The DEA emits these messages beginning when it starts the app.
  			</td>
  		</tr>
  		<tr>
  			<td style="text-align: center;" class="confluenceTd">
  				Router
  			</td>
  			<td style="text-align: center;" class="confluenceTd">
  				`RTR`
  			</td>
  			<td style="text-align: center;" class="confluenceTd">
  
  			</td>
  		</tr>
  	</tbody>
  </table>
  
  ## <a id='format'></a> About Log File Formats and Third-Party Log Management Software  ##
  
  Loggregator formats logging data that it sends to third-party services according to [RFC 5424](http://tools.ietf.org/html/rfc5424), titled *The Syslog Protocol*.
  Logs viewed in the CLI are not in syslog format.
  Third-Party Log Management Software is defined in [RFC 6587](http://tools.ietf.org/html/rfc6587), titled *Transmission of Syslog Messages over TCP*.
  