The monitoring service of OSS provides metrics to measure the running status and performance of the system. The monitoring service also provides a custom alert service to help you track requests, analyze usage, collect statistics on business trends, and discover and diagnose system problems in a timely manner.
Metrics of the OSS monitoring service are classified into basic service metrics, performance metrics, and billable usage metrics. For more information, see Metrics.
High real-time performance
Real-time monitoring can reveal potential traffic fluctuations during various periods. This facilitates the analysis and evaluation of business scenarios. Real-time monitoring metrics (except for billable usage metrics) allow for minute-level metric data to be collected and aggregated with an output delay of less than a minute. User information that is collected every minute is aggregated into a single value and displayed within one minute to represent the overall monitoring for the minute.
Billable usage metrics
In line with the billing policies, billable usage metrics are collected and presented based on the following criteria:
- Billable usage metric data is collected each hour. Resource metering data for each hour is aggregated into a single value that represents the overall monitoring for that hour.
- Billable usage metric data is displayed with a delay of nearly 30 minutes.
- The statistics collection time is the start time of the relevant statistical period.
- The statistics collection deadline is the end time of the last statistical period of the current month. If no metric data is produced in the current month, the statistics collection deadline is 00:00:00 on the first day of the current month.
- A maximum amount of metric data is pushed for presentation. For precise metric data, go to the Billing Management console and click Usage Records.
For example, you only use PutObject requests to upload data and perform the operation an average of 10 times per minute. Then in the hour from 08:00:00 to 09:00:00 on May 10, 2018, the metric value of the number of PUT requests is 600 (10 × 60 minutes), the statistics collection time is 08:00:00 on May 10, 2018, and the data is displayed at around 09:30:00 on May 10, 2018. If the data is the last metric data from 00:00 on May 01, 2018, the statistics collection deadline for the current month is 09:00:00 on May 10, 2018. If you have not produced any metric data in May 2018, the statistics collection deadline will be 00:00:00 on May 1, 2018.
OSS alert service
You can use an account to set up to 1,000 alert rules. You can configure alert rules for other monitoring metrics in addition to billable usage metrics and statistical metrics. You can also configure multiple alert rules for a single metric.
Metric data retention policy
Metric data is retained for 31 days before being automatically cleared upon expiration. To store or perform offline analysis on metric data that is over 31 days old, you can use tools or write code to read the CloudMonitor data storage. For more information, see Access metric data by using the CloudMonitor API.
The OSS console displays metric data from the last seven days. To query metric data that is older than seven days, we recommend that you use CloudMonitor SDKs. For more information, see Access metric data by using the CloudMonitor OpenAPI.
Access metric data by using the CloudMonitor OpenAPI
Monitoring, diagnosis, and troubleshooting
The Service monitoring, diagnosis, and troubleshooting topic describes how to monitor the running status of OSS and perform diagnosis and troubleshooting. This topic provides an overview of the following aspects:
- OSS monitoring
Describes how to use the OSS monitoring service to monitor the running status and performance of OSS.
- Tracking and diagnosis
Describes how to use the OSS monitoring service and logging function to diagnose problems as well as how to associate the relevant information in log files for tracking and diagnosis.
Describes typical problems and methods to troubleshoot the problems.
Bucket names must be globally unique in OSS. If you delete a bucket and then create a bucket with the same name as the deleted bucket, the monitoring and alert rules set for the deleted bucket will be applied to the new bucket.