Value based status monitoring

Is it a duplicated question? Guess not Kindof related to #518

Is your feature request related to a problem? Please describe. A lot of status elements are not measurable by just “online/offline”. For example we have a lot of background processes where the actual warning sign for an exited queue worker would be a queue filling up. This happens on a database level and the queue worker is not exposed by design. What we do is to have a status endpoint which exposes some values as json, for example the queue item count.

Describe the solution you’d like A perfect way to enable monitoring like this would be the possibility to get a specific url, parse values (either by type, like bool/int, or using a regex) and have a threshold for a warning.

Describe alternatives you’ve considered ELK Stack. Doable but a huge overload for a simple task. Also we could have additional status endpoints that would return 200 only if everything is fine, but this forces the monitoring level into the applications which is kind of not nice.

Additional context Example monitoring values (GET request on the status enpoint, something lik https://myapp.com/appstatus.json)

{
  "app_version":"fc12f05",
  "database_reachable":true,
  "laravel_version":"8.63.0",
  "queued_jobs":12,
  "failed_jobs":0,
  "php_version":"8.0.10",
  "report_generated_at":"2021-10-22 12:53:54"
}

We would like to get warning when database_reachable goes to false and when queue_jobs is more than 100.

[UmutAlihan]

Hi, this feature would be a statping killer 😃

Currently I am migrating my monitors to uptime-kuma and only feature missing is this returned json based monitoring with regex.

For example I have a selenium grid deployment and would like to check a json response from /health/status endpoint, which returns a large json. I only need to see this key/value pair in the json:

“message”: “Selenium Grid ready.”

The below regex syntax provides this control with Statping. (message)“: “((\”|[Selenium Grid ready.])*)”

I am currently only checking for 200 status code. But I would love to see readiness monitoring as in this example at uptime-kuma too.

Cheers,

[moay]

If the system is offline, something not running, then chances are your service will also not respond to a check from UK.

You are absolutely right. For example if the database is not reachable, in our case probably the system won’t even render the status endpoint.

Depending on how creatively you craft your push script, it’s a fire and forget task.

Also valid. Just thinking about creating a small script where we configure the needed status checks in an ini/json/yaml/whatever file and run them one by one. This could be a valid use case, at least for checking the background processes individually and independent from the status endpoint rendering. This will still end up sending a lot of requests to UK in a short period of time, don’t know where the limit is there. But if done in sequence, shouldn’t be a problem.

I still think that this doesn’t solve all my issues, but together with #518, this could be a good solution. Thanks for the input.