Monitoring metrics other than response time

[ball-hayden]

👋 This project looks awesome.

I'm thinking about setting this up to monitor our service, but it would be helpful if we could report on metrics other than just response time.

Specifically, I'm thinking about monitoring background work queues - I would like to be able to report the number of pending items in a work queue, and/or the average time taken for a job to be processed. I could easily expose this information for Upptime to scrape if there was a response format Upptime understood.

Is this something that would fit as part of the project, or is it too much feature creep?

[AnandChowdhary]

This is definitely very interesting. I'd love to see @upptime become a viable alternate to services like Statuspage, which also report, for example, "the number of items in this background process queue" as a metric.

I could easily expose this information for Upptime to scrape if there was a response format Upptime understood.

What do you have in mind? Could it be like an endpoint Upptime can use where you return a JSON response with the number of items currently in said queue, for example? Or do you have any other ideas about how to achieve this in a more secure way (in case a publicly available endpoint is too open)?

[ball-hayden]

like an endpoint Upptime can use where you return a JSON response with the number of items currently in said queue, for example?

Yeah - I was thinking something exactly like that. e.g.

curl https://myservice.example.com/upptime/queues/high_priority

{
  "value": 100
}

do you have any other ideas about how to achieve this in a more secure way (in case a publicly available endpoint is too open)

Would a repo secret sent as an auth header be sufficient?
Equally, I'd argue that these endpoints shouldn't be exposing anything that isn't going to be published on the status page, so an open endpoint should be fine?

[AnandChowdhary]

Some suggestions from #111:

I was wondering if it's possible to monitor ICMP response times, instead of HTTP response times. Also, would it be possible to disable showing the response times altogether? — @SagnikSRHUSE

Maybe it's also possible to add even more protocols. — @RafGamer

[alvarolopez]

Hi @AnandChowdhary.

Another related suggestion would be to have no monitoring whatsoever, but manually generate issues when needed.

I have checked the documentation and I could not find how to do it (maybe there is a way to do so), but it would be interesting in order to manually manage issues from non-web services (such as compute clusters).