Hur importerar man data till Predictive Insight, PI och i vilka fall det gör störst värde?
Vi på Compose IT har under många år samarbetat med IBM och jobbat med deras produkter. Under 2018 gjorde vi en djupdykning i IBM:s Predictive Insight (PI) för att se hur PI kunde komplettera våra övriga produkter.
I vår förra artikel om Predictive Insight beskrev vi vad PI klarar av och hur den fungerar. Vi nämnde även två testfall vi har jobbat med och hur man kan överföra data till PI. I denna artikeln kommer vi att gå djupare in på hur man kan överföra data till PI. Vi kommer även berätta mer om de två testfall vi nämnde och beskriva både ett fall där PIs resultat var ovärderligt och ett fall PI inte är optimerad för.
Predictive Insight har stöd för att överföra data från många olika typer av system. Det finns flera färdiga medieringspaket från IBM som överför data från en källa till PI. Det finns medieringspaket för ett flertal system, bland annat Splunk, Nagios, SCOM och ITNM. Data kan också överföras direkt från en relationsdatabas, CSV filer, JSON filer och JSON http posts till PI.
När CSV eller JSON används som importmetod kan det finnas att behov av att bearbeta data till ett passande format. Det kan vara ett urval av fält som ska exporteras till PI eller så kanske ett fält måste formateras. Den vanligaste bearbetningen som sker innan data importeras till PI är att formatera tidsstämpeln då PI kräver tidstämplar i formatet mikrosekunder. Om det finns ett bearbetnings-behov så är Elastic Stacks Logstash det alternativ som IBM rekommenderar. Elastic Stack, som Logstash är en del av, är en opensource lösning som vi på Compose IT också har erfarenhet av. Då Logstash är opensource baserat så finns det ett flertal moduler för insamling, filtrering och export av data tillgängliga. IBM har skapat moduler till Logstash för PI som formaterar data och skriver det till en CSV fil med PI struktur. Med hjälp av Logstash blir det alltså möjligt att formatera och importera data till PI oberoende av källans dataformat.
När data importeras ifrån en relationsdatabas till PI så används PIs medierings verktyg.
När vi importerade data till PI för de två testfallen som omnämndes i vår förra artikel så användes två olika import-och bearbetningsmetoder och i båda testfallen så användes produktionsdata.
I det första testfallet så hade vi ett känt problem med ett skript som intermittent inte exekverade korrekt. Problemet uppstod varje natt mellan ett och tre. För att försöka hitta problemets grundorsak så började vi samla in och skicka prestandadata från servern som körde skriptet samt information om hur skriptet exekverades till PI. Denna data samlades in, kompilerades till JSON format, skrevs till Kafka, lästes från Kafka och importerades till PI i real-tid. I detta fallet så användes ett skript för att plocka ut data från Kafka och importera det till PI men Logstash funkar lika bra. Vi rekommenderar kombinationen Kafka -> Logstash då vi tycker Kafka är en väldigt bra produkt och för att det är lätt att läsa från Kafka med hjälp av Logstash.
Idén var att PI skulle kunna finna relationer mellan datavärdena som skulle kunna hjälpa oss att hitta grundorsaken till problemet. Men eftersom problemet redan existerade och uppstod på en regelbunden basis när vi började ge PI denna data så ansågs problemet som en del av det normala beteendet. PI visar bara korrelationer mellan datavärden när det finns två aktiva avvikelser som relaterar till varandra. Eftersom detta problem ansågs vara del av det normala beteendet var det ingen avvikelse och inga relationer visades. PI hittade en del andra intressanta saker men inget som relaterade till det kända problemet. AI produkter som PI är i många fall väldigt bra men detta är inte ett av fallen de är optimerade för.
I det andra testfallet så sökte vi inte efter något speciellt utan var nyfikna på vad PI skulle hitta om den fick analysera oregelbunden icke-tidsseriedata. För att göra detta så samlade vi in event som hade skett under en period av sex månader från eventhanteraren Netcool. Denna data skrevs till CSV filer som bearbetades med hjälp av PIs medieringsverktyg och importerades till PI. PIs analys av datavärdena tog några timmar, vi lät analysen köras över natten och morgonen därpå var den klar.
Att analysera icke-tidsseriedata i PI kan vara svårt och i vissa fall helt värdelöst. Eftersom PI behöver en tillräckligt stor datamängd för att kunna hitta ett normalt beteende och på så sätt hitta avvikelser. Om det är för få datapunkter under ett intervall anser systemet att avsaknad av data är det normala och varje mottagen datapost blir då en avvikelse. T.ex. om det kommer in väldigt få events så anses inga event vara det normala och så fort det kommer ett event ses det som en avvikelse. Detta kan korrigeras något genom att sätta inställningen aggregerings intervall, men det längsta möjliga intervallet är 60 minuter. Finns det tillräckligt med data så kan PI vara lika värdefullt för icke-tidsseriedata som för tidsseriedata.
I detta fall så fanns det tillräckligt med data och PIs resultat visade sig vara väldigt värdefullt. Incidenter som ledde till ett något större antal larm blev uppenbara och PI hittade värdefulla relationer mellan avvikelser som normalt kanske inte hade hittats alls. De relationerna PI hittade var relationer som normalt endast hade kunna hittas av någon med väldigt god kunskap om de övervakade systemen. För att hitta relationerna måste det finnas både väldigt god kunskap om arkitekturen, så som systemens relation till varandra och varje enskilt systems syfte.
Om inte denna kompetens finns så kan PIs resultat vara helt ovärderligt för att snabbt hitta var det är fel och lösa det.
Lärdomen att ta med sig är att PI är väldigt bra i många fall men ger inte lika mycket värde i andra fall.
PI är inte en produkt som avser att finna grundorsaker till problem genom att analysera de inkommande eventen med varandra i real-tid. Istället är den skapt som ett proaktivt felhanterings system som hittar avvikelser genom att analysera de inkommande datavärdena med det inlärda mönstret. PI har även förmågan att hitta relationer mellan olika dataserier. Eftersom PI kan hitta relationer så kan den definitivt vara till ovärderlig hjälp när man söker efter grundorsaker eftersom alla påverkade parter är kända.
PIs styrkor ligger i dess förmåga att kunna analysera data, hitta vad som är normalt och vad som är avvikande. Det är det som gör det möjligt att hitta potentiella problem vid första tecken på att de kan uppstå. Därför kan inte PI hitta problem som ur dess synvinkel alltid har funnits och alltid sker vid samma tidpunkt. PIs algoritmer lär sig vad som är normalt utan någon yttre påverkan. När PI hittar en avvikelse eller en relation så är det för att det är en avvikelse eller en relation. Är det så att PI inte hittat en avvikelse eller en relation så är det för att det är normalt och det inte finns någon relation. Det betyder inte att det inte finns problem utan att problemet har funnits så länge att det har blivit det normala. Om detta skulle vara fallet är det en indikation på att det finns behov av PI som komplement till de existerande system.
Men bättre sent än aldrig, vi hjälper er att hitta era problem innan de uppstår men hjälp av PI!
