Opbeans: implement randomized distributed tracing about apm-integration-testing HOT 8 CLOSED

For reference, here's how we have split up /api/* into its own service for opbeans-node: elastic/opbeans-node#36

To be frank, I'd prefer if you reverted that once we have this thing going. It'll be confusing why transactions/traces from opbeans-node look slightly different than everybody else

from apm-integration-testing.

For good measure: What are the standard endpoints in /api?

/api/stats
/api/products
/api/products/:id
/api/products/top
/api/products/customers
/api/types
/api/types/:id
/api/customers
/api/customers/:id
/api/orders
/api/orders/:id

# bonus curve ball: 
POST /api/orders

from apm-integration-testing.

For reference, here's how we have split up /api/* into its own service for opbeans-node: elastic/opbeans-node#36

from apm-integration-testing.

What percentage should be used when flipping a coin? 50%?
Should it be a parameter so we can tune for longer traces if needed?

from apm-integration-testing.

opbeans-node have the following HTTP endpoints:

• GET /is-it-coffee-time - Not called by the UI and probably unique to opbeans-node
• GET /log-error - Not called by the UI and probably unique to opbeans-node
• GET /log-message - Not called by the UI and probably unique to opbeans-node
• GET /throw-error - Not called by the UI and probably unique to opbeans-node
• GET /throw-async-error - Not called by the UI and probably unique to opbeans-node
• GET /api/stats
• GET /api/products
• GET /api/products/top
• GET /api/products/:id
• GET /api/products/:id/customers
• GET /api/types
• GET /api/types/:id
• GET /api/customers
• POST /api/customers - This one is so far special to opbeans-node and isn't used by the UI yet
• GET /api/customers/:id
• GET /api/orders
• POST /api/orders - This one isn't used by the UI, but by the workload script
• GET /api/orders/:id
• GET /* - Catch all that doesn't match any of the above. Used to serve static files to the frontend

from apm-integration-testing.

@beniwohli On the other hand, this removes the issue of recursion. If all opbeans-* exposed two services like this, the other opbeans-* could just call that one to not trigger the random proxy again. That way we'd not have an infinite loop of proxy calls 😅

But I'm not sure how easy it is for other languages to host multiple services in the same container like we do for opbeans-node

from apm-integration-testing.

For this first iteration I would keep it simple, the odds of a very long trace are very low.

from apm-integration-testing.

@elastic/apm-agent-devs thanks for doing this in record time. Closing the issue

from apm-integration-testing.