4 ms·
> But where's the difference between not being able to pull vs. not receiving metrics for a period of time? Let's say I have a service that's only used once pe
by sz4kerto 9y ago
> But where's the difference between not being able to pull vs. not receiving metrics for a period of time?
Let's say I have a service that's only used once per day, at a random point in the day. I need to know if the service is available all the time, even if it's not used. With pull, I'll get back an 'OK' e.g. every minute. You could say that we should implement heartbeats, but again, then this service needs to be configurable to pick up changes in the monitoring infrastructure, then I need to have a separate check for the presence of heartbeats and the values of the samples..
- zaroth 9y agoMonitoring if the process is running, if the input queue is free, if it will take a new job, etc. seems to me the responsibility for all that should be with whatever supervisor has the ability to reset/restart the service. Then it can report stats on uptime and number of restarts required. What if the service spins up on demand when it's needed, does its job, and then exits. You want to track how often it starts, how long it runs, how long the job was in the queue, how much CPU/RAM/IO was consumed, etc. With push that's all part of the cleanup code in the process. With pull it seems like you could completely miss that the process was even ever run?
- bbrazil 9y agoThat's a short lived batch job, for which a different approach is needed - basically push is the sane option there as pull won't cut it. Prometheus has the Pushgateway for this. The push vs pull debate is relevant for longer running daemons, not batch jobs.