|
Needed to add this patch as well. The type for gateway_snapshot_interval can be negative, so use a signed type
---- Ryan Doyle From: "Ryan Doyle" <rdoyle@xxxxxxxxxx> To: "Nathan Scott" <nathans@xxxxxxxxxx> Cc: pcp@xxxxxxxxxxx Sent: Wednesday, 20 March, 2013 1:58:34 PM Subject: Re: additional metrics for elasticsearch PMDA Hi Nathan/others Please see new patch - just disregard the previous one. This now transposes the results hash and "renames" the problematic key values so it can be easily accessed with es_value subroutine. The metric names are no longer hard-coded and instead the keys for each value are iterated through. Let me know if this needs more work. Cheers! ---- Ryan Doyle From: "Nathan Scott" <nathans@xxxxxxxxxx> To: "Ryan Doyle" <rdoyle@xxxxxxxxxx> Cc: pcp@xxxxxxxxxxx Sent: Tuesday, 19 March, 2013 5:12:28 PM Subject: Re: additional metrics for elasticsearch PMDA (cc'ing the list as discussed on IRC) ----- Original Message ----- > > Heya Nathan, > > Patch is attached. > Thanks! > It is not as clean as I would like it but that stems from how these > metrics are exported from the elasticsearch status API: > > Heres a nice output > > { > "_all": { > "indices": { > "qa4": { > "primaries": { > "search": { > "fetch_current": 0, > "fetch_time": "0s", > Zimbra thinks little of your nice output, and has kindly removed all whitespace. Sorry 'bout that. > > Where all hash keys map directly to the elasticsearch PMID name (EG: > primaries. search. fetch_current). We take advantage of this in the > PMDA using the es_value function and passing in a reference to the > metric requested where each array member is separated by a period. > > > Unfortunately , the settings hash does not follow the same convention > and has periods in the key! EG: > Ugh! > > }, > "settings": { > "index.gateway.snapshot_interval": "10000", > "index.number_of_replicas": "1", > "index.number_of_shards": "5", > "index.version.created": "190199" > }, > > This makes the code less clean, but it looks like these are the only > 4 metrics that follow this convention. If you can think of a nicer > way to do this, I'm all ears. > You might be able to use a hashed instance domain here, instead of the array based ones (which was all that existed when this PMDA was originally coded). Refer to the pmdasimple.pl PMDA for an example - the %timeslices there is a perl hash. Instance names can have dots within them - would that make life easier for these metrics? cheers. -- Nathan
|
