Add a prometheus serviceMonitor resource to the helm chart.

[willejs]

It would be nice if the helm chart optionally included a prometheus operator service monitor. This will tell prometheus operator to create a scrape config, load it into the prometheus config, and start scraping the metrics that OPA serves. It's a well known and practiced pattern to include these into helm charts rather than through an annotation...

I looked at doing this, i was going to add the service monitor into the helmify kustomize-for-helm.yaml and add a new if statement to the helmify.go script that post processes the kustimize to add in the sprig templating if statement... However, I suspect i need to add a bit more kustomize magic?

[bergerx]

It would also be helpful to include https://github.com/open-policy-agent/contrib/tree/main/grafana-dashboard also to the chart like kubernetes/ingress-nginx#6381 (comment) when enabling the ServiceMonitor.

[bergerx]

The Gatekeeper's default exposed metrics may not be what people expect, they are just some generic counters and distributions about gatekeeper's internals, and there is nothing about specific constraints, constaintTemplates, and/or violations. The list of these metrics is captured in https://open-policy-agent.github.io/gatekeeper/website/docs/metrics/.

There is also the https://github.com/open-policy-agent/contrib/tree/main/gatekeeper_mtail_violations_exporter item under the contrib (open-policy-agent/contrib#137)
This one seems to be exporting some "per constraint" metrics from logs.

[bergerx]

As I see #689 got stuck on the suggestion to push that into the contrib repo and eventually dropped. I read that suggestion of moving that away from Chart to contrib as "we have no intention to maintain ServiceMonitors as part of this Chart".

Is there an explicit decision about releasing any artifacts from the https://github.com/open-policy-agent/contrib repo as part of the gatekeeper chart, or are you aiming for the gatekeeper Chart only having resources from non-contrib repos?
If no contrib resources can be used in the chart, let's just close this one as rejected, as there is no way to implement this.

[maxsmythe]

Unfortunately this would have to live in contrib. We want to avoid including 3rd party projects in our default manifsts/charts, as we don't want to imply we will provide ongoing support for those integrations, and don't want to risk things like dealing with incompatibilities due to version skew.

[bergerx]

That's understandable but can you explicitly close this by rejecting to signal others that this won't happen.

[maxsmythe]

Sure thing.