EN

📝 Van Azure DevOps naar Splunk: Volledig inzicht in workitems, MTTR en teamvoortgang

21 juli 2025 - door Tom de Bruijn 4 min leestijd

In veel DevOps-omgevingen zie ik het volgende patroon: in een monitoringtool gaat een alert af, waarop, handmatig of geautomatiseerd, een ticket wordt aangemaakt in incident registratie systemen als Azure DevOps of Jira. Een engineer onderzoekt het incident, documenteert de oorzaak, en sluit uiteindelijk het ticket af. Wat er in deze flow ontbreekt: samenhangend inzicht. Tickets en logging zijn soms wel geintegreerd, maar leven in de praktijk vaak in gescheiden werelden. Dit leidt tot twee veelvoorkomende problemen:

- Gebrek aan directe context: Vanuit het ticket is vaak onvoldoende informatie beschikbaar, en er ontbreekt een directe link naar de relevante logdata of het bijbehorende dashboard. Engineers moeten handmatig op zoek naar de juiste logs, wat tijdrovend en foutgevoelig is.

- Beperkt inzicht in incidentstromen: Omdat tickets niet zichtbaar zijn in Splunk, ontbreekt daar het overzicht van hoeveel issues er spelen, welke al zijn opgelost en wat de doorlooptijden zijn. Hierdoor is het lastig om trends te signaleren, processen structureel te verbeteren of effectief bij te sturen.

✅ Met een slimme integratie tussen ticketing- en monitoring software heb ik dit opgelost. In deze blog leg ik uit hoe je dit technisch opzet. De implementatie is robuust, schaalbaar en makkelijk aanpasbaar aan je eigen datamodellen en vergelijkbare tools als Jira en ook andere monitoringplatforms. Hierdoor krijg je:

  • 📌 Voor engineers: directe koppeling van logs en events aan relevante tickets (workitems), geen context-switch nodig.
  • 📈 Voor managers: Stuurinformatie - Duidelijke rapportages over MTTR, MTBF en doorlooptijden, overzichtelijk, instelbaar, betrouwbaar.
  • 👨‍💻 Voor teams: Snel context bij een errorlog of alert – gelinkt aan het juiste ticket, overzicht over alle tickets, per project, prioriteit, tag of afdeling.
  • 📊 Voor de hele organisatie: inzicht, data-gedreven verbeterkansen en minder verrassingen.

💡 *Voor deze blog gebruik ik specifiek Azure DevOps en Splunk als voorbeeld, dezelfde opzet is ook toepasbaar op andere tooling.*

🔧 Hoe bereik je dit?

Om ticketinformatie van Azure DevOps correct te koppelen aan Splunk en bruikbare inzichten te genereren, zijn de volgende componenten nodig:

• Azure DevOps PAT Token - Voor REST API-calls naar Azure DevOps, om de workitem ID's en bijbehorende metadata op te halen.

• Splunk REST Token - Nodig om de huidige status van workitems in Splunk op te halen via Splunk’s REST API.

• Splunk HEC Token - Voor het aanleveren van nieuwe events aan Splunk via de HTTP Event Collector.

• Splunk Index + Sourcetype - Een Splunk index en een JSON sourcetype waarin de verrijkte workitem-data wordt opgeslagen.

• Server voor Yaml Script - Een server of runner waarop het YAML-script draait dat toegang heeft tot zowel Azure DevOps als Splunk.

🧩 Het YAML script in vijf duidelijke stappen:

1⃣

Request Azure DevOps API - WIQL

Met de Azure DevOps WIQL API kan je zoals de naam (Work Item Query Language) zegt, zoekopdrachten doen. Ik haal bij deze API call een lijst ID's van workitems op, die de afgelopen 24 uur een wijziging hebben gehad.

2⃣

Batch request Workitems metadata

Met de Batch request Workitems API vraag ik vervolgens van de lijst ID's de relevante data velden op per workitem.

3⃣

Query Splunk REST API

Met de Splunk REST API controleer ik of de workitems al aanwezig zijn in Splunk en wat de huidige status is op basis van tijd.

4⃣

Filter Events in pipeline

In de pipeline heb ik nu de opgehaalde events van AzureDevOps en van Splunk. Middels filtering in de code match ik deze lijsten en kijk ik waar de waarde van AzureDevOps nieuwer is dan die van Splunk, of nog niet in Splunk staat. Op deze manier worden alleen nieuwe- of update van events behouden.

5⃣

Verstuur alleen nieuwe events naar Splunk via HEC

Stuur de gefilterde events in batch op via de Splunk HTTP Event Collector.

*💡- Let op dat de API's van Azure DevOps en Splunk limieten hebben, in het YAML script maak ik daarom gebruik van batch verwerking. *

*💡- Een volledig voorbeeld script nodig? neem gerust contact op!*

📊 Splunk Dashboard:

Het eindresultaat is een dynamisch Splunk-dashboard dat de workitem data visualiseert. De belangrijkste componenten:

• Eén Base search - die alle data ophaalt en verwerkt, alle andere panelen maken gebruik van deze search waardoor er niet onnodig veel queries worden uitgevoerd en het dashboard goed eprformt.

• Tijd filtering – werktijden - MTTR MTBF - . De MTTR (Mean Time To Repair) en MTBF (Mean Time Between Failures) wordt standaard berekend middels het vergelijken van twee timestamps, bijvoorbeeld voor MTTR de tijd tussen incident “acknowledged” en “resolved”. In Splunk is het echter ook mogelijk om voor MTTR alleen de tijd tussen werktijden te meten, 08:00-17:00. In de avond- nacht- en weekenden wordt er immers niet gewerkt. Hiervoor is wel een slimme macro nodig.

• Visualisaties & filters - filters op, Afdeling/team, prioriteit, tag, label, status etc. Dit maakt het eenvoudig om bottlenecks per team te identificeren, prioriteitenschema’s te bewaken en trends over tijd te visualiseren.

📬 Volledige code nog nodig, of dit graag een keer live zien? Vraag een demo!

Neem onderstaand contact met mij op of reageer op deze post op LinkedIn.

Terug naar overzicht