Group monitors

[julian-piehl]

⚠️⚠️⚠️ Since we do not accept all types of pull requests and do not want to waste your time. Please be sure that you have read pull request rules:
https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md#can-i-create-a-pull-request-for-uptime-kuma

Tick the checkbox if you understand [x]:

• I have read and understand the pull request rules.

Description

Hello Guys,

I saw that many users requested a grouping feature... and I also wanted one. So I added it.

You can group services however and how deep you like.

The group always takes the state of the worsted child. If all are green and one in red. The whole group will be red.

This means you can set your notification at the parent level and get one message instead of 10 if something is broken.

Also, if you want to do maintenance, you can just set it at the parent and all children go into maintenance too.

The same happens if you pause the group.

To add a group, simply add a monitor and select "group" as its type.

To add monitors to this group, just edit the monitor and select the group in the "monitor group" dropdown.

If you create subgroups, it can look like this:

And of course, if one item in the subgroup fails, the subgroups fails and also the main group itself.

In text fields, subgroups are displayed using slashes like this Cloud / HTTPS.

And your state, which group is collapsed and which not, gets saved in your browser.

In your status page, you can now simply select the group to get displayed instead of every single service separately.
This makes the status page more simple and better for your normal users.

Fixes:

• collecting monitors into groups #2692
• Add a possibility to make groups and priority's  #2585
• [groups] Dependent monitoring of hierarchical monitors #1089
• [Feature Req.] Status Page - Add sub-groups #639
• [groups] Support for collections #549
• Group notifications #324
• Ability to create Dependency Relationships #216
• [Feature Request] Service Grouping #29
• Group monitors and search filters #12

Type of change

Please delete any options that are not relevant.

• User interface (UI)
• New feature (non-breaking change which adds functionality)
• This change requires a documentation update (maybe)

Checklist

• My code follows the style guidelines of this project
• I ran ESLint and other linters for modified files
• I have performed a self-review of my own code and tested it
• I have commented my code, particularly in hard-to-understand areas
  (including JSDoc for methods)
• My changes generate no new warnings
• My code needed automated testing. I have added them (this is optional task)

[Gauvino]

Absolutely incredible, I’ve so long to get this into Kuma thank you so much

[david7867z]

Finally, some order is brought into my life.
Hopefully the feature is approved soon!

[a1git]

Awesome .. can you please also share if there is an API which we can use to script existing objects into groups..

[julian-piehl]

Awesome .. can you please also share if there is an API which we can use to script existing objects into groups..

If I'm seeing it correctly, kuma only has a small amount of API endpoints. Most of them for generating badge SVGs.
So currently there isn't an endpoint for creating or editing monitors.

I don't want to speak for the project maintainers, but I think this is a feature which we can expect somewhere in the future, but currently there isn't an API for this type of automation.

In difference to most projects, the kuma frontend gets all data through web sockets. If you really want to script your task, maybe you can connect to this web socket and send commands to it like the frontend client does... But this would be a very tricky task, I think. Or create a python script which clicks for you in the browser.

But currently I see no official API support for automation.

[a1git]

I am using this API => https://pypi.org/project/uptime-kuma-api/0.9.0/

[julian-piehl]

I am using this API => https://pypi.org/project/uptime-kuma-api/0.9.0/

Exactly what I said. The creator of this API build its own client which connects to the web socket. So technically it's possible to use groups with this API. But the Maintainer of the API project first has to implement this feature.

[chakflying]

Quickly reviewed most of it and it looks quite reasonable! I don't expect this to be merged anytime soon but:

• to prevent infinite recursion, should there be a server-side check for loops? Or the parenting should be limited to a reasonable number?
• Using isActive in the backup code probably won't work since it needs to set the actual active column in DB? But I'm also refactoring this in Fix: Update json backup tool for new features #2667 so maybe we can ignore it for now.

[julian-piehl]

I don't expect this to be merged anytime soon

Why do you think that? I mean, it's a bigger feature, but also a long expected from many users.

to prevent infinite recursion, should there be a server-side check for loops?

Currently, there is a client-side check to stop loops. But maybe a server-side check should be added too, to be secure.

Or the parenting should be limited to a reasonable number?

I also thought about this. It would stop users from creating their complete own structure, but maybe. The question is how deep should it max go. And should this value be editable using the Settings Page, or an env?

Using isActive in the backup code probably won't work since it needs to set the actual active column in DB?

isActive only is a getter for checking if the monitor itself and all ancestors are active. To set the value, you still use this.active. The same goes for getting the active state of the monitor itself.
The backup logic should still be working.

[ItsCryptic]

