Meaningful shoot availability using eBPF (GEP as first step)

gardener / monitoring

Components needed for Gardener monitoring

Apache License 2.0

1 stars 3 forks source link

Meaningful shoot availability using eBPF (GEP as first step) #13

Open istvanballok opened 3 years ago

istvanballok commented 3 years ago

Measure the meaningful availability of the api server using eBPF.

wyb1 commented 2 years ago

We now have the connectivity-exporter. Next step is integrating it into Gardener.

vlerenc commented 2 years ago

@istvanballok @wyb1 Could you please share some light, why we do not plan to complete this one (and the prom operator takes precedence)? If possible, we usually try to complete begun topics, before starting new ones, especially large new ones.

wyb1 commented 2 years ago

Once the prometheus operator is in Gardener (the GEP does not need to be fully implemented) it would be possible to start integrating the connectivity-exporter in parallel.

vlerenc commented 2 years ago

Yes, thanks @wyb1. I am only curious: why did it take precedence? I am not asking to do things in parallel, just why we thought introducing this one is more critical than finishing the other one? Was everybody tired (people tire when working for a long time on a subject matter - me too) or something else (we need to wait on something, the other is just to important)?

wyb1 commented 2 years ago

Integrating it now would cause double effort for the monitoring parts (integrating into the monitoring stack the "old" way and then changing it once the prometheus-operator is there).

vlerenc commented 2 years ago

Hmm... well, not sure I fully got it (integrating one new component vs. the expected benefits of meaningful availability that can then hopefully help us replace the old aggregated bot metrics with something "more trustworthy"), but anyway @wyb1. Thank you still.

vlerenc commented 2 years ago

@juergenschneider and me discussed with @wyb1 the subject matter and understood:

We took up the Prometheus operator on higher priority because it promises a huge improvement for how components can define what to scrape and what to visualise
Meaningful availability will require considerably more effort to really establish it (and replace what is currently in place)

We said, we could target for Q3'22 to file a GEP in which we outline the plan how to continue here that covers:

Deployment of the connectivity exporter as such
Replacing the seed/shoot(?) probes and conditions (otherwise we have two solutions measuring API server availability with vastly different numbers)
Replacing the current availability monitoring, so that connectivity exporter data is used and the availability is being reported in a "meaningful way", which would finally conclude the job