Add browser traffic in loadgenerator and export traces in frontend

[jordibisbal8]

Changes

In this PR, we aim to add browser traffic using playwright (as discussed #1164). This PR should now solve the issue commented here that exports the traces for the frontend-web correctly. The main changes are:

• Installed playwright in the DockerFile
• Increase memory constraints for the load generator container to be able to run playwright for several concurrent users
• Added playwright user and two tasks in the locustfile. One goes to the /cart page and the others adds a product to the cart
• Added environment variable to enable browser traffic (false by default)
• Increased delay interval in milliseconds between two consecutive exports using scheduledDelayMillis

Update: Locust generates traffic by using the baggage header synthetic_request=true. By doing this, the frontend can correctly export the traces using the OTEL_COLLECTOR_NAME endpoint instead of using the not available localhost.

Merge Requirements

For new features contributions please make sure you have completed the following
essential items:

• CHANGELOG.md updated to document new feature additions
• Appropriate documentation updates in the docs
• Appropriate Helm chart updates in the [helm-charts][https://github.com/Added environment variable and increased memory limit of loadgenerator opentelemetry-helm-charts#1014]

Maintainers will not merge until the above have been completed. If you're unsure
which docs need to be changed ping the
@open-telemetry/demo-approvers.

[julianocosta89]

Hello @jordibisbal8,

I think I'm missing something here.
I've fetched your PR, re-built the loadgen and frontend, set the env var LOCUST_BROWSER_TRAFFIC_ENABLED=true and started the demo.
Waited some traffic and didn't get the service frontend-web in Jaeger.

When I manually navigated to the browser, I got it.

Did I miss something or am I understanding the PR wrongly?

[jordibisbal8]

Hello @jordibisbal8,

I think I'm missing something here. I've fetched your PR, re-built the loadgen and frontend, set the env var LOCUST_BROWSER_TRAFFIC_ENABLED=true and started the demo. Waited some traffic and didn't get the service frontend-web in Jaeger.

When I manually navigated to the browser, I got it.

Did I miss something or am I understanding the PR wrongly?

@danielgblanco helped me figure out the issue. We were testing it for k8s, where we use OTEL_COLLECTOR_NAME in the frontend code. However, it seems that for docker this variable does not exist.

I have pushed this commit, where we use OTEL_COLLECTOR_HOST for both k8s and docker. I have followed the same pattern used for the frontend-proxy here

Now trying it locally using docker, I can see the frontend-web traces in Jaeger. Could you please double-check it @julianocosta89? Thank you!

[puckpuck]

I tested your branch and got what I expected using a local docker compose deployment.

I really like the usage of the synthetic_request baggage element to drive which Collector to output to.

[julianocosta89]

@jordibisbal8 sorry for being the picky one 😅

I've tested and now I can see the frontend-web spans, but even though the you are setting the synthetic_request headers, you are not setting the span attributes and app.synthetic_request is set to false.

Would you be able to take a look?

[jordibisbal8]

@jordibisbal8 sorry for being the picky one 😅

I've tested and now I can see the frontend-web spans, but even though the you are setting the synthetic_request headers, you are not setting the span attributes and app.synthetic_request is set to false.

Would you be able to take a look?

No problem. Now that you mention it, I can see this happening as well.

After investigating it, the second spans in the frontend correctly contain the app.synthetic_request=true and the loadgenerator contains no attributes (same behaviour as we have for the non-web traffic from the loadgenerator). However, it looks like the first request (fetching) sets the attribute app.synthetic_request=false. This is happening due to the behaviour added in this PR

[jordibisbal8]

@jordibisbal8 sorry for being the picky one 😅
I've tested and now I can see the frontend-web spans, but even though the you are setting the synthetic_request headers, you are not setting the span attributes and app.synthetic_request is set to false.
Would you be able to take a look?

No problem. Now that you mention it, I can see this happening as well.

After investigating it, the second spans in the frontend correctly contain the app.synthetic_request=true and the loadgenerator contains no attributes (same behaviour as we have for the non-web traffic from the loadgenerator). However, it looks like the first request (fetching) sets the attribute app.synthetic_request=false. This is happening due to the behaviour added in this PR

As mentioned @julianocosta89, this was the issue. I have solved it in this last commit fd6bc27 by adding a window.env IS_SYNTHETIC_REQUEST that we can use in the FrontendTracer to not always set the span attribute app.synthetic_request=false. I have done it following this approach since the baggage data is not available in the FrontendTracer

[julianocosta89]

Thanks for the patience @jordibisbal8!
This is great!