GetLogs - Simple Log Service

Operation description

Note

Simple Log Service supports scheduled SQL jobs. For more information, see Create a scheduled SQL job.

The Host in the request syntax consists of the project name and the Simple Log Service endpoint. You must specify the project name in the Host.
Create and obtain an AccessKey pair. For more information, see AccessKey pair.

An AccessKey pair that belongs to an Alibaba Cloud account has permissions to access all APIs. This poses a high security risk. We strongly recommend that you create and use a RAM user to make API calls or perform routine operations and maintenance (O&M). The RAM user must have the required permissions to access Simple Log Service resources. For more information, see Create and authorize a RAM user.

Obtain the name and region of the project, and the name of the Logstore that contains the logs you want to query. For more information, see Manage a project and Manage a Logstore.
Simple Log Service imposes limits on log queries. Therefore, you must design appropriate query and analytic statements and set a reasonable query time range. For more information, see Log query limits and Log analysis limits.
You must configure indexes before you query logs. For more information, see Create indexes.
If the number of logs that match a query varies greatly, the Simple Log Service API cannot predict the number of times you must call this operation to obtain the complete result. Check the value of the x-log-progress header in each response to determine whether to call the operation again. Each repeated call consumes the same number of query capacity units (CUs).
When a log is written to a Logstore, the latency before the log is queryable using the GetHistograms and GetLogs operations varies based on the log type. Simple Log Service classifies logs into the following two types based on their timestamps:
- Real-time data: The timestamp of the log is within the time range of (-180 seconds, 900 seconds] relative to the current server time. For example, if a log is generated at UTC 2014-09-25 12:03:00 and is received by the server at UTC 2014-09-25 12:05:00, the log is processed as real-time data. This typically occurs in normal scenarios. The latency for real-time data to become queryable is about 3 seconds.
- Historical data: The timestamp of the log is within the time range of [-7 × 86,400 seconds, -180 seconds) relative to the current server time. For example, if a log is generated at UTC 2014-09-25 12:00:00 and is received by the server at UTC 2014-09-25 12:05:00, the log is processed as historical data. This typically occurs in data backfill scenarios.

Note

Simple Log Service calculates the difference between the log time (the __time__ field) and the server receipt time (the __tag__: receive_time field). If the difference is in the range of (-180 seconds, 900 seconds], the log is real-time data. If the difference is in the range of [-7 × 86,400 seconds, -180 seconds), the log is historical data.

Simple Log Service provides examples of how to use the GetLogs operation in Java and Python software development kits (SDKs). For more information, see GetLogs examples for Java and GetLogs examples for Python.

Authorization

The following table describes the authorization information that is required for this operation. You can add this information to the Action element of a RAM access policy statement to grant RAM users or RAM roles the permission to call this operation.

Action	Resource
`log:GetLogStoreLogs`	`acs:log:{#regionId}:{#accountId}:project/{#ProjectName}/logstore/{#LogstoreName}`

Try it now

Try this API in OpenAPI Explorer, no manual signing needed. Successful calls auto-generate SDK code matching your parameters. Download it with built-in credential security for local usage.

Test

RAM authorization

No authorization for this operation. If you encounter issues with this operation, contact technical support.

Request syntax

GET /logstores/{logstore}?type=log HTTP/1.1

Path Parameters

Parameter	Type	Required	Description	Example
logstore	string	Yes	The Logstore from which to query data.	example-logstore

Request parameters

