@gnosis.pm/dx-monitor
v0.0.2
Published
Gnosis monitor is a general porpouse notification system.
Downloads
2
Keywords
Readme
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. '[email protected]'
, can be a list alsosubject
: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