On 6/28/2011 8:30 PM, Jeff Blaine wrote:
4. Moving the poller into a common C file instead of
duplicating it as it is in the existing xstat_*_test.c
files means either
a) We agree that the "Handler" function is
always named the same, such as xstatHandler
b) We add yet another argument to poller()
for passing in the handler function
I'm speaking of the handler passed to xstat_cm_Init()
Comments?
Actually, I see no way of sanely making this 1 poller
unless a lot more is agreed on for uniform naming.
These are all called from the old RunTheTest in
each *_test binary, which is what was extracted
from xstat_fs_test as poller():
xstat_fs_test xstat_cm_test
------------- -------------
FS_Handler CM_Handler
xstat_fs_Init xstat_cm_Init
xstat_fs_Cleanup xstat_cm_Cleanup
So unless anyone has any clever ideas, there's going
to be a cmpoller() and fspoller() with 90% identical
code.
On 6/28/2011 8:24 PM, Jeff Blaine wrote:
I've split RunTheTest (the actual stat poller) and
CountListItems (an aux function) out of xstat_fs_test.c
into xstat_common.c [FN3]
I've adapted xstat_fs_test.c to use them from there.
The goal of my effort, as above and going forward, is to
allow for some form of monitoring agent or somesuch.
In ultra-particulars for *my* immediate case, we already
syslog all data from all hosts we manage to a single master
host and use Splunk(tm) extensively[FN1]. We'd like an
"agent" splitting stats to syslog (and thus Splunk, which
has built-in time series charting!). Others may implement
something different that feeds data to an RRD, Graphite[FN2],
etc. In fact, we may end up down that road too someday,
but for now we want *something* and we already have the
receiving+parsing+graphing tool in place.
I have several questions at this early stage, and note
that I'm not a C magician:
1. Is that the filename you want the "common" stuff to be?
Let's choose wisely now and not create a turd.
2. The extracted "poller" function has turned ugly
signature-wise, IMO. I'm fine with it, and also
fine with changing it. That's a question, somehow.
poller(struct cmd_item *fslist,
struct cmd_item *collidlist,
int freq,
int period,
int debug,
int oneshot)
3. It's a little presumptuous above, but okay(?)
that fslist and collidlist are struct cmd_item.
Comments?
"RunTheTest()" (the initcmd in xstat_fs_test) now
amounts to little more than:
code = poller(a_s->parms[P_FS_NAMES].items,
a_s->parms[P_COLL_IDS].items,
freq, period, debugging_on, one_shot);
return (code);
From my testing, the xstat_fs_test builds and runs exactly
as before.
Footnotes
FN1:
http://www.kickflop.net/blog/2010/12/10/any-metric-graphing-with-cron-some-code-syslog-and-splunk/
FN2: http://graphite.wikidot.com/
FN3: This was the proposed idea from the Jabber server today,
instead of adding a -syslog argument to xstat_fs_test
because it's "hacky" in others' opinions.
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
