CA Service Management

 View Only
  • 1.  Audit Log Options

    Posted Jun 02, 2016 10:58 AM

    Does anyone have any experience with the Audit Log options in SDM?  We're looking to install the audit_ins and audit_upd options and I'm wondering what to expect as far as any performance issues on the database - we're running SQL 2008 on a Windows 2008 server with approximately 400 concurrent users at peak times.  Any feedback would be appreciated!



  • 2.  Re: Audit Log Options
    Best Answer

    Posted Jun 02, 2016 02:19 PM

    Hi Steve -  in the documentation wiki the audit log options are explained here:

    https://docops.ca.com/ca-service-management/14-1/en/administering/administering-ca-service-desk-manager/options-manager#OptionsManager-AuditLogOptions

     

     

    With that, as it states there, when these are turned on, every insert and update is tracked - which as you know can be a lot, and can cause the audit log tables to grow VERY quickly.  Unfortunately there is not currently a way to track just certain changes to certain objects etc.    This can cause other problems besides performance.  We have very few customers using those options, so I dont have much of a benchmark or point of experience to talk about the effects of performance, it would be something you would need to test out in your environment to see how it reacts.

    Hope this helps a bit.

    Thanks,

    Jon I.



  • 3.  Re: Audit Log Options

    Posted Jun 06, 2016 03:13 AM

    Hello Steve,

     

    I would echo what Jon has said.

     

    The question to ask is not "What can we track?" but "What do we NEED to track?" The latter is typically a much smaller set than the former. It is much better suited to a business cost-benefit analysis.

     

    A talk to the auditors, or whoever is driving this, will get better requirements.

     

    The end result is - as Jon indicated - that most sites do not turn on auditing. Instead they figure out how much they really need to track, and how to do it.

     

    There is a lot of scope for information which may suffice:

    • Archived BOXI reports which show the system state of play.
    • The session_log to track user logins.
    • Notifications on key entries that are then archived.

     

    And if worst comes to worst, there is always customisation available for tracking key information.

     

    Thanks, Kyle_R.



  • 4.  Re: Audit Log Options

    Posted Jun 07, 2016 12:36 PM

    Hello ssonderman and thanks to and Kyle R and Jon Israel for their input.

     

    to add to that track

     

    We do audit_log on both insert and update and we either have increased the number of object to be audited as per our policy requirements.

     

    With correctly sized architecture we don't have noticeable performance degradation with audit be turned on (as an MSP we run significant amount of separate instances and some of our setup are more that significantly large compare to yours).

     

    The most important part as mentioned by Jon and Kyle is the grow of the audit_log so this is important to have procedure to purge that table frequently to the minimal need for online access and move those data to an offline reporting DWH for historical perspective and be compliant with your company auditing policy.

    The purge of the table accomplish 2 things:

    -  keep the table size acceptable for disk usage and related costs.

    - increase query performance when trying to retrieve data by viewing the log in the GUI. There is mostly no impact on the others (like update any object) as insert operation are well optimize in modern SQL and straight forward.

     

    Note that for better performance you can also dedicate a SDM virtual dbagent for that table using parameters in the nx.env at the cost of the RAM for it (around 10mb per agent if I recall but also depend on your cache settings).

     

    So to summarize from my experience the auditing is not a big deal in condition you keep it to the real business requirements, size and finetune your architecture according and correctly define procedures to keep MDB healthy.

     

    just my 2 cents, Hope this help to make your own opinion.

     

    /J



  • 5.  Re: Audit Log Options

    Posted Jun 07, 2016 07:45 PM

    Thanks Jerome,

     

    Some seriously useful insights there.

     

    Just to highlight the reason why some of us are leery of auditing is this part:

     

    >> the auditing is not a big deal in condition you keep it to the real business requirements, size and finetune your architecture according and correctly define procedures to keep MDB healthy.

     

    As Han Solo said in a different context, but applicable to so many things performance related in SDM: "That's the real trick, isn't it?"

    It has occurred that the business process has been little more than "What's this? Auditing? Sounds cool! Let's turn it ALL ON. We NEED it."

    Merriment ensues.

     

     

    Not saying that is likely to apply to anyone who's actually taken the time to research this thread of course. But the scars . . . they run deep. :-)

    Kyle_R.