Sentry is an application monitoring system, which can be used for online monitoring and error analysis of various technology stacks at the front and back end. This time we used it for online log analysis practice of Spring Boot project.

Create a project

First, you need to follow the prompts to create the project in Sentry. The project platform can be Spring Boot or Java.

Importing dependencies & configurations

Sentry provides an official Spring Boot Starter.

<dependency>
  <groupId>io.sentry</groupId>
  <artifactId>sentry-spring-boot-starter</artifactId>
  <version>3.1.1</version>
</dependency>
Copy the code

In addition, we need to configure application.properties to import the project key (DSN) we created in Sentry:

sentry.dsn=https://key@host/id
Copy the code

The first mistake

Write our Controller to try to throw a simple exception.

@RestController
public class HelloController {

  @RequestMapping("/")
  public void test(a) {
    throw new IllegalArgumentException("hello world"); }}Copy the code

If there is no problem with the previous configuration, then we can see this exception message in the “Issue” panel of Sentry.Click on the exception to see details. You can see some basic information about this exception, such as “user info (not set here)”, “user environment”, “Tag”, “StackTrace”, “Breadcrumbs”, “Request Headers”, And some user-definable content (called Context).Here’s a concept from Sentry. First, exceptions generated in the same place are summarized as an “Issue,” and each exception generated in that place is called an “Event.” So if you raise an exception twice in the same place, you still have only one Issue, but you can see two events on the Event page.

Customize user information

Now that we know about the exception, we also want to know which user triggered the exception. The Sentry SDK provides the SentryUserProvider, which can be used to provide user information in case of an exception. We only need to configure a Bean.

    @Bean
    public SentryUserProvider sentryUserProvider(a){
        return() - > {// The actual user information may be obtained by other means
            User user = new User();
            user.setId("userId");
            user.setUsername("Zhang");
            user.setEmail("[email protected]");

            return user;
        };
    }
Copy the code

The exception is raised again and we get the user information.

Customize tags to filter exceptions using tags

As the number of exceptions increases, we want to be able to filter out specific exceptions, and Sentry provides a “Tag” function to filter by Tag. We already have a lot of Tags, but we want to be able to customize them based on our business needs. Of course, the Sentry SDK provides BeforeSendCallback, which allows us to add Tags.

    @Bean
    public SentryOptions.BeforeSendCallback beforeSendCallback(a){
        return (event, hint) -> {
            event.setTag("name"."zhangsan");
            return event;
        };
    }
Copy the code

You can see that our Tag has been added successfully. Click on this Tag to find all events that contain this Tag.

Integration of Logback

Exception handling is probably covered in our existing Spring Boot service, and most exceptions are probably recorded directly as a log. Sentry also provides support for logging frameworks such as Logback/Log4j2. All you need to do is import the corresponding dependencies, using Logback as an example.

<dependency>
  <groupId>io.sentry</groupId>
  <artifactId>sentry-logback</artifactId>
  <version>3.1.1</version>
</dependency>
Copy the code

The Sentry Spring Boot Starter automatically detects dependencies and configures them for us, so we can simply throw logs instead of exceptions.

@RestController
public class HelloController {
    private static Logger logger = LoggerFactory.getLogger(HelloController.class);
    
    @RequestMapping("/")
    public void test(a){
        logger.error("Logback error!"); }}Copy the code

The interesting point here is that for unhandled wild exceptions, Sentry gives them a fatal level, and when Logback is introduced, logger’s log level is used.By configuring minimum-event-level and minimum-breadcrumb-level in the configuration file, you can specify which log levels will produce an “event” and which log levels will record a “Breadcrumbs”, Note that the logger level is lower than or equal to this level (otherwise it will not be collected).

sentry.logging.minimum-event-level=info
sentry.logging.minimum-breadcrumb-level=debug
Copy the code

Self-built Sentry

In addition to the official Sentry, you can also build a self-hosted version of Sentry. The official version has usage limits and may require a fee; There is no limit to the amount of the self-hosted version, but there is no official technical support. It’s also pretty easy to build your own Sentry, requiring Docker and Docker Compose, and at least 2.4g of free memory on hardware.

git clone https://github.com/getsentry/onpremise.git
cd onpremise
./install.sh
Copy the code

Then you can see the built-in Sentry on localhost:9000, which can be used with the Nginx reverse proxy to adjust the port to 80/443.

The official documentation

This article only introduces some of the common functions of Sentry. For more information about Sentry, refer to the official documentation: docs.sentry.io