4 Auditing
Ethan Arrowood редактировал(а) эту страницу 2018-09-19 14:01:25 -04:00

Auditing

This document defines how Platform Chaos audits chaos events. It lists what is tracked and how it is formatted.

Tracked Data

When a chaos event is initiated or terminated through an API or CLI the following properties are recorded and exported through a JSON object.

Every chaos event will be logged. The general structure of an event log for an API or CLI initiated event is defined below:

  • event log (Object)
    • id (String)
      • GUID unique to this event instantiation
    • type (String)
      • One of 'initiate', 'terminate'
      • As extension functionality grows, more types can be added to this list.
      • These exist for the purpose of filtering audits.
    • user (String)
      • Some identifiable piece of information specifying which user executed the chaos event
    • system (String | Object)
      • Some identifiable piece of information specifying which system the chaos event was executed from
      • If more system information can be provided, do so in the form of an object
    • date (String)
      • UTC timestamp of chaos event initiation
    • resource (String)
      • String representation of the resource targeted by the chaos
      • This is typically generated by chaos resgen and looks like so: "subId/resGrpId/resName"
    • event (String)
      • Chaos event identifier (can be name, uri, or something else) that denotes what was executed

Here is an example template:

{
  "id": "",
  "type": "initiate",
  "user": "",
  "system": "",
  "date": "",
  "resource": "",
  "event": ""
}

Additionally if an Extension emits an event, the logging schema will be slightly different.

  • event log (Object)
    • auditId (String)
      • A unique identifier for the emitted event
    • eventName (String)
      • Some identifiable piece of information specifying the chaos event
    • system (String | Object)
      • Some identifiable piece of information specifying which system the chaos event was executed from
      • If more system information can be provided, do so in the form of an object
    • date (String)
      • UTC timestamp of chaos event initiation
    • resources (String)
      • String representation of the resources targeted by the chaos
      • This is typically generated by chaos resgen and looks like so: "subId/resGrpId/resName"
    • extensionLog (Object)
      • an optional object extension authors can utilize to log pertinant data related to their module.
{
  "auditId": "",
  "eventName": "",
  "system": "",
  "date": "",
  "resources": "",
  "extensionLog": {}
}

Example

Check the below code snippet link for an implementation example. It is from a published extension that is implementing auditing through the sdk.

https://github.com/trstringer/azure-chaos-fn-webapp-startstop/blob/master/start/index.js#L1-L35

Notice how in line 14 the auditer is being initialized with an eventName and resources string. After that point, context.log is called as usual. Every time it is called, audits are being added to the SDK's internal audit list. These audits are appended to the body of response when context.done is called (on line 28 or 33).