[groups] Conditional monitoring

[LukasL28]

⚠️ Please verify that this feature request has NOT been suggested before.

• [X] I checked and didn't find similar feature request

🏷️ Feature Request Type

New Monitor

🔖 Feature description

A Monitor, that uses other Monitors as a and/or condition.

✔️ Solution

Add another Monitor, where you can select other Monitors as condition

Example: I have an application, with a Database and a Webserver, but I want users to only see the application as a whole on their Status Page. So why not make a Monitor where I can select the Database Monitor (Docker Monitor) and the Webserver Monitor (Ping) and combine them into one called “Application”, then I have to set the condition for example “or” so if the Database or the Webserver are down the whole Application is displayed as being down.

❓ Alternatives

No response

📝 Additional Context

No response

[michield]

Isn't it sufficient to just monitor the Website? If the DB is down, the Website would be down as well. Unless I misunderstand the setup.

[skaempfe]

In general I like the idea. In detail it might get quite complex quite fast. Being able to add more than one URL to the http check and define how many have to be UP to be "healthy" sounds interesting. But the complexity of several and/or's of stacked checks might be a real pain...

There are other feature requests already suggested where one can define dependent monitors( #1236 ), so if monitor a is down, then monitor b will also not work and should not be checked separately (and alerted separately).

One possible solution, in a direction as @michield suggested (outside uptime-kuma): Implement a small "health-check" as part of your Webserber which checks all dependent services on demand. That's what we are doing in many of our applications and that's why I suggested a new monitor type ( see #2501 ). Every application checks it's direct dependencies (database, backend systems and so on) and reports their status within its own healthcheck.

{
  "status": "DOWN",
  "checks": [
    {
      "name": "database",
      "status": "DOWN",
      "data": {
        "errorcode": "42",
        "description": "connection timeout"
      }
    },
    {
      "name": "smtp-server",
      "status": "UP"
    }
  ]
}

For some more details and examples please take a look at the eclipse documentation: protocol-and-wireformat

[danmed]

My use case may be a little more simplified than what you all would use this for but for example.. .i'm monitoring my home internet connection along side services within my LAN.. if my internet connection is down then i don't need notifications for everything inside my LAN.. so for me i'd only need a 2 tiered option..

[wortkrieg]

+1 on this request. Use case would be e.g. for multiple servers running in a cluster. If one of them fails I can display an outage via only one monitor on a status page. Or just send a notification if all of the monitors (could be multiple redundant switches in my core network) in one condition fail. Configuration might be done quite easy, a bit like adding tags but choosing monitors instead of tags and saying globally if the monitor should work as a and/or conditional. No need to setup the monitors twice, just use the status information of the already existing monitors..

[maxpivo]

also +1. The ideal feature for me would allow association with the parent monitor, e.g. ping. If the ping monitor is down, none of the below service specific monitors get notified on. should just be able to select parent when creating a new monitor. This way for the basic use case of "is host on the network?" no, then all the http/tcp service monitors in place don't notify, which make incident response more actionable (host is offline, don't worry about the services until the host issue is resolved)

[Bodge-IT]

+1 on this. While I can see the arguement for creating monitors that are simple and highlight any subordinate issues, it does sometimes help to have structural dependencies. e.g. had 1 monitor for http call (to track internet availablity) failing, all subsesequent fault finding showed DNS issue on the Uptime Kuma system, spent 30 mins tracking down DNS issues when suddenly realised the Kuma system gets external DNS through site-to-site VPN. The VPN was down....

Would be a nice to have to link monitors showing clear relationships.

[ACiDGRiM]

I will share that this is valuable beyond the original post usecase. For example, I want to test connectivity to the internet and only send alerts if "internet" is up. Furthermore, I want to test if the edge router for my remote network is up before sending alerts for services behind it.

[CommanderStorm]

@Bodge-IT

Would be a nice to have to link monitors showing clear relationships

I think #2693 (to be merged in https://github.com/louislam/uptime-kuma/milestone/31) will solve this issue.

From a UX perspective, I think Conditional Monitors could easily get very confusing. Ideas to get around this?

[Bodge-IT]

@Bodge-IT

Would be a nice to have to link monitors showing clear relationships

I think #2693 (to be merged in https://github.com/louislam/uptime-kuma/milestone/31) will solve this issue.

From a UX perspective, I think Conditional Monitors could easily get very confusing. Ideas to get around this?

A suggestion for the ui, would simply be a depends-on button for a node(showing status of depended-on nodes i.e. down/red if any depended-on node is affected). The button could maybe trigger a popup(I know...terrible UI but quick), that displays links to one or more depended-on nodes(including their current status).
Your point about getting confusing is valid, but by definition these things are hierarchical in nature and therefore threadable as opposed to flat. You could simply display them as a folder structure with down-the-line dependents shown inset under the dependent node.

[CommanderStorm]

I dont think the popup would solve the problem of having

• loops in the conditions
• Communication about how these work would be challenging

I don't fully get what you mean by the folder structure. Could you provide a mockup (ms-paint/ drawn on paper and photographed)?

[ACiDGRiM]

The dialogue I'm suggesting could look like this mockup

WebApp dependents ☑️ dependent 1 ✅️ API health ☑️ dependent 3

Then when opening dependent settings for any other monitor, WebApp could not be selected as a dependent. However a monitor could be a dependent for multiple master services.

API Health dependents ☑️ dependent 1 ☑️ dependent 3

This would allow any number of apps to depend on one master monitor, and prevent a master monitor from being dependent on any other, including loop scenario.

This has some limitations, where a line of legitimate dependencies (i.e. monitoring remote service which depends on internet, monitor which depends on the local router) however that would require testing the whole relationship chain for loops. This achieves the goal to minimize Down notifications while potentially minimizing complexity.

Just my 0.03$ adjusted for inflation

[zimbres]

Not sure if it is similar to this, but in systems like WhatsUP Gold, PRTG, Zabbix, there is an option for device dependencies, I can set a parent monitor and in case of its down or paused, its childs status will be ignored.

[Bodge-IT]

Sort of. I used to use What'sup Gold in my DevOps days. My idea sort of combines that relationship dependency to enable a sort of "if this and that then this must be at fault" then activate this notification sort of monitoring.

I'd be happy with the parent dependency thing too, it would still improve the product.

On Wed, 5 Jul 2023 at 15:24, Marcio Zimbres @.***> wrote:

Not sure if it is similar to this, but in systems like WhatsUP Gold, PRTG, Zabbix, there is an option for device dependencies, I can set a parent monitor and in case of its down or paused, its childs status will be ignored.

— Reply to this email directly, view it on GitHub https://github.com/louislam/uptime-kuma/issues/2487#issuecomment-1621869153, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOLMKVGSJGSK54KD5B4WA3XOV2KRANCNFSM6AAAAAATKWCGYA . You are receiving this because you were mentioned.Message ID: @.***>

[sevmonster]

Would it simply be enough to allow a service to be assigned to multiple groups? I think all the usecases presented here would be covered, except the advanced conditional processing part—but I am not sure what real benefit that would provide over multi-grouping.

[fboaventura]

Hi!

I'll share an image to help explain my use case for conditional monitoring, or dependency, for groups and single assets.

This is my home lab, from where I monitor not only assets in my local network but also external servers and services:

As it is now, if srv01 (uptime-kuma) fails to reach the firewall, I'll get a push notification for each asset above it as being down. If it fails to reach the wifi-rtr02, I'll get a push notification for everything outside srv01 being down.

Ideally, in both cases above, I would only receive a notification stating that wifi-rtr02 is down and everything above it is unreachable because srv01 can't tell if they are down or not. And the notification for each state (up, down, and unreachable) would be configured separately. I could opt not to receive an unreachable notification or just for the first alert while still getting a down notification every X minutes.

Again, ideally, dependencies would be established on all levels: services or a group of services to servers, servers or a group of servers to network assets, network assets to links, etc.