headers
Rodrigo Campos | 1 Sep 2009 03:33
Picon

Re: Bug#535786: Change severity of 535786 to important

On Mon, Aug 31, 2009 at 09:55:52PM +0200, Sebastian Harl wrote:
> Hi Rodrigo,
> 
> On Mon, Aug 31, 2009 at 04:27:42PM -0300, Rodrigo Campos wrote:
> > On Mon, Aug 31, 2009 at 03:36:28PM +0200, Sebastian Harl wrote:
> > > On Mon, Aug 31, 2009 at 09:22:49AM -0300, Rodrigo Campos wrote:
> > > > It seems it should not change the ABI:
> > > > 
> > > > http://markmail.org/message/aqommixeonl5l5sj#query:netfilter%20libiptc+page:1+mid:fdxs37gp6e2igpto+state:results
> > > > 
> > > > Patrick said that in the second email of the thread.
> > > 
> > > In that thread you pointed out, I could only find patches for the build
> > > system to basically change 'noinst_LTLIBARIES' to 'lib_LTLIBRARIES' for
> > > libiptc (i.e. install that library on 'make install' instead of making
> > > it available for internal use only). Which patch did you have in mind?
> > 
> > And that didn't do the trick ?
> 
> Well, that has nothing to do with API / ABI changes but rather about
> making the library available at all.

Well, but if it is available and ready to be used, that's all you need to fix
it. (if I'm not wrong)

> > 
> > Sounds ok. But you can simply put into the sources the last library, so you
> > don't need to support both APIs, you just check if the version (if I'm not wrong,
> > it have a version now also) available of libiptc is the same or "compatible"
> > with the one in the sources. If its not, you use the one inside collectd and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Florian Forster | 1 Sep 2009 08:47
Favicon

Version 4.8 branch created - features frozen

Hi,

just wanted to let you know that I created the "collectd-4.8" branch and
pushed it to the repository. From now on only bugfixes will be included
in that branch, new features will go into 4.9.

Currently the goal is to release collectd 4.8.0 on September 13th.

Regards,
-octo
--

-- 
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
Permalink | Reply | 0 comments |
headers
Yann | 4 Sep 2009 16:40
Picon

Shouldnt collectd also provide an interface to the data?

Hello, I've been following collectd for quite a while now and have
been stuck so far by the lack of good graphing software. One of the
problems I see is that it is really hard to access the data - collectd
has drivers to write either to rrd, csv etc... just when it comes to
graphing, every graphing tool would need all those drivers too - at
the moment all the tool I've seen were only able to use RRDs as an
entry point...

It doesn't get  better if you want proper GUIs (think QT/GTK) and not
web front ends. The GUI has to run on the same server as the collectd
server so that it can access the data - I'm probably not the only one
that doesn't have KDE on my collectd server to run kcollectd, which
does look nice although :)

So, here comes my christmas wish for collectd.. Could collectd 5
provide a read interface to the data, an API that my frontend GUI
could use to gather the data and display it nicely? With the data that
gets taken out of csv or SQL if that' were I write to.. That would
make it a lot easier to graph the data on a different server than the
one doing collectd.

Anyway, I should be able to survive without, I guess I'll install a
web frontend on my collectd server as everyone else, just that would
really rock :)

Thanks for reading and for the great tool

Yann
(Continue reading)

Permalink | Reply | 17 comments |
headers
matthew sporleder | 4 Sep 2009 16:52
Picon

Re: Shouldnt collectd also provide an interface to the data?

On Fri, Sep 4, 2009 at 10:40 AM, Yann<yann.hamon@...> wrote:
> Hello, I've been following collectd for quite a while now and have
> been stuck so far by the lack of good graphing software. One of the
> problems I see is that it is really hard to access the data - collectd
> has drivers to write either to rrd, csv etc... just when it comes to
> graphing, every graphing tool would need all those drivers too - at
> the moment all the tool I've seen were only able to use RRDs as an
> entry point...
>
> It doesn't get  better if you want proper GUIs (think QT/GTK) and not
> web front ends. The GUI has to run on the same server as the collectd
> server so that it can access the data - I'm probably not the only one
> that doesn't have KDE on my collectd server to run kcollectd, which
> does look nice although :)
>
> So, here comes my christmas wish for collectd.. Could collectd 5
> provide a read interface to the data, an API that my frontend GUI
> could use to gather the data and display it nicely? With the data that
> gets taken out of csv or SQL if that' were I write to.. That would
> make it a lot easier to graph the data on a different server than the
> one doing collectd.
>
> Anyway, I should be able to survive without, I guess I'll install a
> web frontend on my collectd server as everyone else, just that would
> really rock :)
>
> Thanks for reading and for the great tool
>

Do you need a tool that can parse your config and tell your app where
(Continue reading)

Permalink | Reply | 8 comments |
headers
Yann | 4 Sep 2009 16:59
Picon

Re: Shouldnt collectd also provide an interface to the data?

> Do you need a tool that can parse your config and tell your app where
> the output is going, or are you proposing that collectd provide a
> proxy to its various output plugins for you to access "raw" data?
>

None of those, sorry if I wasn't clear... What I would need is more
collectd "serving" the data to a client upon request.
Imagine I want to build a GTK frontend, that would run on my laptop: I
would specify the collectd server address and port, then click on
"server1" "load" and "daily" - the GTK frontend needs a way to
retrieve the data from the collectd server, here one day of load data
for server1 - and right now there is no easy way to do that (afaik)...

