Re: Cloud Logging Format

On Wed, Apr 04, 2012 at 02:19:07PM -0700, Gene Golovinsky wrote:
> On Wed, Apr 04, 2012 at 08:56:33AM -0700, Gene Golovinsky wrote:
> 
> > [Gene Golovinsky] Yes, the originator of the message, the actual
> > logging entity should be aware of the information populated into the
> > Syslog message
> 
> What is a logging entity? RFC 5424 talks about 'originators',
> 'collectors', and 'relays'. I hear you saying it is the syslog originator.
> [Gene Golovinsky] Yes, it is a syslog originator.
> 
> > If not, what does it take to distribute the necessary information to
> > the originators? Or is the idea that proxies add SDEs while forwarding
> > syslog messages?
> 
> > [Gene Golovinsky] Yes again. As a request for service (API call)
> > travels through processing nodes those nodes add SDs to the message.
> > Each node is aware of the context and can add appropriate SD.
> 
> I fail to understand this. Which API call? Who is calling this API?
> Which nodes add SDs to messages (presumably SYSLOG messages?). Are we now
> talking relays?
> [Gene Golovinsky] I am referring to some of the scenarios discussed in the
> examples in the draft. In "cloud" deployments in lots of cases actions
> result in response to a request for service. This request is typically
> done by calling a remote API (REST, or other Web Service like call). Such
> an API call typically comes to a front end Web Server and then dispatched
> to the backend. Backend may consists of multiple compute nodes. In some
> cases requested service is satisfied by several compute nodes. Each node
> should be able to add SDs to the log message. So these are probably not
> relays, but rather distributed originators. These are not to be confused
> with service gateways briefly discussed in the draft. Those gateways are
> for passing service request/response and are also originators.

I understand that you assume that a frontend passes information down
to the backend compute notes so that their implementation can put the
correct SDE into the SYSLOG messages.
 
> > I like to see how this can reasonably implemented and deployed.
> 
> > [Gene Golovinsky] I am not sure I understand this. It has been
> > actually implemented and deployed by several vendors in their "cloud"
> > implementations.
> 
> Such as? Sorry if I am ignorant. Do typical web servers do this sort of
> thing or do you have some specific application frameworks in mind?
> [Gene Golovinsky] No, the typical Web Server does not do this sort of
> thing. This is more appropriate for SaaS and IaaS environments. I know of
> several SaaS providers that implemented something like this and, at least
> one IaaS vendor.

I happen to run a normal web server in an IaaS environment. So I might
just be unlucky. Anyway, I like to see more discussion added to the
document how this is supposed to implemented and deployed. I like to
see less "could" language and see more "as done by XYZ" language or
even text explaining what information APIs need to move around to make
all this work.

And then there needs to be discussion the SDEs semantics and what they
really contain. For example, is it meaningful to identify a client by
an IP address in a world moving to shared NATs? What exactly are those
gateways? What exactly are the user identities and their formats?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>