【腾讯云ES】正确的使用姿势get！日志场景优化案例回顾

1. 根治个别索引造成写入短板，阻塞整个链路。排除由于es原因导致消费能力无法提升的可能性
2. 保证分片的均匀分布和合理大小，提升各节点写入能力。排除单节点分配不均导致的性能问题
3. 平滑优雅的过渡流程，最小化操作，过程中尽量保证业务无感、故障可回退

1. 制定template和ilm策略的命名和管理规范，核心策略数量简化到个位数，完成替换后统一删除旧的。避免template过多不易维护，甚至错误覆盖导致一系列的集群、索引问题
2. 仅用别名来读写索引，对外屏蔽内部索引策略

- 使用`ilm索引生命周期`的rollover能力，将`rollover_alias`设置为索引名即可
- 例如，`log1-2022.10.19`这个索引，以后使用时，都仅指定`log1`，es会根据该别名，定位到需要读写的具体索引
- 写入时，以往logstash直接带出了后缀日期，后续这个后缀交给`ilm索引生命周期`来自动管理，logstash写入时只需指定`log1`
- 查询时，kibana的index pattern将通配改为使用别名`log1`来指定分片均匀分布

- 热层索引主分片数等同于热节点数量
- 索引`total_shards_per_node`=2，避免索引维度分片聚堆
- 提升分片均衡算法中的索引权重`cluster.routing.allocation.balance.index`，以保证索引层面的分片均匀分配索引策略尽量减少，并抽象归类为

- 大日志主题（日增索引大小>960G），共用一套模版：

    1. rollover条件，`max_primary_shard_size=40g`，`max_age=1d`，两条件触发任何一个即滚动一个新索引供写入
    2. rollover后1d降温，即从创建开始，最长2d会降温
    3. 降温后13d删除，即从创建开始，最长15d会删除
- 小日志主题（240G<日增索引大小<960G），共用一套模版：

    1. rollover条件，`max_primary_shard_size=40g`，`max_age=2d`，两条件触发任何一个即滚动一个新索引供写入
    2. rollover后1d降温，即从创建开始，最长3d会降温
    3. 降温后13d删除，即从创建开始，最长15d会删除
- 小日志主题（60G<日增索引大小<240G），共用一套模版：

    1. rollover条件，`max_primary_shard_size=40g`，`max_age=4d`，两条件触发任何一个即滚动一个新索引供写入
    2. rollover后1d降温，即从创建开始，最长5d会降温
    3. 降温后10d删除，即从创建开始，最长15d会删除
- 微日志主题（日增索引大小<60G），共用一套模版：

    1. 索引热阶段分配在即冷节点，索引从创建到删除始终在温节点，
    2. rollover条件，`max_primary_shard_size=40g`，`max_age=8d`，两条件触发任何一个即滚动一个新索引供写入
    3. rollover后1d降温，即从创建开始，最长9d会降温
    4. 降温后6d删除，即从创建开始，最长15d会删除ilm+组件模版本次优化核心配置示例

PUT _ilm/policy/ALIAS_POLICY_VER.2022.11.02-large_topic_ilm
{
  "policy": {
    "phases": {
      "hot": {
        "min_age": "0ms",
        "actions": {
          "rollover": {
            "max_primary_shard_size": "40gb",
            "max_age": "1d"
          }
        }
      },
      "warm": {
        "min_age": "1d",
        "actions": {
          "allocate": {
            "include": {
              "_tier_preference": "data_warm"
            }
          }
        }
      },
      "delete": {
        "min_age": "13d",
        "actions": {
          "delete": {
            "delete_searchable_snapshot": true
          }
        }
      }
    }
  }
}

PUT _component_template/ALIAS_POLICY_VER.2022.11.02-large_topic_component_template
{
  "template": {
    "settings": {
      "index": {
        "lifecycle": {
          "name": "ALIAS_POLICY_VER.2022.11.02-large_topic_ilm"
        },
        "number_of_shards": "32",
        "number_of_replicas": "0",
        "routing": {
          "allocation": {
            "total_shards_per_node": 2,
            "include": {
              "_tier_preference": "data_hot"
            }
          }
        }
      }
    }
  }
}

PUT _component_template/ALIAS_POLICY_VER.2022.11.02-tiny_topic_component_template
{
  "template": {
    "settings": {
      "index": {
        "lifecycle": {
          "name": "ALIAS_POLICY_VER.2022.11.02-tiny_topic_ilm"
        },
        "number_of_shards": "24",
        "number_of_replicas": "0",
        "routing": {
          "allocation": {
            "total_shards_per_node": 2,
            "include": {
              "_tier_preference": "data_warm"
            }
          }
        }
      }
    }
  }
}

PUT _index_template/ALIAS_POLICY_VER.2022.11.02-log1
{
  "template": {
    "settings": {
      "index": {
        "lifecycle": {
          "rollover_alias": "log1"
        }
      }
    }
  },
  "index_patterns": [
    "log1-*"
  ],
  "composed_of": [
    "ALIAS_POLICY_VER.2022.11.02-small_topic_component_template"
  ]
}

# PUT <log1-{now/d{yyyy.MM.dd|+08:00}}-000001>
PUT %3Clog1-%7Bnow%2Fd%7Byyyy.MM.dd%7C%2B08%3A00%7D%7D-000001%3E
{
  "aliases": {
    "log1": {
      "is_write_index": true
    }
  }
}

1. 通过脚本3，将所有日志主题最新的写入指向的索引，更新别名`log1`的属性`is_write_index=true`
2. 通过脚本4，激活所有新模版（提交index_template）修改logstash的写入方式，去除时间后缀，重新部署所有管道通过脚本5，将当前各主题最新索引赋予rollover_alias策略并手动执行rollover观察写入稳定后，关键流程结束待所有旧索引生命周期结束后（预计两周），删除所有旧模版、旧ilm策略