Monitoring is about states, not exact values, so report the states, as
otherwise it results with bloating databases, very long accesses to results
and long synchronisations.

Instead of many entries like:

http://url/ : http_query: OK status code 302 on IPs IP elapsed_time: ERROR IP IP replied in 5.02s which is longer than maximum 5.00s
http://url/ : http_query: OK status code 302 on IPs IP elapsed_time: ERROR IP IP replied in 5.03s which is longer than maximum 5.00s
http://url/ : http_query: OK status code 302 on IPs IP elapsed_time: ERROR IP IP replied in 5.04s which is longer than maximum 5.00s
http://url/ : http_query: OK status code 302 on IPs IP elapsed_time: ERROR IP IP replied in 5.01s which is longer than maximum 5.00s
http://url/ : http_query: OK status code 302 on IPs IP elapsed_time: OK IP IP replied in 0.08s which is shorter than maximum 5.00s
http://url/ : http_query: OK status code 302 on IPs IP elapsed_time: OK IP IP replied in 1.37s which is shorter than maximum 5.00s
http://url/ : http_query: OK status code 302 on IPs IP elapsed_time: OK IP IP replied in 0.09s which is shorter than maximum 5.00s
http://url/ : http_query: OK status code 302 on IPs IP elapsed_time: OK IP IP replied in 1.37s which is shorter than maximum 5.00s
http://url/ : http_query: OK status code 302 on IPs IP elapsed_time: OK IP IP replied in 0.09s which is shorter than maximum 5.00s

It's minimised to:

http://url/ : http_query: OK status code 302 on IPs IP elapsed_time: ERROR IP IP replied in more time than maximum 5.00s
http://url/ : http_query: OK status code 302 on IPs IP elapsed_time: OK IP IP replied in less time than maximum 5.00s

This affects:

 * bot_status
 * http_query

Obviously some information are removed from the monitor, but anyway they are
just text entries and not parsable. So other approaches shall be used to make
graphs from those values, which is not covered by pure promise status.