All Products
Search
Document Center

Simple Log Service:UpdateLogStore

Last Updated:Jul 24, 2026

Updates the attributes of a Logstore.

Operation description

Operation description

  • Before updating a Logstore, call the GetLogStore operation to obtain the current Logstore configuration. Modify the configuration as needed and pass it as parameters to the UpdateLogStore operation.

  • The Host in the request syntax consists of the project name and the Simple Log Service endpoint. Specify the project in the Host.

  • An AccessKey pair has been created and obtained. For more information, see AccessKey pair.

An Alibaba Cloud account AccessKey pair has access permissions on all API operations. This poses a high security risk. We recommend that you create and use a Resource Access Management (RAM) user to call API operations or perform routine O&M. The RAM user must have the required permissions on Simple Log Service EPS resources. For more information, see Create a RAM user and authorization.

Operation logs are generated when you call this operation.

Authentication resources

The following table lists the authorization information for this API operation. You can add the information to the Action element in a RAM access policy statement to grant a Resource Access Management (RAM) user or RAM role the permissions to invoke this API operation.

ActionResource
log:UpdateLogStoreacs: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

The table below describes the authorization required to call this API. You can define it in a Resource Access Management (RAM) policy. The table's columns are detailed below:

  • Action: The actions can be used in the Action element of RAM permission policy statements to grant permissions to perform the operation.

  • API: The API that you can call to perform the action.

  • Access level: The predefined level of access granted for each API. Valid values: create, list, get, update, and delete.

  • Resource type: The type of the resource that supports authorization to perform the action. It indicates if the action supports resource-level permission. The specified resource must be compatible with the action. Otherwise, the policy will be ineffective.

    • For APIs with resource-level permissions, required resource types are marked with an asterisk (*). Specify the corresponding Alibaba Cloud Resource Name (ARN) in the Resource element of the policy.

    • For APIs without resource-level permissions, it is shown as All Resources. Use an asterisk (*) in the Resource element of the policy.

  • Condition key: The condition keys defined by the service. The key allows for granular control, applying to either actions alone or actions associated with specific resources. In addition to service-specific condition keys, Alibaba Cloud provides a set of common condition keys applicable across all RAM-supported services.

  • Dependent action: The dependent actions required to run the action. To complete the action, the RAM user or the RAM role must have the permissions to perform all dependent actions.

Action

Access level

Resource type

Condition key

Dependent action

log:UpdateLogStore

update

*LogStore

acs:log:{#regionId}:{#accountId}:project/{#project}/logstore/{#logstore}

  • log:TLSVersion
  • log:Encrypted
None

Request syntax

PUT /logstores/{logstore} HTTP/1.1

Path Parameters

Parameter

Type

Required

Description

Example

logstore

string

Yes

The name of the Logstore.

test-logstore

Request parameters

Parameter

Type

Required

Description

Example

project

string

Yes

The name of the project.

ali-test-project

body

object

Yes

The request body parameters.

logstoreName

string

Yes

The name of the Logstore.

test-logstore

shardCount deprecated

integer

No

The number of shards.

Note

This operation does not support updating the number of shards. You can modify the number of shards only by calling the SplitShard or MergeShards operation.

2

ttl

integer

Yes

The data retention period. Unit: days. Valid values: 1 to 3650. A value of 3650 indicates permanent retention.

30

encrypt_conf EncryptConf

No

The encryption configuration. Encryption is disabled by default.

Example 1 (enable default encryption):

{
    "enable": true,
    "encrypt_conf": "default"
}

Example 2 (enable BYOK encryption):

{
    "enable": true,
    "encrypt_conf": "default",
    "user_cmk_info": {
        "cmk_key_id": "xxxxx",
        "arn": "acs:ram::112340000000:role/rolename",
        "region": "ap-southeast-1"
    }
}

autoSplit

boolean

No

Specifies whether to enable automatic sharding. After this feature is enabled, a shard is automatically split when the write traffic continuously exceeds the limit, which improves write capacity. You must set maxSplitShard (the maximum number of shards after splitting) when you enable automatic sharding.

true

enable_tracking

boolean

No

Specifies whether to enable the WebTracking feature. Default value: false. You can use the WebTracking feature to collect and analyze user behavior data in browsers or mini programs, such as page views, purchase records, and time on site.

  • true: enables WebTracking.

  • false: disables WebTracking.

false

appendMeta

boolean

No

Specifies whether to record the public IP address and log arrival time. Default value: false.

  • true: enables the feature. After this feature is enabled, Simple Log Service automatically adds the public IP address of the log source device and the time when the log arrives at the server to the Tag field of the log.

  • false: disables the feature.

false

maxSplitShard

integer

No

The maximum number of shards for automatic sharding. Minimum value: 1. Maximum value: 256.

Note

This parameter is required when autoSplit is set to true.

64

telemetryType deprecated

string

No

The type of observable data. The default value is log data. Valid values:

  • None: log data. This is the default value.

  • Metrics: time series data.

None

hot_ttl

integer

No

The retention period of data in the hot tier of the Logstore. Unit: days. Minimum value: 7. The value cannot exceed the value of ttl. By default, all data within the retention period is stored in the hot tier.

After the data storage time exceeds the configured hot data retention period, the data is moved to the infrequent access (IA) tier. When you enable the IA tier, the hot data retention period must be at least 7 days. For more information, see Intelligent tiering.

Examples:

  • Scenario 1 (hot tier only, 30 days): {"ttl": 30} or {"ttl": 30, "hot_ttl": 30}

  • Scenario 2 (hot tier 7 days, IA tier 23 days): {"ttl": 30, "hot_ttl": 7}

60

mode

string

No

Simple Log Service provides two types of Logstores: Standard and Query.

  • standard: supports one-stop data analytics capabilities of Simple Log Service. This type is suitable for scenarios such as real-time monitoring, interactive analysis, and building complete observability systems.

  • query: supports high-performance queries. The index traffic fee is approximately half that of the Standard type. However, SQL analysis is not supported. This type is suitable for scenarios with large data volumes, long storage periods (weeks or months), and no log analysis requirements.

standard

infrequentAccessTTL

integer

No

Infrequent access (IA) tier. No minimum storage time is required. Data must be stored for at least 30 days before being moved to the archive tier.

When the log retention period exceeds the sum of the hot tier retention period and the IA tier retention period, the remaining storage time is converted to archive tier storage.

Examples:

  • Scenario 1 (hot tier 7 days, IA tier 23 days): {"ttl": 30, "hot_ttl": 7}

  • Scenario 2 (hot tier 7 days, IA tier 30 days, archive tier 60 days): {"ttl": 97, "hot_ttl": 7, "infrequentAccessTTL": 30}

  • Scenario 3 (hot tier 60 days, IA tier 0 days, archive tier 60 days): {"ttl": 120, "hot_ttl": 60, "infrequentAccessTTL": 0}

30

shardingPolicy ShardingPolicy

No

The hash-based write configuration. When data is written, logs are routed to shards based on the configured hash policy. Before configuring this parameter, ensure that the hash ranges of shards are evenly distributed. This configuration may affect write capacity. Proceed with caution.

Response elements

Element

Type

Description

Example

None defined.

Examples

Success response

JSON format

{}

Error codes

See Error Codes for a complete list.

Release notes

See Release Notes for a complete list.