Skip to content

Commit 378598d

Browse files
MXClydeMXClyde
committed
Add default retention period for monitoring data
Add info box clarifying that logs and metrics are retained for 30 days by default in Mendix on Azure. This addresses a common customer question about data retention in Azure Managed Grafana and Log Analytics.
1 parent 0537a31 commit 378598d

1 file changed

Lines changed: 167 additions & 0 deletions

File tree

‎content/en/docs/deployment/mx-azure/mx-azure-monitor.md‎

Lines changed: 167 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,167 @@
1+
---
2+
title: "Monitoring Mendix on Azure with Grafana"
3+
url: /developerportal/deploy/mendix-on-azure/monitor/
4+
weight: 15
5+
description: "Describes the Grafana monitoring functionality for apps running on Mendix on Azure."
6+
---
7+
8+
## Introduction
9+
10+
Mendix on Azure uses integrated Grafana instances to provide observability and analytics for your apps. This document describes how you can access Grafana dashboards, view logs and metrics, and configure alerts for your Mendix applications running on Azure.
11+
12+
Grafana is an open-source platform that offers the following capabilities:
13+
14+
* Query and visualize metrics, logs, and traces.
15+
* Build interactive dashboards.
16+
* Configure alerts based on operational thresholds.
17+
18+
When deploying Mendix on Azure, an Azure Managed Grafana instance is automatically provisioned as part of the cluster setup.
19+
20+
## Overview
21+
22+
Azure Managed Grafana is a fully managed Grafana service provided by Microsoft Azure. It removes the operational overhead of managing Grafana infrastructure.
23+
24+
Azure Managed Grafana offers the following benefits:
25+
26+
* Azure hosts, maintains, and secures the Grafana instance
27+
* No manual installation, upgrades, or patching required
28+
* Authentication and access control integrated with Azure Active Directory (AAD)
29+
* Native integration with Azure observability services, including:
30+
* Azure Monitor
31+
* Log Analytics
32+
* Azure Managed Prometheus
33+
34+
## Grafana Access Configuration
35+
36+
You can configure access to Azure Managed Grafana dashboards as either *public* or *private*. For private access, the Grafana instance must be connected through a private endpoint. For more information, see [Enabling Connectivity between Mendix on Azure and Other Private Networks](/developerportal/deploy/mendix-on-azure/configuration/interconnecting-networks/#solution-2-privatelink-with-private-endpoints).
37+
38+
You can enable private Grafana access during cluster creation, or later under **Advanced Settings**.
39+
40+
To access Grafana dashboards, the user must have the Grafana Admin permissions assigned on the target Azure subscription. Developers cannot access Grafana dashboards, unless they have the required permissions on the subscription.
41+
42+
## Viewing Grafana Logs and Metrics
43+
44+
Azure Managed Prometheus is provisioned automatically to collect application and Platform metrics. Logs are collected by Azure Monitor and stored in the Log Analytics Workspace.
45+
46+
{{% alert color="info" %}}
47+
Logs and metrics are retained for **30 days** by default.
48+
{{% /alert %}}
49+
50+
To view the logs, perform the following steps:
51+
52+
1. In Grafana, go to **Dashboards > Mendix**.
53+
2. Choose one of the following options:
54+
55+
* For Container logs, click **Container Insights**, and then select one of the following containers:
56+
57+
* **mendix-operator** - The Mendix Operator manages the lifecycle of all Mendix app containers.
58+
* **m2ee-sidecar** - The M2EE sidecar container sends the configuration into the Mendix Runtime and monitors its status.
59+
* **mendix-agent** - The Mendix Agent is responsible for maintaining a secure communication channel between the cluster and the Mendix on Kubernetes portal.
60+
* **mx-coastguard** - Coastguard is responsible for executing backup and restore jobs in the cluster.
61+
62+
* For Mendix application logs, click **Mendix App Dashboard (Native)**.
63+
* For Azure-managed NGINX ingress logs, select the **app-routing-system** namespace.
64+
65+
## Setting up Grafana Alerts
66+
67+
Grafana alerts help monitor your application and notify you when specific conditions occur, such as errors in logs or high CPU usage.
68+
69+
To set up alerts in Grafana Unified Alerting, you must create a contact point to which notifications are sent, and an alert rule which Grafana evaluates.
70+
71+
### Creating a Contact Point
72+
73+
A contact point defines where Grafana sends alert notifications (for example, email, Slack, or Webhook).
74+
75+
{{% alert color="info" %}}
76+
For testing, we recommend using a Webhook contact point. This type of contact point makes it easy to verify alert delivery.
77+
{{% /alert %}}
78+
79+
To create a contact point, perform the following steps:
80+
81+
1. In Grafana, go to **Alerting > Contact points**.
82+
2. Click **Manage contact points**.
83+
3. Click **Create contact point**.
84+
4. Enter a **Name** for the contact point.
85+
5. Select the **Integration type** (for example, **Webhook**).
86+
6. Provide the required configuration details.
87+
7. Click **Save contact point**.
88+
89+
When an alert is triggered, the endpoint (for example, `Webhook.site`) receives incoming request, confirming that notifications are working.
90+
91+
### Creating an Alert Rule
92+
93+
An Alert rule defines what Grafana continuously evaluates and when an alert should transition into a firing state. Alert rules are based on queries from supported data sources such as logs and metrics.
94+
95+
To create an alert rule, perform the following steps:
96+
97+
1. In Grafana, go to **Alerting > Alert rules**.
98+
2. Click **New alert rule**.
99+
3. Select the **Data source** (**Logs** or **Metrics**).
100+
4. Add a **Query**.
101+
5. Add the **Expressions**:
102+
103+
* **Reduce** - To convert time series data into a single value
104+
* **Threshold** - To define when the alert fires.
105+
106+
6. Configure the **Alert condition**.
107+
7. Set an **Evaluation interval**.
108+
8. Assign the rule to a **Folder** and **Evaluation group**.
109+
9. Verify the following:
110+
111+
* A contact point exists.
112+
* A notification policy references the contact point.
113+
* The query returns data.
114+
* Reduce and Threshold conditions are configured.
115+
* The alert rule is enabled.
116+
117+
10. Click **Save rule**.
118+
119+
#### Sample Alert Rule 1: Alert for Critical or Fatal Log Errors
120+
121+
This alert detects severe errors in Mendix application logs. It helps detect serious application failures early by triggering when a critical or fatal log message appears.
122+
123+
##### Query
124+
125+
```text
126+
ContainerLogV2
127+
| where PodName startswith "envname-"
128+
and ContainerName == "mendix"
129+
and LogLevel in ("critical", "fatal")
130+
| summarize count() by bin(TimeGenerated, 1m)
131+
| order by TimeGenerated asc
132+
```
133+
134+
##### Alert Condition
135+
136+
* **Reduce** - **Last**
137+
* **Threshold** - `count > 0`
138+
139+
Any critical or fatal log entry cause the alert to fire.
140+
141+
#### Sample Alert Rule 2: Alert for High CPU Usage
142+
143+
This alert monitors CPU usage for a Mendix application. It help identify performance or scaling issues by triggering when CPU usage exceeds the defined threshold.
144+
145+
##### Query
146+
147+
```text
148+
rate(
149+
sum without (id, name) (
150+
container_cpu_usage_seconds_total{
151+
namespace=~"mendix",
152+
pod=~"envname-*",
153+
container="mendix"
154+
}
155+
)[1m:]
156+
)
157+
```
158+
159+
##### Expressions
160+
161+
* **Reduce** - **Median**
162+
163+
##### Threshold
164+
165+
* Trigger when the reduced value is above **0.1**.
166+
167+
This alert fires when the application consumes more than 0.1 CPU core.

0 commit comments

Comments
 (0)