Hi Christian,

Thanks for the kind words, much appreciated, and the very interesting
email. In line of principle i'd not be shy to say that you may want to
use a different tool for that; but at the very same time i'd like to
explore with you (and anybody interested in the conversation) whether
there is an opportunity for improvement. 

Reading your goal i see two challenges: 1) any field, before being
printed as part of a JSON, needs a semantics (ie. string, hex, int,
MAC address, IP address, etc.) to be attached to and 2) of course
such a list will never be comprehensive, especially when we look at
IPFIX and PENs. Issue #1 can be countered with a giant map that does
attach a semantic to fields, for example, using something like
https://www.iana.org/assignments/ipfix/ipfix.xhtml as reference: it
would be some work but the basic infrastructure is already there. But #2
means you will always hit a point where you have to integrate existing
knowledge with custom primitives (aggregate_primitives framework) which,
a bit, kills your original point (meaning you will never have a 100%
guarantee you are decoding everything - but you indeed can get a
warning that you are not). How does all of this sound, would this be
good enough? Any better proposals, ideas?


On Sun, Jan 27, 2019 at 12:37:27AM +0100, Christian Meutes wrote:
> Hi!
> I'm using pmacct since a long time now .. so the first thing (not
> quite..) to say and to express is really my gratitude to Paolo for
> creating these cool tools!
> So the reason for my first mail to the list is the following: I wonder
> if there is a way to export flow data, received by nfacctd and is then
> written to a json-formatted file, but this without nfacctd having
> worked on any further aggregation (defineable via "aggregate:") and
> also without losing any types.
> Basically it should export all flows via the print plugin, but
> *lossless* (take as received and serialize into JSON).
> I suppose that manually declaring all possible types via primitives
> for making them assignable in the aggregate-directive is not really
> the way to go (don't get me wrong this explicit design is a necessary
> minimum to have, otoh losing data because some new type/value was
> received but yet not declared and configured, this seems to me as a
> basic use case as well).
> Am I mistaken? Ideas?
> Thanks!
> -- 
> Christian
> e-mail/xmpp: christ...@errxtx.net
> PGP Fingerprint: B458 E4D6 7173 A8C4 9C75315B 709C 295B FA53 2318
> _______________________________________________
> pmacct-discussion mailing list
> http://www.pmacct.net/#mailinglists

pmacct-discussion mailing list

Reply via email to