Grip op je Splunk platform in 3 simpele stappen

Het is maandagmorgen en je logt in op je werkplek. Tot je schrik zit je inbox vol met berichten uit je Service Management tool dat er storingen op Splunk zijn geweest het weekend. Als je zelf inlogt op Splunk zie je een rode driehoek in de zwarte balk bovenin en als je een search start krijg je foutmeldingen en het is super traag… Herkenbaar?

De afgelopen jaren heb ik meerdere Splunk omgevingen mogen aanschouwen, beheren, implementeren en ontwerpen. In al die jaren heb ik geprobeerd om te zorgen voor zoveel mogelijk grip op het platform om te voorkomen dat ik tegen bovenstaand scenario aanloop.

De dynamische aard van Splunk in gebruik en data intake maakt dat er geen vaste formule is voor het beheer van de omgeving. De gebruikersklacht dat Splunk “traag” is, is zo lastig vast te pakken. Toch denk ik een manier te hebben gevonden die ervoor zorgt dat een Splunk omgeving optimaal werkt. Hetgeen resulteert in een lagere beheerslast en meer focus op waarde ontwikkeling.

In deze blogpost help ik je met een aantal tips op weg om meer grip te krijgen en met een gerust hart uit te loggen aan het einde van de dag.

Zorg dat je Monitoring Console goed werkt

Deze eerste tip klinkt als een open deur maar dat is helaas niet altijd het geval. De Monitoring Console is een enorm waardevolle gereedschap in je gereedschapskist en is essentieel voor het onderzoeken van mogelijke problemen.

Meer informatie over de Monitoring Console vind je uiteraard op docs.splunk.com.

In een omgeving met 1 Splunk server is de Monitoring Console na installatie direct werkbaar maar al snel heb je de beschikking over 1 of meedere Indexers, Heavy Forwarders of een Search Head Cluster. Zorg dat deze juist geconfigureerd zijn in de setup pagina en (tip!) zorg dat de labels voor de clusters goed geconfigureerd zijn. Dit maakt de Monitoring Console veel bruikbaarder en kan ook gewoon achteraf nog rechtgetrokken worden.

Oh ja en nog dit. De Monitoring Console wordt vaak geinstalleerd op een losse Splunk server, op zich geen probleem, maar dan op een systeem wat virtueel is en (te) lage specificaties heeft. Jammer want vooral bij grote omgevingen heeft de Monitoring Console toch behoorlijk wat resources nodig. Vooral CPU cores want sommige dashboards hebben veel searches. Denk hier dus aan als je een server als Monitoring Console gaat inzetten.

Wanneer en hoe gebruik je de Monitoring Console?

De Monitoring Console kun je gebruiken tijdens een controle van de omgeving maar komt vooral tot zijn recht als er problemen zijn en je onderzoek moet doen.

Bij een controle van de omgeving kun je gebruiken maken van de Index Cluster Overview of Search Head Cluster Status and Configuration. De Monitoring Console is ook nuttig voor het bekijken van de status van Universal Forwarders; melden ze zich nog, welke Splunk versie draaien ze, lopen ze tegen bandwith problemen aan, etc.

Als je performance of stabiliteits problemen hebt dan is de Monitoring Console essentieel. Je kunt de resources van instances bekijken, de queues van je indexing pipeline, de replicatie van je Search Head bundle naar de indexers en nog veel meer.

Het loont echt om de Monitoring Console goed op te zetten en hem te gebruiken in je beheerroutine.

Werk aan een goede alerting strategie

Een Splunk platform wordt vaak 24/7 gebruikt in grote organisaties maar het is natuurlijk niet altijd zo dat er 24/7 iemand is om Splunk in de gaten te houden. De juiste alerting op het juiste moment in de juiste kanalen is daarom essentieel!

Mijn advies hier is het volgende:

  1. Denk na over waar je de alerts wil ontvangen en zorg dat de Splunk server waar de Monitoring Console actief is alerts hier kan afleveren (e.g. Slack, email, SMS)
  2. Zet de alerts aan die meegeleverd worden met de Monitoring Console en laat de alerts binnenkomen waar je ze wilt hebben
  3. Installeer SplunkAdmins (beste app van Splunkbase voor admins!) op de Splunk server waar ook de Monitoring Console actief is
  4. Configureer de macro’s in SplunkAdmins
  5. Enable de alerts met HIGH in de omschrijving en laat de alerts binnenkomen waar je ze wilt hebben

