Today, Steven Wagner wrote forth saying... > So, looking at this here example plugin (and writing one of my own, the > aforementioned universal uname plugin), I'm wondering if it's part of The > Plan for the plugin to determine when to publish its metrics. I notice > that g3_job_t has a reference to a collect function *and* a publish > function, but I don't remember seeing anyplace in the scheduler where it > decides on when to *publish* metrics/jobs.
the "collect" function has the responsibility of calling the "publish" function whenever it deems necessary. if you look inside ./plugins/test-plugin.c you see how the "collect" function checks to see if it should "publish" the metric. i separated the "collect" side of things from the "publish" side of things for two reasons. 1. both functions operated on the same data job->data and 2. i needed a way for a job to specify what to do when data is "pulled". when a client pulls data from a host, the queue is walked (with read locking) and the "publish" function is called on each queue item (job). the "publish" function takes an arg which most likely will be a handle to a multicast channel, database, client socket, etc. make sense? btw, there is a rwlock on the queue (for queue inserts, extracts, etc). and each job has a rwlock (to protect the data). this makes it possible to have multiple backends and frontends operate on the same queue without trippinng over each other too much. > (since it seems one job may handle multiple metrics, we might want to start > making that differentiation...) yep. one job can handle multiple metrics (e.g. 1,5,15-min load). the data for the job (job->data) in this case will be an array of values and when "publish" is called it will likely publish all metrics in the array. > Speaking of which, I am having some trouble writing a plugin that does > exactly that, because I am a chimp. yeh. and you have so much rich documentation to work with.. i don't see why you can't get it. :P > It's also not immediately apparent how a plugin specifies each metric's > position in the metric tree... not to a chimp like me, anyway (see previous > paragraph). the position in the metric tree will be determined by how the "publish" function publishes the data. it will format the message so that the listening module (not built yet) will know how to interpret the message. i've thought about have a "serialize" and "deserialize" function in the job structure (serialize would replace "publish"). actually .. i think that's the left way to do it. serialize will take the job->data structure and structure it for the wire. deserialize will take a wire message and convert it into a job->data structure. > I just think it would be neat to have a plugin or two that work on all > platforms, that's all. :) i think so too. we're close. -matt
