How to monitor your Mendix Web Application with Prometheus — Locally

Prometheus and Mendix: Simple and Easy!

The procedure described in this article intends to demonstrate how to configure Prometheus to monitor a local instance of a Mendix Application, launched by Studio Pro. Yes, it’s possible and indeed very simple.

Scenario

Once again using the same scenario as described in the previous article: a simple application that takes two numbers and calculates their sum. But this time the goal is to measure some key features of our application so that we can extract data useful in Business Decisions.

For that, we need to add some “instruments” in the application’s code. These instruments will collect the data required by the Business Rules and will make them available to Prometheus.

In Mendix we have available two types of metrics that can be used in the instrumentation of your code: Counters and Gauges.

• Counters are used to increment a business value by a given step. For example: how many times a certain endpoint was called, or the Reset button was clicked.
• Gauges are used to register the reading of a business value. For example: the size in bytes of the images being uploaded, or the current memory usage.

The Prometheus documentation states that there are two more metric types: Histogram and Summary, both not yet available in Mendix.

Procedure

[1] Download the compacted package with the Prometheus application. There are packages for Linux, MacOS, and Windows. Prefer the LTS version. Extract the package to a folder without blank spaces.

Contents of the Prometheus Windows package

[2] Edit the prometheus.yml file to include the configurations required to connect your Mendix application to the Prometheus application.

Add these lines to prometheus.yml so that it can monitor your application

  - job_name: "mendix"
    metrics_path: "/prometheus"
    static_configs:
      - targets: ["localhost:8090"]

Your Mendix app will use the endpoint /prometheus to make available the metrics data. In addition, it will use the admin port 8090. Notice that this YAML file also includes the configuration so that Prometheus can monitor itself!

[3] In Studio Pro, go to App Settings/Configurations/Default/Custom and add a new custom variable as shown below:

Custom configuration required to use Prometheus with our Mendix-created app.

[
  {
    "type": "prometheus",
    "settings": {
      "step": "30s"
    }
  }
]

This configures Mendix to use Prometheus as the type for metrics registration. Mendix allows to use of multiple types simultaneously, such as JMX, Influx, and Statsd, besides Prometheus. The reporting frequency is defined as 30 seconds. You can adjust the scrape_interval in the prometheus.yml to be 30s as well.

# prometheus.yml

# my global config
global:
  scrape_interval: 30s # Set the scrape interval to every 30 seconds. Default is every 1 minute.
  evaluation_interval: 30s # Evaluate rules every 30 seconds. The default is every 1 minute.
  # scrape_timeout is set to the global default (10s).

...

[4] Now let’s add the instruments to our Mendix code. These instruments can only be added in Microflows. Since our application is very simple, let’s assume that the Business Board is interested in quantifying how many times the Sum button is clicked, the value of the Result, and how many times the Reset button is clicked. All of this will be collected every 30 seconds.

Instruments added to the buttons of our UI.

Microflow “ACT_Calculator_Sum” is called by the button “Sum”

Detail of Gauge Activity defined to register the $Result value

Microflow ACT_Calculator_Reset is called by the button “Reset”

The metrics Counter and IncrementCounter are very similar. The former allows us to define the increment value, whereas in the latter the increment value is fixed, equal to one.

Observe in the comments the name of each metric. We’ll use these names to create a simplified dashboard in the Prometheus app.

[5] Start the Prometheus app using the command line (so that you can follow the logs), by opening a PowerShell terminal and typing the command below:

.\prometheus.exe

[6] Starts the Mendix application via Studio Pro (either by using the menu Run/Run locally or by hitting F5). Notice that the Prometheus configuration we’ve made earlier is shown in the log messages:

The console shows that the custom configuration has been applied

[7] Navigate to http://localhost:8080 to access your app. Use the input fields to add some numbers and then click on the Sum button.

[8] In another tab, navigate to http://localhost:8090/prometheus and search for test_app_calculator_sum_gauge . You’ll get the metrics registered in the Prometheus time series database.

Output showing the metrics being monitored

[9] Once again, open another tab and navigate to http://localhost:9090 to open the Prometheus application front end. Select the menu Status/Targets to confirm that your Mendix application is correctly configured:

Both endpoints are Up, indicating that Prometheus is properly configured

[10] Back to the Mendix app, randomly change some values in the input fields, and hit the Sum button to generate the data. In this simplified example, a Business Rule requires that the value of the $Result variable should be monitored. Then alternate to the Prometheus app, click on the menu Graph , and type test_app_calculator_sum_gauge in the expression field. Hit Execute to get the results in the Table. To see as graph, click on the Graph Tab, as shown below:

Metrics for test_app_calculator_sum_gauge instrument

Similarly, we can also plot the other two metrics required by the Business Rules: test_app_calculator_sum_counter or test_app_calculator_reset_increment_counter:

Metrics for the test_app_calculator_reset_increment_counter instrument

Conclusion

As you may have noticed, the graphical capabilities of Prometheus are not astonishing. To create a really good-looking dashboard, we must use another tool that works very fine with Prometheus: Grafana.

But I think the main goal of this article was accomplished. Now, we can instrument our Mendix code to measure some important Business Metrics. Locally! With a minimum configuration!

Imagine how cool would be to plot the rising of memory consumption alongside the number of calls to a given Microflow, showing that something needs to be adjusted in our code.

Besides the metrics created by ourselves, there are plenty of metrics that we can use to investigate potential issues in the code. The complete list can be found in this link: List of Metrics.

In the next article, let’s move one step further and connect Grafana to Prometheus so that we can configure a better-looking dashboard able to be shown in a Board Meeting.