I looked into doing this using a QueueListener instead of PeriodicWork but felt that QueueListener had 2 major drawbacks that PeriodicWork didn't.

1. A QueueListener is called for every transition that an item makes moving from being queued to actually executing. While totally doable to implement the plugin this way, there are 4 different states a job can transition into and in the normal case jobs transition between them very quickly. We would likely need some sort of rate limiting or throttling code to prevent from sending metrics too quickly. This would make the code more complicated without much obvious gain.

2. Using a QueueListener implementation is great when jobs are always flowing through the system, but during times that it's idle no events would be sent. This isn't the end of the world, but for clusters that aren't very heavily loaded this could pose a problem with monitors constantly transitioning into no data states. Using PeriodicWork ensures that data is flowing even if the instance is idle.

@bbeck Thanks for submitting this PR along with #81, we'll take a look at these shortly.