[collectd] Announcing “Collection 4” (C4)

[Pander]

On 2011-04-22 15:18, Josef Liška wrote:
> Hi List,
> I'd like to test collection 4. I have succesfully built and installed a
> deb package, and now I am stuck with web server configuration.
> 
> Could anyone post working config for either nginx or apache?

Ubuntu Apache 2

apt-get install libapache2-mod-fcgid

	ScriptAlias /fcgi-bin /opt/collection4/bin/
	Alias /share/ /opt/collection4/share/
	<Directory "/opt/collection4/bin">
		SetHandler fcgid-script
		AllowOverride None
		Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
		Order allow,deny
		Allow from all
	</Directory>

I could not get it to work in /var/www. I suspect the path to etc is
hardcoded somehow.

I'm no Apache expert. If someone has improvements to the above, please
let me know.

Pander

> Best regards
> Josef Liška
> 
> CHL | system care
> 
> Telefon: +420.272048055
> Fax: +420.272048064
> Mobil: +420.776026526 denně 9:00 - 17:30
> Jabber: jl at chl.cz
> http://www.chl.cz/
> 
> 
> Dne 13.9.2010 10:09, Florian Forster napsal(a):
>> Hi everybody,
>>
>> I've been working on a new front-end for collectd for some time and
>> finally reached a state worth publishing. “Collection 4” (abbreviation
>> “C4”) is intended to supersede "Collection 3" eventually, but this
>> doesn't mean that I won't accept patches for Collection 3 anymore, of
>> course. C4 is far from finished, so expect changes in functionality
>> frequently and also in between patch releases.
>>
>> The main goal of C4 is performance. Collection 3 had a lot of startup
>> overhead, because a lot of Perl-Modules needed to be parsed even when
>> only totally unrelated graphs were to be drawn ([0]). C4 uses FastCGI to
>> use the same process to handle multiple requests, reducing startup
>> costs several magnitudes. Because the available graphs and the list of
>> required files for each are kept in memory, most requests can be handled
>> without disk access once the process has been initialized. In my
>> experience, the browser is the bottleneck now. C4 tries to be friendly
>> in this respect by limiting the amount of data sent to the browser to a
>> useful size ([1]).
>>
>> The second central feature is graph configuration. While many front-ends
>> do a great job of displaying arbitrary data nicely, ultimately I want to
>> be able to configure the graphs to look exactly the way I want them to
>> look. That's why that feature was present in Collection 3 and in
>> Collection 2, too. The configuration syntax used in C4 is more flexible
>> than the syntax used in Collection 3. It allows create a graph from
>> multiple identifiers (think: files) but also allows one identifier to
>> appear in multiple graphs. Unfortunately, this is not yet fully
>> implemented to users cannot see this feature in all its glory.
>>
>> Another important aspect are "data providers": C4 doesn't entirely focus
>> on RRD files as the source of its data, but abstracts away the source of
>> the data to make it easy to add new "providers" in the future. This
>> means, however, that reading ("fetching") the data needs to be separate
>> from rendering ("graphing") the data ⇒ no rrdgraph(1) ([2]). Currently
>> graphs are rendered using gRaphaël, which currently lacks many graphing
>> features supported by the configuration (hence the limitation in the
>> previous paragraph). In the near future I hope to see a data provider
>> for RRDCacheD (using "rrdc_fetch") and possibly CSV files.
>>
>> The HTML-based interface provided by the front-end is very simple and
>> leaves a lot of room for improvements. Patches are especially welcome in
>> this respect. (Almost?) all the actions are also available in a JSON-
>> encoded form. My hope is that better front-end programmers than me use
>> this to create nice front-ends based on C4 ([3]), basically using it as a
>> back-end ([4]).
>>
>> So, without further ado, here's the link to the homepage, wiki page and
>> download links:
>>
>>   Homepage:  http://octo.it/c4/
>>   Wiki:      http://collectd.org/wiki/index.php/Collection_4
>>   Download:  http://octo.it/c4/files/collection-4.0.0.tar.bz2
>>
>> Needless to say: Feedback is *very* welcome. So are patches :)
>>
>> Best regards,
>> —octo
>>
>> [0] When using the front-end on a smaller scale, you probably don't
>>     notice this too much, but when you have 50k+ RRD files and the
>>     system is very busy just updating RRD files, you can deliver maybe
>>     two graphs per second. I would have expected loading of Perl modules
>>     to be a CPU-bound operation once the files containing the modules
>>     are in the page cache, but experience tells a different story.
>> [1] For example, printing a list of all hosts may result in 100+ kByte
>>     sent to the browser on large setups. Having such a list in the menu
>>     may be nice when you have 10 hosts. When you have 1000, this will
>>     render the interface slow.
>> [2] This is only a half-truth: Support for rrdgraph(1)-based images is
>>     currently present but not very well maintainable. It *might* be
>>     removed in the future or at very least it will be reorganized.
>> [3] Lindsay / Visage, I'm looking at you! ;)
>> [4] Hey, if it's a front-end and a back-end at the same time, did I just
>>     create one of those "middlewares" businesses always get all excited
>>     about?! ;)
>>
>>
>>
>> _______________________________________________
>> collectd mailing list
>> collectd at verplant.org
>> http://mailman.verplant.org/listinfo/collectd
>>
>>
>> !DSPAM:2,4c8ddcf7114764300399196!
> 
> _______________________________________________
> collectd mailing list
> collectd at verplant.org
> http://mailman.verplant.org/listinfo/collectd