elasticsearch 索引的监控

最新推荐文章于 2024-06-07 16:11:40 发布

Rainly2000

最新推荐文章于 2024-06-07 16:11:40 发布

阅读量991

点赞数 22

文章标签： elasticsearch jenkins 大数据

本文链接：https://blog.csdn.net/lyzchengxuyuan/article/details/136032444

版权

1. 监控索引的健康状态信息

**
如果创建了一个索引test-3-2-1并且你想知道索引test-3-2-1的健康状态可以使用索引的cat端点，代码如下。

GET /_cat/indices/test-3-2-1?v&format=json

会得到类似于以下的健康状态监控信息

[
  {
    "health" : "yellow",
    "status" : "open",
    "index" : "test-3-2-1",
    "uuid" : "mTB_AcxlRTGfQE4ec_TtiQ",
    "pri" : "1",
    "rep" : "1",
    "docs.count" : "4",
    "docs.deleted" : "1",
    "store.size" : "24.3kb",
    "pri.store.size" : "24.3kb"
  }
]

从上述返回结果可以看出索引的健康状态、运行状态、主分片和每个主分片的副本分片的数量、现有文档总数、删除文档总数、索引占用的空间大小、主分片占用的空间大小。由于该索引运行在单节点上，副本分片无法分配，所以主分片占用的空间和索引占用的总空间大小是一样的。索引的健康状态分为3种，如果存在主分片没有得到分配，则健康状态为red；如果存在副本分片没有得到分配，则健康状态为yellow；如果主分片和副本分片都得到了分配，则健康状态为green。为了让副本分片得到分配，在本地再启动一个节点node-2，代码如下。

.\elasticsearch.bat -Epath.data=data2 -Epath.logs=log2 -Enode.name=node-2

再次查看索引test-3-2-1的健康状态，从下述返回结果可以发现，副本分片成功分配后，索引的健康状态变为green，索引占用的空间大小增大一倍。

[
  {
    "health" : "green",
    "status" : "open",
    "index" : "test-3-2-1",
    "uuid" : "mTB_AcxlRTGfQE4ec_TtiQ",
    "pri" : "1",
    "rep" : "1",
    "docs.count" : "4",
    "docs.deleted" : "1",
    "store.size" : "48.6kb",
    "pri.store.size" : "24.3kb"
  }
]

2. 监控索引分片的段数据

如何查看一个索引的段信息？我们可以通过以下代码去查询

GET /_cat/segments/test-3-2-1?v&format=json

会得到类似于以下的信息

