Add PodMonitoring support to falco-exporter

[bzaleski578]

Motivation

Use falco-exporter with GCP's Managed Service for Prometheus

Currently Falco uses ServiceMonitor object from the API monitoring.coreos.com/v1 that works with the Prometheus-operator
That object is not compatible with GCP's Managed Service for Prometheus.

Feature

Add support for PodMonitoring (API: monitoring.googleapis.com/v1)

Additional context

In my GKE I am using the below two helmcharts to deploy Falco and store its alerts in Prometheus:

• https://github.com/falcosecurity/charts/falco
• https://github.com/falcosecurity/charts/falco-exporter

I am also using GCP's Managed Service for Prometheus,
To make the two work together I had to manually add my PodMonitor object to the falco-exporter chart. It would be tremendous to be able to simply choose which object I want to use from my values.yaml..

[alacuku]

Hi @bzaleski578, falco-exporter will be deprecated soon: falcosecurity/evolution#420.

It would be best if you used the metrics exposed by Falco itself.

[bzaleski578]

Hi @alacuku

Thanks for your timely response.

Perhaps this request is still valid though, since the Falco helmchart does not support PodMonitoring either?

[alacuku]

yes, we should support PodMonitoring in the Falco chart.

But it's not clear to me what you mean by this:

Add support for PodMonitoring (API: monitoring.googleapis.com/v1)

[bzaleski578]

Both the objects: PodMonitoring and ServiceMonitor serve the same purpose - provide Prometheus metrics for scraping. However, they come from different APIs and are therefore consumed by different services.

ServiceMonitor (and PodMonitor to be precise) is provided from the Prometheus-operator. So the Prometheus-operator must be deployed in your cluster in order to scrape metrics from ServiceMonitor (or PodMonitor).

In GCP (I don't know how about other clouds) there is an alternative for running the Prometheus-operator. It is called GCP Managed Service for Prometheus and is provided by the cloud vendor. The advantage of using it is that there is no need to deploy custom Prometheus-operator thus reducing maintenance overhead. This GCP Managed Service for Prometheus uses PodMonitoring object for scraping metrics. It cannot use the ServiceMonitor (or PodMonitor) objects instead.

Note: I have seen posts on Internet saying that ServiceMonitor and PodMonitoring are actually compatible and that the compatibility can be achieved by certain annotation(s). I haven't manage to achieve that though, so I am assuming that the objects are not in fact compatible.

The way I see it working is something along these lines:

1. Add PodMonitoring definition in charts/falco/templates.podMonitoring.yaml

{{- if .Values.podMonitoring.enabled }}
apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: {{ include "falco.fullname" . }}
  labels:
    {{- include "falco.labels" . | nindent 4 }}
    {{- range $key, $value := .Values.podMonitoring.additionalLabels }}
    {{ $key }}: {{ $value | quote }}
    {{- end }}
spec:
  selector:
    matchLabels:
      {{- include "falco.selectorLabels" . | nindent 6 }}
  endpoints:
  - port: {{ .Values.podMonitoring.port }}
    interval: {{ .Values.podMonitoring.interval }}
    path: {{ .Values.podMonitoring.path | quote }}
{{- end }}

2. Now either (PodMonitoring or ServiceMonitor) can be used based on your custom values.yaml:

serviceMonitor:
  create: false

podMonitoring:
  enabled: true
  interval: 180s
  path: /metrics

Most likely more changes would be required in the helmchart, this is only a simplistic example of a DevOps' perspective

[alacuku]

@bzaleski578, thank you for the explanation.

While we understand the value of leveraging managed services like Google Cloud Managed Service for Prometheus, our charts are community-owned and designed to remain open and vendor-neutral. This approach ensures that they are usable across a wide range of Kubernetes environments, whether on-premises, multi-cloud, or with any managed Kubernetes service.

As a result, we focus on supporting open-source standards, such as the Prometheus Operator’s PodMonitor and ServiceMonitor CRDs, which provide broad compatibility and are not tied to specific cloud providers.

Anyway, let's hear the other maintainers' thoughts: @falcosecurity/core-maintainers

[Issif]

+1 for Aldo's comment