What Are the Usage Restrictions of AOM?

OS Usage Restrictions

AOM supports multiple operating systems (OSs). When creating a host, ensure that its OS meets the requirements in Table 1. Otherwise, the host cannot be monitored by AOM.

Table 1 OSs and versions supported by AOM




SUSE Enterprise 11 SP4 64-bit

SUSE Enterprise 12 SP1 64-bit

SUSE Enterprise 12 SP2 64-bit

SUSE Enterprise 12 SP3 64-bit


13.2 64-bit

42.2 64-bit

15.0 64-bit (Currently, syslog logs cannot be collected.)


2.2 64-bit

2.3 64-bit

2.5 64-bit


6.3 64-bit

6.5 64-bit

6.8 64-bit

6.9 64-bit

6.10 64-bit

7.1 64-bit

7.2 64-bit

7.3 64-bit

7.4 64-bit

7.5 64-bit

7.6 64-bit


14.04 server 64-bit

16.04 server 64-bit

18.04 server 64-bit


24 64-bit

25 64-bit

29 64-bit


7.5.0 32-bit

7.5.0 64-bit

8.2.0 64-bit

8.8.0 64-bit

9.0.0 64-bit


  • For Linux x86_64 servers, AOM supports all the OSs and versions listed in the preceding table.

  • For Linux Arm servers, AOM only supports CentOS 7.4 and later versions, and other OSs and versions listed in the preceding table.

Resource Usage Restrictions

When using AOM, learn about the restrictions in Table 2.

Table 2 Resource usage restrictions



Usage Restrictions



A maximum of 50 dashboards can be created in a region.

Graph in a dashboard

A maximum of 20 graphs can be added to a dashboard.

Number of resources, threshold rules, components, or hosts in a graph

  • A maximum of 100 resources across clusters can be added to a line graph.

  • Only one resource can be added to a digit graph.

  • A maximum of 10 threshold rules can be added to a threshold status graph.

  • A maximum of 10 hosts can be added to a host status graph.

  • A maximum of 10 components can be added to a component status graph.


Metric data

Metric data can be stored in the database for up to 30 days.

Total number of metrics

Up to 400,000 for a single account.

Up to 100,000 for a small specification.

Metric item

After resources such as clusters, components, and hosts are deleted, their related metrics can be stored in the database for a maximum of 30 days.


A maximum of 20 dimensions can be configured for a metric.

Metric query API

A maximum of 20 metrics can be queried at a time.

Statistical period

The maximum statistical period is 1 hour.

Data points returned for a single query

A maximum of 1440 data points can be returned each time.

Custom metric


Custom metric to be reported

A single request cannot exceed 40 KB. The timestamp of a reported metric cannot 10 minutes later than the standard UTC time. In addition, out-of-order metrics are not received. That is, if a metric is reported at a certain time point, the metrics of earlier time points cannot be reported.

Application metric

  • When the number of containers on a host exceeds 1000, the ICAgent stops collecting application metrics and sends the ICAgent Stopped Collecting Application Metrics alarm (ID: 34105).

  • When the number of containers on a host is less than 1000, the ICAgent resumes the collection of application metrics and the ICAgent Stopped Collecting Application Metrics alarm is cleared.

Resources consumed by the ICAgent

When the ICAgent collects basic metrics, the resources consumed by the ICAgent are greatly affected by the number of containers and processes. On a VM without any services, the ICAgent consumes 30 MB memory and records 1% CPU usage. To ensure collection reliability, ensure that the number of containers running on a single node must be less than 1000.


Size of a log

The maximum size of each log is 10 KB. If a log exceeds 10 KB, the ICAgent does not collect it. That is, the log will be discarded.

Log traffic

A maximum of 10 MB/s is supported for each tenant in a region. If the log traffic exceeds 10 MB/s, logs may be lost.

Log file

Only text log files can be collected. Other types of log files, such as binary files, cannot be collected.

The ICAgent can collect a maximum of 20 log files from a volume mounting directory.

The ICAgent can collect a maximum of 1000 standard container output log files. These files must be in JSON format.

Resources consumed during log file collection

The resources consumed during log file collection are closely related to the log volume, number of files, network bandwidth, and backend service processing capability.

Log loss

ICAgent uses multiple mechanisms to ensure log collection reliability and prevent data loss. However, logs may be lost in the following scenarios:

  • The log rotation policy of Cloud Container Engine (CCE) is not used.

  • Log files are rotated at a high speed, for example, once per second.

  • Logs cannot be forwarded due to improper system security settings or syslog itself.

  • The container running time, for example, shorter than 30s, is extremely short.

  • A single node generates logs at a high speed, exceeding the allowed transmit bandwidth or log collection speed. Ensure that the log generation speed of a single node is lower than 5 MB/s.

Log loss

When a single log line exceeds 10,240 bytes, the line will be discarded.

Log repetition

When the ICAgent is restarted, identical data may be collected around the restart time.



You can query the alarms generated in the last 15 days.


You can query the events generated in the last 15 days.


Application discovery rule

You can create a maximum of 100 application discovery rules.

Service Usage Restrictions

If the AMS-Access service is powered off or restarted unexpectedly when you use AOM, a metric data breakpoint occurs on some resources such as hosts, components, and containers in a collection period. This breakpoint is visible on the monitoring page and has no impacts. To avoid breakpoints in a metric graph, set the value of Interpolation Mode to 0 or average on the Metric Monitoring page. In this way, the system automatically replaces breakpoints with 0 or average values, as shown in Figure 1.

**Figure 1** Changing the interpolation mode

Figure 1 Changing the interpolation mode