Monitoring Your Mendix Apps with an APM Tool

Last modified: November 7, 2023

1 Introduction

There are several application performance monitoring (APM) tools for cloud applications available through a software as a service (SaaS) based data analytics platform. These APM tools provide comprehensive monitoring of servers, databases, tools, and services.

Mendix provides out-of-the-box configuration to use Datadog, AppDynamics, Dynatrace, Splunk Cloud Platform, and New Relic to provide additional monitoring for your Mendix Apps running on Mendix Cloud.

This document explains what information can be provided to a SaaS-based data analytics platform.

For details on how to add a specific APM tool to your app, see one of the following documents:

2 What Information Can Mendix Supply to a SaaS-based Data Analytics Platform?

Mendix provides two types of monitoring data:

  • Data from the Mendix Runtime, the Java Virtual Machine (JVM), the database, and the SaaS (for example, Cloud Foundry) environment – this is described in Environment Metrics, below
  • Data from within the Mendix app itself – this is described in App Metrics, below

3 Environment Metrics

Once you have configured your data analytics platform for your app, it will automatically send information about the environment in which your app is running.

3.1 Environment Metrics Namespaces

The metrics from your app’s environment are supplied in the following namespaces:

  • commons.pool2 – database connection pool metrics
  • jetty – metrics from the ingress controller of the app
  • jvm – metrics from the Java virtual machine in which the Mendix runtime runs
  • postgresql – database metrics specific to PostgreSQL databases
  • system – metrics from the base system running on the platform or PaaS — in Datadog, these are disabled by default but can be enabled using the DD_ENABLE_CHECKS environment variable.

Many of these metrics are described in more detail in Metrics – Mendix Runtime.

3.2 Useful Metrics for Mendix Apps

The following metrics are useful when monitoring the performance of your Mendix app:

  • mx.database.diskstorage_size
  • jvm.heap_memory
  • jvm.heap_memory_committed
  • jvm.heap_memory_init
  • jvm.heap_memory_max
  • jvm.non_heap_memory
  • jvm.non_heap_memory_committed
  • jvm.non_heap_memory_init
  • jvm.non_heap_memory_max
  • postgresql.connections
  • postgresql.database_size
  • postgresql.max_connections
  • postgresql.percent_usage_connections

Note that the absolute values are often not useful, but looking at trends over time can indicate performance issues or future action that might be required. Some of these trends are similar to those described in Metrics.

4 App Metrics

Mendix provides logging of various actions within the app. These are sent to your data analytics platform with the namespace mx. Timing values are sent in milliseconds.

By default, Mendix only passes request handler activity, but you can configure it to provide metrics for microflows and activities as well. You can find how to do this in Customizing the Metrics Agent, below.

4.1 What Metrics Can You Get From Your App?

4.1.1 Request Handler Metrics

Unless you customize your metrics agent, the metrics agent provides metrics for all your request handlers. The metrics provided are listed below:

4.1.1.1 mx.soap.time

This is a timing/histogram value for SOAP requests.

4.1.1.2 mx.odata.time

This is a timing/histogram value for OData requests.

4.1.1.3 mx.rest.time

This is a timing/histogram value for REST requests.

4.1.1.4 mx.client.time

This indicates the time it takes to handle a request to a request handler used by the web UI. You can get results for all of the following types of requests:

  • REST, ODATA, SOAP doc requests
  • /xas requests (general queries for data in data grids, sending changes to the server, and triggering the execution of microflows)
  • File upload/download requests
  • /p requests

This metric helps you to gain an overview of how long users have to wait for individual requests; hence, it indicates overall application performance.

4.1.2 Microflow Metrics

For the microflows you select (see Customizing the Metrics Agent, below), the metrics agent provides the following metrics relating to the time the microflow takes to run:

  • mx.microflow.time.avg
  • mx.microflow.time.count
  • mx.microflow.time.max
  • mx.microflow.time.median
  • mx.microflow.time.95percentile

4.1.3 Activity Metrics

For the activities you select (see Customizing the Metrics Agent, below), the metrics agent provides the following metrics:

  • mx.activity.time.avg
  • mx.activity.time.count
  • mx.activity.time.max
  • mx.activity.time.median
  • mx.activity.time.95percentile

4.2 Customizing the Metrics Agent

