Open source release ‘promacct’: Network traffic accounting using Prometheus

November 14th, 2016

Network traffic accounting with pmacct
At Kumina we’ve been a long-time user of pmacct. pmacct is an easy to use daemon for UNIX-based systems to perform network traffic accounting. Under the hood, pmacct makes use of libpcap to capture network traffic from the operating system. In our current deployment we’ve configured pmacct to write its results into a MySQL database. At the end of every month we run various queries on this database, ranging from simple summation per host to computing the 95th percentile. These results may then be used for billing purposes.

Pmacct and MySQL database
Given that the number of servers, IP addresses and the amount of traffic at Kumina has increased steadily over the last couple of years, we’re at this point running into the problem that pmacct in combination with a MySQL database simply no longer scales. Not only are our search queries taking a long time to complete, even insertions of new data are becoming problematic. A SQL database server is not the right tool for storing and processing time series.

Improving monitoring and trending
Over the last couple of months we’ve been working on replacing and improving our existing monitoring and trending setup with Prometheus. So far our experiences using it have been very positive, which is why we’ve decided that we also want to use it as the basis for a new traffic accounting setup. Being able to create recording rules that use functions like quantile_over_time() is exactly what we need, as it allows us to compute traffic percentiles not just at the end of the month, but in real-time.

Alternative for pmacct: promacct
After searching online, we haven’t been able to find a Prometheus metrics exporter that could act as a drop-in replacement for pmacct, which is why we’ve decided to develop it ourselves, called promacct. Where proamcct differs from pmacct is that instead of periodically storing results to a database, it provides access to its metrics over HTTP, allowing Prometheus to scrape it directly.
Due to promacct supporting aggregation by source/destination IP addresses, we can now easily create traffic graphs for individual hosts:

screen-shot1-promacct

Per-datacenter traffic quantiles are computed through recording rules, so that they can be inspected at real-time:

screen-shot2-promacct
Today we’re glad to announce that we’re releasing promacct as Open Source Software. Its source code can be found on our company’s GitHub page. Be sure to give it a try and let us know whether it works for you.

Enjoy and feel free to share!


Birdwatcher: Accessing Calico/BIRD metrics through Prometheus

October 28th, 2016

At Kumina we maintain a Kubernetes setup running on Amazon EC2. For the low-level networking between containers, we make use of Calico. Calico configures all of our EC2 systems to form a mesh network. The systems in this mesh network all run an instance of the BIRD Internet Routing Daemon.

One of the problems we ran into with Calico is that it’s sometimes hard to get a holistic view of the state of the system. Calico ships with a utility called calicoctl that can be used to print the state of a single node in the mesh, but using this utility can easily become laborious as the number of EC2 instances increases.

Given that we already make strong use of Prometheus for our monitoring, we’ve solved this by writing a tool called Birdwatcher that exports the metrics generated by BIRD in Prometheus’ format. This allows us to put alerts in place for when an excessive number of changes to routes occur, or when routes simply fail to work for a prolonged period of time.

Today we’re happy to announce that Birdwatcher is now available on our company’s GitHub page. If you’re a user of both Calico and Prometheus, be sure to give it a try. Enjoy!

 

screen-shot-birdwatcher


Kumina sponsoring CloudABI: practical sandboxing for UNIX

October 14th, 2016

Ed Schouten: “Almost exactly two years ago I started working on a project called CloudABI. In a nutshell, CloudABI is a UNIX-like programming environment for Linux and the BSDs that allows you to easily design sandboxed applications. It accomplishes this by making strong use of capability-based security, inspired by the University of Cambridge’s Capsicum. Compared to traditional UNIX applications, CloudABI applications are better resistent against security vulnerabilities, easier to test and easier to maintain. CloudABI is available as Open Source Software, free of charge. Feel free to watch my talk at 32C3 if you’re interested in all of the nitty-gritty details.

Some time ago I decided to visit the folks at Kumina, as I used to work there until early 2012. That’s why you’ll see my name next to some of the older posts on this blog. During my visit, Tim made me an offer I simply couldn’t refuse: a job at Kumina that allows me to spend a significant amount of time every week to continue the development of CloudABI. As you can see, I’ve accepted the offer. As of last month, I’m a member of the team once again!

What brings me joy is that this step makes the development of CloudABI sustainable. Over the last couple of weeks I’ve already managed to implement at least one large new feature: support for 32-bit hardware architectures. The CloudABI Development Blog now has an article describing the work that was needed to realise this.

At Kumina my job consists of a mixture between systems administration and software development. There are various pieces of software that we’re developing in-house. One of my tasks is to release some of these as Open Source Software, so stay tuned for my next posts!”


Buckler: Authentication and authorization for Kibana, for free!

September 29th, 2016

 

