WIP: 📖 (doc): Add a doc as a guidance to help users know how to consume the metrics and integrate it with other solutions

[camilamacedo86]

• Improved Metrics Consumption Documentation:
  • Added a comprehensive guide for consuming metrics exposed by Operator-Controller and CatalogD services.
  • Detailed steps to enable metrics, validate access using curl, and integrate securely with Prometheus Operator using ServiceMonitor

[netlify]

❌ Deploy Preview for olmv1 failed.

Name	Link
🔨 Latest commit	bdda0de
🔍 Latest deploy log	https://app.netlify.com/sites/olmv1/deploys/6769bc1229cd9300087b7ec3

[camilamacedo86]

/hold

Just to ensure that we all convey

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 74.25%. Comparing base (10f0f77) to head (e7556e3).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1524   +/-   ##
=======================================
  Coverage   74.25%   74.25%           
=======================================
  Files          42       42           
  Lines        3329     3329           
=======================================
  Hits         2472     2472           
  Misses        676      676           
  Partials      181      181           

Flag	Coverage Δ
e2e	52.11% <ø> (ø)
unit	56.98% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[bentito]

We should probably be proposing to fix this, if needed, not remove it, since via Prometheus is the primary way people would likely want to monitor metrics for op-con doing its work.

[camilamacedo86]

Hi @bentito

I think the best approach might be:

• a) remove it since we do not support the integration now
• b) Create an epic for us to do an RFC to know how we will support it.
• We need to discuss how we do it with the install script, etc. and let it follow the priority list

WDYT?

[tmshort]

Could we move a fixed monitor.yaml to documents, rather than deleting it?

[joelanford]

Could we move a fixed monitor.yaml to documents, rather than deleting it?

Not opposed, but we need to be careful about how we do this because our service names are not part of our public API and may change at any time. If we were the ones managing the ServiceMonitor, we could make sure that it was updated appropriately if/when we change our service names. By documenting it, we may inadvertently put the service name and namespace in our public API, which IMO requires a MUCH bigger discussion.

[camilamacedo86]

/hold cancel

It seems reasonable to get merged now.
All suggestions are done
And in the community meeting on Dec 17, we discussed it and we agreed to remove the unused and unsafe config

[camilamacedo86]

I adding
/hold

Because we need to merge

• ✨ Replace kube-rbac-proxy with controller-runtime metrics authentication/authorization #1475
• ✨ Replace kube-rbac-proxy with controller-runtime metrics authentication/authorization catalogd#460

First due the doc added

[camilamacedo86]

/hold cancel

[joelanford]

Something we haven't really talked about or established a community-wide standard around: If something is not part of our public API, should we document it? If so, how and where?

As soon as something is documented, it is not unreasonable for consumers to believe it is part of the public API, so we need to be extremely careful about documenting things that fall outside that.

Metrics are not included in our public API. So the above question is very relevant to this PR.

Do we have any prior art here? @michaelryanpeter , what is your stance on how to handle this?

[camilamacedo86]

During the review about remove the manufests, it was mentioned that we need to create documentation. To address this, I’ve prepared a draft for discussion before we invest more time into it.

The idea is to align on expectations—what should or shouldn’t be included—before proceeding further.

Here’s what we need to clarify:

1. Should we include details on how to consume the metrics generally?
2. Or should we focus solely on consuming metrics via Prometheus?

If we choose the option 2, it might result in incomplete or uneven information.

Let’s discuss and agree on the direction before diving deeper into this.

Looking forward to your thoughts!

c/c @tmshort @tylerslaton @michaelryanpeter

[camilamacedo86]

@michaelryanpeter ^ wdyt