🦄 Chasing Traces Like Unicorns: Implementing OpenTelemetry in Angular

Once upon a time in a land of frontend chaos, brave developers struggled to find what the f*** was going wrong in production. Errors were like wild beasts — appearing, disappearing, teleporting across services — and no brave knight had the weapon to trace them properly.

Enter the majestic beast: OpenTelemetry 🪄✨

🧚‍♀️ What is OpenTelemetry?

OpenTelemetry is your enchanted toolkit for collecting traces, metrics, and logs from your applications. Think of it as the unicorn horn that pierces through the fog of frontend confusion, giving you a full map of your app’s behavior from browser to backend and back.

With OpenTelemetry, you're not just logging errors. You're tracing user journeys, seeing which spells (requests) failed, and where the dragons (delays) hide.

🌈 Why Should Frontend Devs Care?

Let’s be honest. Frontend apps are the glittering princess castles of software — they look good, but the plumbing underneath can get ugly fast. Crashes, slow fetch calls, ghost clicks — they all become a nightmare to debug without observability.

Using OpenTelemetry on the frontend:

1. Helps trace issues from UI to backend services
2. Gives performance insights for requests & user interactions
3. Enables correlation of logs with actual user actions
4. Makes you look like a goddamn wizard 🧙‍♀️ in your team

🦄✨ Installing the Magic Dust

Before summoning unicorn-level observability, install the following OpenTelemetry packages. These are the stable, battle-tested versions:

npm install @opentelemetry/api@^1.9.0 \ @opentelemetry/instrumentation-fetch@^0.37.0 \ @opentelemetry/instrumentation-user-interaction@^0.46.0 \ @opentelemetry/instrumentation-xml-http-request@^0.201.1 \ @opentelemetry/resources@^2.0.1 \ @opentelemetry/sdk-trace-web@^1.8.0 \ @opentelemetry/semantic-conventions@^1.34.0 

Once installed, you’ve got everything you need to spy on your app like a sassy fairy with a magnifying glass.

🧙‍♂️ OpenTelemetry Service: Your Spellbook

Create a magical Angular service to initialize the spellbinding observability:

// src/app/core/telemetry/open-telemetry.service.ts import { Injectable } from '@angular/core'; import { defaultResource, resourceFromAttributes } from '@opentelemetry/resources'; import { ATTR_SERVICE_NAME } from '@opentelemetry/semantic-conventions'; import { ConsoleSpanExporter } from '@opentelemetry/sdk-trace-base'; import { BatchSpanProcessor, SpanExporter, WebTracerProvider } from '@opentelemetry/sdk-trace-web'; import { FetchInstrumentation } from '@opentelemetry/instrumentation-fetch'; import { XMLHttpRequestInstrumentation } from '@opentelemetry/instrumentation-xml-http-request'; import { UserInteractionInstrumentation } from '@opentelemetry/instrumentation-user-interaction'; import { registerInstrumentations } from '@opentelemetry/instrumentation'; import { environment } from '../../../environments/environment'; @Injectable({ providedIn: 'root' }) export class OpenTelemetryService { constructor() { this.initializeOpenTelemetry(); } private initializeOpenTelemetry(): void { const resource = defaultResource().merge( resourceFromAttributes({ [ATTR_SERVICE_NAME]: 'unicorn-frontend', }) ); const spanProcessors = []; if (!environment.production) { spanProcessors.push( new BatchSpanProcessor(new ConsoleSpanExporter() as unknown as SpanExporter) ); } const provider = new WebTracerProvider({ resource, spanProcessors }); provider.register(); registerInstrumentations({ instrumentations: [ new FetchInstrumentation({ propagateTraceHeaderCorsUrls: /.*/ }), new XMLHttpRequestInstrumentation(), new UserInteractionInstrumentation(), ], }); } } 

🌟 Personal opinion from a tired fairy dev: ConsoleSpanExporter is noisy af. Like glitter in your eyes. You can still find traceId in headers — don’t clutter your logs unless you want full chaos mode.

⚙️ Initialize Tracing in App Module

Add the following initialization logic so that the magic spell is cast before the app even begins:

export const initializeTracing = (tracingService: OpenTelemetryService) => (): void => { // Tracing initializes in the constructor }; export const appInitializerFactory = (tracingService: OpenTelemetryService) => async () => { initializeTracing(tracingService)(); }; { provide: APP_INITIALIZER, useFactory: appInitializerFactory, deps: [OpenTelemetryService], multi: true, } 

🔮 Add Trace Info to NGINX Logs (Because Even Servers Need Fairy Dust)

Why is this important?
Because logs aren’t just backend noise - they're gold when you want to trace issues or monitor behavior across systems. Services like Splunk Cloud thrive on structured, rich logs.

With this setup, you:

1. Extract trace and span IDs from the traceparent header
2. Customize what data appears in your logs
3. Format it all into clean JSON
4. And as a bonus? Add emojis to make them stand out 🌈😈

🔥 Sample NGINX Config Snippet

Add this at the top of your config file (default.conf.template, etc.):

map $http_traceparent $trace_id { ~^(dd)-([0-9a-f]{32})-([0-9a-f]{16})-(dd)$ $2; default -; } map $http_traceparent $span_id { ~^(dd)-([0-9a-f]{32})-([0-9a-f]{16})-(dd)$ $3; default -; } log_format with_trace escape=json '{' '"🕒timestamp":"$time_iso8601",' '"💋httpUserAgent":"$http_user_agent",' '"💌request":"$request",' '"💅status":"$status",' '"💖traceId":"$trace_id",' '"🎀spanId":"$span_id"' '}'; 

🐉 Direct Logs to Standard Output

Want your logs to fly straight into the rainbow without clutter? Add this:

access_log /dev/stdout with_trace; error_log /dev/stdout error; 

No more dark caves of error.log. Trace IDs will light your path like fairy lanterns 🧚.

🏁 The Final Word from the Unicorn Queen

Using OpenTelemetry in frontend apps isn’t just for backend folks or infra wizards. You, the enchanted JS slinger, can now trace like a beast and debug like royalty. Don’t just chase bugs — track their exact path through the kingdom.

Stay magical. Stay traced. Stay fabulous.