⚡ Cribl-onboarding 10 keer sneller: pipelines bouwen met AI

Wie Cribl bij een klant implementeert, weet dat het platform zelf vaak snel staat. De meeste tijd gaat zitten in het onboarden van databronnen. Elke source heeft zijn eigen logformaat en vraagt om een pipeline die de data parset, opschoont, verrijkt en voorbereidt voor de destination. Van firewalls en proxy's tot Windows, Linux, cloudservices en applicaties. Voor je het weet heb je tientallen pipelines te bouwen.

Voorheen bouwde ik die pipelines handmatig, al dan niet met bestaande Cribl-packs als uitgangspunt. Logsamples verzamelen en analyseren, functies configureren, regex schrijven, testen en bijstellen. Een tijdrovend proces, waarbij ik gemiddeld slechts één tot twee goed werkende pipelines per week opleverde.

Inmiddels gebruik ik Claude Code en laat ik binnen vijf minuten een pipeline genereren. Met synthetische testdata werkt deze vervolgens voor 70–80% wanneer wij de echte data later koppelen, met goede representatieve klantdata werkt de gegenereerde pipeline vaak direct volledig. Door te werken met vaste standaarden, regels en geheugen zijn de pipelines bovendien consistenter opgebouwd, kwalitatief beter en goed gedocumenteerd.

In deze blog laat ik zien hoe ik Claude Code hiervoor inzet, hoe ik dit heb ingericht en waar je op moet letten.

Hieronder licht ik de werkwijze stap voor stap toe. Eerst leg ik de regels vast en zorg ik voor bruikbare data zonder klantgegevens. Daarna bouw ik de eerste pipeline en test ik die in Cribl. Elke volgende pipeline bouwt voort op het geheugen van het project en gaat ook weer Cribl in. Stap 6 staat los van die volgorde: een aparte agent die over het hele proces heen kijkt.

Stap 1: een project met duidelijke regels

Ik werk met Claude Code, met per klant een eigen projectmap. Daarin staan alle pipelines, samples en lookups, en een bestand met instructies: CLAUDE.md. Dat bestand leest Claude aan het begin van elke sessie in. Daar steek ik de meeste tijd in. Er staat onder andere in:

• Wat wel en wat niet. Welke Cribl-functies ik gebruik en welke ik juist vermijd.
• Mijn stijl. Hoe ik functies en groepen indeel. Elke pipeline krijgt een comment met de laatste aanpassing en wie eraan gewerkt heeft. Elke functie krijgt een eigen, beknopte comment die uitlegt waarom, niet alleen wat.
• Hoe te antwoorden. Kort, met de bestanden als resultaat, en eerst vragen als iets onduidelijk is.
• Hoe om te gaan met aannames en/of gokken. Niet gokken. Weet de AI een veldnaam of formaat niet zeker, dan zegt hij dat en vraagt hij het na. Een aanname moet herkenbaar zijn als aanname.
• Welke bronnen wel en niet. Voor informatie de documentatie van Cribl en de officiële documentatie van de logbron zelf. Geen willekeurige fora of blogs als bron van waarheid.

Tip: leg niet alleen vast hoe de AI dingen wél moet doen. Vaak is het nog belangrijker om op te schrijven wat hij níet moet doen.

Stap 2: data, zonder echte klantgegevens

Dan de belangrijkste vuistregel: gebruik AI volgens de regels van de organisatie waarvoor je werkt, en stuur nooit echte logsamples van een klant naar een openbaar toegankelijke AI-dienst. Geen hostnamen, geen IP-adressen, geen gebruikersnamen, geen e-mailadressen en ook geen andere persoonsgegevens. Werkt een bedrijf met een eigen, afgeschermde AI-omgeving, dan kunnen de regels daar anders zijn.

Het goede nieuws: dat is ook niet nodig. Om een pipeline te bouwen heeft AI het formaat van de logs nodig, niet de inhoud. De structuur en de velden zijn genoeg, de echte waarden niet. Een syslogregel van een firewall met een nep-IP en een verzonnen hostnaam is voor de pipeline net zo bruikbaar als de echte.

Er zijn twee keuzes:

• Geanonimiseerde klantdata (voorkeur). Echte samples, maar met alle gevoelige waarden vervangen. Dat doe ik niet met de hand, maar met een script dat volledig offline draait. Ook dat script kun je prima door AI laten schrijven. Het vervangt IP-adressen, hostnamen, gebruikers en andere waarden door nepwaarden, en wel consistent: dezelfde host krijgt overal dezelfde nepnaam, zodat de samenhang in de data intact blijft.
• Synthetische data. Op basis van de officiële documentatie van de logbron laat ik AI voorbeeldlogs genereren in het juiste formaat. Ideaal als de bron nog niet is aangesloten of als je er nog geen toegang toe hebt.

Echte data heeft de voorkeur: dan weet je nagenoeg zeker dat je pipeline ook in productie goed werkt.

Stap 3: de eerste pipeline, in drie bestanden

Voor elke pipeline maak ik drie bestanden:

• Sample data: de geanonimiseerde of synthetische logs.
• De pipeline: de functies, in mijn stijl en met comments.
• Knowledge items: de lookups en andere kennis die de pipeline gebruikt, zoals een tabel die eventcodes vertaalt naar een leesbare omschrijving.

