To continue our interesting exchange,
On Tuesday, September 3, 2002, at 03:37 PM, Steven Wagner wrote:
I am particularly interested in laying the groundwork for that so that
we can upgrade the monitoring core here with a vanilla RPM and not
worry about hosing any future proprietary metrics.
Definitely.
In this discussion, lets assume a node has received a metric from a host
named "subetha", that describes the size of its CPU1's cache. The fully
qualified metric name is "cpu/cache/size".
The node hostnames here are 12 characters long (and the hostname metric
reports their FQDNs). I like the idea of identifying the hosts
separately using a metric transmitted sparingly instead of tacking it
on to every metric name the host transmits... although I definitely
think it's the right way to go as far as naming schemes go
(debug/metadata display), I believe the hostname should be decoupled
from the transmitted metric.
So the host name is actually implied. You don't need to include it in
any metric, since the source address of the XDR packet itself identifies
the originating host. The transmitted metric name only needs to locate
the metric in the host's tree hierarchy, like "cpu/cache/size".
Maintaining a separate hash (of (strlen(metricname) + 1 +
sizeof(uint32_t)) * num_of_metrics) bytes in size) that has XDR metric
names as keys and an internal metric index as values doesn't strike me
as being too icky from a memory/performance footprint either.
I agree that adding the hash is not difficult or slow. It would fit
right into our methodology of processing metrics. My problem is with
failure resistance. What do we do if we just crashed and don't know
about any branches?
At some point a node is going to need each branch that contains a
metric to be described to it in detail.
Wouldn't it be easier if the metric name self-described its own
branches? Imagine that each metric name contains an absolute path
(filesystem analogy). Then the branches would not have to be described
in detail, they could be automatically created as necessary. The real
problem in my mind is shared fate. If the "branch-description" message
is separate from the "metric" message, then we can potentially receive
one without the other. If the branch description is included in the
metric packet (via a fully qualified name), then this is not a problem.
I would further like to point out that the minimum packet size in the
Ethernet protocol is 64 bytes. As most metrics are numeric types that
require only 4 bytes or so, most of the packet will be empty. We have
plenty of room available for a fully qualified name, and that space will
otherwise be wasted.
I always liked URLs. Besides, everybody knows what a URL looks like.
At least, everybody who's running gmond does, I hope ...
gmond://host[.cluster?]/cpu/1/idle_percentage
[etc.]
Excellent idea.
-Federico
Rocks Cluster Group, Camp X-Ray, SDSC, San Diego
GPG Fingerprint: 3C5E 47E7 BDF8 C14E ED92 92BB BA86 B2E6 0390 8845
