sflow module and increasing useragent
moseleymark at gmail.com
Fri Aug 12 17:09:05 UTC 2011
>> Cool, thanks, I'll take a look at that -- though working with XDR
>> looks like it could be somewhat painful :)
>> On a related note, I get a trickle of errors like this in the nginx error log:
>> sFlow agent error: sfl_agent_error: receiver: flow sample too big for datagram
>> which must be hitting the in-code limit of 1400 bytes. Would it be
>> quite horrible if I were to bump up SFL_DEFAULT_DATAGRAM_SIZE over
>> 1460? I'm assuming under normal conditions, it'll just fragment, which
>> I'm ok with at the rate they're occurring now. But again, I'm worried
>> about some data structure in the code (that my casual reading of the
>> code isn't turning up) will overflow.
> IT looks like you'd have to bump up both SFL_MAX_DATAGRAM_SIZE and SFL_DEFAULT_DATAGRAM_SIZE. For example:
> #define SFL_MAX_DATAGRAM_SIZE 3000
> #define SFL_MIN_DATAGRAM_SIZE 200
> #define SFL_DEFAULT_DATAGRAM_SIZE 3000
> If you are not using jumbo frames and packet-loss-in-transit ever hits 50% then you might have a problem getting data through to the collector (just when you really needed it) so in the end the right solution is to apply the length-limits as proposed on the sFlow mailing list. This can be done in sfwb_sample_http() at the point where the string lengths are filled in for the sample. I intend to put that fix in very soon, and add the missing "X-Forwarded-For" and "req_bytes" fields too. If you think there are any other fields or counters missing then now is a good time to chime in.
Cool, I'll play with that.
As far as other counters/fields, I was sort of curious why there's no
timestamp field. Obviously you could just use the time the packet got
sent as the timestamp, but I imagine precision-minded people would get
bent out of shape about not having the exact time as recorded by the
More information about the nginx