Logging suggestion

[Guy Rixon]

It sounds reasonable to concentrate the log-harvesting interface in a special
service for a group of services. However, if we do so, we then need a way of
recording the log-harvesting endpoint in the resource document for each
service.

It's implicit in the current support-interfaces spec that the extra interfaces
are extra operations on the main endpoint of a service. Therefore, they don't
need to be separately registered since their access URLs are obvious. This
arrangement isn't necessary and we can change it if we wish; but we should be
clear about this.

On Thu, 8 Dec 2005, Paul Harrison wrote:

> I think that I agree with Doug and Kevin on this - imposing a
> requirement for a logging interface on *every* service is a significant
> barrier to implementation, as this sort of interface does not fit easily
> with existing low level logging libraries, so some sort of adapter layer
> would have to be written in every service to gather and send the
> requested information.
>
> Having a localised logging service that was able to accept log
> information in a number of ways that recognised the facilities of
> existing log libraries - e.g. in java log4j has serveral methods
> available for remote logging, that are not necessarily web services. The
> implementer of a web service could chose the easiest way to send the log
> information to the localised log collecting/storing server - and I think
> that push is more appropriate.
>
> In this way there could be a small number of implementations of the log
> collecting server, which could then potentially do more complex actions
> such as periodically storing gathered logs in a vostore.
>
>
> Doug Tody wrote:
> > Hi Ani -
> >
> > On Wed, 7 Dec 2005, Ani Thakar wrote:
> >
> >> There are two different logging services that we are talking about here,
> >> I think:
> >>
> >>     - site logging
> >>     - VO logging
> >>
> >> The first is the logging service at a given site that may or may not
> >> provide a query interface for users to view the logged data.  This logs
> >> all the services at a given site (e.g. STScI).
> >>
> >> The second is the VO-wide log harvesting that collects the logs from all
> >> the VO services in a VO domain (e.g. NVO).
> >>
> >> Which one do you mean by "centralized logging service"?
> >
> >
> > The suggestion was that the VO logging interface and functionality not
> > be provided by individual services, but by some centralized site logging
> > service (specific to VO, not httpd logging or some such)) which the
> > domain-wide VO log harvestor can access.
> >
> >
> >> The logging interface in the support interfaces draft only deals with
> >> the minimum that any site or service needs to do to get its log data
> >> harvested to the VO logging VOStore.
> >>
> >> It's fine if each site has a central logging service that has a log
> >> harvesting interface hanging off it that the VO log harvester can use to
> >> retrieve log data from it periodically.  Each individual service does
> >> not need to support a log harvesting interface.
> >
> >
> > This is what was meant by a "centralized logging service" for a site.
> >
> >
> > I still think it would be good if low level infrastructure capabilities
> > like
> > service registration, logging, heartbeat, etc., could function
> > independently
> > of complex high level data management functionality such as VOStore.
> >
> >     - Doug
> >
>
>
> --
> Paul Harrison
> ESO Garching
> www.eso.org
>

Guy Rixon 				        gtr at ast.cam.ac.uk
Institute of Astronomy   	                Tel: +44-1223-337542
Madingley Road, Cambridge, UK, CB3 0HA		Fax: +44-1223-337523