New event if the message of a push notification changes?

[manelrodero]

⚠️ Please verify that this bug has NOT been raised before.

• I checked and didn't find similar issue

🛡️ Security Policy

• I agree to have read this project Security Policy

📝 Describe your problem

When monitoring every 1 minute via URL push, a new event does not appear if the status has not changed.

For example, if I use a URL like this https://my.kuma/api/push/r35ZHhZ43F?status=up&msg=Idle&ping=0 to indicate that the server is Up but not working (Idle) using the message I get the following event:

But when I send a status change with a new message https://my.kuma/api/push/r35ZHhZ43F?status=up&msg=Running&ping=1, no event appears because the server is still Up.

Is there a way to log this "state change" of the service?

📝 Error Message(s) or Log

No response

🐻 Uptime-Kuma Version

1.22.1

💻 Operating System and Arch

Ubuntu 18.04.6 LTS

🌐 Browser

Microsoft Edge Versión 115.0.1901.183

🐋 Docker Version

ocker version 24.0.2, build cb74dfc

🟩 NodeJS Version

No response

[CommanderStorm]

One possiblitly would be changing your up/down definition:

• Idle => Down
• Running => Up

Your usage of the push monitor is possibly out of scope for an uptime monitor

[manelrodero]

You're right, I don't just want to know if the service works (up) or doesn't work (down) but the last state of the same in the style of what can be done with Nagios.

If I do it as you indicate I will see a color change from green to red which is not entirely true ;-)

Let's imagine that you want to monitor a print queue. It can be up and running with 0 jobs in the queue or with 10 jobs in the queue.

You could solve this by sending the number of jobs in the Ping parameter. But I have seen that if the ping is 0, the current value is reported as N/A.

I'm going to rethink how we implement monitoring for these types of services.

Thanks for the help.

[CommanderStorm]

See #2790 (comment)
See #1675 (comment)

Also see the issues requesting custom vales for push monitors
A ping of 0ms does not make sense => N/A

[manelrodero]

Thanks for the information.

They are interesting monitoring proposals because not every time a service responds to a ping or an HTTPS request it can be considered to be "Up". For example, a web application can respond but if the database behind it is down, there is no data. Any improvements to be able to know if something works or doesn't work in this broader sense will be welcome.

An option to activate the generation of a new event if the message changes, even if the status does not, can serve to include useful information when solving problems.

And you're right that a ping of 0 doesn't make sense, hehe, but since I was using it to pass the number of jobs in the print queue I found it curious that it said N/A when a 0 had been passed. I would understand if it was N /A if no value was passed to you ;-)

I said, thank you very much for the help and for this fantastic project.

[bernarddt]

I'm also looking for this solution. My scenario is very similar to the printer queue case. I have a worker service that pulls information from hardware on a LAN, and that service is "up" or "down" but then I also want it to report a count, but in my case, if the count is more than a set value the system should consider it a fail and send an alert. So to give a broader example: If you have a IOT device that reports temperature, it can be up because it is calling the heartbeat server, but when it reports temps above say 100degrees I want Uptime Kuma to report this as a "warning" or "failed" state since there is trouble that needs to be addressed on that IOT's room.

A good addition would also be if we can set a Keyword that should be present in the message. So if it is not, the service should considered to be in a failed state.

Are there any good examples of how the current implementation of the Push Monitor can be used? I'm curious as to how the "ping" apply, or the "status" or the "Msg" values. How they are used, can I send anything, how long can the message be?

[github-actions]

We are clearing up our old issues and your ticket has been open for 3 months with no activity. Remove stale label or comment or this will be closed in 2 days.

[github-actions]

This issue was closed because it has been stalled for 2 days with no activity.