Chapter 7: MicroProfile Metrics #16
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Adding content for chapter07
|
Awaiting review feedback and approval. |
|
@donbourne @Channyboy can you review |
donbourne
requested changes
Apr 16, 2024
|
|
||
| === Introduction to MicroProfile Metrics | ||
|
|
||
| It is essential to monitor its status regularly to ensure smooth microservice operations. You can monitor a microservice using two different techniques: Metrics and health checking. Health checks provide information on the health status of a service, such as whether it is up and running, while Metrics offer more detailed information on its performance, such as response times, throughput, and error rates. In the previous chapter, we discussed health checks and their importance. This chapter will cover the MicroProfile Metrics specification, which provides a standardized way of collecting and exposing performance data for Java microservices. |
There was a problem hiding this comment.
It is essential to monitor its status regularly to ensure smooth microservice operations.
->
It is essential to monitor your microservices to ensure smooth operation.
|
|
||
| *MicroProfile Metrics* is a specification for developers who want to measure their applications' performance more thoroughly. It provides a set of annotations and APIs to track various metrics related to the application's health and performance. For instance, developers can use these APIs to track metrics such as the number of requests processed, the response time of each request, and the size of the response sent back to the client. | ||
|
|
||
| This specification defines a standardized format for exposing these metrics, which other tools and frameworks can easily collect and track. By using this specification, developers can monitor the performance of their applications in real time and identify any issues that may impact the user experience. |
There was a problem hiding this comment.
for exposing these metrics
->
for exposing metrics
|
|
||
| This specification defines a standardized format for exposing these metrics, which other tools and frameworks can easily collect and track. By using this specification, developers can monitor the performance of their applications in real time and identify any issues that may impact the user experience. | ||
|
|
||
| Moreover, this specification defines a set of standard metrics that we can expose in various formats, such as JMX (Java Management Extensions), JSON (JavaScript Object Notation), or Prometheus. Developers can choose the format that works best for their needs. With the help of this tool, developers can optimize their applications for better performance, ensuring that they meet the requirements of their consumers while delivering a seamless experience. |
There was a problem hiding this comment.
the spec only mandates that there is a prometheus format for metrics. No JMX / JSON.
|
|
||
| Moreover, this specification defines a set of standard metrics that we can expose in various formats, such as JMX (Java Management Extensions), JSON (JavaScript Object Notation), or Prometheus. Developers can choose the format that works best for their needs. With the help of this tool, developers can optimize their applications for better performance, ensuring that they meet the requirements of their consumers while delivering a seamless experience. | ||
|
|
||
| *JMX* is a robust platform that provides developers the tools to monitor and manage Java applications efficiently. It offers a wide range of features that allow developers to identify and diagnose various application problems, including performance issues, memory leaks, and other critical errors. By leveraging JMX, developers can ensure their Java applications run efficiently and effectively, leading to a better user experience. With JMX, developers can gain insights into their applications that would otherwise be difficult to obtain, making it an essential tool for anyone building and managing Java applications. |
There was a problem hiding this comment.
JMX is not part of MP Metrics.
|
|
||
| *JMX* is a robust platform that provides developers the tools to monitor and manage Java applications efficiently. It offers a wide range of features that allow developers to identify and diagnose various application problems, including performance issues, memory leaks, and other critical errors. By leveraging JMX, developers can ensure their Java applications run efficiently and effectively, leading to a better user experience. With JMX, developers can gain insights into their applications that would otherwise be difficult to obtain, making it an essential tool for anyone building and managing Java applications. | ||
|
|
||
| In addition to JMX, developers can benefit from JSON's clear and concise way of representing data. *JSON* allows developers to represent a wide range of data types, including strings, numbers, arrays, and objects. It is also widely supported across different programming languages and platforms, making it ideal for transmitting data between systems and platforms. |
There was a problem hiding this comment.
JSON is not part of MP Metrics v5.x
| @Timed(name = "productLookupTime", | ||
| tags = {"method=getProduct"}, | ||
| absolute = true, | ||
| description = "Time needed to lookup for a products") |
There was a problem hiding this comment.
Time spent looking up a product
| ---- | ||
|
|
||
| It will expose a metric called `productLookupTime`, which will track the amount of time spent in the `getProduct()` method in milliseconds. | ||
| You can visit the following URL `++https://localhost:<port>/metrics?scope=application++` (Replace `<port>` with the actual port where the server is running) to see the Response time of this method as below: |
There was a problem hiding this comment.
Response time -> response time
|
|
||
| The gauge metric `productCatalogSize` can be accessed through the following endpoint: | ||
|
|
||
| `/metrics?name=io_microprofile_tutorial_store_product_resource_ProductResource_productCatalogSize` |
There was a problem hiding this comment.
as the doc doesn't show the package name, it would probably be better to set absolute=true and just use the absolute name here.
There was a problem hiding this comment.
Vendors may, by their on implementation, support /metrics?name=<name> to directly retrieve that metric from all scopes. But the specification itself only illustrates /metrics?scope=<scope>&name=<name>
|
|
||
| === Summary | ||
|
|
||
| This Chapter delved into the intricacies of MicroProfile Metrics, illuminating its role as a pivotal specification for efficiently monitoring microservices. Now you are equipped with a thorough understanding of diverse metric types and their application for monitoring microservice performance. This chapter highlighted the need of regular microservice monitoring via metrics and health checks, emphasizing metrics for detailed performance insights such as response times and throughput. Through practical examples, this chapter showcases how to instrument microservices with MicroProfile Metrics, leveraging standard metrics, and creating custom metrics to monitor microservices comprehensively. |
There was a problem hiding this comment.
need of regular -> need for regular
| … | ||
| ---- | ||
|
|
||
| ==== Tracking number of invocations |
There was a problem hiding this comment.
Tracking number of invocations using @Counted
Channyboy
reviewed
Apr 19, 2024
|
|
||
| 2. *Gauge*: It is a metric type that measures an instantaneous value of something , which can arbitrarily go up or down. It’s used to capture the value of a metric at a particular point in time like the size of a queue, memory usage, or current number of active user sessions. Gauges are typically used for values that fluctuate over time and provide a current "gauge" of what's happening. | ||
|
|
||
| 3. *Histograms*: They provide a distribution of values for a given metric, which are useful for identifying performance outliers. It measures the frequency of values in different ranges (or "buckets") and is useful for tracking the distribution of values, such as response times or data sizes. Histograms can give insights into the variability, average, median, percentiles, and trends of the measured data over time. |
There was a problem hiding this comment.
In 5.x, standard deviation (variability) and median isn't provided anymore.
Channyboy
reviewed
Apr 19, 2024
|
|
||
| === Using Metadata for Metrics | ||
|
|
||
| In MicroProfile Metrics, metadata plays a crucial role in defining, understanding, and managing the various metrics that applications expose. Metadata essentially provides descriptive information about a metric, such as its name, description, type, unit of measurement, and additional tags or labels. This information not only aids in the identification and categorization of metrics but also enhances their interpretability, making it easier for developers, operators, and monitoring tools to understand what each metric represents and how it should be used. |
There was a problem hiding this comment.
Strictly. speaking the Metadata object doesn't actually hold tag/label data. That belongs under the MetricID object. Both work together to work as metadata I suppose. The rest of the guide/tutorial doesn't seem to get into the nitty gritty details of using the API so this we can ignore I suppose. wdyt @donbourne
Channyboy
reviewed
Apr 19, 2024
| In MicroProfile Metrics, metrics are organized into three distinct scopes: Base, Vendor, and Application. This categorization is designed to clearly separate metrics by their origin and relevance, making it easier for developers and operators to monitor and manage the performance of their microservices. Each scope serves a specific purpose and contains a different set of metrics: | ||
|
|
||
| - *Base Metrics* are common to all applications, such as the number of CPUs or the amount of free memory. These metrics provide essential information about the underlying Java Virtual Machine (JVM) and the core libraries that are common across all MicroProfile applications. Base metrics typically include JVM-specific metrics such as memory usage, CPU load, thread counts, and garbage collection statistics. The intention behind base metrics is to offer a consistent set of low-level metrics that are universally applicable and useful for monitoring the health and performance of the JVM itself, which is the foundation upon which all MicroProfile applications run. | ||
| Base metrics are exposed under the path `/metrics?scope=base`. |
There was a problem hiding this comment.
In 5.x, base metrics have become optional. Not sure if that's worth mentioning for the purpose of the tutorial.
Channyboy
reviewed
Apr 19, 2024
| - Base Scope (`MetricRegistry.Type.BASE`): Contains metrics that are fundamental and common across all MicroProfile applications. These metrics provide basic information about the underlying JVM and application server. | ||
|
|
||
| - Vendor Scope (`MetricRegistry.Type.VENDOR`): Contains metrics that are specific to the implementation of the MicroProfile platform being used. These metrics offer insights into vendor-specific features and optimizations. | ||
|
|
There was a problem hiding this comment.
Since custom scopes were mentioned above, it may be worth mentioning that a meter registry is created for these custom scopes.
Channyboy
reviewed
Apr 19, 2024
| // … | ||
| ---- | ||
|
|
||
| It will expose a metric called `productLookupTime`, which will track the amount of time spent in the `getProduct()` method in milliseconds. |
Channyboy
reviewed
Apr 19, 2024
| [source, java] | ||
| ---- | ||
| import org.eclipse.microprofile.metrics.Metrics; | ||
| import org.eclipse.microprofile.metrics.MetricType; |
There was a problem hiding this comment.
won't need this line (MetricType) for the example
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Adding content for chapter07