NTS Event Trace Policy - Driver add-on for Event Tracing at Levels 0 and 1

4 Likes
over 1 year ago

Background to the NTS Event Trace Policy

The attached package of three policies started as a single policy and Global Configuration Value (GCV) setting to enable dumping of the driver event document on Input from the Vault or Application when running at trace level 3 was not possible. This could be found in production environments where turning up the trace level of a driver would result in negative performance impacts due to a busy system. Trouble shooting in those circumstances was often challenging as not knowing what the initial event was required a crystal ball that was often in short supply. Between various consultants and support staff the initial policy was developed and enhanced over time to trace out some basic event information as the first action of a driver on either the Publisher or Subscriber channels.

Over time this policy was further enhanced with additional capabilities to trace out the full received event and to ensure confidentiality was maintained in all data dumped to the trace file. The current implementation of this policy is composed of three separate policies. Two policies (drv-nts-traceEvent-Input and drv-nts-traceEvent-Output) act as wrappers to the third policy (drv-nts-traceEvent). The first two policies use a seldom used capability to "include" policies within policies. Here the third policy is "included" within the other two to allows local variables to be passed to the third policy. The third policy does all the actual work of tracing out a short list of basic information or manipulating a node-set variable of the event document before it is dumped to the trace file. The third policy is not directly linked to the driver, so it does show up as un-linked if viewed in iManager. This is often an indication of an orphaned policy may need to be deleted manually, but doing that will break the driver in this situation.

Neat features of this implementation include:

  1. the use of the "Include" functionality
  2. the use of wrapper policy to set local variables to identify channel and direction
  3. the use of a direct Java call to get the current driver trace level
  4. manipulation of a node-set variable representing the complete event document

This package can be added to any existing driver and the GCV configured as desired. As the configuration is controlled through a GCV it does require a driver restart to change the desired action after modifying the GCV.

Historical note: This policy started life back in the days of "Novell Technical Support", which since moved to NetIQ Support after that. As the policy was initially moved into a packaged model in the NetIQ days, it retains the references to NTS.

The NTS Event Trace Policy

A packaged and updated set of policies based on the original NTS Trace Event Policy created to assist troubleshooting of driver issues when the Driver Trace Level needs to be set to 0 or 1 for any reason.

Three polices and one GCV resource are included in the package to provide the desired event data trace output. The GCV nts.eventTrace, inlcuded in the drv-ntx-traceEvent-GCV resource, controls the output generated. Tracing of Event Data is only generated if the driver Trace Level is set to 0 or 1 and the nts.eventTrace GCV is set to 1 or 2. Any Driver Trace Level setting of 2 or higher will disable the additional event trace output.

The values for the nts.eventTrace GCV are:
0 = debug event trace disabled ==> no additional event data trace information is generated
1 = debug event trace with minimal details ==> five lines of basic event data details are generated (sample below)
2 = debug event trace full details ==> full event data information is included in the trace file

No event data information is included in the trace file for the events of: init-params, query-schema or schema-def.

The full details event data trace output will have child elements removed for <password>, @attr-name="nspmDistributionPassword" and attributes where is-sensitive=true" and replaced with the text "!-- content suppressed --". This will ensure security of password and sensitive attributes is not included in full detail event trace information.

Two Policies are used as wrappers to generate header statements that identify the Policy Set that is being processed when generating event data information.

The Policy drv-nts-traceEvent-Input is linked as the first policy in the Subscriber Event Transform Policy set and the Input Transform Policy set. This policy sets the Header statement to "******** Input Event - (...) XML Doc ********", with the (...) replaced with the short name for the linked Policy set -> (sub-etp) or (itp). This policy then 'includes' the drv-nts-traceEvent Policy to generate the rest of the basic or detailed event data added to the driver trace file.

The Policy drv-nts-traceEvent-Output is linked as the last policy in the Publisher Command Transform Policy set and the Output Transform Policy set. This policy sets the Header statement to "******** Output Event - (...) XML Doc ********", with the (...) replaced with the short name for the linked Policy set -> (pub-ctp) or (otp). This policy then 'includes' the drv-nts-traceEvent Policy to generate the rest of the basic or detailed event data added to the driver trace file.

Minimal details event data format:
******** Input Event - (...) XML Doc ******** {see above for (...) values}
Operation:
Object Class (if available):
Object (src-dn):
Association (if present):
Event-id:

******** Output Event - (...) XML Doc ******** {see above for (...) values}
Operation:
Object Class (if available):
Object (src-dn):
Association (if present):
Event-id:

The combination of the header statements and the previous Trace line (with either '....ST:' or '....PT:') can be used to identify the channel and Policy Set processing the event data.

Channel and Header examples:

Subscriber Input (eg: change from IDV)
[02/12/20 09:40:30.958]:driver ST:
******** Input Event - (sub-etp) XML Doc ********

Subscriber Output (eg: change or query sent)
[02/12/20 09:40:30.976]:driver ST:
******** Output Event - (otp) XML Doc ********

Subscriber Output Response (eg: status of change or query response from application)
[02/12/20 09:40:31.137]:driver ST:
******** Input Event - (itp) XML Doc ********

Publisher Input (eg: change from Application)
[02/12/20 09:41:15.473]:driver PT:
******** Input Event - (itp) XML Doc ********

Publisher Output (eg: change sent to IDV)
[02/12/20 09:41:15.527]:driver PT:
******** Output Event - (pub-ctp) XML Doc ********

Publisher Output Response (eg: change status sent to application)
[02/12/20 09:41:15.538]:driver PT:
******** Output Event - (otp) XML Doc ********

 

I hope you enjoy learning from this set of policies and find it useful when trouble shooting in the future.

Cheers,

D

Comment List
Anonymous
  • OK, that is very clever... 

     

    This is my favorite part:

    com.novell.nds.dirxml.driver.Trace:getTraceLevel((com.novell.nds.dirxml.driver.Trace:new("level"))) < "2"

    You are checking the current trace level!  Coolio! I did not know you could do that!  

    Now you have me wondering what else we might be able to get access to in Policy with this approach...

     

     

Related Discussions
Recommended