You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We're taking a closer look at how we can improve the way applications and services are defined and interact within Sentry. Our goal is to streamline your navigation experience and reduce the effort it takes to get cross-service insights from Sentry
The Challenge We See
We've identified a few key challenges in our current model:
Project Setup Complexity: Setting up projects for each service can quickly get tedious because you need to create a project, get a unique DSN and then setup the right alert rules, inbound filters etc for each project
Fragmented View of Applications: With applications often split into separate projects, it's challenging to get a unified view of your application's health - you’re often grappling with our project selector
Difficulty in Connecting problems: Performance problems in one part of an application can be caused by a problem far away. For example a front-end service is slow because the API endpoints supporting it are slow. It's tedious to find such connections today.
What we’re proposing
We're considering a new model that treats your entire application more holistically. This model centers around Applications and Services, aiming to simplify how you monitor apps via Sentry.
Services are entities that respond to any internal or external request. They would be automatically discovered by Sentry or defined by you via a service identifier
Applications are more subjective - they should be the overarching structure, encompassing the services that make up your application. This includes everything from front-end components to backend services, managed under a single DSN for easier setup and maintenance.
One model we're considering would let you send service data to the correct app simply by using the App’s single DSN without needing to create any projects.
Applications can evolve as your teams grow, for e.g. the following is a map of an app:
This app has 5 services BUT as the teams grow, they could have mapped these services as separate apps too:
We Need Your Insights!
Applications and Services are very often subjective constructs so your feedback is very valuable. We’d love to hear from you on the following topics:
Your Definition of Applications and Services: How do you currently define an 'application' vs. a 'service' within your workflow? Does this distinction matter to you?
Data Correlation: What challenges have you faced in correlating data across different parts of your application? What would make this easier?
On-boarding and Configuration: How do you envision an ideal setup process for new projects in Sentry? What could simplify this for you?
Navigation and Incident Investigation: How do you currently navigate between different parts of your application in Sentry? How could this experience be improved?
Team and Ownership Boundaries: How do you manage team boundaries and ownership within Sentry? What tools would help you model your organization’s structure more naturally?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
We're taking a closer look at how we can improve the way applications and services are defined and interact within Sentry. Our goal is to streamline your navigation experience and reduce the effort it takes to get cross-service insights from Sentry
The Challenge We See
We've identified a few key challenges in our current model:
What we’re proposing
We're considering a new model that treats your entire application more holistically. This model centers around Applications and Services, aiming to simplify how you monitor apps via Sentry.
Services are entities that respond to any internal or external request. They would be automatically discovered by Sentry or defined by you via a service identifier
Applications are more subjective - they should be the overarching structure, encompassing the services that make up your application. This includes everything from front-end components to backend services, managed under a single DSN for easier setup and maintenance.
One model we're considering would let you send service data to the correct app simply by using the App’s single DSN without needing to create any projects.
Applications can evolve as your teams grow, for e.g. the following is a map of an app:
This app has 5 services BUT as the teams grow, they could have mapped these services as separate apps too:
We Need Your Insights!
Applications and Services are very often subjective constructs so your feedback is very valuable. We’d love to hear from you on the following topics:
Beta Was this translation helpful? Give feedback.
All reactions