CINQby Quinten Stekelenburg
Splunk® IT Service Intelligence (ITSI); De oplossing voor monitoring en analyse, welke aangedreven door machine learning en kunstmatige intelligentie inzicht biedt in de gezondheid van kritieke IT- en zakelijke diensten en hun infrastructuur.
Een uitleg als bovenstaande, gevolgd door de verschillende usecases die Splunk ITSI vervult is wat ik vooral terugvind op het internet. Wat ik nog weinig zie zijn de ervaringen uit de praktijk of technische how-to’s. Zonde, want na een korte kennismaking met ITSI is vaak de reactie: ‘ziet er super gaaf uit’ – kort gevolgd door – ‘maar wat is er nodig voor de inrichting? Hoe werkt het en/of waar moet ik beginnen?’
In dit artikel geef ik antwoord op deze vragen en neem ik jullie graag mee naar het startpunt van ITSI, namelijk het aansluiten van een databron. Ik ga wat meer in op de techniek achter de oplossing en laat aan de hand van een praktijkvoorbeeld zien hoe je de metrieken van Applicatie Performance Monitoring op Splunk ITSI aansluit met daarbij een integratie naar ServiceNow.
Als uitgangspunt nemen wij een bestaande databron, de APM-monitoring in een organisatie, links in het HLD als cloud oplossing weergegeven. Dat is de monitoring die door middel van metingen inzicht biedt in de beschikbaarheid- en performance van een applicatie, dienst of een omgeving. Uit de APM-monitoring komen inzichten. Dit zijn de ruwe meetresultaten maar ook al verrijkte data zoals beschikbaarheid- of performance alerts.
Laten we kort stilstaan bij het versturen van de data naar Splunk. Veelal wordt hiervoor gebruik gemaakt van een webhook. Splunk biedt hiervoor zelf de HTTP Event Collector (HEC) aan. Middels HEC wordt de data op een veilige manier naar de Splunk omgeving verstuurd waarnaar het direct in de juiste index wordt opgeslagen. In het HLD noemen wij deze index de APM_Name_Private_index.
Met de alert-data in Splunk is de vervolgstap deze gereed te maken voor Splunk ITSI. Hiervoor is het nodig om de structuur van de data aan te passen naar een structuur die geschikt is voor ITSI. Dit aanpassen van de data naar een geschikt formaat wordt normaliseren genoemd en licht ik graag even toe.
Normaliseren is nodig zodat Splunk ITSI begrijpt wat voor data het binnen krijgt en wat het vervolgens met een event moet doen. Normaliseren lijkt in het begin wat omslachtig, de data zit immers al in Splunk. Het is daarom waarschijnlijk al eerder genormaliseerd tijdens het indexeren, dus waarom moet je het nog een keer aanpassen?
Zie het als volgt; wanneer je meerdere databronnen aansluit op Splunk, dan is de data los van elkaar goed te begrijpen en ook toepasbaar voor ieders doeleinde. Het is echter moeilijk om de data voor hetzelfde doeleinde te gebruiken. Wanneer de data genormaliseerd wordt naar een eenduidig bestandsformaat met daarbij een eenduidige key-value indeling is het voor Splunk ITSI mogelijk wat met de events te kunnen doen.
Belangrijk hierbij is dus dat de key-value indeling door normalisatie hetzelfde wordt. Als voorbeeld: waar in de APM Name Private index links in de afbeelding weergegeven, een veld als responstijd wordt aangeduid met de key-value combinatie performance=value, zal in index 2 dat veld bijvoorbeeld timer=value zijn en in index 3 responsetime=value. Door normalisatie kan dat voor alle drie de databronnen eenduidig aangepast worden naar itsi_duration=value.
Voor het normaliseren van data naar ITSI-events zijn regels en richtlijnen opgesteld, welke door Splunk zijn opgenomen in het Common Interface Model (CIM). Hierin staat beschreven welk veld(key) welk doeleinde(value) heeft en worden er voorbeelden gegeven voor hoe deze toegepast kunnen worden. Los van het CIM zijn er ook Cheat Sheets en Templates beschikbaar gesteld voor veel gebruikte integraties.
Het normaliseren – oftewel het hernoemen van velden – gaat in de praktijk middels een Scheduled Search. Zoals de naam al zegt is een Scheduled Search een zoekopdracht in Splunk die je herhaald kan laten uitvoeren. Voor dit doeleinde kijkt de zoekopdracht iedere minuut of er in de APM_Name_Private_index nieuwe events binnen zijn gekomen. Indien dit het geval is worden de velden uit de events middels meerdere eval commando’s aangepast naar ITSI-velden en middels een collect commando weggeschreven naar een aparte summary index, in het HLD genaamd apmname_alerts_itsi_public.
Onderstaand een stuk voorbeeld code SPL waarbij de eval commando’s voor de belangrijkste ITSI-velden worden toegelicht. In de praktijk dient deze code aangepast te worden op de eigen situatie.
Tijdens de normalisatie is het event middels het collect commando verstuurd naar de apmname_alerts_itsi_public summary index. Vanuit deze public index wordt door een correlation search de events opgenomen door Splunk ITSI. Dit is een standaard functionaliteit binnen Splunk ITSI en kan gezien worden als een macro die een index scant op nieuwe events en de integratie naar Splunk ITSI start. Eenmaal in Splunk ITSI komen de events binnen als “notable event”. Een notable event kan gezien worden als een losstaand alert. Wanneer een alert weer een positieve status heeft, bijvoorbeeld inloggen applicatie was onbeschikbaar en nu weer beschikbaar, wordt het event afgesloten en toegevoegd als Episode. Op zowel de losstaande notable events als de episodes worden correlatie zoekopdrachten gedaan en kunnen incidenten gestart worden. Deze correlaties binnen een databron als tussen databronnen toont de kracht van ITSI.
Voorbeeld: uit een notable event wordt een incident aangemaakt, bijvoorbeeld applicatie 1 is traag bij opstarten (performance), of inloggen werkt niet (beschikbaarheid). Uit episodes kunnen middels deep-dives alerts komen als, de afgelopen 4 maandag ochtenden was het inloggen traag tussen 08:00 en 10:00 of inloggen werkt iedere dinsdag tussen 07:00-08:00 niet. Ook kunnen correlaties gelegd worden tussen databronnen, een incident als, deze servers hadden een hoog CPU, gelijktijdig was de applicatie traag.
Het incident wordt dus aangemaakt binnen ITSI. Een overzicht van de openstaande en/of gesloten events is terug te vinden in de Episode Review:
Voor de integratie naar ServiceNow wordt een standaardoplossing binnen ITSI aangeboden, zie hiervoor de Splunk Docs - ITSI SNOW. In ons voorbeeld is in 1 van de besproken velden, de itsi_tag aangegeven om de integratie naar ServiceNow te starten. Vanuit Splunk ITSI wordt middels een XML/SOAP call een incident in ServiceNow aangemaakt en/of voorzien van een nieuwe status. De integratie tussen Splunk en ServiceNow werkt bidirectioneel. Indien in ServiceNow dus een update wordt doorgevoerd, wordt deze ook naar Splunk verzonden en vice versa.
Event in ServiceNow – aangemaakt door Splunk ITSI
In dit artikel heb ik jullie een inkijkje gegeven over het aansluiten van data op Splunk ITSI. Wij hebben gebruikmakend van HEC, alert data van een APM-product gestuurd naar een Splunk omgeving. Middels een saved search hebben wij vervolgens de event data genormaliseerd naar een Splunk ITSI event. Tijdens het normaliseren is middels eval commando’s aangegeven wat voor event (entiteit) het betreft en wat de status (urgentie/impact) is. Ook is aangegeven onder welke groep (correlation_key) het nieuwe notable event valt en of het gaat om een nieuwe gebeurtenis (event_key) of een vervolg (existing_event_key) op een bestaande gebeurtenis betreft. Doordat in de Tag is aangegeven, ook de koppeling naar ServiceNow Now-IT te starten, zal vanuit ITSI ook direct het evenement hiernaartoe doorgestuurd worden en gekoppeld worden aan de business_service, met daarin mogelijk een instructie, samenvatting en aanvullend bericht.
Persoonlijk vind ik Splunk ITSI een gave oplossing, na al dan niet wat handmatig instellen in het begin, kan vervolgens veel waarde gehaald worden uit de automatische correlaties en berichtgeving die eruit volgt.