Hi Thomas, Great initiative, which i fully support.
I'd like to make two points, which is nothing new to the feedback that you already received: 1) what TC and Andreas say in different ways is true: there is not a reliable, featureful, well supported frontend to pmacct. So in essence lots of room there; 2) agree with Karl about reconfiguration API. Moreover consider: all maps, which is supposedly the content prone to change over time, are all already realoadable at runtime with no loss (via a UNIX signal); what you can't do is reload the base configuration, ie. instantiate a new plugin, change config for an existing plugin, upgrades, etc: this part, i believe, is much less prone to change once you put the setup in prouction. Cheers, Paolo On Tue, Sep 16, 2014 at 09:25:19AM +0000, Thomas King wrote: > Dear all, > > we at DE-CIX think about adding new features to pmacct that are needed from > our side. As pmacct is open-source we would like to release our additions as > open-source as well. To assess if our features are of general interest I > would like to discuss our features with you. The questions for us is here: > Are the features we might add be supported by the community? > > We are thinking about adding features in the following categories: > - High availability: We would like to enhance pmacct in such a way that if > pmacct dies on one machine another will take over automatically. We assume > that existing open-source tools (e.g., heart-beat) can be combined with > pmacct in order to achieve this. > - Reconfiguration via API: As we want to use pmacct in a dynamic environment > we want to be able to change the configuration via an API without restarting > pmacct. > - Report and statistic engine: We would like to define a set of reports > (e.g., throughput in bits per seconds pro MAC address or interface) which can > be displayed on a website including fancy looking graphs. This will probably > not be included into pmacct directly instead it will be a standalone tool > that relies on pmacct. > - Notification: If a threshold is met we want to be informed by mail (e.g., > the throughput for an interface reaches a certain level we want to receive a > mail). This will probably not be included into pmacct directly instead it > will be a standalone tool that relies on pmacct. > > I am aware that these feature descriptions are somewhat high-level. We > already created a more detailed technical description of what we need to add > to pmacct so that it fits our requirements. We will share this list later but > we do not want to steer the discussion to much in one direction. > > Any feedback to our ideas is highly appreciated! > > Best regards, > Thomas > > -- > Dr. Thomas King > Manager Research & Development > > DE-CIX Management GmbH | Lindleystraße 12 | 60314 Frankfurt am Main | Germany > | www.de-cix.net > Phone +49 69 1730902 87 | Mobile +49 175 1161428 | Fax +49 69 4056 2716 | > [email protected] > Geschaeftsfuehrer Harald A. Summa | Registergericht AG Koeln HRB 51135 > > _______________________________________________ > pmacct-discussion mailing list > http://www.pmacct.net/#mailinglists _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
