The services feature allows you to group transactions into different sets that belong together and get aggregated together in their own chart and overall response time.
When your project is a combination of multiple services combined with CLI scripts or workers running in different contexts, then having just one aggregated chart with just one response time can distort your view of the real picture. The response times, request numbers and failure rates are aggregated by comparing apples with oranges.
Services can be switched from the top level navigation of any project. Depending on the number ofservices in a project you see an expanded selector or a dropdown:
Services allow for a project to differentiate between different types of users. Depending on the purpose of your project, this distinction may be helpful,_or it may be critical. This is because it’s only when the group of users is uniform (e.g., a shop’s end-users vs its backend administrators) is the aggregated data meaningful.
Why? When a project is composed of multiple services (such as micro services and different user types) combined with CLI scripts and workers running in different contexts, having just one aggregated chart can distort the perception of how the project is working. This is because the needs and timing of regular users are notably different from backend, administration-type, users.
If, for example the performance of backend transactions are slower than for regular users, that may be entirely acceptable. However, for regular users, slow transaction response times can mean the difference between a successful purchase and abandoning a cart for another online shop.
By aggregating them together, neither could be distinguished from the other. You couldn’t discern if the frontend response times were higher than they should be, or backend response times were unnaturally low. By using multiple services, the information stored becomes far more meaningful.