Design Q&A: Monitoring

[asafm]

Hi,

I'm writing here all the things I saw missing in the Monitoring Doc:

• Missing goals/intro/motivation: What does component aiming to achieve?
• ServiceMonitor in architecture drawing makes you think it is a process, but it's a K8s entity: a CRD used by Prometheus Operator. I would clarify that in the drawing, and in the description of that architecture
• I would clarify right in the beginning that OpenSearch doesn't have Prometheus Metrics OOTB, thus you install in OpenSearch a plugin which exposes Opensearch Metrics in Prometheus format. What you wrote down below, but move it up as part of the description.

Questions:

• Part of the audience of this operator will likely have an existing monitoring solution, be it their own Prometheus or 3rd party solution, or their own Grafana or 3rd party solution. Is there a plan in this component roadmap to support that? I know Prometheus support a configuration option which converts into a lightweight agent.
• How does go about configuring Prometheus?
• What is the "Default go metrics" - You mean the metrics of the Opensearch Controller process it self?
• Regarding "OpenSearch Controller Metrics" - This an entirely different section I think as it deals with what metrics the operator it self need to expose and it should be a part of each Operator component design no?
• Regarding configuring the OpenSearch Prometheus Exporter plugin - do you configure it such that it will expose cluster / indices based metrics only on the active master?
• Should we mention that Grafana installed has a different license model than the rest?
• Which component is in charge of installed Grafana? How will that be accomplished?

[asafm]

Added a PR for enhancing the doc a bit: #50 @a-pel-a

[asafm]

@a-pel-a Do you want to add the answers to those questions in the PR I wrote? You want me to help you with that?