CSS provides log query and log backup, enabling you to easily manage and analyze logs to efficiently locate faults, optimize performance, and enhance system security.
When log backup is enabled, the generated log backups are stored in OBS buckets, which will result in additional costs. For details, see .
The OBS bucket used for storing log backups has been created. The OBS bucket must meet the following requirements:
You can search records by log type, node, log level, or keyword. For a detailed description of each type of logs, see Log Introduction.
When a log file reaches 128 MB or when the time reaches 00:00 UTC, the system automatically compresses and archives it. Only unarchived logs appear on the log search page, while archived logs remain accessible through the log backup function.
Cluster logs can be backed up to OBS buckets, where you can download them for in-depth analysis at any time.
Logs are backed up incrementally. After the backup is successful, you can access the target OBS bucket to obtain the full log files by clicking Log Path.
Table 3 lists the log types, where clustername indicates the cluster name.
Log Name | Description |
|---|---|
clustername_deprecation.log | Deprecation log file |
clustername_index_indexing_slowlog.log | Slow indexing log file |
clustername_index_search_slowlog.log | Slow query log file |
clustername.log | Run log file |
clustername_access.log | Access log file |
On the Log Backup page, click Disable Backup. In the displayed dialog box, click OK. Disabling log backup does not automatically delete existing log backups. Instead, you need to manually delete them on the OBS console.
Log Type | Description | Purpose |
|---|---|---|
Run logs | Run logs, or main logs, record the cluster status and key information about write and query operations. For example, write logs record operations such as index creation, index mapping update, and write queue exhaustion; and query logs record query queue status and query exceptions. | Check the status and write and query operations of each cluster node, including inter-node connectivity, full GC, index creation or deletion, and cluster-level query errors. |
Slow indexing logs | Slow indexing logs record indexing operations (such as bulk, index, update, and delete) that took a long time to complete, helping you identify performance bottlenecks. | In the case of slow write performance, you can query slow indexing logs to locate the cause. |
Slow query logs | Slow query logs record search requests that took a long time to complete. They help you monitor and analyze time-consuming search requests, so you can identify performance bottlenecks, optimize SQL queries, and improve overall system performance. | In the case of slow query performance, you can query slow query logs to locate the cause. |
Deprecation logs | Deprecation logs record deprecation warnings. Deprecation warnings are written to this log when you use APIs, configurations, or functions that are marked for removal in future versions. | Check for APIs or features that are about to expire in future versions. |
Access logs | Access logs record cluster access requests, such as the request path and source address. You cannot check access logs on the console. To check them, you need to back them up to an OBS bucket or transfer them to a target cluster first. | If there is a surge in service requests, you can analyze the request sources and paths by checking the access logs. |
Run logs record the cluster status and key information about write and query operations. For example, the log record below indicates that an index named test was created and afterwards the cluster status changed from YELLOW to GREEN.
Figure 1 Run log sample

Log content:
Slow indexing logs record indexing operations that took a long time to complete. For example, the log record below shows an indexing request that lasted longer than the preset threshold. The log contains the index name, duration, and request content.
Figure 2 Slow indexing log sample

Log content:
1. Log generation time
Slow query logs record search requests that took a long time to complete. For example, the log record below shows a search request that lasted longer than the preset threshold. The log contains the index name, duration, and request content.
Figure 3 Slow query log sample

Log content:
Deprecation logs record deprecation warnings. For example, the log record below indicates that GET /_cat/master has been deprecated and should be replaced with GET /_cat/cluster_manager.
Figure 4 Deprecation log sample

Log content:
Access logs record cluster access requests and source addresses. For example, the log record below has recorded source information for the /_snapshot/my_backup/my_snapshot/_restore?pretty=true operation.
Figure 5 Access log sample

Log content:
Log4j2 is used as the log component in OpenSearch clusters. Multiple log levels (ERROR, WARN, INFO, DEBUG, and TRACE) are supported. The default log level is INFO. To facilitate troubleshooting and debugging, you can dynamically adjust the log levels.
Example
The left part of the console is the command input box, and the triangle icon in its upper-right corner is the execution button. The right part shows the execution result.
PUT _cluster/settings{"persistent": {"logger": {"org.opensearch.action": "DEBUG"}}}
PUT _cluster/settings{"persistent": {"logger": {"org.opensearch.action": null}}}
To facilitate troubleshooting, debugging, and performance analysis, you may enable trace logging for the HTTP/Transport module and view detailed trace logs.
Enabling trace logging is a non-persistent configuration and will be disabled upon a cluster restart.
Operation Guide
The left part of the console is the command input box, and the triangle icon in its upper-right corner is the execution button. The right part shows the execution result.
PUT _cluster/settings{"transient": {"logger.org.opensearch.transport.TransportService.tracer": "trace","transport.tracer.include": "","http.tracer.include": "","logger.org.opensearch.http.HttpTracer": "trace"}}