I've been waiting for this feature! I'm very excited for this to get merged!!

[julian-piehl]

to prevent infinite recursion, should there be a server-side check for loops?

Thanks to server- and client-side checks, endless loops should now be impossible.
Thanks for the hint @chakflying

[louislam]

It sounds like it is duplicate of #1236?

[julian-piehl]

It sounds like it is duplicate of #1236?
@louislam

Partially. Dependence is just one function of this PR. Only a side functionality. The main feature is the grouping. That the group displays the state of the children only got added because I wanted something to be shown in the group state. But it's very useful.

[louislam]

It is good to read the pull request rules first next time. A large pull request should have a discussion first.

I originally planned to merge #1236 in 1.21.0.
Since I believe that I can merge either one pr only. It may be hard for me to make a decision. Usually I will reject the later one. But in this case, I think this pr's UI/UX is better and the solution is straightforward.

While for #1236, it provides many-to-many relation, which means a monitor belong to more than one group. But I don't like the new status DEGRADED is being added.

So it is hard for me to choose.

[julian-piehl]

Earlier we discussed about the status being displayed for groups. And the other solution using Dependencies (#1236).
I initially just added this feature to the groups because I didn't know what icon to display else.

Maybe it would be a cool idea to remove this feature from this pr again and put the expand icon in the status position instead.
Then the pr #1236 could be merged too, allowing to create better dependency monitors like some people requested.
Or both dependency functions can be implemented... But I don't know if that causes confusion.

[louislam]

Testing this PR, I haven't found any major issues, but I do have some suggestions:

1. If they are always empty and N/A, they could be hidden.
   

2. Prefixing the group name seems to be too long in my opinion.
   

3. If a monitor has been added to a group, should it be hidden in the "root" list?
   

4. In terms of UX, it would be great if users could add a list of child monitors in the edit page. However, considering it is just the first PR for the group, it is ok to not include this in this stage. We could do it in another PR.

   An example from the maintenance edit page:
   

Thanks for the great work!

[julian-piehl]

1. If they are always empty and N/A, they could be hidden.

Ping and avg ping can be hidden, because there is no use. I will change this.
The graph shows the same stats the other monitors show. For example, if one children is red, the group is also red, which gets displayed in the graph.

2. Prefixing the group name seems to be too long in my opinion.
3. If a monitor has been added to a group, should it be hidden in the "root" list?

This prefix style is only applied in two cases:

1. Select Boxes
2. When you are using the search bar

That's also the reason you are seeing the element 2 times (point 3). This happens when using the search, because both, the parent and the child are matching your search key.
I have no idea how I could visualize this in a better way. Ideas are appreciated.

When using no search key, the groups are displayed like expected.

4. In terms of UX, it would be great if users could add a list of child monitors in the edit page. However, considering it is just the first PR for the group, it is ok to not include this in this stage. We could do it in another PR.

A great idea. I will look into it.

[louislam]

1. If they are always empty and N/A, they could be hidden.

Ping and avg ping can be hidden, because there is no use. I will change this. The graph shows the same stats the other monitors show. For example, if one children is red, the group is also red, which gets displayed in the graph.

2. Prefixing the group name seems to be too long in my opinion.
3. If a monitor has been added to a group, should it be hidden in the "root" list?

This prefix style is only applied in two cases:

1. Select Boxes

2. When you are using the search bar

That's also the reason you are seeing the element 2 times (point 3). This happens when using the search, because both, the parent and the child are matching your search key. I have no idea how I could visualize this in a better way. Ideas are appreciated.

When using no search key, the groups are displayed like expected.

4. In terms of UX, it would be great if users could add a list of child monitors in the edit page. However, considering it is just the first PR for the group, it is ok to not include this in this stage. We could do it in another PR.

A great idea. I will look into it.

No problem, I got your point. I merge it first.

[ldev-coder]

It would be possible to add the function of when I add a group or subgroup on the status pages, the same to let the group open or close it in the customer view, as there is in the dashboard the possibility to open the group or when it is open it can be closed ?

Dashboard

Page Status

[fr4nc1stein]

It would be possible to add the function of when I add a group or subgroup on the status pages, the same to let the group open or close it in the customer view, as there is in the dashboard the possibility to open the group or when it is open it can be closed ?

Is someone working on this feature, a dropdown on monitor group in the status page?
Its easy to identify what happen under the group if we have this feature.

[CommanderStorm]

No, nobody is working on this as far as I know.
If you/someone else would like to contribute such a change, here is the Contribution guide:
https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md

Necroposting on closed PRs is also really not scalable from a project maintanance perspective
=> See #3324 for the correct issue ^^