ES在elkf日志分析系统的配置问题

设置关闭es监控【默认是关闭的】

es监控的写入很容易会耗尽所有的存储空间，导致空间的存储不够！！ES数据没办法写入。

PUT _cluster/settings
{
  "persistent": {
    "xpack.monitoring.collection.enabled": false
  }
}

设置节点的分片的的问题

防止数据量多的情况下分片超出限制不能写入数据

PUT /_cluster/settings
{
  "transient": {
    "cluster": {
      "max_shards_per_node":10000
    }
  }
}

https://segmentfault.com/q/1010000019243427

异常日志太多数据记录的问题，ES出现异常会不断的写入错误日志文件，导致空间不够

需要看下怎么去监控这快的事情

ES需要设置跨域才能让kibana和外部访问

注释掉

关于ES多节点的设置问题

一定要ES是从来没有用过的，新建的ES，可以设置为主节点吗？
真的不清楚！

LIM生命周期的设置

术语理解

• rollover 滚动索引
• shrink 压缩索引
• 5个主分片，1个副本分片的理解

冷温热架构设计？

热阶段。Hot phase阶段，热度比较高的指的是指把搜索量比较大的数据放这个阶段的。

将您最近、最常搜索的数据存储在热层中。热层通过使用最强大、最昂贵的硬件来提供最佳的索引和搜索性能。

温阶段。Warm phase阶段

冷阶段。frozen操作可以减少内存压力

当您搜索的频率较低且不需要更新时，将数据移至冷层。 冷层针对搜索性能的成本节省进行了优化。

目前分析Lined indices很多的原因是什么？

生命周期旧配置

{
  "policy": "7-days-default",
  "phase_definition": {
    "min_age": "1d",
    "actions": {
      "shrink": {
        "number_of_shards": 1
      },
      "forcemerge": {
        "max_num_segments": 1
      }
    }
  },
  "version": 4,
  "modified_date_in_millis": 1653883500645
}

生命周期新配置

{
  "policy": "7-days-default",
  "phase_definition": {
    "min_age": "0ms",
    "actions": {
      "rollover": {
        "max_primary_shard_size": "50gb",
        "max_docs": 5000
      },
      "set_priority": {
        "priority": 96
      },
      "shrink": {
        "number_of_shards": 2
      }
    }
  },
  "version": 9,
  "modified_date_in_millis": 1654049613775
}

当前动作

新配置后切分成节点出来的数据中，有个Current action【当前动作】类型。
【如图】

• current action为shrink的时候代表着压缩数据～

将索引收缩到number of primary shared具有更少主分片的新索引？最新配置的分配是2个，会出现新增索引的情况。

https://www.elastic.co/guide/en/elasticsearch/reference/8.0/ilm-shrink.html

• current action 为rollover的时候代表着滚动索引～

  而旧的配置发现很多都是current action 是migrate，

index太多的原因？

migrate 因为当时设置的最大的max_num_segments 是1，min_age又为1D，所以会经常分出来新的索引？
这里涉及到久的数据基本都是和migrate强制合并有关系，也就是说现在就算去手动migrate也是没任何作用的，节点数还是那么多
— 新配置后去掉migrate，设置了shrink，但是出现shrink进行节点新增，目前还不知道为啥。如果在current action为shirink的情况下设置强制合并是可以的，但是current action还是shirink。对节点是毫无影响

当您仍然可能搜索数据但不经常需要更新时，将数据移至热层。暖层针对搜索性能而不是索引性能进行了优化。

现有的Linked Indices有521，其中大部分都是这个状态，而且存储大小都为225b，很明显这里存在不合理的配置，优先级这里是被设置是为50，预计是比**Hot phase**的阶段优先级更高。而且是1天的时间就移入这个阶段，导致这里有问题。
还有旧的配置基本上current action除了是migrate，最后一个都是rollover滚动索引
了解文档知道migrate这个强制合并的操作是，减少每个索引分片中的段数并清理已删除的文档？？
但是确新增了很多225b的新索引，这个是个很奇怪的操作
终于找到问题，是和data strem结合的时候索引前面还有一个时间的，会导致就算是已经后期的索引规则还是会影响到之前的，例如ds-canmou-api-logstash-2022.04.20-2022.05.19-000016 本来是根据现有的时间去操作的，但是因为它之前带了时间，会导致匹配的时候会匹配到之前带有时间的索引，从而影响，导致错乱。1天的回滚时间设置加上merge索引设置和从热阶段到温阶段的回滚策略，导致索引增长很快就多了起来。

!!!!!关于logstash的配置还是要重新在熟悉，制定正式环境比较好的规则，保持日志分析系统的稳定
之前的配置

input {
  kafka {
    bootstrap_servers => "xxxx"
    topics => "test"
    group_id => "ttt"
    codec => "json"
  }
}
filter {
  json {
    source => "message"
  }
  if [app_name] {
    mutate {
      add_field => {
        "index_name" => "%{app_name}"
      }
     }
  }
}
output {
  elasticsearch {
    hosts => "x.x.x.x:9309"
    index => "canmou-api-logstash-%{+YYYY.MM.dd}"
    action => "create"
    ilm_enabled => false
    user => elastic
    password => xxxxxx
  }
  stdout { codec => rubydebug }
}
                                                                                                                                      60,1          Bot

后续的配置

input {
  kafka {
    bootstrap_servers => "xxxxxx"
    topics => "test"
    group_id => "ttt"
    codec => "json"
  }
}
filter {
  json {
    source => "message"
  }
  if [app_name] {
    mutate {
      add_field => {
        "index_name" => "%{app_name}"
      }
     }
  }
}
output {
  elasticsearch {
    hosts => "x.x.x.x:9309"
    index => "canmou-api-pro-logstash"
    action => "create"
    ilm_enabled => false
    user => elastic
    password => xxxxxx
  }
  stdout { codec => rubydebug }
}
                                                                                                                                      60,1          Bot

