Flewton is an extensible Netflow collector.
Refer to the comments in the sample configuration shipped with Flewton.
In a nutshell:
java [options] -jar flewton.jar
By default, Flewton will search for its configuration file as
./flewton.cfg, using the first one found. You can specify a path to your configuration using the
flewton.config system property, for example:
java -Dflewton.config=/usr/local/etc/flewton.cfg -jar flewton.jar
Flewton uses log4j for logging. By default, the log level is
INFO and output is sent to stdout. To customize logging, create your own log4j.properties and set the
log4j.configuration system property:
java -Dlog4j.configuration=file:///path/to/log4.props -jar flewton.jar
Implementing backends in other languages
Backends can be implemented in several languages. We currently support:
There are three ways you can tell Flewton about your external backends:
1. Place them in
2. Run flewton with
-Dflewton.backend_path, placing your external backends in that directory.
3. Include your backends in the classpath so they can be loaded as resources by the classloader.
Identify your external backends in
flewton.cfg by using their entire names, e.g.:
py/my/CoolerBackend.py. The default cfg that ships with flewton contains a few commented out examples, the source for which can also be found in the Flewton source code.
- Your class should extend
- Your class should have an
__init__method that accepts an instance of
- Module names must begin with ‘
py/’ to be properly identified as python. E.g.:
write(record). The class types for
recordare the same as they would be in Java.
- Currently only Netflow v5 is supported, but additional Netflow formats are possible by implementing decoder classes as
Nis the version). See
com.rackspace.flewton.Recordv5for an example. Patches welcome.