De eerste pipeline is altijd het meeste werk. Niet omdat de AI het niet kan, maar omdat ik net zo lang bijstuur tot hij er precies uitziet zoals ik wil. Comments op mijn manier. Bepaalde functies wel, andere niet. Een lookup in plaats van een lange reeks if-statements. Een pack in plaats van losse pipelines. Elke correctie die ik geef, maakt de volgende pipeline beter.

Stap 4: testen in Cribl

Daarna gaat de pipeline Cribl in. Daar test ik hem met de sample data en controleer ik of de output klopt: worden de velden goed geparset, doen de lookups wat ze moeten doen en komt het event eruit zoals de destination het verwacht?

Klopt er iets niet, dan gaat de correctie terug naar Claude Code. Zo komt ook die les in het geheugen terecht en gaat het bij de volgende pipeline meteen goed. Pas als de output klopt, keur ik de pipeline goed. De pipelines bundel ik in één pack, zodat ze samen te installeren en te beheren zijn.

Tip: in Cribl kun je de output van de pipeline op de sample data downloaden als JSON. Die stuur je terug naar Claude, ter controle of om een fout direct aan te wijzen.

Stap 5: de volgende pipeline, met het geheugen van het project

Hier wordt het interessant. Claude Code heeft een geheugen per project. Naast de instructies in CLAUDE.md legt Claude zelf vast wat hij leert: elke correctie die ik geef en elke afspraak die we maken, ook tijdens het testen, komt in de volgende sessie gewoon terug. En omdat de eerste pipeline in dezelfde map staat, kan hij die er altijd bij pakken. Je hoeft dus niets opnieuw uit te leggen.

De volgende pipeline begint met één zin: "Neem de stijl van de vorige pipeline over, maar bouw hem nu voor bron X." De AI weet al hoe ik comments schrijf, welke functies ik wel en niet gebruik, hoe ik lookups opzet en hoe een pack eruitziet. Wat overblijft, is het werk dat er echt toe doet: het formaat van bron X begrijpen en controleren of de output klopt. Daarna gaat ook deze pipeline Cribl in om te testen, en zo herhaal ik stap 4 en 5 voor elke nieuwe source.

Zo maakt elke pipeline de volgende sneller. Na een paar bronnen ben ik vooral aan het reviewen en testen, en nauwelijks nog aan het bouwen.

Stap 6: een review-agent kijkt naar de gehele omgeving

Deze stap staat los van de werkwijze hierboven. Het is een aparte agent: een AI-medewerker binnen Claude Code, met zijn eigen regels. Hij bouwt niet mee, maar kijkt over het hele proces heen. Na vijf tot tien pipelines legt hij alles naast elkaar en kijkt hij naar de logica, niet regel voor regel.

Daar komen nuttige dingen uit:

• Pre-processing. Stappen die in elke pipeline terugkomen, zoals het afsplitsen van een syslog-header, kun je beter één keer vooraf doen, in een pre-processing pipeline.
• Samenvoegen. Drie syslogbronnen met bijna dezelfde pipeline? Die kunnen samen, met gedeelde functies. Ze kunnen misschien ook in hetzelfde pack, dat is makkelijker te beheren.
• Overlap. Velden die in de ene pipeline anders heten dan in de andere, of een lookup die op twee plekken bestaat.

Tip: wie zijn eigen werk controleert, ziet zijn eigen fouten zelden. Omdat de review-agent niet zelf heeft meegebouwd en zijn eigen regels volgt, vangt hij veel meer op.

Het resultaat: tot 10 keer sneller werken, met kwalitatief betere pipelines

Bij meerdere klanten ging ik van één tot twee pipelines per week naar tien tot soms wel twintig. Een deel is volledig afgerond en getest; de rest staat klaar op synthetische data en is direct inzetbaar zodra de bron is aangesloten. Omdat alle pipelines volgens dezelfde afspraken zijn gebouwd, zijn ze ook makkelijker te reviewen, te beheren en over te dragen.

Belangrijk: de AI vervangt de vakkennis niet. Ik bepaal de stijl en de architectuur, ik test elke pipeline in Cribl en ik keur hem goed. De AI neemt het tijdrovende deel over: het bouwen van de pipeline zelf en het schrijven van de functies.

Ook Cribl zet in op AI

Cribl zelf zet ook steeds meer in op AI. Je kunt inmiddels zelfs de interface van Cribl naar je hand zetten, door met AI apps te bouwen die dat voor je doen.

De Cribl Marketplace staat vol met zulke apps, en veel daarvan zijn zelf ook met AI gemaakt. Eén app komt heel dicht bij mijn aanpak: Pack Builder. Daarmee bouw je met AI packs op basis van je samples, en dat kan zelfs in bulk. Een mooie optie als je liever binnen Cribl blijft. Daarnaast vind je er ook andere apps, bijvoorbeeld om samples te downloaden.

Contact

📬 Meer weten over deze aanpak, of hulp nodig bij het onboarden van bronnen in Cribl? Neem contact op via de opties hieronder, of stuur me een bericht op LinkedIn.