Software Engineering

Errors happen everywhere

Do you know this scenario?

You run an online shop and advertise efficient order processing and fast shipping to the customer. In addition, you offer support for answering urgent customer inquiries via a hotline. A customer calls the hotline and asks when he can count on the delivery of his order. He had already recorded and ordered the order over a week ago in your shop. The support representative only recognizes in the system that the order hasn’t yet been delivered, but can’t identify the root cause of the issue. Internally, the request is forwarded to the second-level support. Now the exact analysis begins. The problem was caused by an error in an interface between two systems. Unfortunately, the occurrence of this error wasn’t logged or reported early. Efficient order processing looks different!

But how can you manage this situation in order to identify such problems at an early stage and react appropriately?

First of all, it is important to consider „fault tolerance“ as pattern early in the system design and to sensitize each developer accordingly. Ideally, the system is so robust that it can deal independently with different error scenarios, eg. by limiting the number of requests or retry mechanisms. There are a number of patterns, such as Circuit Breaker, and best practices to help designing a robust system. In addition, it makes sense to define and establish a central, uniform process for the management of errors that have occurred. For a central error management process, it is important that all relevant information be recorded so that an analysis of the situation can be done very quickly and promptly. When possible, searching in log files should be avoided. With a system is made available that makes it very easy to log and analyze errors. We use very successfully in several customer projects. In this blog post I would like to introduce with the most important functions. In subsequent blog posts I show the concrete use with two different infrastructures. is an open source platform for monitoring system errors. The platform enables logging of errors that occurred in real time, without the need to look into log files. Thus, the support and operations can act immediately after the occurrence of errors and perform error analysis. Problems are solved faster, which ultimately increases customer satisfaction. allows the notification to be configured over multiple channels, for example Email or SMS. Furthermore, it is not limited to any particular programming language or technology. The client API is provided in several programming languages:

    • Python
    • C#
    • JavaScript
    • Node.js
    • Java
    • Perl
    • PHP
    • Go

    Furthermore, can be easily integrated into existing applications using the underlying configured logging framework. The following integrations are available:

    • SLF4J
    • commons-logging

    In addition, sentry also offers interesting integration capabilities:

    • Bitbucket
    • Jira
    • Slack
    • Asana

    sentry automatically detects if the same error is reported multiple times. This can occur, for example, if retry mechanisms are used in the application and they repeatedly encounter the same error. In this case, only the number in the form of events in sentry is recorded. This greatly simplifies error management.

    The platform is available in two editions:

    Cloud: In this case, the costs are based on the number of recorded events. Additionally you get professional support.
    On-Premise: Sentry can be run locally as Docker container. According to license terms, you are responsible for the operation itself. Professional support is currently not available for this edition.
    By using the provided Docker container, sentry can be set up and tested locally in just a few minutes. Instructions can be found under Installation with Docker.

    Web UI

    sentry organizes issues in projects. Projects could be created according a specific subject matter or for particular application. It is also possible to limit the access for projects accordingly. Thus, the visibility of issues for accountability can be set very well. In addition, further settings can be made at the project level. The interface is based on a task or bug management and is therefore very easy to use.




Logger Integration

The simplest usage of sentry is to use the logging framework capabilities. The example below uses SLF4J in conjunction with Logback to transfer each recorded error to sentry.

1. Add all required libraries within the Maven project file (pom.xml):


Add SentryAppender within the logging configuration. Example: logback.xml

    <!-- Configure the Console appender -->
    <appender name="Console" class="ch.qos.logback.core.ConsoleAppender">
            <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>

    <!-- Configure the Sentry appender, overriding the logging threshold to the WARN level -->
    <appender name="Sentry" class="io.sentry.logback.SentryAppender">
        <filter class="ch.qos.logback.classic.filter.ThresholdFilter">

    <!-- Enable the Console and Sentry appenders, Console is provided as an example of a non-Sentry logger that is set to a different logging threshold -->
    <root level="INFO">
        <appender-ref ref="Console"></appender-ref>
        <appender-ref ref="Sentry"></appender-ref>

The configuration enforces the transfer of all warning messages and errors to sentry.

3. Configure connection data to sentry server:
The connection data is available as DSN (Data Source Name). It can be obtained within the project

There are several ways to configure the DSN within the application:

configuration file (Default:
Java System Properties (java -Dsentry.dsn=https://public:private@host:port/1 -jar app.jar)
Environment Variable (SENTRY_DSN=https://public:private@host:port/1)
API (Sentry.init(“https://public:private@host:port/1”)

4. Record an error to sentry:

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class FilesCleanupProcessor {
    private final Logger logger = LoggerFactory.getLogger(FilesCleanupProcessor.class);
    public void process(Exchange exchange) {
      try {
      catch (BusinessException ex) {
         logger.error("Could not cleanup allocated resources, because of {}.", ex);
         // Error will be transfered to sentry.

5. Add additional meta data to an error entry in sentry by using MDC tags:

MDC.put("customerNumber", "004711");
MDC.put("customerName", "Max Mustermann Ltd.");
logger.error("Could not cleanup allocated resources."");

MDC-Tags are stored as meta data in sentry. This meta data are available within the sentry web ui.

Integration with Java API

Add all required libraries within the Maven project file (pom.xml):


2. Configure connection data to sentry server:
The connection data is available as DSN (Data Source Name). It can be obtained within the project
settings. There are several ways to configure the DSN within the application:

configuration file (Default:
Java System Properties (java -Dsentry.dsn=https://public:private@host:port/1 -jar app.jar)
Environment Variable (SENTRY_DSN=https://public:private@host:port/1)
API (Sentry.init(“https://public:private@host:port/1”)




3. Basic usage of the API

sentry provides a Static and an Instance-API. It is recommended to use the Static-API. The
subsequent example shows an example of the Static-API.

Establishes a connection to sentry. It will use the configuration data from config file


Defines the user reporting this error:

Sentry.getContext().setUser(new UserBuilder().setUsername("max-mustermann").build());

Records the error message:

Sentry.capture("Testmessage send from SentryHelloWorld.");

4. Advanced usage of the API

Add additional meta data to further classify the error:

1Sentry.getContext().addTag("CustomerNumber", "004711");

Breadcrumbs are very suitable to record the action before the error:

                new BreadcrumbBuilder().setMessage("user-action-1").build()


sentry is a powerful tool for detecting errors in real time. It allows proactive detection and removal of errors. The integration via the used logging framework allows the use without additional programming. However, the SDK can better classify a potential error. The source code examples in this blog post can be found on github.