This topic provides answers to frequently asked questions about OSS monitoring service.
OSS and Cloud Monitor are two Alibaba Cloud services. OSS sends data to Cloud Monitor for analysis and processing. Statistics on the storage and traffic usage displayed in the OSS console are collected by Cloud Monitor.
Latencies of two to three hours exist when OSS sends data to Cloud Monitor. The interval at which OSS sends data cannot exceed five minutes. If the interval exceeds five minutes, Cloud Monitor rejects the data and the data cannot be sent again. Therefore, we recommend that you do not calculate the fees based on the data from Cloud Monitor. To check fees, we recommend that you contact after-sales technical support to submit a ticket.
What do I do if the status of the alert rule displays Insufficient Data?
Solution: You can view data on the Monitoring Service Overview tab of the Users tab. The alert rule displays Insufficient Data if no data is generated.
What do I do if the data of object upload or download is not updated in real time in the Cloud Monitor console?
Cause: The latest data that is visible in the Cloud Monitor console is detected by sending requests, during which latencies exist.
- Check whether latencies of access to the client exist.
- Capture packets to analyze data if latencies exist when users access the corresponding bucket.
- Analyze access logs to confirm whether latencies exist.
What do I do if latencies of access from the monitoring system of a company to OSS exist?
- Check whether the network works properly. You can ping the IP addresses of other networks to test whether latencies exist.
- Create an ECS server that is located in the same region as the OSS bucket. Start access from the ECS server to the bucket to test whether latencies exist.
- Send the ID of the request with latencies to after-sales technical support. Check whether access latencies exist.
- Capture packets to obtain upload data. Use the following parameters to analyze packets:
tcpdump -i <Outbound port name> -s0 (Public IP address of the host and OSS endpoint) -w result.pcap
What do I do if the valid request rate is low?
Problem description: Cloud Monitor displays a message, indicating that OSS bucket p2xxx of 135114002 has a valid request rate of 30.51%, which is lower than 90%, and the error lasts zero minutes.
Solution: The abnormal request rate is calculated based on the formula: Abnormal request rate = Count of 2xx and 3xx responses/Total count of responses. You can view the ratios of abnormal responses including 2xx and 3xx responses, and confirm whether the increase of abnormal HTTP status codes leads to the decrease of valid request rates. You can also enable OSS real-time analysis.
What do I do if Cloud Monitor returns HTTP status code 404?
Problem description: Cloud Monitor displays a message, indicating that the number of error requests to resources in OSS bucket ***-ali of 197*****745 that do not exist is 30, and the error lasts five minutes and is fixed at 11:45.
Cause: The requested resources do not exist. The response is normal.
What do I do if Cloud Monitor returns NoSuchWebSiteConfigration?
Cause: The loaded feature configurations do not exist when the client requests OSS data. As a result, HTTP status code 404 is returned. HTTP status code 200 is returned if the feature is configured. These cases are normal.
Why does the OSS console display no statistics on API operations?
Cause: Statistics on API operations are displayed the next day. For example, statistics on API operations on October 12 are displayed on October 13.in OSS, which is normal.
What do I do if data is inaccurate when I check bills generated for OSS monitoring service?
- Enable OSS logging and check bills based on statistics on OSS logs.
- Enable OSS real-time log analysis to import, analyze, and process logs and view the results.
What do I do if Cloud Monitor shows that the valid request rate during a certain period is decreased to 0 but the data in OSS logs and the OSS console is reasonable?
Cause: Cloud Monitor calculates the valid request rate based on the formula: 100% - Count of 2xx and 3xx responses/Total count of responses. Solution: Check whether exceptions exist in the OSS console or OSS logs.
Cause: The time OSS uses to send the entire cluster logs to Cloud Monitor exceeds the time window predetermined by Cloud Monitor. However, Cloud Monitor rejects data that fails to be received for the first time.