Semantic slogging!

The whole point of using RSS 1.0 for the service logs was to ensure that the data captured in the slog(s) carried some semantic meaning. Therefore, it will be necessary to create an RDF schema for classifying slog entries. The most important area will be error logs. It will be useful to classify errors so that an administrator can query a set of logs and obtain statistics on the types and frequencies of errors that are occurring in services, be they local or distributed. Usage patterns and the like can be inferred from the entries in activity slogs. Through an administrators interface, it should be possible to interrogate a slog and attach additional/new classifications to slog entries.

Should slogging be provided by a web service?

There is the danger of getting a bit 'web service happy', but if service logging was provided by a web service then you could either centralize or distribute service logging as you see fit and the whole logging system could become a self contained entity. I guess it would lead to a lot of unnecessary traffic as requests are made to 'slog this for me please'. But then again the service making the request could get on with it's work while another gets on with the tedious job of writing log stuff out to a file system.

Administering slogs

An administrator's interface for managing, reviewing an maintaining the service logs would be a useful tool. The administrator would be able to view all logs (slog aggregator) and in the case of distributed services there could be many, and from the one interface manually archive, clear, interrogate, and configure the service logs.

Need service calls to archive/clear logs

It is very important that there are service calls available to archive and clear log files remotely. It would then be possible to have cron jobs running that archived the logs at regular (daily, weekly depending upon usage I guess) intervals.

Where do log entry links lead?

When a log is presented as an RSS feed, by definition the feed is a summary, and therefore each entry should be a summary of the activity and/or error. Therefore, the item's link should point to the full log entry. In the case of an activity log entry, the link's target will be a full description of the activity and include all metadata available. For an error log you will have access to the exception stack trace and a link (mailto: or similar) that can be used to submit the details of the exception (plus comments) to the service provider.

The furtherance of slogging

I have been 'slowly' adding to the service log by building up the parts of the log feed. I originally chose RSS 1.0 because I wanted the RDFishness but I wonder whether the overhead is really worth it. I mean I could use RSS 2.0 which is cleaner and still have the namespaced metadata components that I want. But, then again I think I'll stick with it because this is my project, my work, my time and therefore it's my call :)