libmetrics-devel Mailing List for libmetrics
Status: Beta
Brought to you by:
loosifer
Menu
▾
▴
libmetrics-devel — Libmetrics developer mailing list
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: Tim N. <arc...@we...> - 2005-04-21 06:13:13
|
Luke, have you seen this? http://apr.apache.org/ I don't think it does what we want (specifically, they don't check the input data in *any* of their functions as a matter of policy), but it might be something that we can depend on for reasonable-sized chunks of functionality. :) -- Tim Nelson Server Administrator WebAlive Technologies Global Level 1 Innovation Building, Digital Harbour 1010 LaTrobe Street Docklands, Melbourne, Vic, 3008 Phone: +61 3 9934 0812 Fax: +61 3 9934 0899 E-mail: tim...@we... http://www.webalive.biz/ "Your Business, Your Web, Your Control" |
|
From: Tim N. <arc...@we...> - 2005-04-20 04:12:27
|
How do I get it to compile? ./configure is currently exiting with: --------------------- checking for uname... yes configure: creating ./config.status config.status: creating Makefile config.status: error: cannot find input file: Makefile.in --------------------- :) -- Tim Nelson Server Administrator WebAlive Technologies Global Level 1 Innovation Building, Digital Harbour 1010 LaTrobe Street Docklands, Melbourne, Vic, 3008 Phone: +61 3 9934 0812 Fax: +61 3 9934 0899 E-mail: tim...@we... http://www.webalive.biz/ "Your Business, Your Web, Your Control" |
|
From: Tim N. <arc...@we...> - 2005-04-13 01:49:15
|
On Tue, 12 Apr 2005, Luke Kanies wrote: > On Mon, 2005-04-11 at 11:17 +1000, Tim Nelson wrote: >> On Fri, 8 Apr 2005, Luke Kanies wrote: >>> Well, the real problem here is that the functions aren't meant to take >>> arguments, and the disk function obviously needs to do so. >> >> I was kinda wanting to myself for something else, but if we use >> the "get function" thing I talk about in the other mail, that'll solve the >> problem for me. But not for disk :). And disks aren't the only things >> which have multiples. Eg. >> - CPUs >> - Load averages >> - Network interfaces >> >> As time goes on, I suspect that multiples of things are going to >> become more popular. > > I agree with that statement, but I don't think your solution quite > covers it, unless the va_start stuff does the rest. It seems that for Yes :). > most things that involve multiple numbers (disks, cpu, load, network), > each type of metric needs a function to collect all of the information > and store it in some globally accessable place, and then there needs to > be a specifically named metric for each instance (each disk, each cpu > type, etc.) that one can use to retrieve each of the values. Hmm. The problem with storing information in a global place is, what if the source of the information changes it? That's not a problem with the current libmetrics, but it is with the distropicker thing I wrote, and a problem I'll need to deal with (but copeable :) ). > Is that basically what you had in mind? Is the collection function what > you are calling 'va_start'? > > Do you have an idea for such an architecture? Read "man va_start", and then tell me whether you still want these answered :). > BTW, I've CC'ed the libmetrics-devel list, so we can start getting these > emails on record. Please continue in that vein. I was intending to do that as soon as I'd subscribed (which I now have). Also, I'm going to have a busy week here, so I won't get back to working on libmetrics in that time. -- Tim Nelson Server Administrator WebAlive Technologies Global Level 1 Innovation Building, Digital Harbour 1010 LaTrobe Street Docklands, Melbourne, Vic, 3008 Phone: +61 3 9934 0812 Fax: +61 3 9934 0899 E-mail: tim...@we... http://www.webalive.biz/ "Your Business, Your Web, Your Control" |
|
From: Tim N. <arc...@we...> - 2005-04-13 01:44:00
|
On Tue, 12 Apr 2005, Luke Kanies wrote: > On Mon, 2005-04-11 at 11:20 +1000, Tim Nelson wrote: >> On Fri, 8 Apr 2005, Luke Kanies wrote: >> >>> On Fri, 2005-04-08 at 14:49 +1000, Tim Nelson wrote: >>>> Another idea -- we should pass the name of the metric into the >>>> function it calls. In many cases this would be useless, but it would mean >>>> that we could call the same function with different names and it would >>>> return different values (this would have a variety of uses, and is >>>> necessary for my distro thing). >>> >>> Huh; yeah, that could solve the problem that we're having. Require an >>> argument, and for most cases that argument would be worthless, but for >>> the case of disks (or other systems with more than one value) it would >>> get that value. >> >> It would also mean that I could create a metric for each variable >> in my variables system (dynamically, depending on the contents of the >> config file), and point them all at the same function, but with different >> names :). > > I think I'm with you here... Maybe not; I was assuming (dumb :) ) that you'd flicked throught the distropicker code I sent you. It uses the GNU functions hsearch_r eg. al (man hsearch_r) to store a bunch of variables which it extracts from eg. /etc/redhat-release. >>> Do we create a separate metric for every disk? That means adding >>> metrics at run-time (which is fine, but not currently done). If we >>> don't do that, then how do we know that the metric is able to give us >>> more information? >> >> That's not what I was thinking :). I think between the idea >> above, and the va_start one, we should have it covered, though :). > > But now I'm lost. Currently, each metric returns a single value, not an > array of values. So, following this scheme gives us a separate metric > for each disk (even if the metric is the same function but just a > different name). How else could we do this? > > And can you explain the 'va_start' thing for me in more detail? I don't > really understand it. And what does 'va' stand for? "man va_start" :). Sorry. I've been assuming that you know C better than I do because you know more config-mgmt. A few weeks ago, I wouldn't've recognised va_start either. I'll ignore the rest of your reply in this section (above), and let you rephrase it in light of "man" (Sounds very 19th-century :) ). >>>> Also, it might be nice to have a function in libmetric.c/h which >>>> is something like get_result or something like that (get_metric_value?). >>>> I suggest this because we might be able to alter things on the way through >>>> if we so desire. >>> >>> Yeah, that is a good idea. Should be pretty easy. > > So people could create filters? I missed your statement about altering > the output on the way out; how would we alter it? That is, what exactly > might we want to do to it? Sorry. If people call "get_metric(foobar)", we can eg. have it search the metrics first, and then search my variables afterwards, so that it can return something from either. Or change the backend completely, and not have to worry about people calling it directly. Whatever :). :) -- Tim Nelson Server Administrator WebAlive Technologies Global Level 1 Innovation Building, Digital Harbour 1010 LaTrobe Street Docklands, Melbourne, Vic, 3008 Phone: +61 3 9934 0812 Fax: +61 3 9934 0899 E-mail: tim...@we... http://www.webalive.biz/ "Your Business, Your Web, Your Control" |
|
From: Luke K. <lu...@ma...> - 2005-04-13 00:19:41
|
On Mon, 2005-04-11 at 11:17 +1000, Tim Nelson wrote: > On Fri, 8 Apr 2005, Luke Kanies wrote: > > Well, the real problem here is that the functions aren't meant to take > > arguments, and the disk function obviously needs to do so. > > I was kinda wanting to myself for something else, but if we use > the "get function" thing I talk about in the other mail, that'll solve the > problem for me. But not for disk :). And disks aren't the only things > which have multiples. Eg. > - CPUs > - Load averages > - Network interfaces > > As time goes on, I suspect that multiples of things are going to > become more popular. I agree with that statement, but I don't think your solution quite covers it, unless the va_start stuff does the rest. It seems that for most things that involve multiple numbers (disks, cpu, load, network), each type of metric needs a function to collect all of the information and store it in some globally accessable place, and then there needs to be a specifically named metric for each instance (each disk, each cpu type, etc.) that one can use to retrieve each of the values. Is that basically what you had in mind? Is the collection function what you are calling 'va_start'? Do you have an idea for such an architecture? BTW, I've CC'ed the libmetrics-devel list, so we can start getting these emails on record. Please continue in that vein. -- I also realize I can no longer spell "pseudo". My finger have now hard-wired "sudo". Thanks, Unix! I also cannot uppercase "cat" for the life of me. --Jonathan Rentzsch --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://config.sage.org |
