add statsd service monitor into helm chart

[ido177]

closes: #56664

---

Add ServiceMonitor for StatsD to enable Prometheus monitoring. This allows Prometheus to scrape metrics from the StatsD service

[Miretpl]

Hi @ido177, if there is an addition to the values.yaml, the changes in the values.schema.yaml are also required (that is the reason of failing tests - https://github.com/apache/airflow/actions/runs/18531823289/job/52818611830?pr=56668). It looks like this PR is still in progress. Do you have the possibility to convert it to a draft? If not, maybe just add the [WIP] at the beginning of the title to mark it somehow that it is not ready to review yet (tests are failing)?

[ido177]

Oops, I missed that one. Is there an automated way to fill up the values.schema.json file(some cli tool like helm schema or some script)? I'm sure it's not done manually, but I couldn't find a documented workflow.

I tried helm schema, but it changes the file wrong way, apparently something else should be used or maybe some extra args required.

[Miretpl]

To be honest, I've done it manually every time as I didn't have many changes to introduce really, but some automated way of filling it will some check it a pre-commit could be nice 🤔

[Miretpl]

From my end, the change looks good; the only question is whether we want to have in the official Helm chart things which require the installation of a custom resource in the k8s to work. If yes, we should probably add some information somewhere in the doc and values files that this feature will not work without the installation of a proper CRD.

[ido177]

If everything is fine with adding Service Monitor, I would also like to add it to the pgbouncer Metrics Exporter. It contains important metrics for monitoring.

[RomanKrasavtsev]

@ido177 perhaps it might be better to merge this PR first and create a separate one for PgBouncer, to keep the changes well-scoped and avoid expanding the file set here.

[jscheffl]

One request as leftover: Can you please also add a small test to see that based on the configuration the desired outcome is generated?

[Miretpl]

Hi @ido177, could you add a small test case for this?

[noderat]

I would suggest adding this behind helm's APIVersions capability check such as {{- if .Capabilities.APIVersions.Has "monitoring.coreos.com/v1/ServiceMonitor" }}

[jscheffl]

Still missing some tests.

[jabbera]

@ido177 Please allow for the apiVersion to be customizable for those of us who use a managed Prometheus offering. For example microsoft uses: azmonitoring.coreos.com/v1

https://learn.microsoft.com/en-us/azure/azure-monitor/containers/prometheus-metrics-scrape-crd#example-service-monitor

Traefik does this: https://github.com/traefik/traefik-helm-chart/blob/e66342de879b16214216b9196dba9aece36a5d7a/traefik/templates/servicemonitor.yaml#L8

There will also need to be a way to disable the crd check if you are adding one. Traefik does this here: https://github.com/traefik/traefik-helm-chart/blob/e66342de879b16214216b9196dba9aece36a5d7a/traefik/templates/servicemonitor.yaml#L4

[jscheffl]

I was reading the code and attempting to understand what is added / achieved here. Did not understand it. A lot of YAML and complexity added. Is this all needed? Looks like rather an external helm reference is needed.

Maybe I am not an expert in this area but see too much complexity for "just service monitoring". What would be the diff to liveness?