SLS data model - regions, projects, Logstores, logs - Simple Log Service

The following concepts describe the SLS data model.

Region

A region is an Alibaba Cloud service node. Deploy services in different regions to reduce access latency for your users.

Project

A project is the basic management unit in SLS for resource isolation and control. Use a project to manage all logs and log sources for an application.

Logstore

A Logstore is the unit for log collection, storage, and consumption in SLS. Each Logstore belongs to a project, and a project can contain multiple Logstores. Best practice: create one Logstore per log type. For example, for a game application named big-game that generates operation logs, application logs, and access logs, create a project named big-game with three Logstores—one for each log type.

Log

A log is the smallest data unit in SLS. SLS uses the following semi-structured data model:

Field	Description	Requirements
time	Reserved field. The time the log was generated, typically extracted from the log timestamp.	Integer. UNIX timestamp in seconds (seconds elapsed since 00:00:00 UTC, January 1, 1970).
topic	Custom field for categorizing logs. For example, categorize access logs by site.	Any string, including an empty string, up to 128 bytes. The default is an empty string.
source	Log source, such as the IP address of the originating machine.	Any UTF-8 encoded string up to 128 bytes. The default is an empty string.
content	Log content, consisting of one or more key-value pairs.	Key: UTF-8 string, up to 128 bytes. Allowed characters: letters, digits, and underscores (_). Cannot start with a digit. Reserved keys: `__time__` `__source__` `__topic__` `__partition_time__` `__extract_others__` `__extract_others__` Value: any UTF-8 string, up to 1 MB.
tags	Log tags: Custom: added when writing data via the PutLogs API. Server-side: added by the service, including `__client_ip__` and `__receive_time__`.	Dictionary format. Both key and value are strings. In the console, tags display with the `__tag__:` prefix.

Topic

Logs in a Logstore can be categorized by topic. Specify a topic when writing logs, then filter by topic when querying. For example, use a user ID as the topic so each user sees only their own logs. If categorization is unnecessary, use the same topic for all logs.

Note An empty string is a valid topic and is the default for both writing and querying. If you do not need topics, use the default empty string.

The following example maps a raw Nginx access log to the SLS data model. The Nginx server IP address is 10.10.10.1:

10.1.1.1 - - [01/Mar/2012:16:12:07 +0800] "GET /Send?AccessKeyId=82251054** HTTP/1.1" 200 5 "-" "Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2"

This raw log maps to the SLS data model as follows:

Field	Content	Description
topic	None	The default value (an empty string) is used.
time	1330589527	Exact log generation time in seconds, converted from the raw log timestamp.
source	10.10.10.1	The server IP address is used as the log source.
content	Key-value pairs	The specific content of the log.

You can extract the raw log content into key-value pairs as follows:

key	value
ip	10.1.1.1
method	GET
status	200
length	5
ref_url	-
browser	Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2

Logs

A collection of logs.

LogGroup

A group of logs.

LogGroupList

A collection of LogGroups for returning results.

Encoding methods

SLS supports the following encoding methods. Specify the method via the Content-Type header in the RESTful API.

Meaning	Description	Content-Type
Protobuf	Protobuf-encoded data model.	application/x-protobuf

Protobuf format details: Data encoding methods.

Note

Protobuf does not require unique key-value pairs, but duplicate keys can cause undefined behavior.

Encode fields in the order of their Protobuf field numbers. Out-of-order fields may fail to parse.