Hi Paolo,
This is our config.
daemonize: true
debug: false
pidfile: /var/run/nfacctd.pid
syslog: daemon
pre_tag_map: /etc/pmacct/my.pretag.map
!nfacctd_disable_checks: false
nfacctd_disable_checks: true
nfacctd_time_new: false
aggregate: tag, src_host, dst_host, src_port, dst_port, proto, tos
Hi Paolo,
I'm writing to asking if you are thinking about supporting Redis as plugin
The advantage to use Redis would be that both Logstash both Telegraf support it
in a native way, then it would be easy to store pmacct data in native way in
Elasticsearch or InfluxDB.
Regards
digitel
Via
On 14/11/2016 19:42, Rasto Rickardt wrote:
Hello Paolo,
+1 for me, main reasons are the usual Redis ones:
Pmacct have already a lot of backend plugins, but if another is needed I
vote for redis. Redis is blazing fast and can act both as a message
queue and a an ephemeral storage. I think
Hello Paolo,
+1 for me, main reasons are the usual Redis ones:
Speed - 100k GET by_id per second
Data persistence across restarts
Multi node deployment is not a MUST like other NoSQL document stores
Lightweight
My use-case is storing time-based events from flows in InfluxDB (bps,
pps, flows per
Logstash supports both Kafka both Rabbitmq as input
(https://www.elastic.co/guide/en/logstash/current/input-plugins.html)
Telegraf does not (https://docs.influxdata.com/telegraf/v1.1/inputs/)
Redis is fast (it's written in C), easy to setup and deploy and very easy to
use as message queue.
