feat: add metrics

[michael-todorovic]

This PR add metrics support in the server. It's designed for scalability and for as much /metrics call as we want. Metrics are generated every minute and cached. They're served on /metrics from the cache so a multi-instance prometheus scraping wouldn't trigger multiple metrics generation from the burrito api (thus k8s api).

I'm pushing the PR early stage so we can possibly discuss topics on it. On my side, we'll give it several days of testing on our systems

[codecov]

Codecov Report

❌ Patch coverage is 59.03226% with 127 lines in your changes missing coverage. Please review.
✅ Project coverage is 40.83%. Comparing base (260dd06) to head (c50545f).
⚠️ Report is 8 commits behind head on main.

Files with missing lines	Patch %	Lines
internal/controllers/metrics/aggregator.go	0.00%	85 Missing ⚠️
internal/controllers/metrics/helpers.go	56.00%	29 Missing and 4 partials ⚠️
internal/controllers/manager.go	0.00%	7 Missing ⚠️
internal/controllers/metrics/metrics.go	98.54%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #712      +/-   ##
==========================================
+ Coverage   39.79%   40.83%   +1.03%     
==========================================
  Files          94       97       +3     
  Lines        5465     5775     +310     
==========================================
+ Hits         2175     2358     +183     
- Misses       3093     3215     +122     
- Partials      197      202       +5     

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[corrieriluca]

Thanks for the PR @michael-todorovic !!

We have been wanting to add a metrics feature in Burrito for a long time!

We should discuss in which Burrito component we want to integrate metrics: even though I don't fully understand how it works, I know that the controller-runtime also has a metrics feature. It actually already exposes a metrics endpoint if I remember correctly. It may be worth to test it instead of putting a custom metrics server in Burrito's server 🤔

However, documentation on this topic is not easy to find in my opinion, it always comes to simple example like here in Operator's SDK documentation (the framework we used to initiate Burrito).

WDYT?

[michael-todorovic]

Hello @corrieriluca, it's been a long time, I finally updated the PR 🙏

[corrieriluca]

Overall LGTM! Thanks @michael-todorovic for your contribution to this long-awaited feature for Burrito!

Can you just look at my comments related to unused functions, as well as markdown lint issues?

Thank you!

[corrieriluca]

Not for this PR, but in the future we should think what metrics we want to emit for the TerraformRepository Controller (number of repository sync, last repository sync, etc.)

[michael-todorovic]

I just added the possibility to enable an ingress on controller to expose metrics (disabled by default).
Enabling the ingress depends on your metrics implementation :)

[michael-todorovic]

I just saw the new pipeline run, curious I thought I fixed the lint issues. I'll check that again!

[corrieriluca]

@michael-todorovic LGTM! I think we are close to merge this one!

Could you just rename the ingress/port to reflect the metrics-only usage of these?

Thanks

[corrieriluca]

I think it should be clear that this ingress and this port are for the controller metrics.

WDYT of metricsIngress for the ingress key, and metrics for the port's name?