On Fri, 26 Jun 2020 at 17:53, Kevin Fenzi <kevin@xxxxxxxxx> wrote:
On Fri, Jun 26, 2020 at 10:32:14AM +0100, David Kirwan wrote:
> Hi all,
>
> If we are moving towards openshift/kubernetes backed services, we should
> probably be sticking with containers rather than Vagrant. We can use CRC
> [1] (Code Ready Containers) or minikube [2] for most local dev work.
>
> I'd be very much in favour of having an Infra managed Prometheus instance
> (+ grafana and alertmanager on Openshift), its something I hoped to work on
> within CPE sustaining infact.
You know, I'm not in love with that stack. It could well be that I just
haven't used it enough or know enough about it, but it seems just
needlessly complex. ;(
Hmm the (prometheus, grafana, alertmanager) stack itself is pretty simple I would have said, but I agree it is certainly complex when installed/integrated on Openshift.. (most things are needlessly complex on Openshift tbh, and its an order of magnitude worse on Openshift 4 with these operators added to the mix).
It would be the obvious choice for me anyway considering this stack is available by default on a fresh Openshift install. We could make use of this cluster monitoring stack, especially if we're also deploying our services on Openshift. I might throw a POC/demo together to show how "easy" it is to get your app hooked into the Openshift cluster monitoring stack, or the
UserWorkload
tech preview monitoring stack[1].If we did use this stack it would add a little extra pain with regards to monitoring storage maintenance/pruning. But maybe far less than running/maintaining a whole separate monitoring stack outside the Openshift cluster. There are also efficiencies to be made when developers are already in the Openshift/Kubernetes mindset, creating an extra Service and ServiceMonitor is a minor thing etc.
- [1] https://docs.openshift.com/container-platform/4.4/monitoring/monitoring-your-own-services.html
David Kirwan
Software Engineer
Community Platform Engineering @ Red Hat
T: +(353) 86-8624108 IM: @dkirwan
_______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
