Monitor application errors with Sentry

Anton4J — Sun, 20 Dec 2020 17:19:32 +0000

How do you handle your application errors/exceptions❓

This is a question I often ask my colleagues. Surprisingly, but half of them answer that they have no dedicated procedure for such situations. That means that until customers contact the support and report the problem, they will be unaware of any issues. No need to mention that from a business perspective that might lead to customer loss.

Ask yourself this question and if you find that you fall into the same category, you might consider taking some actions

Sentry to the rescue❕

Sentry is a tool that takes application crashes and exceptions as first-class citizens, allowing you to manage the full crash lifecycle: from its occurrence till releasing a new version with the fix applied.

Sentry developers follow open-source philosophy, so you can run an instance on your premise. This option might come in handy if your application is highly secured or not allowed to access anything outside the private network. To simplify the deployment of Sentry, you can utilize the Docker image.

On the other hand, you might purchase a license and put off your shoulders the burden of supporting infrastructure.

Integration

Sentry claims to support 88 platforms. Here is how you can integrate Sentry into a Java application.

Your first step will be to register a new application on Sentry and obtain Data Source Name (DSN), which effectively the only required configuration property.

Manual integration

Although this integration option will require manual configuration as well as manual error push, you get full control of the process. With this option, it's up to you what data you would like to see in the error details on Sentry.

Sentry.init();
...
try {
     method()
} catch (Exception e) {
     Sentry.capture(e);
}

Logger integration

If you use Log4j2 or Logback logger, you have an option to integrate it into the logger configuration. Just describe the appender for error level and all error log events will be posted to Sentry

<configuration>

    <appender name="Sentry" class="io.sentry.logback.SentryAppender">
        <options>
            <dsn{{SENTRY_DSN}}</dsn>
        </options>
    </appender>

    <root level="ERROR">
...
        <appender-ref ref="Sentry" />
    </root>
</configuration>

Sprin Boot integration

Like many other modules pluggable into Spring, Sentry provides its own starter bundle, named sentry-spring-boot-starter. After including defining sentry.dsn property value, you are ready to post error data with Sentry.captureException(e)

Interface

Although to my eye Sentry interface looks a bit overloaded with features, it starts growing on you over time. After several days of usage, you will grasp its essential features.

Conclusion

Sentry is a great tool for monitor errors on any application stage. If this brief overview caught your interest, make sure to check out the official blog for a lot more details.

Why you shouldn't use AWS API Gateway HTTP API

Anton4J — Sun, 08 Nov 2020 18:48:28 +0000

Less than a year passed since AWS announced a new API type for API Gateway, namely HTTP API. Here I'd like to share my experience with HTTP API utilization.

Since AWS API Gateway has proved its efficiency (especially in serverless architecture), numerous projects adopted this AWS service. Following developers' requests, AWS gave us a chance to have a lighter experience with gateways configurations and support.

But did AWS cut off some of the useful features pursuing simplicity? In my opinion yes. Here are some of them:

1. Pass static data to API target

HTTP API Gateway has cut off the requests modifications on the way from a user to a target. And it seems to be a reasonable simplification. However, it would be very useful to have a way to pass some static data to the target.

For example imagine a scenario, when a target expects an HTTP header which will authorize a request as a one coming from API Gateway. Original API Gateway allowed certification authorization. But this feature is also gone for HTTP APIs.

2. Restrict access to API with policies

Resource policies when applied to API is a great tool for controlling access to the API. It gives the possibility for granular access definition. With several lines with configuration code, we can define which CIDR blocks, VPCs, or AWS accounts are allowed to send requests to the API.

For HTTP APIs it's not available. We are left to JWT, AWS Lambda, or IAM authorizers. They do the job with flying colors, but useless when access should be allowed only for a defined set of IP addresses.

3. AWS CLI interoperability

If you rely on AWS CLI for configurations, you will need to use a new V2 namespace for HTTP APIs. This might look like a pretty minor thing, but for me, it is not.

I rely on IaC modules for setting up an infrastructure. I use Terraform as an engine. With an introduction of the new CLI version, you cannot start using HTTP API just by updating the type attribute in the module definition. You need to describe your API anew.

4. Linking to Load Balancer

To access resources inside a private VPC, a VPC link needs to be defined. Only Application Load Balancers are supported for it. On the other hand, REST API Gateway type can be linked only to Network Load Balancer, which operates on a lower level of OSI model.

If you have NLB already defined, you won't be able to utilize it.

5. Usage plans

Original API Gateway allows configuring usage plans based on a key. You can issue an API key, defined a quota for it, and be sure that the key holder will not abuse your API. That's also not available for HTTP API.

Now let's take a look at some of the pros for HTTP APIs:

1. It's easy to use

To start with HTTP API Gateway, you just need to define a root and integration for it. That's it, you are good to go. No need to define integration requests, responses, etc.

2. It's cheaper

One of the most important selling points for HTTP API presented by Amazon is price:

Most customers will see an average cost saving up to 70%.

Conclusion

If your API is a simple one or you use API Gateway for prototyping, then I would definitely recommend HTTP API.
For production-grade APIs I decided to stick with the original type of API Gateway.

What is your opinion on that?

DEV Community: Anton4J

Monitor application errors with Sentry

How do you handle your application errors/exceptions❓

Sentry to the rescue❕

Integration

Manual integration

Logger integration

Sprin Boot integration

Interface

Conclusion

Why you shouldn't use AWS API Gateway HTTP API

1. Pass static data to API target

2. Restrict access to API with policies

3. AWS CLI interoperability

4. Linking to Load Balancer

5. Usage plans

1. It's easy to use

2. It's cheaper

Conclusion