@gnosis.pm/dx-monitor

Gnosis Monitor

Gnosis monitor is a general porpouse notification system.

• The monitor responsability is to execute several checks at certain intervals.
• Every checks is an independent module (node dependency), that holds the logic of the check
• Every check is implemented with as little dependencies as possible.
• The monitor will also inject into every check their:
  • Configuration
  • Some repositories that will help to implement the check logic: i.e. web3, mailRepo to send mails, keyValueRepo to handle simple persistance.

Run a monitor group

# Install dependencies
yarn install

# Run any monitor group
yarn start <montitor-group-name>

Monitor groups

A monitor group is a list of checks that are done at the same intervals.

They have a arbitrary name, usually it references either when it's being executed or the functional name of the check list it contains.

They will match a chron job, for example:

00  07  *  *  1      npm run --silent --prefix /usr/src/app daily-midnight

NOTE: Instead of using a chron service within the docker image, we would use Kubernetes chron jobs.

Were daily-midnight is just a group defined in the configuration:

const monitorGroups = {
  'daily-midnight': [{
    name: 'DutchX upgrade',
    description: 'Monitor DutchX master contract changes',
    handler: '@gnosis.pm/monitor-dutchx-upgrade/src/MonitorDutchXUpgrade',
    config: {
      // Any config can be set here, it will be handed to the constructor, but
      // usually no config is needed and most parametrization should be done 
      // by env variable (use a prefix in the env vars to prevent name 
      // collitions)
    }
  },{
    name: 'OWL upgrade',
    description: 'OWL master contract change',
    handler: '@gnosis.pm/monitor-owl-upgrade/src/MonitorOwlUpgrade'
  }],

  // ...
}

Handlers

The handlers are the ones holding the logic for the check.

The handler have only one method:

• check() : Promise<Void>

The monitor will initialize the handler using the config, and also it's going to inject repositories to make check implementation easier. i.e:

new MonitorDutchXUpgrade({
  keyValueRepo,  
  mailRepo,
  web3
  // maybe in the future we add more repos, like slack repo, etc...
}, config)

Were keyValueRepo will be a repository that will allow the checks to persist and access data, so they can keep state.

KeyValueRepo

Allows to persist and fetch data.

The interface is very simple:

• get(key: String) : Promise<JsonValue>:
  • Throw exception if the key doesn't exist
• set(key: key, value: JsonValue) : Promise<void>
• delete(key: JsonValue) : Promise<void>
  • Throw exception if the key doesn't exist

Where JsonValue is any valid JSON: https://www.json.org

For example, the checks can do logics like:

// Save last execution
const now = new Date()
await keyValueRepo.set('dutchx:update:lastExecution', now.toISOString())

// Get last master addresses used and if we already notified
const masterAddress = await keyValueRepo.get('dutchx:update:masterAddress')
const alreadyNotified = await keyValueRepo.get('dutchx:update:alreadyNotified')

MailRepo

Allows to send mails.

The interface is:

• sendMail(params) : Proise<void>

Were params is an object with:

• from: The from will be ignored, so is not actually a param. It'll be set to the one defined in the configuration of the monitor.
• to: i.e. '[e-mail]', can be a list also
• subject: i.e. 'Hi there ✔'
• text: i.e. 'How are you doing?'
• html: i.e. 'How are <b>you</b> doing?'

web3

All checks will receive a web3 instance:

• https://github.com/ethereum/web3.js