Облачная платформаAdvanced

Managing Elasticsearch Cluster Logs

Эта статья полезна?
Язык статьи: Английский
Перевести

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.

  • Log query: On the log management page of the CSS management console, you can query the latest log records by node, log type, and other criteria, so you can quickly locate or diagnose issues.
  • Log backup: Cluster logs are periodically synchronized to OBS buckets. You can download them for in-depth analysis at any time. You can configure custom log backup policies by specifying backup schedules and storage locations. The system backs up all critical logs, including run logs, slow query logs, and deprecation logs. They provide comprehensive data for auditing and troubleshooting purposes.

Impact on Billing

When log backup is enabled, the generated log backups are stored in OBS buckets, which will result in additional costs. For details, see .

Prerequisites

The OBS bucket used for storing log backups has been created. The OBS bucket must meet the following requirements:

  • Storage Class: Standard.
  • Region: the same as that of the cluster.

Querying Logs

  1. Log in to the CSS management console.
  2. In the navigation pane on the left, choose Clusters > Elasticsearch.
  3. In the cluster list, click the name of the target cluster. The cluster information page is displayed.
  4. Choose Logs > Log Search. The Log Search page is displayed.

    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.

Backing Up Logs

Cluster logs can be backed up to OBS buckets, where you can download them for in-depth analysis at any time.

  1. Log in to the CSS management console.
  2. In the navigation pane on the left, choose Clusters > Elasticsearch.
  3. In the cluster list, click the name of the target cluster. The cluster information page is displayed.
  4. Choose Logs > Log Backup. The Log Backup page is displayed.
  5. Enable log backup.
  6. Back up logs. Two options are available: automatic or manual.
  7. Check the backed-up log files.

    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.

    Table 3 Log types

    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

  8. If the log backup function is no longer needed, you can disable it.

    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 Introduction

Table 4 Introduction to different log types

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 log description

    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 A sample of run logs


    Log content:

    • 1. Log generation time
    • 2. Log level, which can be DEBUG, INFO, WARN, or ERROR
    • 3. Log-generating module
    • 4. Name of the log-generating node
    • 5. Log content

  • Slow indexing log description

    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 A sample of slow indexing logs


    Log content:

    • 1. Log generation time

    • 2. Log level, which can be DEBUG, INFO, WARN, or ERROR
    • 3. Log-generating module
    • 4. Name of the log-generating node
    • 5. Index name and ID
    • 6. Log content. In this example, the log recorded the request execution duration, index type, and index request body.

  • Slow query log description

    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 A sample of slow query logs


    Log content:

    • 1. Log generation time
    • 2. Log level, which can be DEBUG, INFO, WARN, or ERROR
    • 3. Log-generating module
    • 4. Name of the log-generating node
    • 5. Index name and shard ID
    • 6. Log content. In this example, the log recorded the query duration, number of hits, and query request body.

  • Deprecation log description

    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 A sample of deprecation logs


    Log content:

    • 1. Log generation time
    • 2. Log level, which can only be DEPRECATION.
    • 3. Log-generating module
    • 4. Name of the log-generating node
    • 5. Log content

  • Access log description

    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 A sample of access logs


    Log content:

    • 1. Log generation time
    • 2. Name of the log-generating node
    • 3. Name of the log-generating thread
    • 4. Log level, which can be DEBUG, INFO, WARN, or ERROR.
    • 5. Log request method
    • 6. Request path
    • 7. Source and destination addresses of the request

FAQ: How Do I Change Log Levels?

Log4j2 is used as the log component in Elasticsearch 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.

  • INFO is the default log level. The levels, in order of increasing detail, are: ERROR, WARN, INFO, DEBUG, and TRACE. When INFO is set, you will see logs for itself and all higher-severity levels (ERROR and WARN), while more verbose levels (DEBUG and TRACE) are excluded.
  • You can change the log level of a specified module in real time via an Elasticsearch API.

Example

  1. Log in to Kibana and go to the command execution page. Elasticsearch clusters support multiple access methods. This topic uses Kibana as an example to describe the operation procedures.
    1. Log in to the CSS management console.
    2. In the navigation pane on the left, choose Clusters > Elasticsearch.
    3. In the cluster list, find the target cluster, and click Kibana in the Operation column to log in to the Kibana console.
    4. In the left navigation pane, choose Dev Tools.

      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.

  2. Run the following command to change the log level of the action module to DEBUG:
    PUT _cluster/settings
    {
    "persistent": {
    "logger": {
    "org.elasticsearch.action": "DEBUG"
    }
    }
    }
  3. Run the following command to restore the default log level INFO:
    PUT _cluster/settings
    {
    "persistent": {
    "logger": {
    "org.elasticsearch.action": null
    }
    }
    }

FAQ: How Do I Enable Trace Logging?

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

  1. Log in to Kibana and go to the command execution page. Elasticsearch clusters support multiple access methods. This topic uses Kibana as an example to describe the operation procedures.
    1. Log in to the CSS management console.
    2. In the navigation pane on the left, choose Clusters > Elasticsearch.
    3. In the cluster list, find the target cluster, and click Kibana in the Operation column to log in to the Kibana console.
    4. In the left navigation pane, choose Dev Tools.

      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.

  2. Run the following command to enable trace logging:
    PUT _cluster/settings
    {
    "transient": {
    "logger.org.elasticsearch.transport.TransportService.tracer": "trace",
    "transport.tracer.include": "",
    "http.tracer.include": "",
    "logger.org.elasticsearch.http.HttpTracer": "trace"
    }
    }
  3. Go to the log details page to view trace logs.
    1. In the cluster list, click the name of the target cluster. The cluster information page is displayed.
    2. Choose Logs > Log Search. The Log Search page is displayed.
    3. Select all log levels (mandatory) and view trace logs.

Related Documents