New component: BrowserSyntheticCheck Receiver

[StephanSalas]

The purpose and use-cases of the new component

Purpose: Provide a way to perform synthetic browser testing, such as loading web pages, synthesizing clicks, and ensuring browser flows work as expected on a regular basis.

Use-Cases:

1. Browser functionality continuous validation
2. Certificate validation
3. Potential capturing of traces generated by browser synthetics for RUM

I would be personally for using https://github.com/microsoft/playwright (apache license) to run the browser checks, however other frameworks could be leveraged.

Example configuration for the component

receivers:
  browser_synthetic:
    check_interval: 5m
    timeout: 15s
    synthetic_scripts:
      - name: "Homepage availability"
        script: |
          async function run(page) {
            await page.goto('https://example.com');
            const title = await page.title();
            if (title !== 'Example Domain') throw new Error('Unexpected title');
          }
      - name: "Login flow"
        script: |
          async function run(page) {
            await page.goto('https://example.com/login');
            await page.fill('#username', 'user');
            await page.fill('#password', 'pass');
            await page.click('#login-button');
            await page.waitForSelector('#dashboard');
          }

Telemetry data types supported

Metrics to start. Logs can be a further addition.

We can start with availability metrics similar to [receiver/http check], and could expand from there. Many different performance-related metrics could be considered for this new Receiver.

Code Owner(s)

Looking for Code Owners, however I would be willing to write it and own it.

Sponsor (optional)

Looking for a sponsor.

Additional context

Elastic and other major Olly providers have this capability. Why not Otel contrib?

[atoulme]

We already have a httpcheck receiver. Playwright seems to involve node.js. Do you know of a way to conduct synthetics tests in Go?

[StephanSalas]

Hey @atoulme, that's a good question...

I was thinking of using the golang library for Playwrite (https://github.com/playwright-community/playwright-go). I have tried a few scenarios, however this still needs a proof of concept to be tried within the contrib context. I'll try and write a gist for it soon to prove this library's workability.

The only downside of this approach is that we would have to leverage the playwrite go <--> nodejs bridge. I'm not sure if this breaks any standards we have as a OSP, but will at least try it out.

The upside over just having a httpcheck receiver is more in-depth testing of the DOM-stack. We can check for click functionality and other events in the DOM, rather than just 200 - OK. I think this also lends itself to increased parity of Contrib with other O11y Providers such as:

1. https://github.com/elastic/synthetics
2. https://github.com/freshdesk/synthetic-monitoring
3. https://github.com/n-schilling/datadog-synthetic-scheduler

[atoulme]

Feel free to come to a SIG meeting to present your ideas.

[StephanSalas]

Will do, and I think probably the governance issue with this idea is the package size needed to accommodate the playwrite-go<--> nodejs bridge:

The bridge between Node.js and the other languages is basically a Node.js runtime combined with Playwright which gets shipped for each of these languages (around 50MB) and then communicates over stdio to send the relevant commands. This will also download the pre-compiled browsers.

Source: https://github.com/playwright-community/playwright-go?tab=readme-ov-file#how-does-it-work

This would blow up the size of this project's binary pretty significantly, and probably does need to be talked through in a SIG Meeting. However, even with this problem I still think this issue would be a valuable addition to the contrib ecosystem because of its intrinsic value (assuming contrib is indeed the correct place for it, and not as an independent & decoupled OTEL-compatible project). It just may need some thought on how we would package this new receiver (E.G: Could it be optional based on a feature flag of some sort?).

EDIT: Could this be an extended component / special Open Container Image we provide on top of OTEL Contrib? I think that would allow us to only package it when users need it. Will think this thru...