matrix-org / matrixmon

A small end-to-end prober and Prometheus stats exporter for a Matrix homeserver

matrixmon

A small end-to-end prober and Prometheus stats exporter for a Matrix homeserver.

Running

Make a copy of the configuration template:

cp mon.yaml.example mon.yaml

Edit mon.yaml with the correct details regarding your homeserver, monitor user, access token and room ID.

Optionally edit the port and other values, if needed.

By default, Matrixmon expects the config file to be found in the same path where it runs. A custom config file location (full path to file including file name) can be set with the environment variable MATRIXMON_CONFIG_PATH.

Using Docker

docker run -ti matrixdotorg/matrixmon -v $PWD/mon.yaml:/app/mon.yaml -p 9091:9091

Manually

On Debian/Ubuntu, example:

To build:

sudo apt-get install perl cpanminus build-essential libssl-dev zlib1g-dev
./install-deps.pl

To run:

perl mon.pl

Metrics

Prometheus metrics are by default exposed at http://localhost:9091/metrics.

License

Apache 2.0

matrixmon's Issues

Make the bot exit if it starts receiving 403

It would be more useful to see the bot exit if it cannot login any more than to make it constantly hammer itself against a wall.

Emergency "Slow mode"

In normal operation the defaults are interval=30s, send_deadline=5s, recv_deadline=20s. This gives a good granularity on the graphs.

During high-stress scenarios, such as near-outage, it may be useful that the monitor can switch to a different mode of much higher interval and longer deadlines, so we get at least some visibility if the server is making progress just very slowly; trading off longer deadlines before giving up, with reduced granularity of time.

Allow using access token instead of password

https://metacpan.org/pod/Net::Async::Matrix#user_id,-access_token

Transaction IDs start at zero and are incremented.

This has a possible failure mode if:

12:00 : matrixmon is started, sending trx_id 0 through (say 720)
18:00 : matrixmon is restarted, losing the local trx_id, causing it to start again at trx_id 0.

The next 6 hours of events will be accepted with a 200 OK by the server (because their transaction ID matches one that has already been accepted) but will not be received by the receiver, showing up as an outage.

When the restarted matrixmon reaches transactionID 721, it will start functioning again.

We should consider initalizing the transaction ID to a timestamp based value here:

https://github.com/matrix-org/matrixmon/blob/master/mon.pl#L152