matt massie wrote:
the reason i'm working so hard on the web client right now is that i want to get back to gmond. the web client uses PowerTemplate in order to separate the parsing/computation side from the presentation side. that way we'll be able to have people build new templates (like "skins") so that people can choose which presentation format they like.
I'd settle for platform-specific graphs in the current environment, but your method's much neater. :)
Reworking gmond to (basically) "be more Apache-like" is an interesting idea but places that much more emphasis on a robust build environment.
it would be easy to take what we have now in each in ./gmond/machines and convert it to this format.
Eheh. Um. Not in the case of my Solaris module. The individual metric updaters actually all reference a central updating function, which populates an intermediary structure. The individual updaters mostly return the proper value from this structure to the monitoring core.
It's not ideal, but anecdotal web evidence says that there is a performance hit on Solaris from hammering the kernel with kvm opens and reads. So I figured it was better to just grab the sysinfo structure from it in one pass instead of hitting it five times in a row on cpu_idle, cpu_user, cpu_kernel, etc.
the gmond scheduler would then take care of loading in the module and checking/multicast its data. the only catch would be that each of the gmond.conf files would have to match since the scheduler would use the order of the modules to determine its primary XDR key.
Maybe the first monitoring core to report on a multicast address also sends out a module_order message? :)
Ah well, I'm using the same conf files everywhere anyway...
another HUGE advantage of this DSO model is that i'll be able to optimize the network packets for CUSTOM metrics in exactly the same way as the base metrics AND store the data in even less memory (not that gmond has a big problem there).
While looking for memory leaks in gmond-solaris, I found this out for myself (turns out that creeping memory usage was NFS...). A pleasant surprise, to say the least. Also a pleasant surprise that I hadn't introduced any new nasty behavior due to my code.
Well, except for the segfault under certain circumstances while listening for/broadcasting metrics *AND* gathering data... ( --deaf anyone? )
