Feature Overview (aka. Goal Summary)

Currently, the ServiceMonitor can be installed manually following the monitoring and logging documentation. However it would be nice for this to work out of the box, a new CRD field like spec.application.serviceMonitor can be created to create a ServiceMonitor depending on the configs for each RHDH instance.

Note: Refer to how the spec.application.route field which allows to either deploy a Route on OpenShift, or skip it on non-OCP clusters

• Do something similar to create the service monitor dynamically

Goals (aka. expected user outcomes)

Ideally, the OpenTelemetry ServiceMonitor would be created out of the box when configured in the RHDH instance. 

Requirements (aka. Acceptance Criteria):

A list of specific needs or objectives that a feature must deliver in order
to be considered complete. If the feature spans across releases then good
to have scope for each release with acceptance criteria. Be sure to
include nonfunctional requirements such as security, reliability,
performance, maintainability, scalability, usability, etc.

• test deployment thoroughly and determine if tests are needed
• update documentation

Documentation Considerations

Provide information that needs to be considered and planned so that
documentation will meet customer needs. If the feature extends existing
functionality, provide a link to its current documentation.

The current documentation will need to be updated to reflect new behaviour.