otel-browser

Name: otel-browser
Author: ollygarden

69stars6forks

How to install otel-browser?

ollygarden/opentelemetry-agent-skills/otel-browser

$npx -y skills add ollygarden/opentelemetry-agent-skills --skill otel-browser

Installs into the current project.

Summary

OpenTelemetry in the browser (Real User Monitoring / RUM) — capturing page loads, Core Web Vitals, route changes, clicks, console output, and JavaScript errors, and connecting frontend telemetry to backend traces. Covers the web tracing SDK (sdk-trace-web, context-zone), the expe

Files · 1

View on GitHub

SKILL.md

1	# OpenTelemetry in the Browser (RUM)
2
3	Entry point for OpenTelemetry mechanics in web apps. Load a reference below based on the task;
4	each reference is self-contained.
5
6	> Stability: Browser/RUM is one of the newest and most experimental areas of OpenTelemetry.
7	> Within the RUM packages covered here, the web tracing primitives
8	> (`@opentelemetry/sdk-trace-web`, `@opentelemetry/context-zone`) and the JS API are stable today.
9	> The Browser SDK (`@opentelemetry/browser-sdk`) and the event-based instrumentations are
10	> experimental and may break between minor versions — pin exact versions. Verify current status
11	> via the Sources of Truth below.
12
13	## References
14
15	\| File \| Use when \|
16	\|---\|---\|
17	\| [`references/setup-sdk.md`](references/setup-sdk.md) \| Wiring up the SDK: the direct providers (`WebTracerProvider` + `ZoneContextManager` for spans; `LoggerProvider` for events) vs the experimental `browser-sdk`, sessions, frontend→backend `traceparent`/CORS propagation, and why a Collector sits in front. \|
18	\| [`references/instrumentation.md`](references/instrumentation.md) \| Choosing and configuring instrumentations: the event-based catalog (navigation, web vitals, console, errors, …), the span-based catalog (fetch, XHR, document-load, long-task, …), per-instrumentation options, and what each captures. \|
19	\| [`references/performance.md`](references/performance.md) \| Keeping it cheap, fast, and private: bundle size, bounded main-thread work, page-lifecycle flushing, telemetry volume/cost, and PII vectors. \|
20
21	## Two telemetry models — read first
22
23	The experimental Browser SDK currently models browser telemetry as spans and events; it
24	does not include metrics. The general JS `MeterProvider` and OTLP/HTTP metrics exporter do support
25	browser builds, but metrics are outside this RUM catalog. Picking the right model for the signals
26	covered here is the first decision:
27
28	\| Model \| Signal \| For \| Examples \|
29	\|---\|---\|---\|---\|
30	\| Events \| Logs API → `LogRecord` \| point-in-time facts (no duration/children) \| web vitals, navigation, console, errors, user action \|
31	\| Spans \| Trace API \| operations with a duration and parent/child \| `fetch`, XHR, document load, long task \|
32
33	## Verify attributes against released semantic conventions before hand-rolling
34
35	Not every browser signal has a released convention yet — e.g. `browser.web_vital` is a released
36	development-stability event, but `browser.navigation` and `browser.resource_timing` have no
37	released convention under the `browser` group, and `exception` is a released stable group of
38	its own (not under `browser`). Check coverage per signal rather than assuming it; before emitting a
39	hand-written span or `LogRecord` with custom attributes:
40
41	1. Prefer a catalog instrumentation from [`references/instrumentation.md`](references/instrumentation.md), then verify its
42	released output shape against the convention; experimental implementations can lag a merged
43	convention (the released Web Vitals package currently does).
44	2. Check whether a released convention covers the signal: use the `otel-semantic-conventions`
45	skill to query the relevant group (e.g. `browser` for `event.browser.web_vital`, `exceptions`
46	for `exception.type`), or WebFetch the matching page under
47	`https://opentelemetry.io/docs/specs/semconv/browser/`.
48	3. If one exists, use its event, body-field, and attribute names verbatim (e.g. the
49	`browser.web_vital` event's required map body has `name`, `value`, `delta`, and `id`), even at
50	development stability. If none exists, define bounded, low-cardinality custom attributes under
51	a stable namespace instead of guessing at a released-looking name.
52
53	## The browser package ecosystem — three repositories
54
55	Browser packages are spread across three upstream repos. The
56	[`opentelemetry-browser` README "Browser Packages" tables](https://github.com/open-telemetry/opentelemetry-browser#browser-packages)
57	are the authoritative, current map. Summary:
58
59	\| Package \| Repo \| Model \| Stability \|
60	\|---\|---\|---\|---\|
61	\| `@opentelemetry/sdk-trace-web` \| opentelemetry-js \| SDK (spans) \| stable \|
62	\| `@opentelemetry/context-zone` \| opentelemetry-js \| context \| stable \|
63	\| `@opentelemetry/instrumentation-fetch` \| opentel

People who liked this also viewed

6 picks

Type

otel-browser

69stars6forks

View on GitHub

How to install otel-browser?

ollygarden/opentelemetry-agent-skills/otel-browser

$npx -y skills add ollygarden/opentelemetry-agent-skills --skill otel-browser

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# OpenTelemetry in the Browser (RUM)
2
3	Entry point for OpenTelemetry mechanics in web apps. Load a reference below based on the task;
4	each reference is self-contained.
5
6	> Stability: Browser/RUM is one of the newest and most experimental areas of OpenTelemetry.
7	> Within the RUM packages covered here, the web tracing primitives
8	> (`@opentelemetry/sdk-trace-web`, `@opentelemetry/context-zone`) and the JS API are stable today.
9	> The Browser SDK (`@opentelemetry/browser-sdk`) and the event-based instrumentations are
10	> experimental and may break between minor versions — pin exact versions. Verify current status
11	> via the Sources of Truth below.
12
13	## References
14
15	\| File \| Use when \|
16	\|---\|---\|
17	\| [`references/setup-sdk.md`](references/setup-sdk.md) \| Wiring up the SDK: the direct providers (`WebTracerProvider` + `ZoneContextManager` for spans; `LoggerProvider` for events) vs the experimental `browser-sdk`, sessions, frontend→backend `traceparent`/CORS propagation, and why a Collector sits in front. \|
18	\| [`references/instrumentation.md`](references/instrumentation.md) \| Choosing and configuring instrumentations: the event-based catalog (navigation, web vitals, console, errors, …), the span-based catalog (fetch, XHR, document-load, long-task, …), per-instrumentation options, and what each captures. \|
19	\| [`references/performance.md`](references/performance.md) \| Keeping it cheap, fast, and private: bundle size, bounded main-thread work, page-lifecycle flushing, telemetry volume/cost, and PII vectors. \|
20
21	## Two telemetry models — read first
22
23	The experimental Browser SDK currently models browser telemetry as spans and events; it
24	does not include metrics. The general JS `MeterProvider` and OTLP/HTTP metrics exporter do support
25	browser builds, but metrics are outside this RUM catalog. Picking the right model for the signals
26	covered here is the first decision:
27
28	\| Model \| Signal \| For \| Examples \|
29	\|---\|---\|---\|---\|
30	\| Events \| Logs API → `LogRecord` \| point-in-time facts (no duration/children) \| web vitals, navigation, console, errors, user action \|
31	\| Spans \| Trace API \| operations with a duration and parent/child \| `fetch`, XHR, document load, long task \|
32
33	## Verify attributes against released semantic conventions before hand-rolling
34
35	Not every browser signal has a released convention yet — e.g. `browser.web_vital` is a released
36	development-stability event, but `browser.navigation` and `browser.resource_timing` have no
37	released convention under the `browser` group, and `exception` is a released stable group of
38	its own (not under `browser`). Check coverage per signal rather than assuming it; before emitting a
39	hand-written span or `LogRecord` with custom attributes:
40
41	1. Prefer a catalog instrumentation from [`references/instrumentation.md`](references/instrumentation.md), then verify its
42	released output shape against the convention; experimental implementations can lag a merged
43	convention (the released Web Vitals package currently does).
44	2. Check whether a released convention covers the signal: use the `otel-semantic-conventions`
45	skill to query the relevant group (e.g. `browser` for `event.browser.web_vital`, `exceptions`
46	for `exception.type`), or WebFetch the matching page under
47	`https://opentelemetry.io/docs/specs/semconv/browser/`.
48	3. If one exists, use its event, body-field, and attribute names verbatim (e.g. the
49	`browser.web_vital` event's required map body has `name`, `value`, `delta`, and `id`), even at
50	development stability. If none exists, define bounded, low-cardinality custom attributes under
51	a stable namespace instead of guessing at a released-looking name.
52
53	## The browser package ecosystem — three repositories
54
55	Browser packages are spread across three upstream repos. The
56	[`opentelemetry-browser` README "Browser Packages" tables](https://github.com/open-telemetry/opentelemetry-browser#browser-packages)
57	are the authoritative, current map. Summary:
58
59	\| Package \| Repo \| Model \| Stability \|
60	\|---\|---\|---\|---\|
61	\| `@opentelemetry/sdk-trace-web` \| opentelemetry-js \| SDK (spans) \| stable \|
62	\| `@opentelemetry/context-zone` \| opentelemetry-js \| context \| stable \|
63	\| `@opentelemetry/instrumentation-fetch` \| opentel

People who liked this also viewed

6 picks

Type