At Kumina, we make heavy use of the ELK stack: Elasticsearch, Logstash and Kibana. All of our servers have their logs collected by Logstash and stored in Elasticsearch, so we can easily access them through Kibana. As of recently we started providing direct access to our Kibana instance to our customers, so that they can perform analysis on the data themselves. This brings us to an interesting problem: Elasticsearch – and in effect Kibana – does not implement any authentication and authorization mechanisms. This means that by default customers would be able to view each other’s data.

Support for access controls is instead offered by a commercial product by Elastic, called Shield. Though Shield certainly looks like an interesting product, it looks far too advanced and costly for the problem we tried to solve at Kumina: simply having partitioned access to the data for several customers. This is why we commissioned the development of a new piece of software called Buckler. Buckler is a light-weight proxy for Kibana, written in Python (Django). It allows you to restrict access in Kibana by adding password authentication. When logged in, a user is only allowed to access indices specified for that user in Buckler’s configuration file.


Free alternative to Shield

Today we’re glad to announce that we’re releasing Buckler as open source software licensed under the Apache License, version 2.0. The Git repository containing sources and documentation can be found on our company’s Git Hub page. In addition to the proxy itself, we’re also releasing a Vagrant environment that allows you to easily test and experiment with Buckler. Right now Buckler only works in combination with Kibana 4.1, as that’ s the version in use at Kumina. There is a fair chance we’re going to extend Buckler over time to support newer versions of Kibana, such as 4.3 and 5.x.

Enjoy!

buckler_logo


Gezocht: Gemotiveerde Linux Systeembeheerder

September 26th, 2016

Heb jij ervaring met Linux (Debian) en ben je op zoek naar een nieuwe uitdaging binnen een open maar professionele werkomgeving? Dan is Kumina misschien wel dé plek voor jou. We zijn een groeiend bedrijf en momenteel op zoek naar een Debian Linux Systeembeheerder die ons team wil komen versterken.

Over Kumina
Kumina verzorgt het systeembeheer voor een grote diversiteit aan klanten in zowel binnen- als buitenland. Van online mediabureaus tot stockfotoverkopers, van multinationals tot software en website developers, geen enkele klant is hetzelfde. Wat onze klanten wél als overeenkomst hebben, is dat ze allen vernieuwend bezig zijn op het gebied van internetgebaseerde applicaties. Naast het systeembeheer, verzorgen we ook redundante oplossingen voor een grote verscheidenheid aan applicaties en denken we mee bij het ontwerp van ‘built to fail’ opstellingen.

We streven er altijd naar om een strategische IT partner te zijn voor onze klanten. Onze focus ligt dan ook op het leveren van topkwaliteit dienstverlening. Dit betekent dat we de tijd nemen om goede oplossingen te implementeren en we continu op zoek zijn naar nieuwe oplossingen voor oude problemen. We zijn altijd vernieuwend bezig en besteden intern veel aandacht aan het verbeteren en automatiseren van onze eigen workflow.

Als bedrijf staan we achter de idealen van open source software, we werken bij voorkeur met packages uit het Debian project. De Linux ervaring van je collega’s varieert van 15+ jaar tot bijna 3 jaar ervaring, dus er is altijd iets te leren of te onderwijzen.

Functie-omschrijving
We streven er naar om een strategische IT partner te zijn voor onze klanten en hechten veel waarde aan een goede samenwerking met onze klanten. Dit betekent dat we altijd tijd maken voor onze klanten en veelvuldig contact met ze hebben. Klantverzoeken variëren van het toevoegen van server aliassen (die we moeten automatiseren) tot het opzetten van geheel nieuwe omgevingen voor (nieuwe) klanten. We verwachten van al onze medewerkers dat ze proactief verzoeken en problemen van klanten oppakken wanneer ze aankomen (of zelfs daarvóór).

Naast bovengenoemde werkzaamheden bestaat een groot deel van de functie uit het innoveren en optimaliseren van onze eigen bedrijfsprocessen. Dit is een continu proces, waarin we zowel op korte als langere termijn een hoop veranderingen verwachten. We testen met regelmaat nieuwe technologieën om deze vervolgens in onze processen te integreren.

Een ander onderdeel van je functie is het oplossen van problemen. We hebben een 24/7 storingsdienst, waarvoor we met roulerende weekeinddiensten werken. Zodra je genoeg ervaring hebt met onze manier van werken, zal je ook worden ingepland in deze diensten. (Er vinden weinig oproepen plaats buiten kantoortijden, één keer tijdens een dienst is al veel). Zodra je wordt ingepland in deze diensten, ontvang je een telefoon van de zaak.

