Een Splunk-architectuur is een verzameling gespecialiseerde componenten die data ontvangen, indexeren, doorzoeken en beheren, waarbij clustering zorgt voor beschikbaarheid en schaalbaarheid. Wie de rolverdeling en de twee clustervormen begrijpt, weet waar zijn eigen omgeving kwetsbaar is. Dit stuk is voor Splunk-engineers en -admins, we sparen het jargon niet.
De componenten op een rij
De Splunk-documentatie vertelt wat elk component doet, niet wat er gebeurt als het uitvalt. En juist met die kolom beoordeel je je architectuur.
Component | Wat het doet | Clusterbaar | Wat er gebeurt als het uitvalt |
|---|---|---|---|
Forwarder | Verzamelt data aan de bron en stuurt die door | n.v.t.; schaal via meerdere forwarders | Die bron levert niet meer aan; data buffert lokaal of gaat verloren, en zonder pipeline-monitoring merkt niemand het |
Indexer | Indexeert, slaat op en voert het zware zoekwerk uit | Ja (indexer cluster) | Zonder cluster: data tijdelijk onbereikbaar en een gat in de indexering. Met cluster: peers nemen over en de cluster manager start fixup |
Search head | Startpunt voor zoekopdrachten, dashboards en alerts | Ja (search head cluster) | Gebruikers kunnen niet zoeken; scheduled searches en alerts slaan over |
Cluster manager | Coördineert het indexer cluster: replicatie, fixup, bundels | Nee; wel redundantie-opties | Het cluster draait door, maar herstelt zichzelf niet meer bij een volgende uitval; geen fixup, geen bundle pushes |
Deployment server | Verspreidt configuratie naar forwarders | Nee | Wijzigingen bereiken de forwarders niet meer; bestaande configuratie blijft draaien, dus het probleem valt pas later op |
License manager | Bewaakt het licentiegebruik van de omgeving | Nee | Indexeren gaat gewoon door; is de license manager langer dan 72 uur onbereikbaar, dan blokkeert Splunk het zoeken op de peers |
Monitoring console | Bewaakt de gezondheid van de hele omgeving | Nee | Je vliegt blind: problemen elders in de omgeving vallen pas op als gebruikers ze melden |
Indexer clustering: replication factor en search factor
Twee getallen bepalen het gedrag van je indexer cluster: de replication factor (RF) bepaalt hoeveel kopieën van de ruwe data het cluster bewaart, de search factor (SF) hoeveel daarvan ook doorzoekbaar zijn, inclusief tsidx-indexbestanden.
Concreet, met RF3 en SF2: elke bucket bestaat drie keer als ruwe data, waarvan twee direct doorzoekbaar. Valt één indexer uit, dan is er geen dataverlies en blijft zoeken mogelijk, terwijl de cluster manager via fixup de aantallen herstelt. Opslag: drie keer de gecomprimeerde ruwe data plus twee keer de indexbestanden.
De klassieke fout: SF gelijkstellen aan RF “omdat het veiliger klinkt”. Dat levert zelden extra weerbaarheid op, maar wel een extra complete set tsidx-bestanden, je opslagverbruik schiet omhoog zonder dat je er iets voor terugkrijgt. Verhoog SF alleen met een concreet herstelscenario waarin die extra doorzoekbare kopie het verschil maakt.
Search head clustering en captain election
Een search head cluster kiest uit zijn leden een captain: die verdeelt scheduled searches, coördineert de replicatie van knowledge objects (dashboards, saved searches, lookups) en bewaakt de clusterstaat. Valt de captain weg, dan kiezen de overgebleven leden een nieuwe, mits ze met een meerderheid zijn.
Dat meerderheidsvereiste verklaart twee vuistregels. Drie search heads is het minimum, want bij twee is elke uitval meteen het einde van de meerderheid. En een even aantal is een slecht idee: splitst een netwerkpartitie een cluster van vier in tweeën, dan heeft geen van beide helften een meerderheid en liggen scheduled searches en replicatie stil terwijl alle machines gewoon aanstaan.
Vijf fouten die we het vaakst tegenkomen
Met meer dan 500 implementaties achter de rug zien we dezelfde fouten terugkomen. De vijf hardnekkigste:
- Search factor gelijk aan replication factor, zonder reden. Zie hierboven: veel opslag, weinig winst.
- Een monitoring console die zelf niet gemonitord wordt. Het systeem dat alles bewaakt, wordt door niets bewaakt. Valt het stil, dan merkt per definitie niemand dat.
- Knowledge objects lokaal op één search head in plaats van in het cluster. Alles werkt, tot die ene search head uitvalt en de dashboards van een heel team nergens anders blijken te bestaan.
- Forwarders die zonder load balancing naar één vaste indexer praten. Eén indexer eruit betekent meteen datagaten, en de load in het cluster is structureel scheef.
- Een deployment server die te veel clients bedient. Duizenden forwarders op één onderbemeten machine: configuratie-updates druppelen dagenlang binnen, of komen nooit aan.
Wat je periodiek zou moeten controleren
Wil je dit één keer grondig laten doorlichten, dan is de Splunk Health Check de kortste route. Structureler kan ook: Splunk-beheer uitbesteden betekent dat deze controles elke dag gebeuren, door een team in plaats van die ene collega. Hoe je daarna van dashboards naar service-inzicht komt, en waarom omgevingen hun heavy forwarders vervangen door een pipeline-laag, lees je in de vervolgblogs. Twijfel je tussen platformen, lees dan welk platform bij je past.
