Event Log Format and Details

Event log streaming sends all transaction data via syslog. It should be noted that the data is simply raw transaction data with no hierarchical grouping of parent and associated child transactions. If required, the remote syslog server must recreate a transaction tree hierarchy as part of log processing.

The following describes the format of an event log entry. The event log file contains single lines of data in JSON format, with meta data and data elements.

  • Meta data has event_ - attributes, and describes the type of event log.

    For example, for "event_type": "transaction.finalise": when a transaction is finalized in the system:

    {
      "event_level": "INFO",
      "event_type": "transaction.finalise",
      "event_source": "voss-un1",
      "event_id": "abc08383-5adb-48cb-8181-ef6adc546791",
      "event_timestamp": "2017-12-04T12:18:07.025595Z",
      "event_message": "Transaction 1267 finalised.",
      "event_data": {
      [...]
    
    • event_id: Unique ID associated with the log entry.
    • event_message: Message specified during log entry creation.
    • event_level: Log level with which log entry was created.
    • event_timestamp: Datetime string of timestamp when the log entry was created.
    • event_type: Unique type associated with event described by log entry.
    • event_source: Hostname of host from which log was created.
    • event_data: Additional data associated with log entry, containing a transaction object.
  • Data is recorded in the "event_data" element of the event type, with each event type determining its own event_data JSON structure.

    For example, for "event_type": "transaction.finalise", the event_data is "transaction", the start of the structure is for example:

    [...]
     "event_data": {
       "transaction": {
         "status": "Success",
         "username": "sysadmin",
         "rolled_back": false,
         "resource": {
           "hierarchy": "1c0nfmo2c0deab90da595101",
           [...]
    
    • transaction: Transaction specific data.
      • action: Transaction’s action field, which is displayed by the Admin Portal in its Action field.
      • completed_time: Datetime string of the transaction’s completed_time field, which is displayed by the Admin Portal in its Completed Time field.
      • detail: Transaction’s detail field, which is displayed by the Admin Portal in its Detail field.
      • duration: Transaction’s duration field (in seconds), which is displayed by the Admin Portal in its Duration field.
      • hierarchy: Transaction’s execution_hierarchy field.
      • message: Transaction’s exception_message field (if any), which is displayed by the Admin Portal in its Message field.
      • operation: Transaction’s operation field.
      • parent_pkid: Transaction’s parent field (if present, can be used to identify a parent transaction pkid value and any sub-transactions).
      • pkid: Transaction’s _id field (this value will be the parent_pkid of sub-transactions if there are any).
      • priority: Transaction’s config['priority'] field, which is displayed by the Admin Portal in its Priority field.
      • processor_host_name: Transaction’s processor_host_name field, which is displayed by the Admin Portal in its Processor Host Name field.
      • resource: resource object associated with transaction
        • hierarchy: Transaction’s resource hierarchy field.
        • model_type: Transaction’s resource model_type field, which is displayed by the Admin Portal in its Model Type field.
        • pkid: Transaction’s resource pkid field.
      • rolled_back: Transaction’s rollback field, which is displayed by the Admin Portal in its Rolled Back field.
      • started_time: Datetime string of the transaction’s started_time field, which is displayed by the Admin Portal in its Started Time field.
      • status: Transaction’s status field, which is displayed by the Admin Portal in its Status field.
      • submitted_time: Datetime string of the transaction’s submitted_time field, which is displayed by the Admin Portal in its Submitted Time field.
      • submitter_host_name: Transaction’s submitter_host_name field, which is displayed by the Admin Portal in its Submitter Host Name field.
      • txn_seq_id: Transaction’s txn_seq_id field, which is displayed by the Admin Portal in its Transaction ID field.
      • username: Transaction’s username field, which is displayed by the Admin Portal in its Username field.

A full example of a transaction.finalise type event log entry is shown below (formatted multiline):

{
  "event_level": "INFO",
  "event_type": "transaction.finalise",
  "event_source": "voss-un1",
  "event_id": "abc08383-5adb-48cb-8181-ef6adc546791",
  "event_timestamp": "2017-12-04T12:18:07.025595Z",
  "event_message": "Transaction 1267 finalised.",
  "event_data": {
    "transaction": {
      "status": "Success",
      "username": "sysadmin",
      "rolled_back": false,
      "resource": {
        "hierarchy": "1c0nfmo2c0deab90da595101",
        "model_type": "data\\/Countries",
        "pkid": "5a203da004222e1c67f93c83"
      },
      "processor_host_name": "voss-un1",
      "pkid": "233cd3b1-8acc-4702-bd64-90653c02cd81",
      "hierarchy": "1c0nfmo2c0deab90da595101",
      "started_time": "2017-12-04T12:18:04.946000Z",
      "detail": "Australia",
      "completed_time": "2017-12-04T12:18:07.022000Z",
      "priority": "Normal",
      "duration": 2.076404,
      "submitted_time": "2017-12-04T12:18:04.461000Z",
      "submitter_host_name": "voss-un2",
      "txn_seq_id": "1267",
      "parent_pkid": null,
      "action": "Update Countries",
      "message": null,
      "operation": "update"
    }
  }
}