Transaction name should be "<METHOD> unknown route" when no automatic/configured name

[SergeyKleyman]

From https://github.com/elastic/apm/blob/master/specs/agents/tracing-instrumentation-http.md#http-transactions

In case a name cannot be automatically determined, and a custom name has not been provided by other means, the transaction should be named unknown route, e.g. POST unknown route. This would normally also apply to requests to unknown endpoints, e.g. the transaction for the request GET /this/path/does/not/exist would be named GET unknown route, whereas the transaction for the request GET /users/123 would still be named GET /users/{id} even if the id 123 did not match any known user and the request resulted in a 404.

I think we should implement #136 (Configuration option: USE_PATH_AS_TRANSACTION_NAME) and #137 (Configuration option: URL_GROUPS) first to provide users with ability to fallback to the current behavior (transaction name as " "). Implementing transaction naming based on the route will require large effort even only for top 5 most popular PHP web frameworks.

[felixbarny]

Implementing transaction naming based on the route will require large effort even only for top 5 most popular PHP web frameworks.

Besides transaction naming, what else would supporting a web framework, like Laravel, include?

How much effort would it be to just support Laravel to start with?

Another alternative would be to auto-detect dynamic parts of the URL

• With heuristics, similar to how the RUM agent is doing it nowadays: feat(rum): categorize transactions based on current url apm-agent-rum-js#827
• Detecting the high-cardinality parts of a URL by analyzing the tree structure of the path: https://github.com/eyalkoren/warehouse

[SergeyKleyman]

I didn't do extensive investigation of this area yet but at the moment I think supporting Laravel would include the following features:

1. Capture route info to derive transaction name
2. Discover service name/version
3. Capture user info for transaction's context.user (although it might be worth investigating if it's possible to capture user info in some centralized not framework-specific way)
4. Detect if request completed with an error (for example whether exception escaped from top level application specific code into framework code)