Basic architecture of Seismometer

TODO: Rewrite this document.

Seismometer is composed of several modules that talk to each other using data bus. Modules perform various tasks: collect data about services (states, metrics or both), detect events that require sysadmin's attention, send alerts and so on.

Modules communicate using messages that can be represented as JSON documents. Exact message schema can be found here.

Except for BrookEngine, these modules come from Seismometer Toolbox.

The below-mentioned tools communicate and run similar to this:

Architecture diagram

General data archiver is not provided by Seismometer Toolbox. Data archiver can be a separate tool running either under daemonshepherd or as standalone daemon.


BrookEngine works as a data bus. All the other modules use it to submit and receive messages.

BrookEngine operates on channels. Clients subscribe to one or more channel to receive messages from them. Clients can also register a channel to publish messages.

Registering and subscribing a channel are independent operations: a client can subscribe to a channel that nobody has registered yet. If any other client starts sending messages to this channel, subscriber will receive them.


Service that keeps several processes running. It's intended to simplify developing new modules, because they don't need to cover daemonization.

daemonshepherd makes also running the modules easier, since they all start and stop under the same supervisor instead of being separate entities in operating system.

Note that nothing stands against running your own tools under daemonshepherd. On the contrary, it was designed to facilitate this.


Simple script to execute checks at appropriate intervals. DumbProbe generates messages and submits them to BrookEngine.


Messenger's task is to isolate probes (e.g. DumbProbe) from network failures. Typically, DumbProbe sends results of checks to locally running messenger, which sends them further to a monitoring server, spooling them in case of connectivity error.