[OpenAFS-devel] xstat_fs_test, etc

[Jeff Blaine]

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
>> OpenAFS-devel@openafs.org
>> https://lists.openafs.org/mailman/listinfo/openafs-devel
>>
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel
>