Application Monitoring 101: How to Configure Sentry (3 of 6)

Summary

This video provides an in-depth guide on configuring a Sentry project, emphasizing best practices for creating projects for different apps or services, and managing access through teams. It explains how to track releases by associating versions of your code with specific events, ensuring that errors are tied to the right release. The importance of using environments to organize errors by deployment context is also covered. Additionally, the deployment feature is highlighted to track when a release is deployed to production, helping teams manage and resolve issues efficiently across various stages of development.

Takeaways

• 😀 A project in Sentry is tied to a single app or codebase, and should follow a one-to-one ratio with the app it represents.
• 😀 For multiple apps or microservices, create separate projects for each. This helps ensure that errors are associated with the correct codebase.
• 😀 In a monolithic architecture, if there are multiple codebases or instances (e.g., API vs. web), create separate projects for each.
• 😀 For monolithic apps with a single codebase but different running instances, create separate projects for each instance (e.g., one for the API, one for the frontend).
• 😀 If you're concerned about too many alerts, use issue owners and alert routing to direct errors to the appropriate team or developer.
• 😀 Teams govern access to Sentry projects, and a member of a team can have access to multiple projects. Projects can also be shared across multiple teams.
• 😀 Releases in Sentry represent versions of code that are deployed. Tracking these releases helps identify issues specific to each version.
• 😀 To fully leverage Sentry's release features, set the release number in your SDK and integrate it with your build process using the Sentry CLI tool.
• 😀 When viewing a release, you can see new and resolved issues, file changes, commits, and the authors of those commits, providing detailed insights into each release.
• 😀 Environments should be specified when initializing your SDK to ensure that events are tied to the correct environment (e.g., production, staging).
• 😀 Avoid creating separate projects for each environment; instead, use environments to filter events within a single project for more efficient tracking.
• 😀 Use the deployments feature to track when releases are deployed, which is particularly useful for projects with frequent builds or deployments that aren't always to production.

Q & A

What is a project in Sentry, and why is it important?

A project in Sentry represents your app and serves as the container for events sent by your application. It is important because it ensures that the events, such as errors, from a specific app or service are properly tracked and grouped under the corresponding project.

When should you create a new project in Sentry?

You should create a new project for each unique application or microservice. For example, if you have multiple React apps or back-end microservices, each should have its own Sentry project. For monolithic architectures, create separate projects for different codebases or distinct instances, such as one for the API and another for web pages.

What is the role of the DSN key in Sentry project setup?

The DSN (Data Source Name) key is provided when creating a Sentry project. It is used to initialize the Sentry SDK in your codebase, ensuring that errors from the correct app or service are sent to the appropriate project in Sentry.

Can projects in Sentry be shared between teams?

Yes, projects in Sentry can be shared across multiple teams. A team in Sentry governs access to specific projects, and any member of a team can access the projects associated with that team.

What is a release in Sentry, and how does it relate to error tracking?

A release in Sentry represents a version of your code that has been deployed. It helps track which issues are associated with specific versions of your app, making it easier to identify whether an issue was introduced in a particular release.

How can you track releases in Sentry?

To track releases, set the release version when initializing the Sentry SDK and use Sentry's CLI tool during your build process. This enables tracking of commits, files changed, and other metadata associated with each release, allowing you to link errors with specific code changes.

What is the benefit of using Sentry's 'suspect commits' feature?

The 'suspect commits' feature allows you to identify which commits are most likely responsible for introducing an issue. By linking releases to commits, you can quickly trace issues back to specific changes in the codebase.

What are environments in Sentry, and why should you specify them when setting up the SDK?

Environments in Sentry (such as 'production' or 'staging') help you distinguish between different stages of deployment. Specifying environments when initializing the SDK ensures that events are properly associated with the correct environment, allowing for better filtering and management of issues.

Should you create separate projects for each environment in Sentry?

No, you should not create separate projects for each environment. A single project should represent your app across all environments (e.g., development, staging, production). Instead, use environment filters to view events by environment.

What are deployments in Sentry, and when should you use them?

Deployments in Sentry are used to track when a release is deployed to a specific environment, such as production. Deployments are useful for correlating issues with specific deployments, especially when releases are triggered by commits but not all commits are deployed immediately.

How do you set up and track deployments in Sentry?

To set up deployments in Sentry, use Sentry's deployment tagging feature. This can be done via the Sentry CLI or API to mark when a release is deployed, which helps track when specific releases go live and connect issues to deployment events.