Child pages
  • Design Decisions - Get Audit Trails
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Current »

Design decisions concerning Get Audit Trails

  • The Bit repository collection defines the level for securing logs (may be bit preservation of logs for some pillars, internal logs for others) and the method (may be pillar-to-pillar or supported by a log client)
    • We will 'pre-define' some levels
  • We define 2 functionality clients: Status and Audit Trails
    • Status is 'how is the system'?
    • Audit Trails is about how a data object has been (historical)
  • Which alarms become part of the Audit Trail is up to the Alarm Service, which will be a contributor to the Get Audit Trails functionality.
  • The message flow (and file exchange) will not be part of the Audit Trail in general. The actions performed as result of the messages will become part of Audit Trails for involved clients and pillars. The Monitor Service may contribute communication information to the Get Audit Trails functionality.
  • No labels