Loading

The simplest way to load monitors is by specifying config.monitors:

monitors:
  - hostname: db1.local
    username: blip
    password: ...

  - hostname: db2.remote
    username: blip
    password: ...

Blip loads the two monitors specified in the config file. This is the simple case, but Blip can load monitors from other sources that support reloading.

The load squence is:

1. LoadMonitors plugin exclusively if defined; else:
2. config.monitors, and then
3. config.monitor-loader.files, and then
4. config.monitor-loader.aws; if no monitors loaded, then
5. Auto-detect local MySQL instances

Calling API endpoint /monitors/reload causes Blip to reload monitors for supported sources:

New monitors are started. Monitors that have been removed (no longer returned by the source) are unloaded (stopped and removed) from Blip. Monitors that have not change are not affected or restarted. A monitor stopped with /monitors/stop stays stopped until /monitors/start, unless its config changes.

Removed monitors are stopped in parallel. A reload waits for them to stop, but no longer than config.monitor-loader.stop-timeout.

Stop-loss prevents reloading from dropping too many MySQL instances due to unrelated external issues. For example, maybe the LoadMonitors plugin has a bug that causes it to return zero monitors when there are really 10 monitors. Stop-loss would prevent Blip from unloading all monitors, which could have adverse side effects for visibility and alerting.

Stop-loss measures the net drop in the number of monitors: the number loaded before the reload minus the number that would be loaded after it. New monitors offset removed monitors, and changed monitors don’t count. For example, with 10 monitors loaded, a reload that removes 4 monitors and adds 1 drops 3 monitors. If the drop is greater than the stop-loss limit, the reload fails and the loaded monitors are not changed. A drop equal to the limit is allowed.

Set config.monitor-loader.stop-loss to enable.