By default, Mendix passes a log of all request handler activity to your data analytics platform and no other information. However, by using JSON to configure the metrics agent, you can add logs of microflows and activities within microflows, and restrict which request handler calls are sent.

4.2.1 Format of Metrics Agent Configuration

To specify which request handlers, microflows, and activities are reported, use a JSON configuration with the following format. (Note that this is the syntax, not an example of this custom setting.)

{
  "requestHandlers": [
    {
      "name": "*" | "<requesthandler>"
    }
  ],
  "microflows": [
    {
      "name": "*" | "<microflow>"
    }
  ],
  "activities": [
    {
      "name": "*" | "<activity>"
    }
  ]
}
Value What Is Sent Note
"name": "*" All Default
"name": "<requesthandler>" All request handler calls of this type Click Request Handlers1 below to see the list of options
"name": "<microflow>" Each time this microflow is run The format is <module>.<microflow>
For example, TrainingManagement.ACT_CancelScheduledCourse
"name": "<activity>" All activities of this type Click Activities2 below to see the list of options

[1 ] Request Handlers (click to see list)

The following Mendix request handler calls will be passed:

Request Handler Call Type Namespace
WebserviceRequestHandler SOAP requests mx.soap.time
ServiceRequestHandler OData requests mx.odata.time
RestRequestHandler REST requests mx.rest.time
ProcessorRequestHandler REST, ODATA, SOAP doc requests mx.client.time
ClientRequestHandler /xas requests (general queries for data in data grids, sending changes to the server, and triggering the execution of microflows) mx.client.time
FileRequestHandler File upload/download requests mx.client.time
PageUrlRequestHandler /p requests mx.client.time

For details on how to analyze some of these values, see Metrics.

[2] Activities (click to see list)

The following Mendix activities can be passed:

  • CastObject
  • ChangeObject
  • CommitObject
  • CreateObject
  • DeleteObject
  • RetrieveObject
  • RollbackObject
  • AggregateList
  • ChangeList
  • ListOperation
  • JavaAction
  • Microflow
  • CallRestService
  • CallWebService
  • ImportWithMapping
  • ExportWithMapping

Example

The following example sends logs for the following:

  • All request handlers
  • The microflow After_Startup in the module Administration
  • The CreateObject and DeleteObject activities
{
  "requestHandlers": [
    {
      "name": "*"
    }
  ],
  "microflows": [
    {
      "name": "Administration.After_Startup"
    }
  ],
  "activities": [
    {
      "name": "CreateObject"
    },
    {
      "name": "DeleteObject"
    }
  ]
}

4.2.2 Passing a Configuration to the Metrics Agent

You pass the configuration to the metrics agent by adding a custom runtime setting to your Mendix Cloud environment.

  1. Go to the Environments page of your app.

  2. Click Details next to the environment you have configured for Datadog.

  3. In the Custom Environment Variable section, add a METRICS_AGENT_CONFIG variable with the value of the JSON required for your configuration.

  4. Click Save.

  5. Restart your app to apply the new settings if you have already connected your node to your data analytics. If you are in the process of connecting your node, you must redeploy your application to apply the changes.

5 Filtering Metrics Ingestion

To filter the ingestion of metrics to APM vendors, you can use these environment variables:

5.1 APM_METRICS_FILTER_ALLOW

Set the value to a comma-separated list of prefixes for the metrics to be allowed. By default, all metrics are allowed, even if they are not specified via this environment variable.

For example, to allow only the session and the JVM metrics, set the environment variable to mx.runtime.stats.sessions,jvm.

5.2 APM_METRICS_FILTER_DENY

Set the value to a comma-separated list of prefixes for the metrics to be denied.

For example, to filter out only metrics starting with jetty or mx.runtime, set the environment variable to jetty,mx.runtime.

5.3 APM_METRICS_FILTER_DENY_ALL

You can use this environment variable can be used to stop ingestion of all metrics at once.

If its value is set to true, all metrics will be denied regardless of the values of APM_METRICS_FILTER_ALLOW, APM_METRICS_FILTER_DENY, and APPMETRICS_INCLUDE_DB.

6 Tuning Log Levels

If desired, you can adjust the log levels. If you configure your app’s log levels via the Log Levels tab on the Environment Details page, the log levels that you set there are also reflected in your APM integrations.

7 Read More