Your web browser is out of date. Update your browser for more security, speed and the best experience on this site.
Hoe InfluxDB inzicht brengt
In een wereld in verandering draait alles rond data. Gegevens over zelfrijdende auto’s en smartphones, bijvoorbeeld, of de servers waarop ze draaien. Bedrijven die voor willen zijn op de concurrentie, zo zeggen experts, moeten werk maken van een slimme datastrategie. Klinkt goed in theorie, maar in realiteit wil je vooral inzicht krijgen in die bergen aan gegevens. Hoe je dat doet vertelde Robbe Rotthier, Java Developer bij Axxes, tijdens Haxx on the Beach.
‘Er is bijvoorbeeld extreem veel data over transport beschikbaar. Een vliegtuig heeft al snel een terabyte aan gegevens: over de snelheid, luchtvochtigheid, het gewicht, de reactiesnelheid van de piloot…’, zei Robbe. Zeer vaak gaat het over time series data: gegevens die een link hebben met een specifiek tijdstip en doorheen de tijd van waarde kunnen veranderen.
Er zijn twee types van time series data. De eerste zijn Metrics: gegevens die op regelmatige basis binnenkomen. Denk bijvoorbeeld aan een dashboard waarop je per minuut of seconde de temperatuur van een warmtepomp kunt bekijken. De tweede variant zijn Events, waarbij gegevens binnenkomen wanneer er iets gebeurt. Het meten van aardbevingen is hier een goed voorbeeld van. Er zit geen regelmaat in, waardoor je er minder makkelijk een patroon in kan vinden.
Hoeveel gegevens houd je bij?
Stel dat er nadien ooit iets misgaat - het product dat van de lopende band rolt is minder goed dan normaal, bijvoorbeeld - dan kan je op basis van die data nagaan wat er fout ging. Het gaat al snel over een hele berg gegevens, waaruit je relevante informatie probeert te filteren. Die allemaal in de cloud stockeren is één ding, daarna de relevante zaken opzoeken is iets anders. Wanneer er bijvoorbeeld iets misgaat met een server wil je bijvoorbeeld de CPU load van het volledige jaar van die server kunnen bekijken.
Tegelijkertijd wil je ook niet iedere seconde gegevens bijhouden. Ook geaggregeerd kan data relevant zijn: de essentie kan je overhouden door met gemiddelden te werken. Wanneer je de data kan weggooien hangt volledig af van de business waarin je opereert.
Al die data op een gestructureerde manier bijhouden kan op verschillende manieren. Wij focussen vooral op InfluxDB, een open-source time series database, die Robbe en zijn collega’s gebruiken voor projecten bij onder andere Port of Antwerp. Het Amerikaans systeem, opgericht in 2013, is gratis zolang je één instantie draait. Met een commerciële licentie krijg je onder andere clustering en horizontal scalability.
InfluxDB is geschreven in Go en is schemaless, je moet op voorhand dus niet definiëren wat je tabel en mogelijke gegevens zijn, je kan er om het even welke data insteken of velden toevoegen. Wat de timing betreft zit het bij InfluxDB wel snor: het systeem is tot op een nanoseconde precies qua timestamp.
Enkele belangrijke termen
De GUI is niet alleen mooi vormgegeven, maar lijkt qua componenten ook hard op andere databases. Een aantal begrippen zijn belangrijk om aan de slag te kunnen:
Organisatie: je klant of het project waar alle data onder gegroepeerd wordt.
Bucket: de ‘emmer’ waar alle data in terechtkomt. In het geval van Port of Antwerp zou je bijvoorbeeld informatie kunnen bijhouden over de posities van een schip en het waterpeil.
Retention policy: wanneer wil je data weggooien?
Measurements: één record uit je tabel.
Tag: gelijkaardig aan geïndexeerde velden uit een normale database.
Field: gelijkaardig aan niet-geïndexeerde velden uit een normale database.
Series: bijvoorbeeld het meten van een temperatuur per tijdstip, dit hoeft niet per se geplot te zijn.
Pivot: je data is anders gestructureerd dan in een normale tabel. Je timestamp is altijd de primary key, om die input deftig in code te verwerken moet je dat pivoteren.
Het is belangrijk dat je vooraf nadenkt over je Tag en Field. Hoe meer velden je indexeert, hoe trager je database wordt en hoe minder vrij geheugen je hebt.
Data toevoegen / Data input / …
Wanneer je vervolgens data in je database wil steken, zou je de bovenste regel van de bovenstaande afbeeldding kunnen gebruiken. Dit is het basisprotocol om gegevens weg te schrijven, het zogenaamde line protocol. Je moet eerst de naam van je bucket geven, hier is dat die “measurement”. Vervolgens plaats je een comma separated list van keys en values na de komma. Na een spatie volgt hetzelfde maar dan voor je Fields. Helemaal op het einde staat optioneel de timestamp.
Dit is de meest basis manier om data in te voeren, maar het is uiteraard niet schaalbaar wanneer het om veel gegevens gaat. Gelukkig zijn er libraries die je daarbij kunnen helpen. Die bestaan voor de meeste grote programmeertalen en JavaScript. Een voorbeeld daarvan zie je onder het line protocol: je haalt hiermee je InfluxDB instances op, je haalt je API op om te schrijven en gaat vervolgens je datapunten wegschrijven. Zo kan je vlot meerdere datapunten tegelijkertijd verwerken.
Het is al iets eenvoudiger, maar je blijft met overhead zitten omdat je een systeem nodig hebt waar die client op draait. Een andere optie is werken met Telegraf, die tussen je input data source en InfluxDB zit en data overpompt. De setup is zeer eenvoudig: je installeert één dependency, geeft een startcommando en steekt er een token in om het geheel veilig te houden.
Data extracten
Nu we over een gevulde database beschikken, is de volgende stap die gegevens visualiseren om ze te kunnen analyseren. Dat kan in de GUI, maar soms wil je ze ook naar een mooie frontend sturen voor de eindgebruiker. Daarom maken we gebruik van flux. Dit is een open source querytaal die op SQL lijkt. Je geeft je timerange op (over hoeveel dagen gaat het?) en stelt bepaalde filters in. Zo bepaal je bijvoorbeeld welke velden wel en niet zichtbaar zijn. Deze query kan je rechtstreeks in de GUI of code plakken, waarna het werkt. Dat maakt het debuggen makkelijk als je ergens vastloopt.
Nu we weten hoe we queries kunnen opzetten, willen we ook “Continue queries” opstellen. In de context van InfluxDB hebben we het ook wel over “Tasks”. In dit geval wordt je query dus elk uur uitgevoerd en wordt data gesampled van de ene naar de andere bucket om vervolgens de gemiddelde waarde van iedere vijf minuten te bepalen. Dit is bijvoorbeeld handig om alerts te krijgen. Stel dat je je CPU load wil monitoren, dan kan je een alert laten uitsturen als de value te lang boven een bepaald percentage zit.
Als we het hebben over de performance van InfluxDB, dan kunnen we niet om de snelheid heen. In de betaalde versie verwerkt het systeem 2,8 miljoen writes per seconde en kan het 1.000 reads per seconde aan. Doordat het sneller is dan Elasticsearch of Prometheus maken heel wat grote partijen er gebruik van. Denk maar aan PayPal, Volvo, IBM en Salesforce, die het doorgaans gebruiken voor de monitoring van hun servers.
De demo
Uit de demo van Robbe bleek dat InfluxDB lokaal installeren zeer makkelijk is. Je begint met de image van Docker binnen te trekken en die vervolgens op te starten met een Docker run-commando. Daar geef je je port mee en geef je je InfluxDB instance een bepaalde naam. In een PowerShell window of via je localhost kan je vervolgens verifiëren of alles goed verlopen is.
Door een bucket aan te maken kun je vervolgens data beginnen wegschrijven. Die trek je, zoals eerder gezegd, eenvoudig binnen via Telegraf. Wanneer je Telegraf instelt zul je een token moeten exposen, wat in het geval van Robbe via PowerShell moest, en Telegraf zelf opstarten. Telegraf zal automatisch zoeken naar de zaken die het kan monitoren en die gegevens in je bucket inladen.
Als je een bucket aanmaakt, moet je er ook een retention policy aan meegeven om te bepalen hoe lang men data moet bewaren. Soms wil je data niet weggooien maar aggregeren. Dat kan zoals gezegd door een Task aan te maken.
In de Data Explorer van InfluxDB heb je verschillende opties om data te visualiseren. Denk maar aan een grafiek, heatmap of histogram. Handig om weten is dat alles wat je in de GUI kan doen ook via een API beschikbaar is.
Horizontaal en verticaal schalen
Een vijftal maanden voor zijn talk moesten Robbe en zijn collega’s bij Port of Antwerp een systeem kiezen om een time series database op te zetten. Ze vergeleken een heleboel tools en kwamen bij InfluxDB uit. Waarom?
In eerste instantie omdat InfluxDB zo laagdrempelig is. De learning curve valt goed mee en er is heel wat documentatie te vinden. Misschien nog wel het belangrijkste argument was de horizontale en verticale scaling die het systeem aankan: ‘Bij de haven hebben we niet alleen heel wat gegevens over het weer, de bruggen en de sluizen, maar ook over de schepen. Iedere drie seconde meten we hun positie. InfluxDB kan daar prima mee om. Je mag wel niet te veel tags gebruiken en hebt veel RAM nodig, maar naar de toekomst toe voorzie ik weinig problemen. Meer zelfs: de bergen data groeien alleen maar, waardoor time series databases alleen maar relevanter zullen worden.’
Bronvermelding
Blijf je graag in the know?
Robbe Rothier
Java consultant