什么是强制合并。还必须设置rollover滚动索引

强制将索引合并到指定的最大段数。此操作使索引成为只读的。

rollover滚动更新

当当前索引达到特定大小、文档计数或年龄时，开始写入新索引。使您能够在处理时间序列数据时优化性能并管理资源使用情况。

临界点的4个参数：
Maximum primary shard size 50G 最大主分片大小
Maximum age 空 多少天数
Maximum documents 最大文档数
Maximum index size 最大索引大小

测试强制合并-出现失败【这里关于merge的理解上有问题】

• .ds-canmou-api-logstash-2022.04.20-2022.04.25-000004
• .ds-canmou-api-logstash-2022.04.20-2022.05.05-000009

提示成功，但是完全没有任何的变化

• .ds-canmou-api-logstash-2022.04.08-2022.05.05-000014
• .ds-canmou-api-logstash-2022.04.08-2022.05.07-000015
• .ds-canmou-api-logstash-2022.04.08-2022.05.09-000016

  测试shrink

  可以生效，但是会新增新的索引出来，规则条件是主分片要保持2个？那不是会一直生成，所以不理解这里了。
  已经索引名称的问题影响到
  shrink的理解
  一开始【5个主分片，一个副本分片】
  
  前提准备，变化效果如下图

  # shrink压缩之前的三个必要条件
  # 设置待压缩的索引，分片设置为5个
  PUT test/_settings
  {
  "index.number_of_replicas": 0,
  "index.routing.allocation.require._name": "node-024",
  "index.blocks.write": true
  }
  

  
  压缩

  # shrink实施压缩
  POST kibana_sample_data_logs_ext/_shrink/kibana_sample_data_logs_shrink
  {
  "settings": {
    "index.number_of_replicase": 0,
    "index.number_of_shards": 1, // 上面5个主分片倒1个主分片
    "index.blocks.write": true
  },
  "aliases": {
    "kiban_sample_data_logs_alias": {}
  }
  }
  

  

  ILM dsl的流程

  

  

  待解决问题

  ES日志采用节点索引策略设计后，节点数量剧增怎么解决，默认ES是1000个节点？

  1. 关于data stream的使用问题，什么是管理数据流？

  2. 关于索引分段的问题，关于7天删除索引的问题？

  3. 关于集群健康值的问题，出现974，但是却出现超过1000分片的问题【集群健康值: yellow (489 of 974)】？

  4. logstash这里不开启ilm_enabled,应该是这里已经用了data stream，所以不用去设置这里吧？？？

  #ilm_enabled => true
  #ilm_rollover_alias => "canmou-api-logstash"
  #ilm_pattern => "000001"
  #ilm_policy => "7-days-default"
  

  
  

  5. 关于kibana调用多个ES的问题，是否可以作为一种方案，还是说只能用集群的方式？

  跨集群通讯？
  https://elasticsearch.cn/question/2963

ES设置生命周期，常用命令集合

# 查看所有索引
GET _cat/indices
# 拷贝索引
POST _reindex
{
  "source": {
    "index": "source_index"
  },
  "dest": {
    "index": "dest_index"
  }
}
# shrink压缩之前的三个必要条件
# 设置待压缩的索引，分片设置为5个
PUT test/_settings
{
  "index.number_of_replicas": 0,
  "index.routing.allocation.require._name": "node-024",
  "index.blocks.write": true
}
# shrink实施压缩
POST test/_shrink/test_shrink
{
  "settings": {
    "index.number_of_replicase": 0,
    "index.number_of_shards": 1, // 上面5个主分片倒1个主分片
    "index.blocks.write": true
  },
  "aliases": {
    "kiban_sample_data_logs_alias": {}
  }
}
# 冷冻索引
POST kibana_sample_data_logs_shrink/_freeze
# 正常生命周期的间隔是10min，可以修改1s，来测试
PUT _cluster/settings
{
  "persistent": {
    "indices.lifecycle.poll_interval": "1s"
  }
} 
# 生命周期的主动设置
PUT _ilm/policy/my_custom_policy_filter
{
  "policy": {
    "phases": {
      "hot": {},
      "warm": {},
      "cold": {},
      "delete": {},
    }
  }
}
# 场景模板，关联配置的ilm_policy
PUT _index_template/timeseries_template
{
  "index_patterns": ["timeseries-*"],
  "template": {
    "settings": {
      "number_of_shareds": 1,
      "number_of_replicas": 0,
      "index.lifecryle.name": "my_custom_policy_filter",
      "index.lifecryle.rollover_alias": "timeseries",
      "index.routing.allocation.require.box_type": "hot"
    }
  }
}
# DELETE _index

PUT timeseries/_bluk
{"index": {"_id": 1}}
{"title": "testing 01"}
{"index": {"_id": 2}}
{"title": "testing 02"}


GET _index/_search

参考资料

Logstash：为 Logstash 日志启动索引生命周期管理
Logstash：Logstash 入门教程 （二）
官方索引生命周期资料
ES一台机器多个节点
ES设置用户密码
Data stream的应用
ES自定义索引模板及生命周期设置
Logstash & 索引生命周期管理（ILM）
logstash的一些配置问题
Lodstash一些配置问题2
Elasticsearch索引生命周期管理方案链接
分片和副本+ELK
集群迁移实战——-
Elasticsearch 索引生命周期管理 ILM 实战指南-比较好的教程