Epic Goal

Provides guidance in steps on how to expose Prometheus compatible metrics of the Operator so people can teach themselves by following the example in the SDK doc.

Why is this important?

From the upstream SDK repo and survey, Operator authors often reached out to SDK doc for learning features and seeking guidance on how to adopt those in their Operator project.

Currently, SDK doc does point out the Metrics in the golang/advanced-topics section but only links out to kubebuilder doc without setting up the stage.

Although users should still be able figure out the feature in this way, it takes quite a lot of context switching due to the fact that kubebuilder is using a different example + without detailed steps in how to add changes to the file in the project.

In the past, some old SDK docs actually did a great job on:

1. gives an high level intro/overview of this feature
2. what benefits this feature gives you
3. what files will get scaffolded (or need to be manually added)
4. how to edit/change/set these files in steps + per use cases
5. and finally, links out to other external doc for "more details"

We would like to keep up that UX in the current SDK doc as well.

Acceptance Criteria

• The doc gives:
  • An high level intro/overview of Metrics
  • what benefits this feature gives you
  • what files will get scaffolded (or need to be manually added)
  • how to edit/change/set these files in steps + per use cases,* e.g.*
    • Step 1. add/set the bind address in your main class in `main.go`
    • Step 2. Create custom metrics with a "custom controller class" in `/controllers/myoperator_controller_metrics.go`
      • 1). add a set of new prometheus metrics (via "NewCounterVec" or "NewGaugeVec")
      • 2). register these "custom metrics" in `init()`
    • Step 3. Add business logics for these metric in `Reconcile()` in `/controllers/groupsync_controller.go`
  • and finally, links out to other external doc for "more details"
• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• ...

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. …

Open questions::

1. …

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>