AP Proposal - Addons Monitoring

[laurafitzgerald]

Problem Statement

Each service managing it's own observability stack brings some cons.

• Overhead of composing a component (OO)
• Overhead of lifecycling that component by a service/addon
• Additional infrastructure in the cluster owned by each service
• Potential Service Interoperability issues caused by each service installing it's own stack.

Architecture Design

Please see this Miro Board for current and Future state of the RHOAM addon based on a migration from using RHOAM managed install of Observability Operator (OO) to Addons Monitoring (OBO)

While the current state applies to RHOAM only atm the Future states hold information on potential architectures that could be used by any Managed Service. Given the addonons components are available by default in OSD and some are centralised services in app-interface we feel this architecture has application across services.

As such I am proposing a new AP.

cc @JameelB @StevenTobin @carlkyrillos @briangallagher

[laurafitzgerald]

@tombentley @emmanuelbernard I believe I need a comment from one of you in order to template out the needed files for a new AP if. you have some time and agree with the proposal. :)

[grdryn]

While anybody can comment on this and give feedback, I've assigned Emmanuel and Tom since they're the two people that the bot will react to.

@emmanuelbernard, @tombentley: if you agree that this should be an AP, then one of you should comment with /create ap so that the bot will assign the next AP number for it and create the skeleton from the template.

[emmanuelbernard]

I think it's a good one to explore. I would go with a 30% draft and get people discuss on this. We woudl want involvement from the open data hub people, conenctors , kafka etc to see whether there is convergence for an architecture pattern.

[tombentley]

/create ap

[bf2-arch-bot[bot]]

Closing following creation of AP-20 @laurafitzgerald, please write your content in _ap/20/index.adoc and open a PR for AP acceptance.