Assured: The Isode Blog

Log Streams and XML

In my previous blog on the new R11.0 logging system, I explained our four basic logging functions (event; audit; debug; pdu) and an outline of functionality.   

One of the key features of the new system is the ability to have multiple logging streams.   This is configured using XML, which I'll show in some examples below.  In simple configurations, configuration is more likely to be done with our GUIs which are built over this underlying configuration.

The following examples shows a number of features:

<log-stream name="Events" clear="yes">

<log-file>dsa-event.log</log-file>

<log-event action="on" level="error critical authfail fatal warning"/>

</log-stream>

This creates a log stream that is recorded into a file, and logs certain classes of errors.  This would be a typical setup where the log records all events that an operator would need to take notice of.

<log-stream name="Events" clear="yes">

<log-file>dsa-event.log</log-file>

<log-event action="on" level="error critical authfail fatal warning"/>

<log-event action="off" facility="DSA" level="*"/>

<log-event action="off" facility="DSA_DISP" level="*"/>

<log-event action="off" facility="DSA_SECURITY" level="*"/>

</log-stream>

This second example shows a system log stream, which maps to syslog on Unix and Windows Event Manager on Windows.   It is useful where system logging is used as a key part of system management framework, particularly where this data is fed to third party management tools such as Tivoli or HP Openview (which support syslog).

This example also shows independent control of logging for different "facilities", which are modules within products.   Different logging information can be sent to different streams, and you can have as many streams as you want.

<log-config>

<log-stream name="Events">

<log-event action="on" facility="PP" event="REPORT_DISCARD"/>

</log-stream>

</log-config>

This final example shows how specific control can be applied for an individual event.  This might be used to hide or enable events, which are of interest to an operator.  For example an ISP would probably not want to see connection failures, whereas a high assurance messaging provider would.   Special streams can also be created, which migh have special processing for certain key events, such as the one shown here (discard of a delivery report, which cannot be processed). 

Steve

Blogs and Consultation

The Institute for Public Policy Research (IPPR) has opened up its Manifesto for a Digital Britain to public comment via its blog. Using a blog as part of a consultation exercise is becoming increasingly common and something we hope to emulate here in the future.

The Manifesto itself might be of interest to readers of this blog, as amongst the questions it poses is how public policy might support ICT developments and infrastructure improvements.

Will.

Why are we blogging? (Part 2)

Steve asked why we are blogging. To the reasons he listed I'd add:

1. As Micah Dubinko says here, the process of blogging encourages a more informal approach to even the most formal of documents (like whitepapers). Even though the current structure of our whitepapers is fine for our mostly technical audience, a less formal introduction to a whitepaper via a blog might help place it in context.
2. The use of trackbacks (as in the post above) may lead to a wider audience.
3. Our 'mass' communications with customers and prospects invariably concentrate on items directly relevant to our products and solutions. The blog, as a more informal medium, will allow us to introduce readers to other stories that are relevant to the markets we are in but not so closely aligned as to warrant inclusion in our regular roundup emails.