[
  {
    "index" : "test-3-2-1",
    "shard" : "0",
    "prirep" : "r",
    "ip" : "127.0.0.1",
    "segment" : "_0",
    "generation" : "0",
    "docs.count" : "0",
    "docs.deleted" : "1",
    "size" : "6kb",
    "size.memory" : "0",
    "committed" : "true",
    "searchable" : "false",
    "version" : "8.6.2",
    "compound" : "true"
  },
……

或者是采用 _segments endpoint查看得到类似于以下代码片段的信息

"indices" : {
    "test-3-2-1" : {
      "shards" : {
        "0" : [
          {
            "routing" : {
              "state" : "STARTED",
              "primary" : true,
              "node" : "pbBVcOsqST6V01O1uXYNRw"
            },
            "num_committed_segments" : 4,
            "num_search_segments" : 2,
            "segments" : {
              "_0" : {
                "generation" : 0,
                "num_docs" : 0,
                "deleted_docs" : 1,
                "size_in_bytes" : 6220,
                "memory_in_bytes" : 0,
                "committed" : true,
                "search" : false,
                "version" : "8.6.2",
                "compound" : true,
                "attributes" : {
                  "Lucene50StoredFieldsFormat.mode" : "BEST_SPEED"
                }
              },
……

随着时间的增长索引段的信息会越来越长，这个时候我们可以采取段合并的方式去对索引段的信息，这里简单的介绍一下索引段合并的作用

索引段合并是指将多个索引段（Index Segment）合并为一个更大的索引段的过程。索引段是在数据库中用于存储索引数据的逻辑单位。索引段合并的作用主要有以下几点：

提高查询性能：当数据库中的索引段过多或过小时，查询性能可能会受到影响。通过合并索引段，可以减少索引段的数量，从而提高查询的效率。
优化存储空间：索引段合并可以减少索引占用的存储空间。合并后的索引段通常会更大，但整体存储效率更高，可以节省磁盘空间。
优化维护成本：当索引段过多时，数据库的维护成本会增加。合并索引段可以减少维护索引的工作量，简化数据库的管理和维护。

需要注意的是，索引段合并并非适用于所有情况。在某些情况下，合并索引段可能会导致性能下降或增加存储空间的占用。因此，在进行索引段合并之前，需要仔细评估数据库的特定情况，并根据实际需求进行决策。

监控索引分片的分配

可以使用_cat/shards查看索引的每个分片的分配结果，也可以使用_shard_stores端点查看索引中已经分配过的分片所在的位置，不显示未分配的分片所在的位置。

使用_shard_stores 会得到类似于以下片段的信息

{
  "indices" : {
    "test-3-2-1" : {
      "shards" : {
        "0" : {
          "stores" : [
            {
              "pbBVcOsqST6V01O1uXYNRw" : {
                "name" : "node-1",
                "ephemeral_id" : "zbKz3VxERVOyTvq3pdI_nw",
                "transport_address" : "127.0.0.1:9300",
                "attributes" : {
                  "ml.machine_memory" : "16964157440",
                  "xpack.installed" : "true",
                  "transform.node" : "true",
                  "ml.max_open_jobs" : "20"
                }
              },
              "allocation_id" : "SrHQqwYKTJmxtSYK-Mi6hQ",
              "allocation" : "primary"
            }
          ]
        }
      }
    }
  }
}

监控索引分片的恢复

_recovery endpoint

在以下索引分片恢复信息的片段中除了有分片号(id)、恢复类型(type)、起始时间(start time in millis)、结束时间(stop time in millis)、数据来源(source)和目标节点(target)这些常规的字段之外，还包含分片恢复过程中的统计信息，例如恢复了多少个文件(files.total)、占用多大空间(total in bytes)、恢复的事务日志的个数(translog)等。

{
  "test-3-2-1" : {
    "shards" : [
      {
        "id" : 0,
        "type" : "EXISTING_STORE",
        "stage" : "DONE",
        "primary" : true,
        "start_time_in_millis" : 1608079382641,
        "stop_time_in_millis" : 1608079383111,
        "total_time_in_millis" : 469,
        "source" : {
          "bootstrap_new_history_uuid" : false
        },
        "target" : {
          "id" : "pbBVcOsqST6V01O1uXYNRw",
          "host" : "127.0.0.1",
          "transport_address" : "127.0.0.1:9300",
          "ip" : "127.0.0.1",
          "name" : "node-1"
        },
        "index" : {
          "size" : {
            "total_in_bytes" : 11631,
            "reused_in_bytes" : 11631,
            "recovered_in_bytes" : 0,
            "percent" : "100.0%"
          },
          "files" : {
            "total" : 10,
            "reused" : 10,
            "recovered" : 0,
            "percent" : "100.0%"
          },
          "total_time_in_millis" : 2,
          "source_throttle_time_in_millis" : 0,
          "target_throttle_time_in_millis" : 0
        },
        "translog" : {
          "recovered" : 0,
          "total" : 0,
          "percent" : "100.0%",
          "total_on_start" : 0,
          "total_time_in_millis" : 405
        },
        "verify_index" : {
          "check_index_time_in_millis" : 0,
          "total_time_in_millis" : 0
        }
      }
    ]
  }
}

监控索引的统计指标

主要使用到endpoint stats

{
  "_shards" : {
    "total" : 12,
    "successful" : 6,
    "failed" : 0
  },
  "_all" : {
    "primaries" : {
     ……
    },
    "total" : {
     ……
    }
  },
  "indices" : {
    "mysougoulog" : {
      "uuid" : "4uU50jAeS_G_s3fzmLgRAw",
      "primaries" : {
        "docs" : {
          "count" : 2,
          "deleted" : 0
        },
        ……
      },
      "total" : {
        "docs" : {
          "count" : 2,
          "deleted" : 0
        },
        ……
      }
    }
  }
}