Daniel Fitzgerald, a Senior Solutions Consultant at New Relic, contributed to the demo project in this post.
Open-source monitoring has made it easier than ever to get metrics from any service. But if you’re not careful, all those metrics can quickly lead to data silos. The good news is that they don’t have to because you can bring all of your data, including telemetry data from open-source tools, together in New Relic One. This includes metrics data from services built on the Spring Boot framework. With the New Relic Micrometer registry, you can now use Spring Boot Micrometer metrics in New Relic One to monitor your services.
This post explains how the New Relic Micrometer registry works and how to install and use it to send metrics to New Relic from an example application.
About Micrometer and registries
Micrometer is a library for collecting metrics from JVM-based applications and services and is included in Spring Boot 2 and backported to Spring Boot 1.3+. If you use Spring Boot to write services, you automatically get metric instrumentation for many Spring Boot component libraries, including Spring MVC and RestTemplate latencies, cache utilization, datastore utilization, and many more.
In Micrometer, you collect metrics about your application using an interface called a Meter
. Meters, according to their documentation, are “created from and held in a MeterRegistry
.” You can then register one or more MeterRegistry
implementations to send metrics to a monitoring system, such as New Relic. This approach decouples your metric instrumentation from the metrics backend you use, and it lets you register multiple MeterRegistry
implementations to send the same metrics to multiple backends.
Understanding Spring Boot Micrometer metrics
Micrometer provides a powerful and flexible way to collect and expose application metrics in a standardized manner. It supports various metric types, including counters, gauges, timers, custom metrics, and distribution summaries. Let's explore each one in detail:
Counters
Counters are used to measure the number of occurrences of an event. They can only increase in value and are often used to track things like the number of requests processed or errors encountered.
Gauges
Gauges are instantaneous measurements of a value at a particular point in time. They can go up and down, and are useful for tracking values like memory usage or the size of a queue.
Timers
Timers are used to measure the duration of an event. They provide insights into the performance of specific operations, such as database queries or API calls.
Distribution summaries
Distribution summaries provide statistical information about a set of values, such as the mean, median, and percentiles. They are useful for understanding the distribution of response times or other continuous variables.
Custom metrics
Micrometer allows you to define and create your own custom metrics based on your specific application requirements. This helpful tool gives you the flexibility to track and monitor application-specific metrics that are important to you.
Spring Boot Micrometer tracing vs metrics
You need to differentiate between tracing and metrics when monitoring your Spring Boot application. While both provide valuable insights, they serve different purposes.
Tracing
Tracing allows you to understand the flow of a specific request as it traverses through different components of your application. It involves tracking individual requests or transactions as they flow through the various components of an application (and potentially across multiple services in a microservices architecture). Tracing provides a detailed, step-by-step view of what happens during a single request or operation. This includes:
- Latency: Time taken for each part of the process.
- Call flow: The path taken through the application or across services.
- Error analysis: Identifying at which point an error or bottleneck occurs.
With tracing, you can visualize the entire lifecycle of a request and pinpoint any areas that require optimization.
Metrics
On the other hand, metrics provide quantitative measurements of your application's performance, resource utilization, and behavior. Metrics are collected over time and can be aggregated and analyzed to gain a deeper understanding of your application's health and performance trends. By monitoring metrics, you can identify patterns, detect anomalies, and make data-driven decisions to optimize your application.
Category | Tracing | Metrics |
---|---|---|
Detail level | Provides a detailed, request-level view, showing the exact path and timing of operations. | Provides a higher-level, aggregated view of system performance and health. |
Purpose | Used for in-depth diagnosis and understanding specific transactions or errors. | Used for ongoing monitoring of the system’s state and performance. |
Scope | Focused and used for detailed analysis of particular issues or processes. | Give a broad picture suitable for long-term monitoring and alerting. |
Data nature | Captures qualitative, sequential data about request flows. | Captures quantitative, statistical data. |
Micrometer’s New Relic registry vs. New Relic’s Micrometer registry
If you’re familiar with Micrometer, you may have previously used the first version of the New Relic Micrometer registry included in the Micrometer project. That New Relic registry version sent metrics to New Relic Insights as events where you could use dashboards to visualize metrics.
This version of the registry uses New Relic’s new Telemetry platform which offers three essential capabilities:
- Native support for New Relic Dimensional metrics: All of the metrics sent via this registry go to New Relic’s metrics system where you can query them using metric-specific features rather than querying Insights events that the previous version created.
- Entities created from the Micrometer metrics: The metric payload includes the name of the service from where the metrics were generated. Using that name, New Relic creates a service entity that you can find in the entity explorer.
- A default overview that captures key Micrometer metrics: Now that the New Relic platform recognizes Spring Boot Micrometer metrics and creates a service entity for each service, you also get a curated dashboard with the key metrics for that service. You can use this as a starting point to build more complex dashboards that include information specific to your service.
How the New Relic Micrometer registry works
The New Relic Micrometer registry is built on the New Relic Java Telemetry SDK, an open source set of API client libraries that send your metric and trace data to the New Relic platform.
After you register the New Relic Micrometer MeterRegistry implementation in your application’s registry, it begins sending metrics to New Relic. New Relic observes the incoming metrics and automatically registers a service entity in New Relic’s entity system and creates a default overview page with key performance indicators like response time, throughput, error rate, and system metrics like CPU utilization and other JVM metrics.
You can choose to use the New Relic Micrometer registry as a standalone, lightweight approach to monitoring Spring Boot applications, or you can also use the Micrometer registry alongside the New Relic Java agent.
Getting started with the New Relic Micrometer registry
Setting up the New Relic Micrometer registry to send your Spring Boot Micrometer metrics to New Relic is relatively straightforward. You can find full implementation details in the project’s GitHub README.
You can use the registry within a Spring Boot application or in any application that uses micrometer for recording metrics. Note that to send metrics to New Relic, you’ll need an Insert API key.
- To add the New Relic Micrometer dependency to your project, choose one of the following methods:
- Via Gradle
implementation 'com.newrelic.telemetry:micrometer-registry-new-relic:0.5.0'
- Via Maven
<dependency> <groupId>com.newrelic.telemetry</groupId> <artifactId>micrometer-registry-new-relic</artifactId> <version>0.5.0</version> </dependency>
- Via Gradle
- Register the
io.micrometer.newrelic.NewRelicRegistry
. To do so, you’ll need to create anio.micrometer.NewRelicRegistryConfig
.See the Spring-Config-Example for full implementation details.
Example: Use the New Relic Micrometer registry with the Spring Pet Clinic Microservices Demo
The Spring Pet Clinic Microservices Demo is a popular demo application that showcases a way to build a containerized Spring Boot microservices application. It includes Prometheus and Grafana for storing and visualizing Micrometer metrics as well as Zipkin to store and view distributed traces.
In the following steps, we’ll add the New Relic Micrometer registry to one of the microservices and see what the experience looks like in New Relic.
Prerequisites
- Download or clone the Spring Boot Spring Boot Microservices Demo project. You’ll find the source code and supporting files for seven services that make up the demo application.
- You’ll need your Insert API key.
- You’ll need Docker on your system.
Note: You can view the source code for the completed project in this repository.
Step 1. Configure the API Gateway service to send metrics to New Relic
- Add the New Relic Micrometer registry dependency. Navigate to
[project-folder]/spring-petclinic-api-gateway/pom.xml
and add the following to the<dependencies>
block:
<!-- New Relic Micrometer metrics --> <dependency> <groupId>com.newrelic.telemetry</groupId> <artifactId>micrometer-registry-new-relic</artifactId> <version>0.5.0</version> </dependency>
- In
[project-folder]/spring-petclinic-api-gateway/src/main/java/org/springframework/samples/petclinic
, create a new directory namednewrelic
. - In the newrelic directory, create a new file named
MicrometerConfig.java
. - Copy the contents of the
MicrometerConfig.java
from my repo into your version of MicrometerConfig.java.This class uses the Spring Boot auto-configuration annotations to register the New Relic Micrometer registry.
Step 2. Modify the Spring Boot application to scan for our new autoconfigured class
- Open and edit the following file:
[project-folder]/spring-petclinic-api-gateway/src/main/java/org/springframework/samples/petclinic/api/ApiGatewayApplication.java
- Find the
@SpringBootApplication
annotation, and modify it to scan for our class:@SpringBootApplication(scanBasePackages = {"org.springframework.samples.petclinic"})
Step 3. Modify the build to include the Insert API Key and Metric API URI
- Modify the top-level
pom.xml
to include the build arguments we need to pass as environment variables to the running containers. Navigate to[project-folder]/pom.xml, and in the <buildArgs>
block add the following new arguments:
<NR_INSERT_API_KEY>${env.NR_INSERT_API_KEY}</NR_INSERT_API_KEY> <NR_METRIC_URI>${env.NR_METRIC_URI}</NR_METRIC_URI>
- Modify Dockerfile to add the environment variables we need. Navigate to
[project-folder]/docker/Dockerfile
, and after the line withENV SPRING_PROFILES_ACTIVE docker
command, add the following to make the environment variables available to the running container:
# Configure New Relic API key and endpoints ARG NR_INSERT_API_KEY ENV NR_INSERT_API_KEY=${NR_INSERT_API_KEY} ARG NR_METRIC_URI ENV NR_METRIC_URI=${NR_METRIC_URI}
Step 4. Build and run the project
- Set the environment variables and use Maven to build the project.
Modify the following command to use your own Insert API Key. You can change the Metric URI value to use the EU region URI:
NR_INSERT_API_KEY=[YOUR INSERT API KEY HERE] \ NR_METRIC_URI=https://metric-api.newrelic.com/metric/v1 \ ./mvnw clean install -PbuildDocker
- Run the project using Docker compose:
docker-compose up
It’ll take a couple of minutes for all the services to start, and you can ignore the
“Problem with dial…”
errors. Once the discovery services are up, those errors will cease.
Step 5. View the api-gateway service in New Relic
- Generate some traffic on the Pet Clinic website by visiting
http://localhost:8080/
. - Navigate to New Relic One, and select the entity explorer.The api-gateway service should be listed in the Services section of the entity explorer.
- Click the api-gateway service. New Relic automatically detects the telemetry as Spring Boot Micrometer metrics and creates a default summary page using those metrics. The service summary includes charts for response time, throughput, and error rate, as well as charts showing JVM metrics. You can also group and filter the charts by the dimensions available on the metrics.
- Create your own charts.
Use the data explorer to choose metrics to chart and build your own dashboard with the metrics coming from the api-gateway.
Step 6. Add the New Relic Micrometer registry to the rest of the services
- Follow the instructions in Step 1 and Step 2 for the remaining services in the application.
- Follow Step 4 to rebuild and run the services.
Tips and best practices for monitoring Spring Boot apps
Now that you have a solid understanding of Spring Boot Micrometer metrics and their significance, let's explore some tips and best practices to help you effectively monitor your Spring Boot applications:
- Define clear monitoring goals: Determine the specific metrics and KPIs that align with your application's performance goals and business requirements.
- Leverage meter filters: Use meter filters to selectively apply monitoring to specific parts of your application. This can reduce overhead and focus on the most critical aspects.
- Consider conditional meter registration: Conditionally register meters based on runtime conditions, allowing you to dynamically enable or disable monitoring based on your application's state.
- Utilize meter binders: Explore meter binders, which are integrations with third-party libraries or frameworks. They provide out-of-the-box metrics for these components, saving you time and effort.
- Set appropriate monitoring frequencies: Determine the optimal frequency at which to collect metrics based on the granularity required for analyzing your application's performance.
- Choose relevant metrics: Micrometer provides a wealth of standard metrics out of the box, such as JVM, thread, and garbage collection metrics. Begin by utilizing these. Avoid metric overload—just focus on the ones that provide relevant insights to you.
- Use tags wisely: Tags can add valuable context to your metrics, like identifying service names, hostnames, or regions. This can be crucial for understanding metrics in a distributed system. Use a consistent set of tags across all your metrics. This consistency is key for effective querying and analysis in your monitoring tool.
- Integrate with a time series database: Integrate Micrometer with a time-series database that suits your needs, such as a href="https://newrelic.com/blog/best-practices/what-is-prometheus" target="_blank">Prometheus, InfluxDB, or Graphite. This will store and allow for querying of your metrics over time. Use tools like a href="https://newrelic.com/instant-observability/grafana-prometheus-integration" target="_blank">Grafana to create visual dashboards to monitor the health and performance of your application.
- Configure threshold-based alerts: Set up alerts for critical metrics to be informed of potential issues. For example, alert on high response times, error rates, or resource utilization. If possible, employ anomaly detection techniques that can alert you to unusual patterns, not just static thresholds.
- Regularly review and adapt metrics: As your application evolves, so too should your monitoring strategy. Regularly review the metrics you’re documenting and Include feedback from different stakeholders (developers, operations, business teams) to ensure that the metrics provide value across the board.
- Utilize distributed tracing: For complex applications, especially those using microservices, integrate distributed tracing tools (like Zipkin or Jaeger) with Micrometer. This will help in pinpointing issues in a distributed environment.
- Monitor application dependencies: Keep track of metrics related to external services your application depends on, such as databases, message brokers, or third-pary APIs. Use health checks and relevant metrics to monitor the health of these dependencies.
Making instrumentation ubiquitous
With New Relic Metrics and New Relic Traces, you can send telemetry data to New Relic, so you can query it and create custom dashboards that tie your application-centric data to your business KPIs.
As part of our open instrumentation initiative, we’re participating in the OpenTelemetry project. It aims to make instrumentation ubiquitous, so you can make the most of your telemetry data for easier and more effective observability. We know you need to ingest and make use of telemetry no matter where it’s from—whether it’s New Relic agents, OpenTelemetry, or other popular telemetry sources like Zipkin, Micrometer, and others. In addition to participating in OpenTelemetry, we have built integrations for other popular open source instrumentation tools like Dropwizard and Kamon.How to use Micrometer Metrics
We plan on evolving New Relic’s out-of-the-box support for Spring Boot Micrometer metrics. If you have ideas, feel free to hit the feedback button at the top-right corner in New Relic One, contribute to the project via New Relic Open Source.
이 블로그에 표현된 견해는 저자의 견해이며 반드시 New Relic의 견해를 반영하는 것은 아닙니다. 저자가 제공하는 모든 솔루션은 환경에 따라 다르며 New Relic에서 제공하는 상용 솔루션이나 지원의 일부가 아닙니다. 이 블로그 게시물과 관련된 질문 및 지원이 필요한 경우 Explorers Hub(discuss.newrelic.com)에서만 참여하십시오. 이 블로그에는 타사 사이트의 콘텐츠에 대한 링크가 포함될 수 있습니다. 이러한 링크를 제공함으로써 New Relic은 해당 사이트에서 사용할 수 있는 정보, 보기 또는 제품을 채택, 보증, 승인 또는 보증하지 않습니다.