On 08/01/19 10:14 -0600, Ken Gaillot wrote: > On Tue, 2019-01-08 at 15:27 +0800, T. Ladd Omar wrote: >> I have a question, if the Pacemaker has an event-notify interface >> which is realized by push&pull. Recently I want to do something >> extra using other process when the resources being started or >> deleted. So I need a way to monitor the resources events. >> ClusterMon and alerts both use external-scripts for extra actions, >> but in my situation, the specific process might have not being >> started. I hope pacemaker itself could store the old events and >> flush them for updating until the specific process starts and >> subscribe to Pacemaker, then pull all the old events. Also the >> Pacemaker could push to it when new events come. > > I would use alerts with alert_file.sh (with custom modifications if > desired) to record them to a file, then have your process look at that. > (Tip: if you only care about events since the last boot, put the file > in /run so you don't have to worry about cleaning it up.)
Based on what's been described, it sounds like asking for extended functionality that might be served with an external "store-and-forward" daemon. Such a daemon would also alleviate the processing complexity in case of plentiful alert subscribers when they are used for subsequent forwarding and/or extraction to assist decisions, since it would conceptually detach such postprocessing from the main executive flow fully (e.g. no sharing of the same security boundaries, cgroup, etc.; access control would be the sole responsibility of this daemon), and allow for durability of the events with desired parameters. Such a daemon could then gradually overtake the responsibility to keep event stream subscribers updated, itself making use of a more suitable hooking directly into pacemaker. That's how the future could evolve. Contributions welcome. >> Above is all what I thought, maybe it is not accurate. Anyway, I >> need some advice. By the way, there is no deletion notify in >> ClusterMon and alerts, right ? > > Correct, configuration changes are not alerted. The only way I know of > to get configuration changes is to use the C API for update/replace > callbacks. It would also be possible to poll the configuration at > intervals and use crm_diff to compare them, but that's probably not any > easier. The hypothetical daemon could keep up with whatever events that get exposed internally. -- Jan (Poki)
pgpAU_esR0VdY.pgp
Description: PGP signature
_______________________________________________ Users mailing list: [email protected] https://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
