anchor.diff:  
   A user is able to query the events endpoint with various filters.  For example, a user could query for all events of a given type, or all events associated with a
   resource since a given timestamp.
  +
   Allowed filters are enumerated on the [API documentation](https://apidocs.cloudfoundry.org/latest-release/events/list_all_events.html).
   
   ### External Auditing Warehouse
  
positive.code: 2018-09-04T17:03:24.00-0700   audit.app.create           admin   instances: 1, state: STOPPED, environment_json: [PRIVATE DATA HIDDEN]
  ```
  
  This command will show the 50 most recent events for that application.
  To see more events, or events that are not attributed to an application, use the following Cloud Foundry API endpoint:
  
  `GET /v2/events`
  
negative.code: ## When are events created?
  
  Most events are created when a user acts upon a resource.
  For example, a user issuing a `cf stop APP_NAME` command causes an `audit.app.stop` event to be created and associated with that user.
  
  * **Service events** (`audit.service*`) are created after the service broker has approved an interaction.
  
  * **Crash events** (`audit.app.crash`) are created when Diego marks an application instance as crashed.
  
  * **Blob events** (`blob.remove_orphan`) are created by a daily clean up job and do not represent user action.
  
  ## Considerations
  
  Audit events can be created at any point during the execution of the action they describe. This means the action associated with the event is not guaranteed
  to have succeeded.
  
  The audit events table can grow to be very large. So, for performance considerations, certain database migrations may result in the truncation of this table.
  In other words, this means that a deployment with such a migration will result in a loss of events.
  
  These migrations are exceedingly rare and any release of capi-release that includes one will note this behavior prominently in its [release notes](https://github.com/cloudfoundry/capi-release/releases).
  
  The order of audit events returned from the API may not match the sequence of events that occurred in the system.
  
  Do not rely on timestamps to sequence events; they may come from different Cloud Controller instances whose times could be slightly mismatched.
  
  Audit events expire after 31 days by default. This is configurable using the capi-release manifest property `cc.audit_events.cutoff_age_in_days`.
  