Vraag mij af hoe dit inzichtelijk werd gemaakt bij mijn voormalige klanten als het niet ingebouwd werd
Waarschijnlijk niet
Mijn persoonlijke ervaring is dat veel partijen niet ver zijn in het "observability" stukje of zelfs ook niet weten wat dat nu exact is (is ook lastig).
Anyhow, ik denk dat je het op verschillende manieren kan aanvliegen maar het valt en staat ook een beetje met de gehele stack, de KPI's en wat nu wel/niet belangrijk is voor jezelf, je eindgebruikers en andere actoren.
Toevallig ben ik redelijk betrokken in observability en kan ik wel iets over mijn ervaringen vertellen. Dus om te beginnen zijn we nog bezig met een referentie architectuur binnen de organisatie. Voor de architecten/mt heb ik een soort vertaling gemaakt wat observability nu is. Dat kwam dan uit op deze one-liner:
“Waarneembaarheid (lees: Observability) is een functie van het systeem waarmee mensen en machines de toestand van het systeem kunnen observeren, begrijpen en ernaar kunnen handelen, of conclusies kunnen trekken over de interne toestand van een systeem door alleen naar inputs en outputs te kijken”
Als ik met teams praat dan probeer ik over het algemeen te zorgen dat een zo'n compleet beeld wordt 'gemonitord'. In principe kan je niet te veel metrics hebben, zolang de kardinaliteit maar niet te complex/groot wordt. (leuke read:
https://chrismarchbanks.c...ning-your-cardinality.pdf)
M.b.t tracing zit ik daar soort gelijk in. Wees vooral zo compleet mogelijk en werk dan met (dynamic) sampling om het werkbaar te houden voor je tracing backend. Mocht dat noodzakelijk zijn. Bij eventuele incidenten of whatever kan je altijd naar 100% sampling gaan.
In principe is het doel dat je niet echt meer 'in' je systemen hoeft te zitten om te weten 'watsgebeurd'. Dan kom ik ook eigenlijk op het punt dat je een soort 'ketenmonitoring' "moet" hebben. Dus traces gaan door meedere systemen, die systemen geven ieder informatie. Om een concreet voorbeeld te geven; niet alleen zie ik informatie over bijvoorbeeld cpu/mem usage van de applicatie (wat imo hele saaie stats zijn). Ik zie ook de throughput over de loadbalancers, netwerk "quality", de lag op bijvoorbeeld een message bus, etc.
Dus om dan terug op je vraag te komen. Je geeft aan dat bijvoorbeeld metrics van 500 errors hebt. Echter kan je ze ook oplossen door je systeem te 'observen'? Nee? Dan is dat exact waar je over kan nadenken hoe je dat wel zou kunnen zonder 'in' je systeem te gaan, een debug dump te maken of ... whatever.
Ik heb hier ook nog een whitepaper over observability die nog work in progress is vanuit de 'special interest group' observability van de CNCF:
https://docs.google.com/d...aF5w1Kh1rBDdLs0-cFsA/edit IMO geeft het ondanks dat het niet klaar is al een mooi beeld.
Als laatste wilde ik nog delen dat je voor Prometheus een soort "extensie" hebt in twee vormen. Dat is Cortex en Thanos. In principe doen ze beide hetzelfde: "horizontally scalable, highly available, multi-tenant, long term storage for Prometheus" - en ze werken ook samen. Het is maar net welke je praktischer vind. Ik gebruik zelf Thanos met succes. Cortex wordt gebruikt bij Grafana cloud en AWS (managed prometheus). Overigens misschien een overkill afhankelijk van je setup
Daarnaast ook redelijk interessant is Grafana Tempo. Een tracing oplossing die in tegenstelling tot bijv. Jaeger niet werkt met een index. Dus je kan dan echt 'yolo' 100% sampling doen met long term storage voor je tracing zolang je maar zelf aan je traceID's komt via bijvoorbeeld logs (exemplars). Zeker ook interessant als je iets met Loki 2.0 (voor je logs) zou kunnen doen.
Wel de sidenote, persoonlijk vind ik zowel Loki2.0 als Tempo nog redelijk "alfa", maar goed, het zou prima in productie kunnen draaien
:strip_exif()/u/80759/monstermania_small.gif?f=community)
Vraag mij af hoe dit inzichtelijk werd gemaakt bij mijn voormalige klanten als het niet ingebouwd werd,
/u/262310/ava.png?f=community)