coop-cloud/monitoring-ng
2
0
Fork 2
Code Issues 7 Pull Requests 5 Packages Projects Releases Wiki Activity

Future of the recipe #14

New Issue
Open
opened 2026-03-19 09:24:37 +00:00 by p4u1 · 6 comments
p4u1 commented 2026-03-19 09:24:37 +00:00
Owner
Copy Link

Just dumping some thoughts as a starter:

  • Sharing Alerts: #3
  • Sharing Dashboards
  • Do we need to split the recipe to make it easier to maintain? @moritz had that idea
  • How to maintain the recipe
  • What are the goals?
Just dumping some thoughts as a starter: - Sharing Alerts: https://git.coopcloud.tech/coop-cloud/monitoring-ng/issues/3 - Sharing Dashboards - Do we need to split the recipe to make it easier to maintain? @moritz had that idea - How to maintain the recipe - What are the goals?
simon commented 2026-03-20 09:41:36 +00:00
Owner
Copy Link

Hey, thank you for the initiative! This is in my personal backlog for quite some time, just didn't get the priority sadly.

Keeping the recipe up to date seemed very complicated, especially if you encounter breaking changes in multiple apps. So splitting the recipe between the per-node deployments (log and metrics collectors) and the headunit for grafana etc. could make this easier, I suppose.

I also had the idea of adding some more labels to recipes a while ago, to allow an easier per-instance monitoring:
https://pad.local-it.org/yNIRGGztRnmaS8eTGgc7cA#

Another idea on usage statistics:

For Maintenance, Host Migration and App Upgrades, I want to know about the activity on a system. First, to check if users are affected by my actions and second, to choose time windows with usually less activitiy for maintenance downtimes.

Also I just copied over #15 from our internal Issues.

There is more, but maybe thats a start :)

Hey, thank you for the initiative! This is in my personal backlog for quite some time, just didn't get the priority sadly. Keeping the recipe up to date seemed very complicated, especially if you encounter breaking changes in multiple apps. So splitting the recipe between the per-node deployments (log and metrics collectors) and the headunit for grafana etc. could make this easier, I suppose. I also had the idea of adding some more labels to recipes a while ago, to allow an easier per-instance monitoring: https://pad.local-it.org/yNIRGGztRnmaS8eTGgc7cA# Another idea on usage statistics: > For Maintenance, Host Migration and App Upgrades, I want to know about the activity on a system. First, to check if users are affected by my actions and second, to choose time windows with usually less activitiy for maintenance downtimes. Also I just copied over #15 from our internal Issues. There is more, but maybe thats a start :)
dannygroenewegen commented 2026-03-24 09:28:51 +00:00
Owner
Copy Link

I also had the idea of adding some more labels to recipes a while ago, to allow an easier per-instance monitoring:

Instance grouping is also something I could use. Haven't tried this yet, so no input on what a good approach would be.

  • Do we need to split the recipe to make it easier to maintain? @moritz had that idea

There are (or were) also recipes for monitoring, monitoring-lite and gathering. Looks like it was tried having it separate before monitoring-ng was created. Would anyone remember why that happened, so we don't go back and forth?

> I also had the idea of adding some more labels to recipes a while ago, to allow an easier per-instance monitoring: Instance grouping is also something I could use. Haven't tried this yet, so no input on what a good approach would be. > - Do we need to split the recipe to make it easier to maintain? @moritz had that idea There are (or were) also recipes for monitoring, monitoring-lite and gathering. Looks like it was tried having it separate before monitoring-ng was created. Would anyone remember why that happened, so we don't go back and forth?
moritz commented 2026-03-24 22:10:36 +00:00
Owner
Copy Link

There are (or were) also recipes for monitoring, monitoring-lite and gathering. Looks like it was tried having it separate before monitoring-ng was created. Would anyone remember why that happened, so we don't go back and forth?

I think a valid reason could be to have consistency between the versions and configurations of all the different services. I was just so frustrated updating the whole stack, that I thought it would be easier to update them separately, but now I changed my mind again. And if there are enough people participating in the maintenance it should be doable.

> There are (or were) also recipes for monitoring, monitoring-lite and gathering. Looks like it was tried having it separate before monitoring-ng was created. Would anyone remember why that happened, so we don't go back and forth? I think a valid reason could be to have consistency between the versions and configurations of all the different services. I was just so frustrated updating the whole stack, that I thought it would be easier to update them separately, but now I changed my mind again. And if there are enough people participating in the maintenance it should be doable.
simon commented 2026-03-27 12:43:54 +00:00
Owner
Copy Link

Another possible topic for later: prometheus alertmanager client for matrix

Another possible topic for later: [prometheus alertmanager client for matrix](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/master/docs/configuring-playbook-alertmanager-receiver.md)
p4u1 commented 2026-03-27 16:32:07 +00:00
Author
Owner
Copy Link

Another possible topic for later: prometheus alertmanager client for matrix

Is this not covered by https://git.coopcloud.tech/coop-cloud/monitoring-ng#adding-matrix-as-alert-contact-point?

> Another possible topic for later: [prometheus alertmanager client for matrix](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/master/docs/configuring-playbook-alertmanager-receiver.md) Is this not covered by https://git.coopcloud.tech/coop-cloud/monitoring-ng#adding-matrix-as-alert-contact-point?
p4u1 commented 2026-03-27 16:37:39 +00:00
Author
Owner
Copy Link

PLAN:

Release a new recipe version

**PLAN:** - [ ] finish image updates https://git.coopcloud.tech/coop-cloud/monitoring-ng/pulls/10 everyone - [ ] merge https://git.coopcloud.tech/coop-cloud/monitoring-ng/pulls/13 @moritz - [ ] update readme https://git.coopcloud.tech/coop-cloud/monitoring-ng/issues/18 @dannygroenewegen - [ ] make alert threshholds configurable https://git.coopcloud.tech/coop-cloud/monitoring-ng/pulls/19 @p4u1 - [ ] configure renovate https://git.coopcloud.tech/coop-cloud/monitoring-ng/pulls/11 - [ ] add a Maintenance.md https://docs.coopcloud.tech/maintainers/maintain/ - [ ] add a monitoring-ng-maintenance team - [ ] add maintainers Release a new recipe version
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
3wordchant aadil abra-bot ammaratef45 Apfelwurm appletalk arjan basebuilder Brooke carla cas codegod100 coopcloud cyrnel dannygroenewegen decentral1se devydave fauno flancian Frando iexos jade javielico jjsfunhouse jmakdah2 joe-irving kawaiipunk knoflook kolaente lambdabundesverband linnealovespie marlon mayel mirsal moosemower moritz nicksellen notplants p4u1 pau pharaohgraphy PhiNatalie renovate-bot ripclap rix rscmbbng sef simon sixsmith stevensting tobias trav val vaznasty virtualboys wolcen wykwit xynosis yksflip
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: coop-cloud/monitoring-ng#14
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?