Det går inte att förutse varenda problem under utveckling och test. Det kommer alltid att ske mer eller mindre problem i produktionsmiljön beroende på vilken typ av system det är och hur toleransen för fel ser ut. Därför är det näst intill omöjligt att uppnå helt problemfria driftscenarios. Konsekvensen att ha problem i produktion kan variera kraftigt beroende på hur förberedda man är. En övervakad IT-lösning där problem kan identifieras och åtgäras före användaren hinner drabbas av det är ett mycket viktigt redskap, och kan i många fall rädda upp en situation som annars kunnat leda till katastrof.
Jag har senaste tiden labbat med OpenTracing som är ett etablerat API som kan användas för att övervaka applikationer. Kort sammanfattat så är det en teknik för att spåra anropskedjor genom olika integrerade delar av ett system. En anropskedja som spårats i Jaeger kallas för trace, och varje trace består av ett eller flera span. Ett span kan vara vad som helst som man vill monitorera i applikationen, t ex ett kodblock eller externt anrop. Till span’et kopplas metainformation som t ex hur lång tid hur anropet tog, om anropet gick bra, applikations och serverinformation samt övrig info som utvecklaren själv väljer att monitorera.
Det går med andra ord att få fram information från anrop som hanteras via de monitorerade applikationerna där det går att se hur stor del av den totala svarstiden som gått åt i respektive del i anropskedjan. I Jaeger-Query går det att söka fram anropen baserat på period och vilken applikation man är intresserad av. Nedan är en bild på hur det kan se ut. Det sista span’et är expanderat där informationen visas, bl a där loggen “Log from within the code” är med:
I den monitorerade metoden getString nedan ser vi hur man explicit lägger till en logg för det aktuella span som anropet befinner sig i:
@RequestMapping("/singlerest")
String getString() {
tracer.activeSpan().log("Log from within the code");
stringComponent.getValue();
}
Arkitekturen ser ut så här. De monitorerade applikationerna rapporterar all information om spans och dess trace till Jaeger Agent, vilket senare skickas vidare till Jaeger Collector. Datat hamner sedan i Kafka vilken används som messaging bus för att kunna hantera peakar. Jaeger Ingestor läser ut informationen från mellanlagringen i Kafka och skriver ner det till databasen som i mitt fall i ElasticSearch. ElasticSearch är optimerad för att hantera stora datavolymer och dessutom göra det snabbt och sökbart. När datat väl är persisterat i databasen så kan man därifrån hänga på sin visualisering. Jag har valt Grafana i det här exemplet.
Grafana är ett kraftfullt visualiseringsverktyg där man kan bygga dashboards med widgets som visar dataunderlaget på olika sätt. För att ha något att visualisera så byggde jag ett enkelt lasttest i Loadcoder.
Jag lät även Jaeger monitorera lasttestets anrop. En fördel med ett sånt angreppssätt är att man har chans att fånga upp fel redan på klientsidan vilket man inte har om felet inträffar redan innan anropet når den första monitorerade applikationen.
Se bilden nedanför där jag satt upp en dashboard som visar felintensitet, lastbalansering mellan servrar, svarstider för anrop och belastning. Alla är helt anpassningsbart genom ElasticSearch Rest API därifrån all data hämtas.
Det är oerhört intressant att se när olika teknologier används tillsammans så här. Speciellt när allt är öppen källkod där det finns möjlighet att både titta på och bidra till de olika komponenterna.
Nu lite reflektioner!
Att bygga eget stöd för applikationsövervakning på det här viset har både sina fördelar och nackdelar/utmaningar. En lösning som jag kort beskriver ovan både saknar stöd för funktioner som man t ex kan förvänta sig från ett enterpriseverkyg, samtidigt som man behöver vara beredd på att koda vissa saker själv. Det finns heller ingen support att ringa om en incident skulle inträffa.
Å andra sidan så kan en egenbyggd open source-baserad lösning i många fall vara mer dynamisk och fri från begränsingar. I organisationer där man inte räds för att lägga driftansvar hos utvecklare så skulle det kunna vara en effektiv väg att gå.
Detta var en kort sammanfattning om min första spaning på Jaeger som teknikstöd för applikationsövervakning. Tills nästa blogginlägg kommer jag undersöka på vilka sätt man kan använda informationen under utveckling och drift.
Författare: Stefan Vahlgren
