Here is the latest Ganglia 3.1 wish list. We will be discussing this list
during the Ganglia meeting.
Brad
Done
------------------
- C module interface as DSO
- mod_python Python module interface
- Dynamically link libraries like expat, apr, libconfuse
- Add TITLE attribute to the XDR data to communicate a human readable name
- Add a GROUP attribute to the XDR data
This would allow metrics to declare the category that they belong to. The
category should be added at the metric definition level and not in the
.conf file.
- Reimplement the built in metrics as C interface modules
- A cleaner XDR encoding:
The current encoding scheme embeds too much information about which metrics
gmond collects. The encoding scheme should treat all metrics the same: as
just "a metric". The encoding should not care if the metric is
metric_cpu_speed, metric_swap_total or a user-defined "gmetric" one.
- Flexible method of adding extra metric metadata.
We could include extra metadata, not just "alias"/"title". For example,
some
metrics have a natural minimum and maximum value. Perhaps coming up with an
extendable way of encoding metric metadata so future changes can be included
without loosing backwards compatibility.
- Re-organization of RPM packages (libganglia, gmond-python ?)
GMond To Do
------------------------
- Gmond module repository
- Implement a perl module interface
- Implement a PHP module interface
- Implement a Ruby module interface
- Metric packing:
Simply that a UDP packet can contain multiple metrics (using the usual XDR
stream decoding) up to the size of a UDP packet. This would help reduce
the overheads when sending many metric updates concurrently. It also
preserves the current gmond behaviour where it sends metric updates in
a single UDP packet.
- Support for counters (metrics with +ve slope)
This shouldn't require much work (from memory, make sure the slope-type
information is preserved and patch gmetad to create RRD files with the
correct options). Currently Ganglia doesn't actually support custom
counter metrics, which is an awkward limitation.
- gmond switching to a non-blocking IO model.
If there's a large number of metric updates then gmond must process them
"quickly" or they will be lost. If this happens whilst gmond is sending XML
data to gmetad there's may be a delay, increasing the risk of metric
update messages being lost. Switching to a non-blocking IO model would
allow
gmond to respond preferentially to the incoming UDP messages.
-* Remove the 4T limit on ganglia metric results
-* Modify all byte count metric to 8 bytes ints
GMetad To Do
------------------------------
- Support for new RRDTool which allows graphs to have dynamic sizes
- Gilad's stacked graphs
- Changing the units of default metrics to their base
For example disk_free's base unit should be bytes, not GB as rrdtool will
automatically append G,M,K etc.)
- Better support for bigger less frequent updates
one packet every 20 seconds per host for all data?
- Multi PB disk limit
- Better on disk RRD perf (tmpfs is an OK workaround)
-* Name RRD directories based on UUID generated by client gmond
has of MAC address? something else? So that renaming hosts, updating DNS or
hosts files don't result in history for the phyiscal gmond client being
lost.
- Integration of gexec/authd ?
- Expand gstat nodelist parameter query options (i.e. return all hosts
with <10% iowait, etc.)
- Interface stats in bits? Self awareness of interface capablity for %
util stats for network.
- Something like a unique per-gmond instance identifier
To help with multi-homing and DNS issues and so the IP address is no
longer the index key. There was discussion of this under the subject
"Overriding hostname" on the Ganglia-general list.
- Give some metrics priority and have them updated more frequently in their
RRDs than others.
- Allow for some sort of in memory RRD (never written to disk) as an
alternative storage for very extreme cases.
- Let the users manage different IO bound pools for their metrics
For extreme cases one based on tmpfs. So that they can be tied correctly
to the right kind of storage IO capabilities for the frequency needed.
- Add more memory metrics
slab, buffers, dirty, writeback, cache_clean (= cached -
dirty+writeback)), mapped, free
Web interface
-------------------------------
- Numerous custom graphs enhancements (Alex Balk, Timothy Witham, others)
- Web frontend face lift
- Mouse over result graphs
- Default cluster view uses text-only per host squares
loading 1700 little graphs chews too much browser
- Better icons.
The current highly-compressed JPEG files for the icons look horrible!
Line-art perhaps suffers worst from JPEG compression artifacts. Could we
not
use either PNGs or (preferably) SVG?
- Add an option to allow switching to SVG in-line RRDTool graphs.
This should be pretty easy to add as a config option. I think support for
SVG in current browsers is now "good enough". A half-way modern version of
RRDTool can generate SVG versions of the graphs, which should look much
better.
- Have some standard way of describing custom graphs.
There currently isn't a standard way of producing custom graphs; "custom"
here means adding support for host-specific and cluster-specific graphs and
also some framework for describing those custom graphs. I have a
solution, that (at least) has merit in both existing and working. Perhaps
it
isn't ideal, but the Ganglia web front-end should provide at least some
standard hooks if not an actual framework.
- Have the option to switch off displaying all the single-metric graphs.
If you have ~300 metrics, the little graphs at the page bottom are all but
useless. They slow down the loading of the page without adding much
insight.
(I have a simple patch that allows a user to choose whether they want to see
these graphs.)
- Fix the pie-chart-generating code.
The current pie-chart code is a bit ugly and can plot things incorrectly
under certain circumstances. There must be some nicer graph plotting
packages out there...
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ganglia-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
