Re: [pmacct-discussion] Looking for a fresh pmacct UI
Le 03/08/2016 à 14:43, Catalin Petrescu a écrit : Why passing by telegraf ? is a kafka (or amqp) consumer not enough ? telegraf is acting as kafka consumer in this case. Sure, but what about writing your own (or use kafka-influxdb with specific encoder) ? anyway this is a creative way of using telegraf :) -- Raphael Mazelier ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
Re: [pmacct-discussion] Looking for a fresh pmacct UI
Le 02/08/2016 à 17:41, Karl O. Pinc a écrit : Time-series storage seems the way to go. Yes for graphing. For tabular or analytic traditionnals sgbd are more suited for me. And rrd-tool seems like the tool for that job. rdd still made a great job, but I think there are better option today. (influx/graphite/grafana). -- Raphael Mazelier ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
Re: [pmacct-discussion] Looking for a fresh pmacct UI
Le 02/08/2016 à 17:35, Robert Juric a écrit : Well would anyone else be interested in developing a dedicated front-end utilizing the existingpmacct database? Or is it the general consensus that everyone exports the pmacct data to other systems for graphical representation? The problem is everyone want something different. I ve made mine but it was really oriented on my buisness need. It is way more easy to pass to export (or consolidate) metrics on a general purpose metric system in my opinion (graphite/influx/whatever for the tsdb), grafana or other for the gui. -- Raphael Mazelier ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
Re: [pmacct-discussion] Looking for a fresh pmacct UI
Le 03/08/2016 à 13:25, Catalin Petrescu a écrit : hi , pmacctd->kafka->telegraf->influxdb->grafana works great for me if used for peering analitics. Why passing by telegraf ? is a kafka (or amqp) consumer not enough ? -- Raphael Mazelier ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
Re: [pmacct-discussion] Looking for a fresh pmacct UI
Le 29/07/2016 à 09:03, Davide Principi a écrit : Thanks raf! This seems more comfortable! My php gui use mysql as backend, but it is trivial to change to sqlite (or whatever). Does it produce any graph? Could you attach some screenshots? No. I graph with grafana. But if you carefully choose what metric you put in your backend (aka not storing full flows), the db should remain small, and it will relatively easy to wrote a grapher with whatever lib (highchart is cool). You can also look at sir (https://github.com/dbarrosop/sir) if you like python, it use sqlite as backend afaik. -- Raphael Mazelier ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
Re: [pmacct-discussion] Looking for a fresh pmacct UI
Le 28/07/2016 à 08:50, Linas Lesauskas a écrit : Hi, just my 2 cents. I found very useful InfluxDB (https://influxdata.com/) for time-series data storage. It is extremely fast and lean on storage questions, uses kind of 20 bytes per record. Combining with Grafana (http://grafana.org/) you can build classy and stylish user interface. Currently we are playing with pmacct->bunch of scripts->influx on the lab and waiting for a more free time to push this to production. best regards, I've used both approach : pmacct > amqp > scripts > influxdb > grafana to display some nice graphs. and custom home made gui (in php :/ ) to display specific informations (top 10 interface / asn / as path / talkers - in/out). All this material is available on https://github.com/ut0mt8 . I think there are trivial to adapt on your needs. -- Raphael Mazelier ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
Re: [pmacct-discussion] MySQL Timezone handling
+1 to storing your application data in UTC. +1. Your server and storage backend should be set to UTC. This is the only way to assure consistency of timestamped data. Zoning should be make on the frontend side. -- Raphael Mazelier ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
