There are a few pieces to this task.
- A separate event service that receives events from the supervisor on a zeromq socket and publishes those events out to anything that's listening. Listening processes will subscribe to the zeromq socket that the event service publishes.
- An internal queue that the supervisor maintains where event data is deposited. This could be represented as a file on the filesystem.
There should be a separate thread in the supervisor that's taking the event data from the census and putting it into the internal queue for publishing. If the supervisor isn't configured to talk to the event service, then it doesn't do anything at all.
The event data that's put into the queue is the "me" portion of the census, e.g. each supervisor puts what it knows about itself (in its entirety, not a diff) onto the queue every time it changes.