[Question] - What is the max time for the thold poller
Hey guys
I also asked this on the forums but not much there
What is the max poller timeout for Thold ? For example for spine if you have a 1-minute poll setup its 58 seconds max before it exits does thold have this same mechanism or does it go until finishes?
Thanks !
No, do you update lib/functions.php from the 1.2.x branch lately. Bug performance bug with 1.2.16 release. So, if you haven't updated, you should.
Hey Larry
This is not on 1.2.16 yet So the thold poller will go indefinitely ? I am not talking about the daemon just the regular php poller
On Mon, Dec 21, 2020, 17:57 TheWitness [email protected] wrote:
No, do you update lib/functions.php from the 1.2.x branch lately. Bug performance bug with 1.2.16 release. So, if you haven't updated, you should.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Cacti/plugin_thold/issues/480#issuecomment-749243064, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADGEXTCELY2NWLO6TBZEQG3SV7HGHANCNFSM4VERJMMA .
We need @browniebraun to get engaged. He wrote the thold daemon.
I know that there are companies with 10's of K of thold using the daemon. What we have a real problem with it message queuing. Each thold triggered has to wait on sendmail. Not a good plan. We need to setup a notification queue (basically a table) to hold all the pending notifications. That way it's light speed to do updates, and then background the actual notifications.
Other option is to use something like redis, but I don't want to build a bunch of additional dependencies right now.
A notification queue wouldn't be that difficult. Could also help for when the mail server is down. As it will retry them. Honestly, maybe the queue should be built into Cacti, and then plugins just push stuff to the queue to send.
Yea, we had always planned to bring the whole 'Notification Lists' into core anyway. We should just pull the trigger (develop of course).
But for the non daemon poller like the basic install of thold does that have a poller timeout ?
Essential later on we plan to move to the daemon on the install I am working on right now but I saw poor performance on the daemon so while I figure that out I see thold sits around 40 seconds to poll 76k thresholds if it goes say to 80seconds would it exit ?
I agree of the notifications as well
On Mon, Dec 21, 2020, 19:48 TheWitness [email protected] wrote:
Yea, we had always planned to bring the whole 'Notification Lists' into core anyway. We should just pull the trigger (develop of course).
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Cacti/plugin_thold/issues/480#issuecomment-749275969, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADGEXTGVLPNOG74MN6B52ZLSV7UG7ANCNFSM4VERJMMA .
@seanmancini, the daemon timing is kind of confusing, and a bit misleading as memory serves. So, we really need to get @browniebraun to chime in. He's in Germany. So, it's past bedtime now.
Ok cool
Just just for my understanding by default without the daemon doesn't thold call on thold_process.php and not the thold_daemon unless you have the service installed
On Mon, Dec 21, 2020, 19:56 TheWitness [email protected] wrote:
@seanmancini https://github.com/seanmancini, the daemon timing is kind of confusing, and a bit misleading as memory serves. So, we really need to get @browniebraun https://github.com/browniebraun to chime in. He's in Germany. So, it's past bedtime now.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Cacti/plugin_thold/issues/480#issuecomment-749277807, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADGEXTCUVDGYHBG4JIY4MQTSV7VD3ANCNFSM4VERJMMA .
@bmfmancini,
It's going to get interesting in the two weeks ahead of us. I'm on the cusp of a major 'develop' commit. Once I start working on 'develop', there will be a clean break between 1.2.x and develop. It'll be hard to be run a 'develop' thold with a 1.2.x branch Cacti in other words.
I'll try to keep some thought on what is supported where, but you should know that 1.2.x will enter into a LTS mode, and all new "make it faster" changes will be focused on the various 'develop' branches, and they wont be backwards compatible.
So, it's going to get interesting. I'll try to manage both worlds, but at some point, 1.2.x will be behind us all.
Larry
Sounds good to me we try to keep up with the latest versions anyway looking forward to the new updates !!!!
On Mon, Dec 21, 2020, 20:02 TheWitness [email protected] wrote:
@bmfmancini https://github.com/bmfmancini,
It's going to get interesting in the two weeks ahead of us. I'm on the cusp of a major 'develop' commit. Once I start working on 'develop', there will be a clean break between 1.2.x and develop. It'll be hard to be run a 'develop' thold with a 1.2.x branch Cacti in other words.
I'll try to keep some thought on what is supported where, but you should know that 1.2.x will enter into a LTS mode, and all new "make it faster" changes will be focused on the various 'develop' branches, and they wont be backwards compatible.
So, it's going to get interesting. I'll try to manage both worlds, but at some point, 1.2.x will be behind us all.
Larry
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Cacti/plugin_thold/issues/480#issuecomment-749279387, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADGEXTGPCWCCWXPIBNMCSLLSV7V2HANCNFSM4VERJMMA .
'develop' is where my attention will be, and Notification Lists and Event Queuing are pretty high on the list after I do a bunch of 'cleanup' and prepare the project for more pull requests from the outside world.
Closing this one. There is no request. Support only.