sflow module and increasing useragent

[Mark Moseley]

>> 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
web server.