Bij TRES komen onze IIS-logs in een Elasticsearch-omgeving, zodat we in de Kibana-interface snel kunnen zien hoeveel verkeer er op onze webservers is en dat vervolgens uitsplitsen naar sites, naar bronnen, zodat we kunnen zien of vanaf bepaalde IP-adressen botjes "vervelend" beginnen te worden.
Dat is best veel data. En schijven die hiervoor gebruikt worden zijn eindig, op een bepaald moment "zijn ze vol", zover moet het natuurlijk niet komen. Onze hosting-partner gaf ons een seintje dat de omgeving richting dat punt ging en vroeg wat er gedaan moest worden. Intern hadden we het er al over gehad, om bijvoorbeeld de retentie-tijd in te korten, nu bewaren we alles van een jaar lang, maar hebben we het echt zo lang nodig? Aan de andere kant, als je die data "nog kunt bewaren" zou het wel fijn zijn, want klanten komen vaak "laat" op de lijn als er een probleem is, of een probleem geweest is. Dan krijg je te horen "ja, halverwege april hadden we problemen met die en die pagina...", en dat krijg je dan oktober te horen, bijna een half jaar na dato.
Toen kreeg ik een heldere ingeving. Want als ik ging zoeken op data, dan ging ik vaak eerst een "exclude" toevoegen, namelijk het IP-adres van onze Zabbix-omgeving. We monitoren onze websites met Zabbix en al die requests worden "net als gewone bezoekers" in de IIS-logs geregistreerd. Maar die requests boeien mij niet, die veroorzaken wij zelf en zijn alleen maar voor het monitoren van de sites. Dus toen bedacht ik mij, kunnen we er ook voor zorgen dat die registraties uit Elasticsearch verwijderd worden?
Het eerste wat ik daarvoor aangepast heb is filebeat.yml. Dat is het configuratie-bestand van de Windows-service "filebeat" die alle IIS-logs naar de Elasticsearch-omgeving stuurt.
Het was even "pielen" om dat goed werkend te krijgen. Ik zie natuurlijk "velden" in Kibana (de web-tool om door je data te zoeken), maar de data die filebeat verstuurt, dat is gewoon de platte tekst. Je moet dus een soort regex per regel toepassen op het IP-adres van je Zabbix-server. Met onderstaande data is dat gelukt.
# ================================= Processors =================================
processors:
- drop_event:
when:
contains:
message: " IP-ADDRESS "
# notice the space before and the space after! if forces to match on the IP and not as part of something else
Het tweede wat aangepast moest worden was de reeds opgeslagen data.
De boel heeft nu ongeveer een jaar gedraaid en er zit dus ook al voor een jaar aan data van Zabbix-requests op onze sites in Elasticsearch. Nadat ik eerst via Kibana naar Management, DevTools en de Console gegaan ben, kon ik daar bepaalde statements uitvoeren om de indexen met hun grootte te bekijken en stuk-voor-stuk statements uitvoeren om die data uit een log van een dag te verwijderen. Daar zitten time-outs op, dus vaak moest dat statement voor een 2e keer uitgevoerd worden. Daarna maak je de index readonly en vervolgens roep je een expunge_delete actie aan om de verwijderde documenten/requests eruit te halen. Hierna hou je de taak "forcemerge" in de gaten om te zien of deze klaar is. Pas daarna ga je door met de volgende. Op het moment dat je bezig bent met die "expunge-actie" wordt er aan de index gewerkt, waardoor deze tijdelijk even groter wordt. De eerste keer dat je dat ziet denk je "ik wil shrinken, niet expanden!", maar dat is de logische actie. Want uiteindelijk is je bestand een stuk kleiner. Vaak zit het bestand eerst rond de 5.2 GB, daarna 4.8 of nog minder.
Alleen, het credo luidt: "1x handmatig, OK", "2x handmatig, nou, voor deze keer dan", "3x of meer handmatig, niet doen: automatiseren!". En dat is ook zo, ik had er niet zoveel zin in om dit 365x uit te moeten voeren. Dus ChatGPT erbij gehaald en gekeken wat er mogelijk is. Je ziet in je browser op het moment dat je in de Console van de DevTools een actie doet, dat via een soort proxy-endpoint loopt, maar Elasticsearch heeft "gewoon" een API die je op de URL van het domein kunt bereiken op poort 9200. Je stuurt je authenticatie mee (username:password) en kunt zo acties uitvoeren. Bij onze hostingpartner staat dit allemaal "dicht" naar buiten en dat wil ik ook zo houden.
Daarom heb ik een bash-script gemaakt die ik op de server zelf draai. Via putty (SSH) en scp (kopiëren van bestanden) start ik daar de taak op, kan in het scherm van Putty zien of het proces netjes doorloopt en zelf met andere dingen aan de slag.
In deze Github-repo staat het script, je kunt het vrij gebruiken voor je eigen omgeving als je een vergelijkbaar probleem hebt en zo zaken wilt opschonen.
In de README.md van het project kun je lezen wat hierboven eigenlijk ook al genoemd is "hoe de code werkt".