Open jnunemaker opened 10 years ago
I do not want this in the backend interface. It would be a new interface, say heartbeat, and would have its own methods to implement and specs to test adherence. This would allow people to use different heartbeat mechanisms with different queue backends.
Isn't this better done the other way around?
You have a heartbeat process that pings someone every time it tries to consume from queue X, if there is a long time between pings or this someone stops receiving pings it would then notify you that something is wrong.
This someone could be CloudWatch (with alerts), PagerDuty, Scout or any other service that looks for this kind of stuff. This would even allow host monitoring, if the service at the other end is configured to handle every host it could maintain information about every host's status and and send notifications based on this.
Running separate resque processes to access queue health is rather cumbersome, I used to do it and it complicates the problem much more than solving it.
I mostly put this as a reminder to myself. Should have documented what I meant more. I do not mean a separate process.
Heartbeat is not even the right term. More I see this as an interface for keeping track of what is happening with your workers in a way that could be show in a UI.
For example, some of the methods would be registering and unregistering workers. What job is a worker working on right now? Hope that makes more sense. Pretty unclear from the description above. Please read my mind in the future. Haha. :)
Well, that's along the lines of what I thought as well, looks like my mentat abilities are still functioning :P
Having this as a presence service for workers would definitely be nice.
Em sábado, 8 de fevereiro de 2014, John Nunemaker notifications@github.com escreveu:
I mostly put this as a reminder to myself. Should have documented what I meant more. I do not mean a separate process.
Heartbeat is not even the right term. More I see this as an interface for keeping track of what is happening with your workers in a way that could be show in a UI.
For example, some of the methods would be registering and unregistering workers. What job is a worker working on right now? Hope that makes more sense. Pretty unclear from the description above. Please read my mind in the future. Haha. :)
Reply to this email directly or view it on GitHubhttps://github.com/bkeepers/qu/issues/80#issuecomment-34557015 .
Maurício Linhares http://mauricio.github.io/ - http://twitter.com/#!/mauriciojr
I'd love optional heartbeat tracking. NullHeartbeat by default, but allow people to inject a redis or whatever based heartbeat that is similar to https://github.com/shaiguitar/resque_stuck_queue. Something that gives people insight into the workers.