Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Monitoring an Eclipse MicroProfile 1.2 Server With Prometheus

DZone's Guide to

Monitoring an Eclipse MicroProfile 1.2 Server With Prometheus

Eclipse MicroProfile has a Monitoring specification in its 1.2 release allowing for a common way of monitoring servers that implement the specification. Here, you'll learn how to monitor MicroProfile 1.2 servers with Prometheus.

· Java Zone
Free Resource

Download Microservices for Java Developers: A hands-on introduction to frameworks and containers. Brought to you in partnership with Red Hat.

Eclipse MicroProfile has added a Monitoring specification in its 1.2 release. This allows for a common way of monitoring servers that implement the specification. In this article, you will learn how to monitor MicroProfile 1.2 servers with the popular Prometheus monitoring system.

Overview

I have described the concepts of Eclipse MircoProfile (MP) Monitoring in a previous article—servers expose a basic set of system metrics that are common for each implementation of the MP-Metrics specification. Applications can in addition also make specific metrics available.

The server then exposes the gathered metric data over HTTP(s) endpoints. Monitoring agents can then connect to the server's /metrics endpoint and poll the data.

Setting Up the (Server) Runtimes to be Monitored

I'll now show how to set up the runtimes to use MicroProfile metrics. For this, I am showcasing WildFly Swarm and OpenLiberty as two of the early adopters of the Metrics specification. I will start with WildFly Swarm.

WildFly Swarm

WildFly Swarm, or Swarm for short, uses a so-called fat-jar approach: You build your application and then get a jar file that contains the application and all of the server logic, which you then just start via java -jar application-swarm.jar. To enable the MicroProfile Metrics to support, you need to pull in the MicroProfile fraction in your build.

For Apache Maven users it looks like this:

<dependency>
<groupId>org.wildfly.swarm</groupId>
    <artifactId>microprofile-metrics</artifactId>
</dependency>

After this is done, you just build your project as usual with mvn install, which will create the usual uber-jar in a target.

When you run it, you will see a line like the following in the server log:

WFSWARM0013: Installed fraction:     Microprofile-Metrics - EXPERIMENTAL    org.wildfly.swarm:microprofile-metrics:2017.11.0-SNAPSHOT

Once the server is ready, it is exposing metrics under http://localhost:8080/metrics by default.

OpenLiberty

You can download OpenLiberty from its homepage. After downloading and unpacking it, you need to create a server configuration. Pass the respective template in to obtain a MicroProfile configuration.

$ bin/server create  mp --template=microProfile1

The /metrics endpoint is secured by default on OpenLiberty.

You need to add a small addition to the config file under usr/servers/mp1/server.xml inside the <server> element.

quickStartSecurity userName="theUser" userPassword="thePassword"/>
<keyStore id="defaultKeyStore" password="Liberty"/>

When this is done, you can start the server via bin/server run mp. With the standard settings, the metrics can then be found under https://localhost:9443/metrics. Credentials are
theUser/thePassword as seen in line 2 of the above snippet.

Setting Up Prometheus

Now that we have our targets set up to be monitored, we can install Prometheus to monitor them. Prometheus is relatively easy to get going. Just download, unpack and start it. Before you can start it, you need to provide a configuration file. Create a file prom.yml with the following content:

scrape_configs:
  # Configuration to poll from WildFly Swarm
  - job_name: 'swarm'
    scrape_interval: 15s

    # translates to http://localhost:8080/metrics
    static_configs:
      - targets: ['localhost:8080']

  # Configuration to poll from OpenLiberty
  - job_name: 'liberty'
    scrape_interval: 15s
    scheme: https
    basic_auth:
      username: 'theUser'
      password: 'thePassword'

    tls_config:
      insecure_skip_verify: true

    # translates to https://localhost:9443/metrics
    static_configs:
      - targets: ['localhost:9443']   

After editing the file, you can start Prometheus via;

$prometheus -config.file=prom.yml

Prometheus will show a few lines about starting and a few seconds later it is ready.

Head over to your browser and go to http://localhost:9090/.

As a first step select Status -> Targets from the menu and make check that both servers are marked as UP.

Image title

List of endpoints to be scraped from along with their corresponding status

Chose Metrics for display.

Image title

Prometheus metric selector with a list of base: metrics

When the servers are running, we are ready to display some metrics (that gets more interesting when you wait a while so that Prometheus has polled more data).

Image title

Metrics as shown in Prometheus UI

In the last chart, you can see that we only asked for the metric, base:memory_used_heap_bytes but got two graphs, one per MP-server, as both expose the same metric under the same name. Prometheus is adding labels on the fly, which can then be used to distinguish the servers (green is OpenLiberty, brown is Swarm).

Conclusion

MicroProfile Metrics defines a common way to expose metrics from systems. Monitoring tools like Prometheus are thus easily able to monitor those servers in a vendor-independent way.

At the time of this article, the MP-Metrics code may not yet be in a Swarm release, but it will be soon.

Download Building Reactive Microservices in Java: Asynchronous and Event-Based Application Design. Brought to you in partnership with Red Hat

Topics:
java ,microprofile ,eclipse ,wildfly swarm ,apache maven ,openliberty ,prometheus ,monitoring

Published at DZone with permission of Heiko Rupp, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}