matt massie wrote:
i just uploaded another snapshot of ganglia
http://matt-massie.com/g3/ganglia-3.0.0.tar.gz
i've been working on polishing the xml before i start work on the
s-expressions side of things (since sexpressions will just be condensed
versions of the xml).
the latest snapshot has the ability to timestamp all data in the xml tree.
run ./tests/test-tree to see a sample. all timestamps are in 8601 format
zulu time.
here is what i propose for the xml... i'm looking for comments .. things
i'm missing.. things you don't like... etc.
all elements of the xml will be tagged with timestamp attributes: "birth"
"age" "step" and "expires". birth is a 8601 timestamp in zulu time of
when the data was created/inserted into the set. age is the number of
secs elapsed since birth. step is the maximum number of seconds between
(re)births [the time threshold] and expires is the number of seconds
after birth that the data will cease to exist.
e.g.
... birth="2003-04-24T23:00:18Z" age="46" step="60" expires="3600" ...
the birth date is in zulu time to handle timezone differences. the
library (as i have it written now) handles the time attributes as such...
if a tag being captured to the data structure has time attributes.. they
are not modified but instead or just put into the data structure. if
however, no time attributes exist, they are created. this behavior is
especially important for gmetad allowing entire portions of the
organization structure (grids, clusters, etc) to be marked as out-of-date
(and even allow for their removal after a period of time). it also
prevents updates of the freshness of a tag simply because it is read
upstream.
Would gmetad be looking only at the age and expiration values?
Chewing through all those human-friendly dates doesn't sound like a fun
time. Plus, RRD (and many other data storage methods) likes
second-based time/date stamps.
Am I to understand there's a differentiation being made between host
attributes (things which don't change until maybe after a reboot, such
as total memory or kernel version) and host metrics (which can change at
any time) ?
Does "expires" refer to the time after which a metric should be marked
as stale/out-of-date, or culled entirely from the tree? Should those
two values be marked
explicitly for each element or determined programmatically (one being
half the value of the other?) ? I'm assuming that the host values would
be inherited by its metric units...
I think that's all the brainpower (such as it is) I can spare for g3 at
this time...