Parameter	Type	Required	Description	Example
project	string	Yes	The name of the project.	ali-test-project
from	integer	Yes	The start of the time range to query. This time is the log time that is specified when the log data is written. The time range that is specified by the from and to parameters is a left-closed, right-open interval. The interval includes the start time but not the end time. If the values of from and to are the same, the interval is invalid. The system returns an error. The value is a UNIX timestamp. It represents the number of seconds that have elapsed since the epoch time January 1, 1970, 00:00:00 UTC. Note To make sure that no data is missed, snap the query time to the minute. If you specify a time range in an analytic statement, the time range in the analytic statement is used for the query and analysis. To specify a time in seconds, use the from_unixtime function or the to_unixtime function to convert the time format in the analytic statement. Examples: `* \| SELECT * FROM log WHERE from_unixtime(__time__) > from_unixtime(1664186624) AND from_unixtime(__time__) < now()` `* \| SELECT * FROM log WHERE __time__ > to_unixtime(date_parse('2022-10-19 15:46:05', '%Y-%m-%d %H:%i:%s')) AND __time__ < to_unixtime(now())`	1627268185
to	integer	Yes	The end of the time range to query. This time is the log time that is specified when the log data is written. The time range that is specified by the from and to parameters is a left-closed, right-open interval. The interval includes the start time but not the end time. If the values of from and to are the same, the interval is invalid. The system returns an error. The value is a UNIX timestamp. It represents the number of seconds that have elapsed since the epoch time January 1, 1970, 00:00:00 UTC. Note To make sure that no data is missed, snap the query time to the minute. If you specify a time range in an analytic statement, the time range in the analytic statement is used for the query and analysis. To specify a time in seconds, use the from_unixtime function or the to_unixtime function to convert the time format in the analytic statement. Examples: `* \| SELECT * FROM log WHERE from_unixtime(__time__) > from_unixtime(1664186624) AND from_unixtime(__time__) < now()` `* \| SELECT * FROM log WHERE __time__ > to_unixtime(date_parse('2022-10-19 15:46:05', '%Y-%m-%d %H:%i:%s')) AND __time__ < to_unixtime(now())`	1627269085
query	string	No	The search statement or analytic statement. For more information, see Query overview and Analysis overview. To use the Exclusive SQL feature, add `set session parallel_sql=true;` to the analytic statement in the query parameter. Example: `* \| set session parallel_sql=true; select count() as pv`. For information about common query and analysis issues, see Common errors that occur when you query and analyze logs. Note* If the query parameter contains an analytic statement (SQL statement), the line and offset parameters are invalid. We recommend that you set these parameters to 0. You must use the LIMIT clause in the SQL statement to turn pages. For more information, see Page through query and analysis results.	status: 401 \| SELECT remote_addr,COUNT(*) as pv GROUP by remote_addr ORDER by pv desc limit 5
topic	string	No	The topic of the logs. The default value is an empty string. For more information, see Topic.	topic
line	integer	No	This parameter is valid only when the query parameter is a search statement. It specifies the maximum number of logs to return for the request. The value ranges from 0 to 100. The default value is 100. For more information about paged queries, see Page through query and analysis results.	100
offset	integer	No	This parameter is valid only when the query parameter is a search statement. It specifies the start line of the query. The default value is 0. For more information about paged queries, see Page through query and analysis results.	0
reverse	boolean	No	Specifies whether to return logs in descending order of their timestamps. The precision is at the minute level. true: Returns logs in descending order of their timestamps. false (default): Returns logs in ascending order of their timestamps. Important If the query parameter is a search statement, the reverse parameter is valid and specifies the sorting order of the returned logs. If the query parameter is a search and analytic statement, the reverse parameter is invalid. The sorting order is specified by the ORDER BY clause in the SQL analytic statement. If the ORDER BY clause specifies asc (default), the logs are sorted in ascending order. If the ORDER BY clause specifies desc, the logs are sorted in descending order.	false
powerSql	boolean	No	Specifies whether to use the Exclusive SQL feature. For more information, see Enable the Exclusive SQL feature. true: Use the Exclusive SQL feature. false (default): Use the standard SQL feature. In addition to using the powerSql parameter, you can also use the query parameter to enable the Exclusive SQL feature.	false

Response elements

Element	Type	Description	Example
	array	The array of logs. Each element is a log.
	object	The array of logs. Each element is a log.	[{'remote_addr': '198.51.XXX.XXX', 'pv': '1', '__source__': '', '__time__': '1649902984'}, {'remote_addr': '198.51.XXX.XXX', 'pv': '1', '__source__': '', '__time__': '1649902984'}, {'remote_addr': '198.51.XXX.XXX', 'pv': '1', '__source__': '', '__time__': '1649902984'}, {'remote_addr': '198.51.XXX.XXX', 'pv': '1', '__source__': '', '__time__': '1649902984'}, {'remote_addr': '198.51.100.XXX', 'pv': '1', '__source__': '', '__time__': '1649902984'}]

Examples

Success response

JSON format

[
  {
    "test": "test",
    "test2": 1
  }
]

Error codes

See Error Codes for a complete list.

Release notes

See Release Notes for a complete list.