Er wordt steeds meer gemonitord, stelt Rob Skillington van Uber. In monitoring-oplossingen zoals rond containers wordt logging langzaam vervangen door metrics. Uber heeft hier specifiek een database voor gebouwd (M3DB), die met Prometheus koppelt. Prometheus is de industriestandaard voor monitoren (timeseries, metrics) van Kubernetes applicaties (en het platform zelf). Het maakt daarbij gebruik van dashboards als Grafana en kan koppelen met allerhande alerting mechanismen. Prometheus is echter “explicitely not solving distributed storage of metrics.” Om die reden heeft Uber M3 gebouwd: “built to scale horizontally” en “very cost effective”. Met als opmerking dat niet iedereen Uber is, dus niet iedereen heeft dit per definitie nodig.
“We had a lot of legacy applications using Graphite”, stelt Rob. Een goed voorbeeld van hoe in deze wereld tegen legacy wordt aangekeken. Legacy, dat is niet Cobol of Fortran, maar een applicatie die vorig jaar is gebouwd.
M3 is voornamelijk een oplossing om grote hoeveelheden metrics uit verschillende zones die Prometheus gebruikt, voor langere perioden op te slaan. Een M3 coordinator dient als proxy tusen Prometheus en de M3DB, waarmee data wordt opgeslagen maar die ook als toegangspunt dient voor Grafana om te queryen. Het voordeel daarvan is dat Prometheus wordt ontlast. M3 in meerdere regio’s uitrollen is een kwestie van een load balancer voor de verschillende coordinators plaatsen.
Uber heeft 4.000 microservices. Het monitoren daarvan kan alleen volledig geautomatiseerd met een goed horizontaal schaalbaar systeem. Het is niet nodig om iets in te stellen om te beginnen met monitoren van een nieuwe microservice, en uitbreiden van M3 is zo eenvoudig als het toevoegen van storage nodes.
De data die M3 oplevert wordt gebruikt voor real time analyses (rittijden, wachttijden, aantal ritten op specifieke plaatsen), maar ook voor analyses op het platform zelf – bijvoorbeeld temperatuur van devices en latency tussen zones. Het gaat dan om miljarden metrics. Queryen van de onderliggende nodes gaat in parallel. Er is dus geen centrale dataset met een index op een enkele node – bij de hoeveelheden data waar Uber mee werkt, is dat niet meer mogelijk. Uber heeft hier een speciale library (FST) voor gebouwd, gebaseerd op regular expressions en vergelijkbaar met hoe Apache Lucene met queries omgaat. Uiteraard zijn de noodzakelijke aanpassingen teruggegeven aan de community.