✨(backend) add prometheus metrics

[lindenb1]

Provides Prometheus metrics, a custom metrics exporter, a CIDR filter for monitoring targeted views, and readiness/liveness probe endpoints for Kubernetes.

Purpose

Simplify operational observability and health checking in containerized environments. By exposing both standard and custom metrics from Django for Prometheus, you can gain deeper insights into application performance. The integrated CIDR filter ensures that only allowed IPs can access the monitoring and probe endpoints of the application, and the built-in readiness/liveness probes provide health checks for Kubernetes to manage pod lifecycles effectively.

Proposal

Integrate these changes to benefit from metrics collection, and streamlined health checks. By centralizing these responsibilities, teams can reduce complexity and maintain a clearer view of application behavior within Kubernetes clusters and similar environments.

[lindenb1]

@virgile-dev Hey Virgile, could you please review the Prometheus implementation? At the moment, it is designed as an on/off switch, so it should not interfere significantly (if at all) with your existing code.

In addition to the Prometheus metrics, I have added the standard probes required by Kubernetes (readiness and liveness checks). I also included a CIDR filter decorator so that the metrics, readiness, and liveness endpoints are accessible only from specific networks, such as the private Kubernetes network where the application is running.

[securitykernel]

@sampaccoud Can you or @AntoLC please do a review?

[AntoLC]

I added the label "keep track", to find interesting PR or issue easily after they are closed.

[rvveber]

I'm re-opening this PR to take over.

• [x] Getting it up to date.
• [x] I'm talking to monitoring expert at B1 to see if we need anything else to fulfil best practice.
• [ ] Implement change requests
• [ ] Successful Review

[gitguardian[bot]]

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

Since your pull request originates from a forked repository, GitGuardian is not able to associate the secrets uncovered with secret incidents on your GitGuardian dashboard. Skipping this check run and merging your pull request will create secret incidents on your GitGuardian dashboard.

🔎 Detected hardcoded secret in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
21501577	Triggered	Username Password	dd35275b6a688231eb17d260565e9845cd3c98af	.github/workflows/label_preview.yml	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Revoke and rotate the secret.

2. If possible, rewrite git history with git commit --amend and git push --force.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}

[rvveber]

LGTM. I just have one concern about the user_documents metric which may lead to excessive cardinality if values for the user_email label are unbounded.

Yes, i agree, and i think its too much of an intrusive metric anyways. We shouldn't include private data like E-Mails in metrics, so lets remove it.

Thank you for Reviewing!