De alerts van SplunkAdmins met HIGH in de description zijn specifieke alerts die aangeven dat er echt iets cruciaals mis is met je platform zoals een Indexer down of je Search of Replication Factor die niet OK zijn op je Cluster Master. In het begin zullen er misschien veel komen en vind je sommige meldingen niet actueel. Zet ze uit of pas ze aan.

Houdt er rekening mee dat als je meerdere Index Clusters hebt dat je de alerts aanpast zodat helder is om welk cluster het gaat. Dat is niet overal even duidelijk namelijk.

Bouw vanaf deze basis verder met alerts die je zelf nuttig vindt zoals alerts als databronnen niet meer binnenkomen of als reports en alerts niet verstuurd worden als er een probleem met de SMTP relay is in Splunk.

Bouw een Platform Dashboard en neem die dagelijks door

Dit is in mijn laatste opdracht bij Schiphol een cruciale tool gebleken. Tijdens de SCRUM dagstart pakten we aan het einde het Platform dashboard erbij en keken we naar afwijkingen die mogelijk interessant zijn. Deze werden onderzocht en eventueel opgepakt door een admin.

Het Platform dashboard bevat grafieken (vaak timecharts) over verschillende KPI’s zoals:

  1. Reponse tijden van een referentie search (aparte blogpost 😉 )
  2. MB’s gelezen of geschreven door apps op Search Heads en Indexers (indicatie van slechte searches of veel te grote lookups)
  3. Load average op Indexers (boven 1.5 is indicatie voor problemen!)

Voeg hier ook vooral dingen toe als je ziet dat bepaalde inzichten tijdens een incident nodig waren om tot een oplossing te komen.

Het fijne van een grafiek is dat het niet gaat om de specifieke waarden maar dat je een op- of neerwaartse spiraal ziet die mogelijk een indicatie is van iets. Klinkt vaag inderdaad maar het is vaak zat voorgekomen dat wij bij Schiphol bepaalde scheduled searches van gebruikers konden stoppen of optimaliseren voordat het hele platform naar beneden werd getrokken!

Bewaar wijzigingen op je platform in een lookup (toegift)

Het is vaak heel lastig onderzoeken wat er binnen Splunk toe geleidt heeft dat een Indexer traag werd of een Heavy Forwarder zijn data niet meer kwijt kon of een index geen data meer binnenkreeg.

De beste manier om dit toch te doen is een lookup bijhouden van wijzigingen op je platform (wat, wie en wanneer).

Met wijzigingen bedoel ik bijna al het admin werk op je platform:

  1. Index wijzigen
  2. App installeren
  3. Server configuratie aanpassen
  4. Indexers bijplaatsen
  5. OS of Splunk patches installeren
  6. Disk vervangen

Het mooie van een lookup is dat je het als annotation in je grafieken op je Platform dashboard kunt plaatsen zodat je misschien een indicatie krijgt wat de oorzaak is geweest bij een verslechtering van de trendlijn. Door een datum/tijd op te nemen in je lookup komt hij bij een timechart precies op de juiste plek te staan

Misschien kun je een aantal wijzigingen wel uit de internal logs van Splunk halen of uit de logging van een automation tool en kun je ze automatisch in de lookup plaatsen.

Conclusie

Splunk biedt zelf natuurlijk een schat aan informatie aan in de _internal index. Hier goed gebruik van maken om je Splunk beheerorganisatie te ondersteunen vergt tijd maar ik hoop dat ik je met deze tips een goede richting op heb kunnen sturen.

Er valt nog veel meer te vertellen over goed Splunk beheer dus er zullen hierover nog meer blogposts volgen!

Over Coen Meerbeek

Solution Architect IT Monitoring / Splunk consultant @ Blue Factory, eigenaar en oprichter @ BuzzardLabs, basketbalspeler en Xbox-gamer. Lees meer van Coen op Launchers.nl en Twitter.

Speak Your Mind

*