I hope this makes more sense, thanks

Yann
Permalink | Reply | 7 comments |
headers
Lindsay Holmwood | 4 Sep 2009 17:22
Picon
Gravatar

Re: Shouldnt collectd also provide an interface to the data?

2009/9/4 Yann <yann.hamon@...>:
>
> None of those, sorry if I wasn't clear... What I would need is more
> collectd "serving" the data to a client upon request.
> Imagine I want to build a GTK frontend, that would run on my laptop: I
> would specify the collectd server address and port, then click on
> "server1" "load" and "daily" - the GTK frontend needs a way to
> retrieve the data from the collectd server, here one day of load data
> for server1 - and right now there is no easy way to do that (afaik)...

I'm actually hacking on a JSON interface onto collectd's RRDs, which
makes it really easy to consume the data:

http://auxesis.github.com/visage

To get free memory stats, you'd make the following request:

http://visage-instance/data/somehost/memory/memory-free

Or if you wanted all the memory stats:

http://visage-instance/data/somehost/memory/

You can specify time ranges as well:

http://visage-instance/data/somehost/load/load?starttime=1252074142&endtime=1252077714

It's a bit rough at the moment, but i'm actively hacking on it so it
should stabilise in the next week or two.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Yann | 4 Sep 2009 17:39
Picon

Re: Shouldnt collectd also provide an interface to the data?

> I'm actually hacking on a JSON interface onto collectd's RRDs, which
> makes it really easy to consume the data:

> http://auxesis.github.com/visage

Oh I've been dreaming of something like this
http://raphaeljs.com/analytics.html  for ages now :) Inline SVG
rendering is something with this type of features is what I consider
to be an absolute must. Please get a demo install so we can lurke ;)

Having the data served in JSON sure makes some sense as it takes away
the problem for the authentication (rely on apache or other httpd) and
makes it easier for javascript apps to get to the data. However it
means you'd need a full httpd server on your collectd host, 'm not
sure if it's the best way?

If you could try to separate the JSON serving and the rest that would
be awsome though :) If I write properly I should be able to adapt to
any other API though...

Thanks for your input!

Yann
Permalink | Reply | 1 comment |
headers
Lindsay Holmwood | 4 Sep 2009 17:49
Picon
Gravatar

Re: Shouldnt collectd also provide an interface to the data?

2009/9/4 Yann <yann.hamon@...>:
>
> Having the data served in JSON sure makes some sense as it takes away
> the problem for the authentication (rely on apache or other httpd) and
> makes it easier for javascript apps to get to the data. However it
> means you'd need a full httpd server on your collectd host, 'm not
> sure if it's the best way?

It's written in Ruby (Sinatra, for those interested) so the web server
side of it can be as light or heavyweight as you want. You can deploy
it with mod_passenger + Apache/nginx if you want something
traditional, or Mongrel/Thin and make it pure Ruby - whatever works
best for your environment.

>
> If you could try to separate the JSON serving and the rest that would
> be awsome though :) If I write properly I should be able to adapt to
> any other API though...

Already done. The UI is very light HTML with crazy JavaScript
shenanigans to render the graphs. It makes AJAX requests back to the
JSON interface, which just happens to be served from the same process.

Lindsay

--

-- 
http://holmwood.id.au/~lindsay/ (me)
Permalink | Reply | 0 comments |
headers
Florian Forster | 4 Sep 2009 19:49
Favicon

Re: Shouldnt collectd also provide an interface to the data?

Hey Lindsay,

On Fri, Sep 04, 2009 at 05:22:59PM +0200, Lindsay Holmwood wrote:
> I'm actually hacking on a JSON interface onto collectd's RRDs, which
> makes it really easy to consume the data:
> 
> http://auxesis.github.com/visage

I've seen you mentioning something along these lines on twitter but
wasn't aware you already had public code :)

> P.S. the other half of what Visage does is graph the data in the
> browser with the Raphaël javascript library. :-)

That looks cool, too ;)

Looks like I have to dig into Ruby at some point ;)

Regards,
-octo
--

-- 
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
Permalink | Reply | 1 comment |
headers
Florian Forster | 4 Sep 2009 19:57
Favicon

Re: Shouldnt collectd also provide an interface to the data?

Hi Yann,

On Fri, Sep 04, 2009 at 04:40:56PM +0200, Yann wrote:
> So, here comes my christmas wish for collectd.. Could collectd 5
> provide a read interface to the data, an API that my frontend GUI
> could use to gather the data and display it nicely? With the data that
> gets taken out of csv or SQL if that' were I write to.. That would
> make it a lot easier to graph the data on a different server than the
> one doing collectd.

so far collectd is basically pipelined. The data enters the daemon on
one side, for example by being read from somewhere or received via the
network, and leaves one the other side (possibly multiple times). There
is next to no “history” recorded within the daemon.

Reading the RRD files back and providing an interface to that data is
well beyond the scope of collectd I'm afraid.

However, it currently looks a bit like RRDCacheD might step up to fill
this gap. With proper support in the library (and possibly command line
tools as well) accessing the data might become as simple as:

  handle = rrdc_connect (server_address);
  data   = rrds_fetch (handle, args);

In general I think collectd is not the right place for this kind of
stuff. But having some sort of general export mechanism in place and do
the graphing somewhere else is definitely a great idea.

Regards,
(Continue reading)

Permalink | Reply | 7 comments |

Gmane