Repository navigation
We have to move monitoring on it's own VM #89
Description
Describe the bug
All the monitoring infrastructure is on preprod 200 and this is absolutly not a good idea.
Every-time we want to update the preprod data (the zfs clone containing sto), we have to reboot the machine.
Expected behavior
I propose to put monitoring on it's own container, because it is far better when monitoring is independent !
(I propose to gain on 105 or 103 machines resources).
Activity
alexgarel commentedon Feb 2, 2022
@CharlesNepote and @cquest do you agree ?
alexgarel commentedon Feb 2, 2022
#81 also have the same issue
alexgarel commentedon Feb 2, 2022
@CharlesNepote could we provision a QEMU VM, possibly on ovh1.
I'm not sure how much resource we need. But I can look into it.
alexgarel commentedon Feb 2, 2022
I would give:
@CharlesNepote could we provision this on ovh1 as a QEMU VM ?
It will then be quite easy to move the monitoring stack there.
[-]We have to move monitoring to 201 or in it's own VM[/-][+]We have to move monitoring on it's own VM[/+]cquest commentedon Oct 11, 2022
Own VM or separate hardware outside of the free+OVH bare metals ?
alexgarel commentedon Oct 13, 2022
@cquest do you have a proposition ?
If we want to lend a server outside, I would take one either in OVH, different DC or at Scaleway
@CharlesNepote ?
CharlesNepote commentedon Oct 17, 2022
Let's start with OVH1 I guess. We still have 400 GB of disk and 190 GB RAM free on OVH1, let's use it!
Be aware it is easy to increase disk space of the VM while decreasing is not. So I would start with a machine with 80 GB and increase it when needed.
@cquest: why a separate machine?
alexgarel commentedon Oct 17, 2022
I think we'd better start on OVH1 and then move if someone sponsors us a VM.
alexgarel commentedon Nov 9, 2022
created the ticket for the VM, I will now create the VM.
alexgarel commentedon Nov 21, 2022
It's done: