Byggde egen felövervakning och OpenTelemetry‑spårning i stället för att köpa dem — sanering av nyttolaster, upptäckt av toppar och regressioner, symbolisering och ett syntetiskt hjärtslag — bakom 11 operatörsvyer.

Situation. Skillnaden mellan en plattform som är uppe och en plattform som fungerar är om någon alls skulle få veta det. Ett fel som en användare stöter på klockan elva på kvällen, på en sida som ingen testar, är osynligt om inte något går och samlar in det. Det vanliga svaret är att köpa en hostad felspårningstjänst, vilket är ett bra svar — och det innebär också att plattformens egna fel, stackspår och användarkontext går vidare till en tredje part.

Uppgift. Fel och spårdata måste samlas in, grupperas och göras möjliga att åtgärda, utan att plattformens inre lämnade plattformen.

Handling. Två delar byggdes. OpenTelemetry sköter spårningen över OTLP, så att ett långsamt anrop kan följas genom frontenden, API:t och databasen i stället för att gissas fram. Bredvid den finns en egenutvecklad felpipeline — en errmon‑tjänst och en ingest‑tjänst — som sanerar nyttolaster före lagring, grupperar fel till återkommande problem i stället för en platt lista, upptäcker toppar och regressioner med en karenstid så att en dålig driftsättning inte larmar någon fyrtio gånger, översätter minifierade stackspår från frontenden tillbaka till läsbar kod och kör ett syntetiskt hjärtslag för att bevisa att pipelinen själv lever. Allt hamnar i databasen som felhändelser, felgrupper, en inkorg, API‑latens och stackprov, och det presenteras i 11 operatörsvyer, däribland en för servicenivåmål.

Resultat. Fel blir en kö som någon kan beta av, och en regression gör sig till känna i stället för att upptäckas av en användare. Att bygga i stället för att köpa kostade verklig tid och innebär att det är ännu en sak att underhålla — en köpt felspårare hade varit igång samma eftermiddag. Det man fick i gengäld var att inget känsligt lämnar plattformen, och att larmreglerna passar den här plattformen i stället för en generisk.