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? Paolo 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 http://www.pmacct.net/#mailinglists
