Restrictions

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
OS	Version
SUSE	SUSE Enterprise 11 SP4 64-bit	SUSE Enterprise 12 SP1 64-bit	SUSE Enterprise 12 SP2 64-bit	SUSE Enterprise 12 SP3 64-bit
openSUSE	13.2 64-bit	42.2 64-bit	15.0 64-bit (Currently, syslog logs cannot be collected.)
EulerOS	2.2 64-bit	2.3 64-bit	2.5 64-bit
CentOS	6.3 64-bit	6.5 64-bit	6.8 64-bit	6.9 64-bit	6.10 64-bit
CentOS	7.1 64-bit	7.2 64-bit	7.3 64-bit	7.4 64-bit	7.5 64-bit	7.6 64-bit
Ubuntu	14.04 server 64-bit	16.04 server 64-bit	18.04 server 64-bit
Fedora	24 64-bit	25 64-bit	29 64-bit
Debian	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
Category	Object	Usage Restrictions
Dashboard	Dashboard	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 can be added to a line graph, and resources can be selected across clusters. Only one resource can be added to a digital 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	Metric data	Metric data can be stored in the database for up to 30 days.
	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.
	Dimension	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	No restrictions.
	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.
Log	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. It is recommended that the log generation speed of a single node be 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.
Alarm center	Alarm	You can query the alarms generated in the last 15 days.
Alarm center	Event	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