BLOG – Monitoring is traditioneel gezien gebaseerd op reactief handelen. Hard- en softwareprestaties werden gemeten naar de geleverde key performance indicatoren. In andere gevallen werd het eco-systeem van een businessproces nauwlettend gemonitord ten einde eventuele fouten snel op te sporen en te verhelpen indien nodig. Deze manier van monitoren gaat achter ons liggen. Met de introductie van nieuwe technieken zoals kunstmatige intelligentie en verbeterde analysesoftware zijn we beter in staat om fouten te voorkomen.
Volgens nieuwe inzichten zoeken steeds meer organisaties naar full stack observability (fso) om een grotere operationele veerkracht te bereiken. Het opzetten van fso is complex, maar levert veel op. Het integreren van logfiles, metrische gegevens, gegevens uit het recente verleden en huidige realtime-gegevens is een complexe activiteit. De integratie van al deze componenten stelt een organisatie in staat om operationele problemen vooraf te kunnen voorspellen. Om het volledige fso-plaatje te schetsen, moeten de relaties tussen deze entiteiten worden vastgesteld en in hun huidige context worden geplaatst. Hoewel application performance monitoring (apm)-tools zijn geëvolueerd van eenvoudige gebeurtenisbewaking naar complexere bewakingsentiteiten, kunnen ze op zichzelf geen relaties tot stand brengen. Wat hiervoor nodig is, is een superieure ai-engine in het hart van fso, die continue de enorme hoeveelheid log-, gebeurtenis-, metriek- en trace-gegevens vastlegt en de integratie van de dumps en hun onderlinge samenhang ondersteunt. Met dit alles in de hand kunnen bedrijven overstappen van een reactieve naar een proactieve omgeving en vervolgens naar een voorspellende omgeving.
Immens
De voordelen zijn immens. Met de nieuwe inzichten kan impact in bijvoorbeeld volume vergrotingen en de effecten hiervan beter voorspeld worden. Root cause-analyses zullen betere en gedetailleerdere inzichten opleveren die herhaling van incidenten kunnen voorkomen. Door realtime prestaties en traceringen voor een applicatie te zien, kunnen ontwikkelaars een diepgaand inzicht krijgen in hoe hun code echt werkt en bepalen hoe deze is te verbeteren. Dit inzicht in code strekt zich verder uit tot de infrastructuur en maakt de implementatie van een beter technisch landschap en capaciteitsbeheer mogelijk dat is afgestemd op de bedrijfsresultaten.
Zoals elk goed monitoringsysteem is fso niet compleet zonder waarschuwingen en gerelateerde integraties met meldingstools. Dashboards kunnen dienen om gegevens op managementniveau weer te geven. Fso is een grote stap voorwaarts die uiteindelijk zinvol gebruikmaakt van kunstmatige intelligentie.
Ruud Pieterse is is chief architect bij DXC Technology
ruuds wondere wereld.
Monitoring in het bedrijf van de toekomst.
wrom zou een traditionele warning dat een disk 80% vol zit nou reactief zijn ?
De belofte van automatische root cause-analyses heb ik vaker voorbij zien komen.
En van alles met elkaar koppelen, het ticket systeem met de monitoring. Nog nooit goed zien werken. Ging je een ticket oplossen en kon je niet vinden wat er nou eigenlijk mis was. Blijkt het om een automatische gemaakt incident te gaan van iets wat al lang gefixt was. En dat achterlijk dure HP Openview.
Maar nu nog beter, met extra AI.
Ik zal ook voorspellend proactief analyseren. Gebaseerd op deep learnings uit het verleden. Monitoring zal duur blijven. En
inadequaat. Prachtige dashboards die we niet kunnen interpreteren. Rood blijft betekenen dat er iets mis is of een een rood bolleke omdat iets al lang verwijderd is zonder monitoring aan te passen. Met een oogopslag een schijnwerkelijkheid op je scherm. Full stack observability met superieure ai-engines. Weltrusten.
Dino, jammer dat je zo negatief bent. Vooruitgang gaat nu eenmaal gepaard met veranderingen en gaat met horten en stoten. We kunnen in de prehistorie blijven Dino, we kunnen ook vooruit kijken wat nog meer mogelijk is. En het is mogelijk, we zien dat steeds meer en meer. Wie slaapt er nu?
Ik weet niet in welke wondere wereld Ruud leeft Dino maar in de wereld van meten is weten blijkt superieure ai-engine gewoon Excel te zijn. Want full stack observability gaat om het verbinden van de genummerde puntjes om zodoende het plaatje af te maken. Zeg maar een breiwerkje van open management protocollen zoals ik 12 jaar geleden al uitlegde met het idee van een service knowledge management system (SKMS). De bron van waarheid want door het verdampen van de infrastructuur werd HP OpenView nutteloos en moest er dus iets anders bedacht worden in de loop van goed naar beter en weer terug naar af. Dat je volgens Ruud een paar loopings gemist hebt omdat je sliep klopt dus wel alleen leert SKMS dat niet elke verandering een verbetering is.
Ruud stelt dat voordelen van full stack observability immens zijn maar kwantificeren ervan wordt gedaan met de voorspelling van een horoscoop. Een organisatie in staat stellen om operationele problemen vooraf te kunnen voorspellen is als voorspelling dat je deze week de ware tegen komt. Gerelateerde waarschuwingen over rozentuinen negerend mis ook een voorbeeld van de grote stap voorwaarts met een zinvol gebruik van kunstmatige intelligentie. Ik lees namelijk alleen maar marketingpraat waardoor ik me kan vinden in de emoties van Dino, negatief maar wel grappig. Het implementeren van full stack observability lijkt me een nogal vrijblijvende inspanningsverplichting zonder resultaten, zeker als je niet eerste een SKMS implementeert.
Goed artikel en gezien de reacties heel waardevol om uit te leggen wat er in de afgelopen jaren mogelijk is geworden. Als je kijkt naar de ontwikkelingen op het gebied van data analyses (of je noemt dit AI, AIOPS, machine learning et cetera) in sectoren als industrie, healthcare, mobility, waarom zou dit dan juist in de wereld van het monitoren van ict systemen en applicaties niet dezelfde disruptieve waarde kunnen hebben?
Wat er nodig is zijn getrainde modellen die in de context opereren van hetgeen wordt gemonitord, zonder reclame te willen maken zijn deze oplossingen er echt wel en die worden ook steeds beter. En natuurlijk zal daar ook zo nu en dan een false positive uit komen en dan laat je de expert er naar kijken en breng je een verbetering aan. Dit is nog altijd beter dan die expert de hele dag zijn eigen staart achterna laten rennen zonder inzicht.
En nee, er is niets mis met een threshold op 80% voor disk capaciteit, dit is natuurlijk ook gewoon een proactieve melding. Waar je naartoe zou willen werken zijn meldingen als “applicatie x begint veel meer dan wat we als normaal beschouwen naar disk te schrijven”, zodat je in plaats van de disk vergroten kan kijken naar waarom schrijft die applicatie ineens veel meer weg.
van oude dinos, de dingen die voorbijgaan..
Ja, de LCM van tot stof wederkeren.
Behalve reclame maken, zonder dat te willen. Dat zal altijd blijven.
Samen met de zinnen die beginnen met “Wat er nodig is zijn” 😛
Zo nu en dan een false positive, zo verkoop je dat aan het management, anders rent de expert de hele dag zn eigen staart achterna zonder inzicht 😉
Bij een bank kreeg ik elke week weer wanhopige applicatie beheerders, met honderduizenden files die on suspicious omstandigheden gewijzigd waren. They build it, we own it 😛 DevOps houzee
Kon je die hele lijst elke keer weer nagaan, want als wij foutje maakten dan had je een true positive ten onrechte afgekeurd. Maar bleek altijd om updates te gaan.
Veilig hoor.
Misschien kan onze computable huisfilosoof ons een mooie definitie van normaal geven, als je het hebt over normaal gedrag van applicatie.
Ik ken vooral uitzonderingen die regels bevestigen.
Onze huisfilosoof kan vast een mooie definitie van het nieuwe normaal geven met zijn context van ‘Sein und Zeit’ maar zijn favoriete filosoof was achteraf gezien fout. Dus als we het over ergens achterna rennen hebben kunnen we ook G.B.J. Hilterman van dit platform om een mening vragen want gokkast van een salsadanser uit Paramaribo die achteraf zeurde over de kwaliteit van de code vergat dat zijn bedrijf vooral failliet ging door gebrek aan regie op de code. Code inzichtelijkheid door reversed engineering voor LCM gaat niet om wat er in de afgelopen jaren mogelijk is geworden maar om wat we afgelopen jaren hebben nagelaten als ik kijk naar software supply chain uitdagingen. Observeren van de huidige gegevens en het doen van prognoses voor de toekomst blijft dit platform dan ook een bron van vermaak want they build it, we own it is onjuist door alle uitbestedingen.
Getrainde modellen die in een bepaalde context opereren zitten vol met de bias van vooroordelen zoals we zien met een harde sanering van alle softwarehuizen in Rusland die we 2 jaar geleden nog vertrouwden. Deze terugkerende softwareontwikkeling levert een heleboel operationele problemen in het software onderhoud op want ontwikkelaars staan niet bekend om het uitvoerig documenteren. Het ontbreken van een centraal platform waar kennis en informatie over services, risico’s, incidenten en beveiligingsmaatregelen worden beheerd bemoeilijk namelijk het ‘in control’ komen. Lang leve dus de firewall want bugs worden niet altijd opgelost omdat het mitigeren ervan goedkoper is en je kunt daarom beter de communicatie monitoren omdat impact van een ongeautoriseerde data extractie een grotere impact heeft dan het vollopen van een schijf.
Foutje bedankt dwingt wet- en regelgeving tot een basis hygiëne in compliance door risico’s, incidenten en beveiligingsmaatregelen deugdelijk te administreren omdat het niet de techniek is die rammelt maar alle regie erop. Een beter technisch landschap en capaciteitsbeheer gaat dan ook meer om de impact van ICT op het klimaat te verkleinen door full stack kijken naar het stroomverbruik want achter elke hype aanrennen is nogal zinloos.