In general i think the addition of domain monitoring here is very nice - but at the same time it is a problem that it is coupled to our local infra. The previously used status.malobeo.org ran on an external host with very high uptime and kind of guaranteed network connectivity. This way it was able to send notifications even if our local infra went down.
The solution for domain monitoring proposed in this MR only works as long as our local network is up, and fanny is actually running. It can only send notifications if some single service fails, but a real network/electricity outage will never trigger notifications since grafana.malobeo.org will be also affected by it.
I think its fine for now, but in the future we should separate our monitoring from the actual local infra to keep it independent. This is either linked to #117 or some self hosted solution in another location
In general i think the addition of domain monitoring here is very nice - but at the same time it is a problem that it is coupled to our local infra. The previously used `status.malobeo.org` ran on an external host with very high uptime and kind of guaranteed network connectivity. This way it was able to send notifications even if our local infra went down.
The solution for domain monitoring proposed in this MR only works as long as our local network is up, and fanny is actually running. It can only send notifications if some single service fails, but a real network/electricity outage will never trigger notifications since `grafana.malobeo.org` will be also affected by it.
I think its fine for now, but in the future we should separate our monitoring from the actual local infra to keep it independent. This is either linked to https://git.dynamicdiscord.de/malobeo/infrastructure/issues/117 or some self hosted solution in another location
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
kalipso
f0de7390e9toae1c69277aae1c69277atod50a9ddbbfYou said you didn't wanna run too many services on one microvm. Should I make a new one for this or do we count this as in scope?
Also, I tested this on local already, it works
116db8851bto4c8253e8e3Also, do you wanna add any more sites to monitor before merging?
Other than that looks goot to me
@@ -112,0 +123,4 @@static_configs = [{targets = ["https://malobeo.org""https://cloud.malobeo.org"There are many domains missing here:
No new host needed
In general i think the addition of domain monitoring here is very nice - but at the same time it is a problem that it is coupled to our local infra. The previously used
status.malobeo.orgran on an external host with very high uptime and kind of guaranteed network connectivity. This way it was able to send notifications even if our local infra went down.The solution for domain monitoring proposed in this MR only works as long as our local network is up, and fanny is actually running. It can only send notifications if some single service fails, but a real network/electricity outage will never trigger notifications since
grafana.malobeo.orgwill be also affected by it.I think its fine for now, but in the future we should separate our monitoring from the actual local infra to keep it independent. This is either linked to #117 or some self hosted solution in another location