Functie-eisen

  • Minimaal 1 of 2 jaar ervaring met Linux Serverbeheer, ervaring met Debian is een pré.
  • Vloeiend Nederlands en Engels, spreken en schrijven
  • Bereidheid om storingsdiensten te draaien (roulerend)
  • In staat om zowel zelfstandig als in teamverband te werken
  • Kennis en ervaring met enkele van het volgende:
    • Debian Linux
    • Apache
    • PHP
    • MySQL / Percona
    • Python
    • Puppet
    • KVM, Qemu
    • PostgreSQL
    • Tomcat
    • GlassFish?
    • Logstash / ElasticSearch? / Kibana
    • HAProxy
    • Heartbeat / Corosync
    • Pacemaker
    • Postfix
    • Icinga
    • NFS
    • DRBD
    • OCFS2
    • Ext4
    • Varnish
    • Unbound
    • POSIX File Permissions
    • Git
    • Docker

Onze perfecte nieuwe collega is iemand die leergierig is, nieuwe zaken snel oppikt en in staat is om zelfstandig te werken. We hechten niet veel waarde aan officiële opleidingen, maar des te meer waarde aan relevante (werk)ervaring, kennis en bereidheid om te leren en goed te presteren.

Een goede aansluiting op het bestaande team, is voor ons erg belangrijk. We bieden een enigszins chaotische, open omgeving waarin je vrij bent om commentaar te leveren maar ook in staat moet zijn om kritiek te ontvangen. We verwachten van iedere medewerker dat ze bereid zijn om te leren, kennis over te dragen en te documenteren. We zijn een hecht team, en alles wat we doen is een team effort. We zijn trots op ons werk en zullen je aanmoedigen om jezelf en ons te verbeteren, zodat ook jij trots kunt zijn op je werk. Het blijven verkennen en leren van nieuwe technologieën en ideeën moedigen we altijd aan.

De werkomgeving
Het werk wordt 4 dagen per week op ons kantoor in Eindhoven gedaan, de vijfde dag werken we meestal thuis. Onze kantoorvilla bevind zich op 10~15 minuten loopafstand van het station. We zijn tussen 8:45 en 9:30 op kantoor en lunchen allemaal samen, op kosten van Kumina. We proberen flexibel te zijn in werktijden, maar het is erg belangrijk dat we weten wanneer we iedereen kunnen verwachten. En natuurlijk niet te vergeten: we hebben goede koffie, iedere kan is vers gemalen.

Arbeidsvoorwaarden
We kunnen je een marktconform salaris aanbieden, afhankelijk van hoe we je kennis en ervaring beoordelen. Als je goed presteert, kun je verwachten dat je inkomen groeit naarmate het bedrijf groeit. Wanneer het met het bedrijf financieel goed gaat, merken de werknemers dat ook in hun eigen salaris. Eén en ander is natuurlijk afhankelijk van je eigen inzet.
Je krijgt 25 vakantiedagen op basis van een 40-urige werkweek. Mocht je minder willen werken dan 40 uur, is dat bespreekbaar. Je maandloon en bijbehorende vakantiedagen schalen dan uiteraard ook mee omlaag. In eerste instantie betreft het een tijdelijk contract, bij goed presteren wordt een vast contract aangeboden.

Geïnteresseerd?
Laat het ons weten! Mail ons op jobs@kumina.nl en geef daarbij duidelijk aan wat je kwalificaties zijn. Heb je nog vragen? Zet ze er gewoon bij en we doen ons best om ze voor je te beantwoorden. Of je komt met ons chatten op IRC (kanaal #kumina op irc.kumina.nl). Als je je zin begint met ‘kumina’, dan krijgen we een notificatie en zullen we sneller reageren, afhankelijk van waar we mee bezig zijn. Hou er rekening mee dat het enkele minuten kan duren voordat we reageren.

Acquisitie op basis van deze vacature wordt niet op prijs gesteld. Dat geldt ook voor recruiters.


awssyncer: an automatic syncer for Amazon S3 that makes use of inotify

September 16th, 2016

# awssyncer: Continuous syncing of local files into Amazon AWS S3.

At Kumina, we’re strong users of the Amazon AWS cloud computing platform. We’ve been using EC2 instances for quite some time and are currently working on expanding this by making use of Kubernetes.

While setting this up, we’ve noticed that we sometimes want to run jobs for which we want to keep track of small amounts of local state (i.e., files on disk). In this case we’ve decided that we want to store this data in S3, but do want to have it efficiently available through the local file system. The advantage of using S3 for this purpose is that it’s globally replicated, unlike EBS.

For this purpose we’ve developed a new utility called awssyncer, which is as of now available on GitHub! awssyncer is a utility written in C++ that uses Linux’s inotify to keep track of local modifications to a directory on disk. The purpose of this utility is to use these inotify events to determine which files need to be synced back into S3. This utility thus provides continuous one-way sychronisation from local disk to S3. A simple container startup script is used to sync files from S3 to local disk on startup.

Though we realise that this utility is fairly specific to our situation at hand, we do invite all of you to give it a try. Feel free to get in touch in case you have any questions or discover any bugs!