Open StephanSalas opened 1 week ago
We already have a httpcheck receiver. Playwright seems to involve node.js. Do you know of a way to conduct synthetics tests in Go?
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:
Feel free to come to a SIG meeting to present your ideas.
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...
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:
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
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?