Only contract owners or administrators may configure MaaS by default. Monitored metrics are "read-only" for all other user types. Additional users must be granted access via IONOS Cloud User Management, which is available in the DCD as well as via Cloud API. Prior to setting privileges for an additional user, ensure they have access to the specific VDC.
MaaS has a new group privilege called Access and Manage Monitoring. The privilege must be enabled for a group so that members of the group inherit this privilege through group privilege settings.
Once the privilege is granted, contract users can access monitoring metrics of virtual instances running in virtual data centers that are shared with them. Contract owners and administrators can access monitoring metrics of all virtual instances, as they have access to all VDCs at any given time.
Use the following procedure to manage monitoring privileges:
1. Open Management in the DCD.
2. Select the Users & Groups option under Users.
3. A User Manager modal will open up. Select the Groups tab.
4. Select the target group.
5. Check the Access and Manage monitoring check box. The box turns blue and displays a tick box.
6. Close the User Manager window. Privileges are activated for the selected group.
Revoke user access by either removing the user from all groups that have the privilege enabled or by disabling the privilege in each respective group.
You can revoke this privilege from a contract administrator only by disabling the administrator option on the user account. The respective user will then fall back into the role of a contract user. All privileges that were set up for the user, before nomination as administrator, will then be in effect.
There are two ways to access the metrics of an instance: from the Monitoring Manager view or via the Inspector pane.
Inside of the data center view of the DCD, right-click the graphical representation of your server. The context menu will show an item called Monitor, which will open a window with the server's metrics. This window can be minimized to the bottom bar.
The Monitoring Manager allows quick access to all running virtual instances within the contract. It also provides access to the configuration of alarms and actions.
1. In the DCD, open the Management option. A drop-down box displays.
2. Select Monitoring.
3. In the left panel, select the target Dedicated Core server. Metrics for the target server displays in the right-hand panel.
You can access MaaS via the properties panel of a virtual instance.
1. In the DCD, open your virtual data center.
2. Select your Dedicated Core server. The Inspector pane for this virtual instance displays on the right side of the window.
3. Click on the Metrics tab. The CPU utilization graph, followed by other graphs, displays showing the basic metrics for the last hour.
4. In the Inspector, you may select Refresh. The basic metrics are refreshed.
5. You can choose to monitor separately. In the Inspector, select Monitor in Background. A separate window displays. The graphs display an enlarged view. Additional information is available for each graph.
In the upper right corner of the pop-up window there are three buttons: minimize (down arrow), maximize (up arrow) and close (x). You to can either enlarge the view to the entire screen or reduce the view to a monitoring bar, which will remain active in the background.
The monitoring bar remains visible even when switching between VDCs. You can add multiple monitoring views of different virtual instances from different VDCs to this bar. Even if you close a virtual data center, the monitoring bar option will remain active.
The monitoring bar will disappear when you log out of the DCD.
If the VDC is closed, you can reopen the Monitoring Manager and also use the Focus Server option to load the VDC that contains the server instance. The server will be selected automatically. The relevant property panel will become available immediately.
In the Monitor in Background view, you may select the refresh interval as well as the time frame for data retrieval.
You can only choose a time frame of up to two weeks. If you select a wider time frame, MaaS will limit the data reported or it may return an error if no data is available. If you change one or both of these values, the view is refreshed. MaaS will display your latest chosen data in the graph.
If you want to create a long-term history of metrics, we advise you to retrieve the raw metric data and store it. Any data older than two weeks will be purged by IONOS Cloud.
Monitoring as a Service (MaaS) gathers metrics on and Cube resource utilization. You can track any virtual instance in your and set triggers when usage limits are reached. MaaS is completely free and can be accessed immediately after a virtual instance is provisioned.
Compatibility: Monitoring is available anytime from the or via for all instances in the . This service is compatible with all boot options and is independent of the operating system used or the instance type.
Actions and Alarms: With MaaS, you may set triggers based on resource usage. The system automatically executes predetermined Actions using set threshold Alarms. The application currently only sends email notifications.
Automation: MaaS lets you access up to two weeks' worth of runtime performance metrics. Raw Prometheus metrics can be gathered using (PromQL) and imported into your own monitoring system.
MaaS collects basic metrics from the virtualization layer on which the virtual instance is running. The application makes it possible to run any configuration of virtual instances, as no client installation is required. Virtual instances can boot from any device using public or private images as well as snapshots or boots from ISO or network. Since no client installation or specific image is required, the feature is also enabled for virtual instances that were provisioned previously. The metrics covered by MaaS are as follows:
| Category | Metrics |
|---|
The collection of monitoring metrics starts when a new instance is provisioned. However, the first metrics will not be available immediately after provisioning. It takes about 10 minutes before the first metrics are collected and can be retrieved in DCD or via API. Once this initial 10 minute period has elapsed, you can poll for metrics at any time.
MaaS provides metric data for the two previous weeks. If you want to create a long-term history of metrics we advise you to retrieve the raw metric data and store it. Any data older than two weeks will be purged by IONOS Cloud.
IONOS currently offers . Memory metrics are currently not available.
Prerequisite: Make sure your account has Monitoring privileges enabled in the user group.
1. Select the Management option in the main menu bar of the DCD.
2. Select Monitoring in the drop-down menu. The Monitoring Manager panel displays.
3. Select the Create button in the Alarms tab.
4. In the Create panel, create an alarm by performing the following substeps:
Name: choose an appropriate name.
Server: select a virtual instance.
Metric: select the relevant metric.
Unit:
select Total for absolute numbers (example: CPU utilization).
Total is unsupported for other metrics except if you’re using “delta” aggregation.
select a per-time rate in all other cases.
Threshold Type: define equality of value.
Threshold: enter the threshold value.
Range: define the time range within which the threshold must exceed the configured parameter limits before triggering an alarm event. The minimum time allowed is 120 seconds.
Range Aggregation: time range aggregation types are Average or Delta.
Average calculates the average of the defined metrics for all samples collected within the defined range. The average metric must be outside the configured parameter for the defined range to trigger an action event. This range aggregation is useful to detect constant load patterns.
Delta compares the change of the defined metric during the defined range. This range aggregation helps detect significant positive or negative spikes within the load patterns.
Alarm Delay: define the duration between the monitoring metric exceeding the configured threshold parameters and sending an alarm notification. The minimum time allowed is zero seconds, which will trigger an action event immediately once the defined criteria are fulfilled. You can also delay the alarm notification by setting a higher value. Setting a higher alarm delay will consider further metric samples in the calculation and continue shifting the range as time passes. As a result, the system may return to its regular functioning mode after a brief spike in the load pattern.
Actions: select one or multiple actions upon alarm trigger.
Select Create to save the alarm.
Once an alarm has been created, you can either edit the alarm configuration or delete it if it is no longer needed.
The details view provides an option to list the status and history of an alarm.
Upon alarm trigger, the alarm icon will blink to indicate that the configured threshold has been triggered. The blinking will stop automatically once the system is back within the threshold. This is monitored within the defined duration. The alarm status is OK while the system runs within the boundaries of the threshold. Once it is outside the boundaries and meets the criteria for triggering an action, the status will change from OK to FIRING. This transition will execute the defined action. When the system returns to the defined threshold boundaries, the status returns from FIRING to OK. The status change will be visible in the alarm manager but will not trigger an action.
The alarm configuration defines an average CPU utilization of 70% or higher as critical, and it has a defined range of two minutes and an alarm delay of zero seconds. The system collects four samples in two minutes in the following example, even though it collects metrics more often.
Sample01: 20% CPU utilization
Sample02: 30% CPU utilization
Sample03: 50% CPU utilization
Sample04: 70% CPU utilization
The alarm will not trigger for this two-minute range because the average of samples for the considered range will be below 70%. Considering subsequent samples:
Sample05: 71% CPU utilization
Sample06: 72% CPU utilization
Sample07: 75% CPU utilization
Sample08: 30% CPU utilization
When reaching "Sample07", the monitoring service will calculate an average CPU utilization above 70%. As the alarm delay is set to zero seconds, it will trigger an action to send an alarm immediately.
Assume the same example but with an alarm delay of 30 seconds. For Sample07, the monitoring service calculates an average CPU utilization above 70%. Still, the system does not trigger an action this time, as an alarm delay of another 60 seconds is configured, but the monitoring system constantly collects further metrics. When it receives Sample08, the monitoring services have calculated the average CPU utilization for the previous 120 seconds, which will be below 70%. The system does not trigger an action as the alarm threshold criteria are unfulfilled.
The examples below show possible configurations for the expression property of an Alarm.
Current CPU Load for all Cores
Setting a trigger when the average load of all cores over the last hour exceeds 90%.
Increase in Received Bytes
Setting a trigger when more than 1MB is incoming within the last ten minutes.
Sent Packets per Second (lower bound)
Set a trigger when there is less than one outgoing packet per second. ****
Storage Writes per Second
Set a trigger when there are more than 100 write operations per second.
In the Actions section, you can configure an action that will be executed when an alarm is activated. Currently, MaaS supports email notifications.
Prerequisite: Make sure your account has Monitoring privileges enabled in the user group.
1. Open the Monitoring Manager and select the Actions tab. The Actions tab displays.
2. Create an Action by performing the following sub-steps:
Define a name for the action.
Select the action type (send email only at the moment).
Provide an Email address.
Select Create.
After creation, you can edit the action configuration or delete it if it is not needed anymore.
The details view of a created action contains an option to list the execution history of an alarm.
You can only delete an action when it is not in use by an alarm.
Access MaaS inside of the using the Monitoring Manager or via the Inspector. |
Learn how to grant, modify and revoke user privileges. |
Use the Monitoring Manager to set Alarms and modify resulting Actions |
CPU |
|
Network |
|
Storage |
|
Using MaaS requires the use of different APIs. Most APIs support basic authentication such as username and password. The exception is the TelemetryAPI. The Telemetry API requires authentication via JSON Web Token (JWT). Authentication via JWT is supported on all APIs as well.
The following APIs must be considered when using MaaS via API. Clicking on each API LINK leads to the specification file:
Consult the sections below to learn more about each API and its relevance to MaaS.
The AuthAPI is an endpoint that is used for the management of JSON Web Tokens (JWT). Any token created has a Time to Live (TTL), therefore it will expire after some time. This TTL cannot be managed by the user.
The number of tokens per identity is limited. Currently, the limit is 50. This limit is subject to change. If the limit is reached you will receive an error message indicating that no further tokens can be generated. In this event, you must delete existing tokens to create new tokens. Expired tokens will not be cleared automatically.
Initially, this API requires authentication via basic authentication (username and password) to generate the first token. Afterward, you can continue using basic authentication but you can also use JWToken to operate the AuthAPI.
If you are a reseller contract owner your account is a member of multiple contracts. Therefore, you must provide the contract number in the form of the header “X-Contract-Number” as the token must be generated in the scope of a contract.
AuthAPI documentation
To generate the first token, execute the following GET call:
The response payload will contain the JWToken that can be used in other APIs. Please read the linked API documentation for further API resources as well as how to manage your token afterward.
When using JWToken, make sure to set authentication to “bearer” so that the application is aware that you will submit a JWToken and not encrypted basic authentication credentials.
Using CloudAPI is optional. It is only needed if you want to grant access to the monitoring feature, especially alarms and actions, to other users who are members of your contract.
The CloudAPI supports basic authentication as well as bearer authentication via JWToken.
CloudAPI documentation
CloudAPI is available in multiple versions. The respective user management properties for granting access to monitoring are introduced in version 6 of the API. Previous versions will not allow managing the respective property.
The MonitoringAPI is a separate service while the API endpoint is included inside the CloudAPI basepath.
The Monitoring resources do not require the versioning tag inside the URL. The MonitoringAPI supports basic authentication (username and password) as well as bearer authentication (JWT).
The MonitoringAPI allows managing (create/read/update/delete) monitoring alarms as well as actions. It contains the same properties, as mentioned above, inside the DCD description. It can be used in the same way.
MonitoringAPI documentation
The TelemetryAPI is an API endpoint compatible with Prometheus specifications. It only supports bearer authentication (JWT). You can find Prometheus documentation below:
The TelemetryAPI allows retrieval of instance metrics. HTTP operations, other than GET, are not allowed.
Although the Prometheus specification contains many more API resources and operations, the TelemetryAPI selectively supports the following GET operations at the moment:
| Default Values |
|---|
| Default Values |
|---|
| Default Values |
|---|
| Default Values |
|---|
| Method | Request URI |
|---|
"unit": "total"
"rangeAggregation": "average"
"comparisonOperator": "greater_than_or_equal_to_threshold
"unit": "total"
"comparisonOperator": "greater_than_or_equal_to_threshold
"range": "4m"
"rangeAggregation": "average"
"unit": "total"
"rangeAggregation": "average"
"comparisonOperator": "greater_than_or_equal_to_threshold"
API LINK | Description |
Auth API allows management of JSON Web Tokens. |
Cloud API is optional. It is used for managing user privileges. |
Monitoring API sets alarms & alerts and retrieves alarm history. |
Telemetry API retrieves raw metrics of a virtual instance. This interface is compatible with Prometheus API. |
GET |
Grafana is an open source platform for data visualization, monitoring and analysis. You may integrate this software with the Monitoring as a Service for more convenient use.
Go to the
Install
Generate the first token
curl -uusername:password or -n if you use
It is also possible to query the metrics using curl:
curl -H "Authorization: Bearer ${TOKEN}"
Login to Grafana
Configuration (on the left side)
Data source
Custom HTTP Headers
Header: Authorization Value: Bearer eyJ0eXAiOiJK....
HTTP Method: POST
Save & Test
Go to Explore (on the left side)
Choose the new Data source
In the Metrics Browser, write instance
Choose one of the metrics
Run query
You can query on these metrics now:
series whitelist:
- instance_cpu_utilization_average
- instance_network_in_packets
- instance_network_out_bytes
- instance_network_in_bytes
- instance_network_out_packets
- instance_volumes_read_bytes
- instance_volumes_write_bytes
- instance_volumes_read_ops
- instance_volumes_write_ops
URL:
