Je kunt een platform volhangen met dashboards en nog steeds blind zijn voor wat er echt remt.
Een actueel bericht over August 24, 2026 is hier de context. Het nieuws is niet het punt; het maakt de operationele beslisdruk zichtbaar.
Dat klinkt paradoxaal, maar iedereen die ooit een trage reconciler heeft moeten uitpluizen kent het gevoel: meer metrics, meer tiles, meer tabs — en toch geen sneller antwoord. De vraag is zelden of je genoeg kunt meten. De vraag is wat die meting kost, en of iemand er nog op stuurt.
In de release notes van 24 augustus 2026 zit een kleine, maar veelzeggende wijziging: voor specifieke custom RootSync- of RepoSync-objects kun je monitoring nu uitzetten via `spec.monitoring.enabled = false`. Daarmee stop je metric telemetry collection en exporting voor die reconciler, met als expliciet effect dat cluster resource consumption kan dalen.
Dat is geen voetnoot. Dat is een ontwerpkeuze.
Monitoring is niet gratis, ook niet als het ‘maar’ telemetry heet
Veel teams doen alsof observability een laag is die je simpelweg toevoegt. In de praktijk is het een vorm van werk.
Elke reconciler die metrics verzamelt, exporteert en verwerkt, gebruikt CPU, geheugen, netwerk en aandacht. Die laatste is misschien de duurste. Want zodra een dashboard bestaat, voelt het alsof het altijd relevant is. Terwijl een deel van die signalen in de dagelijkse operatie nauwelijks nog een besluit versnelt.
Daar zit de echte spanning voor softwareleiders. Niet: kunnen we dit zien? Maar: waarom blijven we het zien?
Als je alles zichtbaar maakt, groeit de kans dat je de belangrijke verschillen afvlakt. Dan zie je niet meer welke reconciler werkelijk afwijkt, maar vooral welke het hardst praat. Observability kan dan verschuiven van hulpmiddel naar achtergrondruis met een rekenrekening eraan vast.
De volwassen vraag is niet ‘meer metrics’, maar ‘welke metrics verdienen hun plek’
De wijziging rond `spec.monitoring.enabled = false` maakt iets expliciet wat veel platformteams liever impliciet houden: niet elk object hoeft dezelfde observabiliteit te krijgen.
Dat is een ongemakkelijke gedachte, omdat we graag uniformiteit bouwen. Eén standaard. Eén set dashboards. Eén manier van kijken. Het voelt beheersbaar. Maar beheersbaar is niet altijd efficiënt.
Een team dat RootSync- en RepoSync-objects blind volledig monitort, koopt misschien zekerheid in op plekken waar niemand meer naar kijkt. En dan betaal je dubbel: eerst in cluster resources, daarna in interpretatie.
Voor performance-teams is dat een belangrijke verschuiving. De bottleneck zit niet altijd in de workload zelf. Soms zit hij in de observability eromheen. Een paar extra exports, een paar extra series, een paar extra panelen — genoeg om de ruis te vergroten en genoeg om de kosten op te laten lopen.
Minder zichtbaarheid kan een betere keuze zijn, als iemand het bewust draagt
Fourlab vindt dit een volwassen signaal, juist omdat het niet doet alsof zichtbaarheid een absoluut goed is.
De beste teams behandelen observability niet als een moreel ideaal, maar als een technische investering met een doel. Als een reconciler kritiek is voor operationele stabiliteit, dan hoort hij zichtbaar te zijn. Als een object nauwelijks verandert, zelden wordt onderzocht en geen besluit voedt, dan is volledige telemetry vaak vooral gewoon een gewoonte.
Dat betekent niet dat je maar wat moet uitzetten. Het betekent dat je expliciet moet kiezen waar bewijs waarde heeft.
En die keuze hoort bij de eigenaar van het platform, niet bij het dashboard zelf. Iemand moet kunnen uitleggen waarom deze RootSync wel metrics verdient en die RepoSync niet. Niet omdat observability “te veel” is, maar omdat zichtbaarheid een kost heeft die je alleen rechtvaardigt als er een gebruiksdoel achter zit.
Dat is de echte consequentie van deze release note: performance-optimalisatie verschuift van puur tunen naar selecteren. Welke signalen helpen ons sneller beslissen? Welke signalen bestaan vooral omdat we ze altijd al hadden?
Volwassen platformteams meten niet alles wat kan, maar alles wat telt
Er zit een verschil tussen een systeem dat veel kan meten en een team dat goed kan kiezen.
De eerste bouw je vrij eenvoudig. De tweede vraagt discipline. Want zodra monitoring een standaardrecht wordt, groeit het aantal “handige” signalen sneller dan het aantal beslissingen dat ze nog ondersteunen. Dan krijg je een observability-landschap dat technisch indrukwekkend is en operationeel traag aanvoelt.
De interessante regel in deze release notes is daarom niet de CVE-update, maar de mogelijkheid om monitoring per custom object uit te zetten. Niet omdat minder meten automatisch beter is, maar omdat het erkent dat telemetry zelf ook workload is.
Dat inzicht is bruikbaar buiten Anthos Config Management. In elk platform, elke data stack en elk productteam loopt dezelfde vraag onder water mee: wat kost het ons om dit te blijven meten?
Wie die vraag niet stelt, optimaliseert uiteindelijk dashboards in plaats van doorvoer.
En dat is precies het moment waarop observability zijn doel voorbijschiet.