Shared tooling and observability across the platform's services
A generated API client that several services share, structured logging followed by OpenTelemetry tracing across the core services, and one AI coding-agent setup in the team's repositories.
- TypeScript
- OpenTelemetry
- Structured logging
- agemon
- Step 1: Backend API
- Step 2: Generated client package
- Step 3: Versioned release
- Step 4: Services that use it
Context
The platform is split into several services that talk to the same backend. Each kept its own copy of the client code for that backend, and each logged in its own way, so following one problem across services meant reading each of them on its own terms.
My role
I built the parts listed below myself, alongside leading the team.
What I built and decided
- A generated, versioned API client package built from the backend, adopted by several services in place of their own duplicated client code.
- Structured logging across the core services, followed by OpenTelemetry tracing, so one request can be followed from service to service.
- agemon, my open-source tool, set up in several of the team's repositories, so AI coding agents work from the same rules and skills everywhere.
- In progress: an internal repository that collects the observability dashboards and checks them.
Outcome
Several services now share one client package instead of keeping their own copies, and the core services log and trace the same way. That is the boundary of the claim: no numbers yet on time saved or on how much faster problems are found.
What I'd do next
Finish the dashboard checks, then measure how long it takes to find the cause of a problem, so the value of tracing is shown rather than assumed.