> > From: [email protected] [mailto:[email protected]] On > > Behalf Of Peter Portante > > Sent: Monday, 8 August 2011 10:49 AM > > > > How 'bout random sample request profiling? > > Profiling for monitoring and activity estimation purposes - isn't that the > point of the sFlow set of patches mentioned a few times on list?
The sFlow patches bother me as I'd prefer to be able to generate sFlow events from a proper internal system, as opposed to the inverse. You shouldn't have to be an sFlow consumer, and it's much more difficult to vary the type of data you'd be ingesting (full headers, vs partial, vs item bodies, etc). The internal statistical sampling would be the start, then come methods of shipping it. You could send to listeners connected over a socket, or have a plugin listen as an internal consumer to the samplings. The internal consumer could provide "builtin" statistical summaries the same as an external daemon could. Which could make everyone happy in this case. I like the sFlow stuff, I'm just at a loss for why it's so important that everything be generated on top of sFlow. So far nobody's addressed my specific arguments as listed above. -Dormando
