extend check api with runner id or tags #3

New Issue

gibheer · 2018-12-14T15:47:07+01:00

gibheer commented

2018-12-14 15:47:07 +01:00

At the moment moncheck has to work on all active checks. With checks split between continents or different types of checks (databases, host checks, remote checks, data checks), this can get a bit troublesome, when a different method of calling the checks is necessary (moncheck only calls binaries with arguments).

To make it possible to run a wider range of check types, the active_check column should be extended with a new field. This field should state the group which should/can run this check.

approach: make the column an array of tags. The runner gets a tag and selects all checks, that match his tag.
approach: create an ID which marks a specific area of checks. The runner then selects all checks that match his defined ID list.

Both approaches would allow the separation into zones/types/... That tag system would it make possible to match multiple tags at the same time, which would allow for example the combination [eu, remote] or [nz, graph]. So it would make it possible to match against a list of tags at the same time. On the other hand it would make it more complicated for postgres to find the correct match, but performance benchmarks would need to be done here.
The second approach would have the advantage, that the type of lookup gets much smaller. By configuring the runner to look for specific IDs, the amount of work necessary by postgres should be minimized quite a bit. I think it would also be easier for others to implement an IN clause than a ANY clause.

At the moment moncheck has to work on all active checks. With checks split between continents or different types of checks (databases, host checks, remote checks, data checks), this can get a bit troublesome, when a different method of calling the checks is necessary (moncheck only calls binaries with arguments). To make it possible to run a wider range of check types, the active_check column should be extended with a new field. This field should state the group which should/can run this check. 1. approach: make the column an array of tags. The runner gets a tag and selects all checks, that match his tag. 2. approach: create an ID which marks a specific area of checks. The runner then selects all checks that match his defined ID list. Both approaches would allow the separation into zones/types/... That tag system would it make possible to match multiple tags at the same time, which would allow for example the combination [eu, remote] or [nz, graph]. So it would make it possible to match against a list of tags at the same time. On the other hand it would make it more complicated for postgres to find the correct match, but performance benchmarks would need to be done here. The second approach would have the advantage, that the type of lookup gets much smaller. By configuring the runner to look for specific IDs, the amount of work necessary by postgres should be minimized quite a bit. I think it would also be easier for others to implement an IN clause than a ANY clause.

gibheer added the

moncheck

label 2018-12-14 15:47:07 +01:00

gibheer added this to the 0.2 milestone 2018-12-14 16:05:22 +01:00

Sign in to join this conversation.