按日期切分索引的原因

在 LabHub 中继续学习

一句话总结

登录索引logs-2026.08.21像这样按日期划分的理由只有为了删除。删除一个文档很慢，但删除整个索引是删除文件，所以立即结束。

循环图: 为了删除 · 索引模板 · ISM（生命周期管理） · 集群状态(cluster state)

为什么需要这个？

在搜索引擎中删除文档并不是实际删除。会显示“已删除”，以后合并段落时会实际删除。所以1亿条旧日志delete_by_query删除的话需要几个小时，在此期间，群集会变慢。

将索引按日期划分的话，“8月1日的删除”DELETE logs-2026.08.01一次。和删除目录一样的花费。

怎么行动

索引模板自动在新生成的索引中设置。

PUT _index_template/labhub-logs
{
  "index_patterns": ["labhub-*"],
  "template": {
    "settings": {
      "number_of_shards": 1,
      "number_of_replicas": 1,
      "refresh_interval": "10s"
    },
    "mappings": {
      "dynamic": false,
      "properties": {
        "@timestamp": { "type": "date" },
        "level":      { "type": "keyword" },
        "message":    { "type": "text" },
        "trace_id":   { "type": "keyword" },
        "pod":        { "type": "keyword" }
      }
    }
  }
}

"dynamic": false是这个设置的核心。理由如下。

**ISM（生命周期管理）**自动化这项删除工作。

hot (7일)  →  warm (23일, 복제본 0, 강제 병합)  →  delete

映射爆炸

dynamic打开的话，每次新字段出现时都会自动生成映射。但是，如果应用程序在日志中将用户ID放在字段名中（user_12345: "..."),如果把错误对象全部用JSON插入的话，字段就会变成数千个。

字段增加的话，**集群状态(cluster state)**会变大，因为它会复制到所有节点上，所以整个集群都会变慢。严重的话，主节点会死掉。这被称为映射爆炸(mapping explosion)。

阻止的方法有三个。

"dynamic": false—未定义的字段会保存，但不进行索引(无法搜索，但可以查询)
"dynamic": "strict"— 如果出现未定义的字段，拒绝
index.mapping.total_fields.limit—设定上限（基本1000）

strict虽然看起来很安全，但很危险。如果收集器附加了收集器没有预料到的字段，**文档将被全部拒绝，日志也会丢失。**实际上，Fluent Bit的内部字段_p贴上后，400错误无限重试，导致日志被完全堵住过。所以登录索引中false去比较好。

常见的误解

多放置碎片就快。一个碎片相当于一个鲁森索引，分别使用文件手柄和内存。一天几GB级的日志中，放置5个碎片是浪费的。经验法则是每个碎片10~50GB，如果小于这个，就减少碎片。

text哇keyword弄混了。text通过分析并用令牌拆分，虽然可以进行专业搜索，但无法进行汇总和排序。keyword是整个保存的，可以汇总·排序，但不能部分搜索。等级·板名·轨迹ID是keyword，信息正文是text全部。

将保管期限和费用纳入设计中

登录索引设计的一半是搜索性能，另一半是什么时候什么东西要丢弃是吗。如果不确定后面的话，总有一天磁盘会塞满，那时会急忙删除。连必要的东西都会删除。

**划分步骤。**最近的放在快速磁盘上，旧的放在慢存储器上，更旧的放在对象存储中，最后删除。索引生命周期管理（ILM）是自动进行转移。

阶段	期间（例）	做什么
hot	0~3天	写作和搜索都会发生
warm	3~14天	仅限阅读。合并片段，减少副本
cold	14~90天	通过慢节点或对象存储
delete	90天~	删除

**把碎片切碎是最常见的错误。**每个碎片都有内存和文件手柄因为粘在一起，所以如果小碎片有数千个的话，群集就会变慢。每个碎片10~50GB 以为目标，如果一天比这个少，那么索引就不要按日期而是按周来制作。数据流的滚动条件（max_primary_shard_size）交给。

**不允许搜索所有字段。**不搜索只查看的字段 index: false这样做的话，会提供索引费用和存储空间。相反，只统计的数字是 doc_values只要有就行。

不将不同形状的日志放入一个索引中。 因为字段名称重叠，类型如果不同，索引会被拒绝，该文件将**悄悄丢失。**每个服务都会分开索引，共同字段设定名称规范。

**费用一般不是从搜索中出来的，而是从索引中出来的。**每秒文档数即等于CPU。如果在运营中直接发送调试级别的日志，就会每天支付费用。进行抽样，正常请求将被追踪代替，日志将转移到只在异常情况下留下的方向。

在实际工作中真正重要的东西

在日志中插入Trace ID是观测性的一半。如果有的话，可以一次性找到“这个慢请求留下的日志”。如果没有的话，就只能用视觉和pad名称来搜索。

从一开始最好遵循标准的字段名。ECS（Elastic Common Schema）是@timestamp，log.level，service.name，trace.id定好了相同的名称。如果以后要改，就必须重新编号所有的旧索引。