Support to group endpoints into services

[alvarolopez]

For complex setups, it would be desirable to have a way to group different endpoints into higher level services).

For instance, one could have a group "Webservers" with several endpoints, and another group "Database" with other endpoints, and so on and so forth. It should also be possible to generate downtimes, issues and interventions also to these services.

[AnandChowdhary]

Makes a lot of sense, yes! How do you envision this working? Say you add 3 sites to a "group", we will not only tell you the response time etc. of each site, but also a group average? And perhaps a collapsable in the README?

[Andre601]

What I feel like would be a good (visual) solution:

• On the site, have the grouped endpoints in their own "box". It would basically be a header with the group name and those entries in one area.
• On the readme, just split up by headers and have separate tables for these entries. Like one table for all in group A, one for all in group B, etc.

I hope you get what I imagine here...

[alvarolopez]

The most simple approach (that would work for us) is to implement them just as containers: i.e. only some way of grouping endpoints together, with a small description linked with an overall status: OK or DEGRADED. The endpoints will still have their own metrics, and the group can be collapsed or not.

For instance, this is how it looks in our current status page (that we are migrating tp upptime): https://status.ifca.es/

[josephtaylor-mn]

What do you mean by containers? How did you get this to work?

[Soneji]

@alvarolopez Hi
I also like this idea and think your proposed methodology of grouping is amazing! I would love to see this implemented

[wolfier74]

Add that pls

[Soneji]

One alternative way I thought this could be set up would be to have a keyword in the yaml configuration file, such as:

sites:
  - name: example.com
    url: example.com
  - hr
  - name: example.com
    url: example.com

which could add a simple horizontal rule to the status website between monitors.

Let me know your thoughts.

PS Thank you for this great tool!

[AnandChowdhary]

Interesting, I was thinking something like:

groups:
  - id: 1
    name: API endpoints
sites:
  - name: example.com
    url: example.com
    group-id: 1
  - name: example.com
    url: example.com
    group-id: 1

[Soneji]

This looks good! 👍

Maybe we could have groups insides the sites block and inside the group block have the corresponding sites

This would avoid an extra field in every site

Just an idea, bit unsure of the yaml

additionally I was thinking it would be cool to have an option as to which groups are expanded or not expanded by default in the status page, for which I think your original implementation would be better

[ririko5834]

Yes, you can add something like cstate has
Config for groups:

groups:
    - name: Group 1
      description: Example group 1

and then

sites:
  - name: example.com
    url: example.com
    group: "Group 1"

The group description should be visible, when you place mouse on it:

[Soneji]

I think a numerical unique group-id value would be better than string matching

[ririko5834]

Ok, but add also group description

[nijel]

It would be also great to have an option to collapse a group by default - this is useful to hide endpoints which are not interesting for most of the users. We currently use this with Cachet (https://status.weblate.org/).

[mai0li]

Was this somehow implemented? Don't want to create a duplicate discussion thread.

[PersonalDom]

Just found this thread after making my own Facepalm is their an update for this?

[PersonalDom]

I'll link my thread here, so you can take a look at how i've designed the yml and actual page (just as ideas.)

My thread.

[LukePrior]

This sounds like a great feature to have.

[JuniYadi]

this is good if it can be made by group or category.

[JonathanTreffler]

This is not a solution for everybody here, as it does not allow for a parents status to be determined by its children uptime monitors, but if (like me) all you want is a visual way to group your monitors, you can achieve this using custom CSS:

status-website:
  css: "#sapper > main > section.live-status > article:nth-child(2), #sapper > main > section.live-status > article:nth-child(n+4):nth-child(-n+10) { margin-left: 40px; }"

The code above moves monitor 2 and monitors 4 -10 40px to the right, therefore making them appear grouped:

(in the screenshot monitors 3 - 6 are visible)

This is useful if you can determine the health of a server independently from knowing if all services on it are running.

[GammaPi]

I prefer the maintainer's approach:

groups:
  - id: 1
    name: API endpoints
sites:
  - name: example.com
    url: example.com
    group-id: 1
  - name: example.com
    url: example.com
    group-id: 1

[GammaPi]

Does h4 look good?

[AnandChowdhary]

Yes, I think we can add some margins above the heading for better visual separation, but this is exactly how I envisioned it. Thanks for your hard work!

[alvarolopez]

So cool, is there any chance this gets implemented soon?

[AnandChowdhary]

I'm happy to accept a PR, would you be up for it? I can also guide you on what to do! :)

[Tealk]

any news on the proposal?