Zodra je op een (multi-tenant) Kubernetes cluster met quotas gaat werken wordt het gebruik van requests en/of limits verplicht voor alle workloads. Vooral met requests komt het regelmatig voor dat applicatieteams per container veel meer resources aanvragen dan ze echt nodig hebben en gebruiken. Dit zorgt ervoor dat clusters moeten groeien met extra nodes, want gereserveerde resources kunnen niet door anderen gereserveerd worden, en in het geval van geheugen zelfs niet gebruikt.

Om te zorgen dat de kosten niet te hard stijgen, en dat resources efficiënter worden gebruikt, is de taak aan alle gebruikers, en d beheerders, om te gaan “rightsizen”, het goed instellen van de requests en limits aan de hand van het echte (verwachte) gebruik om verspilling tegen te gaan.

Het klinkt in deze tijd van Observability misschien raar, maar soms is het gewenst om minder te monitoren.

Wanneer je clusters groeien, en de CPU, geheugen, en opslag druk van je monitoring stack blijft groeien, kan het soms gewenst zijn om minder verschillende metrics te verzamelen om die druk lager te houden. In die gevallen kun je op een OpenShift cluster terugvallen op het minimal CollectionProfile.

Als je op OpenShift User Workload Monitoring hebt aangezet kunnen ontwikkelaars wel custom metrics laten ophalen en opslaan, en ze uitvragen via de OpenShift Web Console, maar complexere dashboards zijn (nog) niet in de console mogelijk.

Gelukkig is het wel mogelijk om via de community Grafana Operator deze metrics ook uit te vragen, en via dashboards inzichtelijk te maken. Wel loop je dan tegen het probleem aan dat als je dit via de reguliere instantie van Thanos Querier wilt doen het een alles-of-niks spel wordt: Of je hebt geen toegang tot metrics, of je mag bij alle metrics van het cluster en alle applicaties.

Ook dat laatste probleem kan opgelost, door de speciale tenancy poort van Thanos Querier te gebruiken, waarbij je per query metrics voor één namespace tegelijk mag opvragen, mits je rechten hebt op die namespace.

In OpenShift is een monitoring stack aanwezig, gebaseerd op Prometheus, die standaard al erg veel rijk metrics verzamelt over allerlei onderdelen van je platform. Zo kunnen applicatie-teams hier al standaard van alles in over vinden over het geheugen-, CPU-, disk-, en netwerk-gebruik van hun applicaties.

Wanneer een team hun applicatie wil verrijken met custom metrics dan kan dat ook, maar hier moeten wel zowel aan de platform kant als aan de applicatieve kant een aantal dingen voor gedaan worden.