标签: Elasticsearch

  • 在保证精度的同时大幅降低成本,Elasticsearch 向量搜索选项及效果

    在保证精度的同时大幅降低成本,Elasticsearch 向量搜索选项及效果

    前言

    近年来,在检索增强生成(RAG,Retrieval-Augmented Generation)兴起等背景下,向量搜索的重要性日益凸显。向量搜索是将文本、图像等高维数据嵌入向量空间,基于相似度进行检索的技术。通过该技术,能够实现传统关键词搜索无法捕捉的、基于语义相似性的检索。

    另一方面,可处理向量搜索的产品与服务不断增多,想必有不少人在选择时会感到迷茫。不同服务支持的向量搜索选项也存在差异。尤其在近期,为提升向量搜索性能与资源效率的各类选项纷纷涌现,其中 “向量量化” 与 “二进制向量” 作为有助于降低资源用量、提升检索速度的技术备受关注。

    本文将聚焦向量搜索引擎的有力选择之一 ——Elasticsearch,结合具体配置方法,解析向量量化、二进制向量等选项及其效果。

    Elasticsearch 中的向量搜索

    Elasticsearch 作为全文搜索引擎广为人知,而自 7.x 版本起,它开始支持稠密向量(Dense Vector)类型,向量搜索功能得到强化。稠密向量是用于存储高维向量数据的数据类型。

    Elasticsearch 稠密向量文档:Elasticsearch Dense Vector 文档

    向量搜索的算法

    在 Elasticsearch 中处理稠密向量时,会使用近似最近邻(ANN)搜索算法。目前可使用名为 HNSW 的算法。HNSW(Hierarchical Navigable Small World,分层可导航小世界)是一种高速的近似最近邻搜索算法,采用基于图的数据结构,能高效检索相似向量。

    用于资源削减的选项:向量量化与二进制向量

    向量搜索的性能与资源效率存在权衡关系。Elasticsearch 提供向量量化与二进制向量作为调节这种权衡的选项。

    选项说明优势劣势推荐使用场景
    向量量化将向量各维度用更少的比特数表示的方法。在 Elasticsearch 中,可替代 32 比特的 float 型,实现 8 比特、4 比特、1 比特的量化。大幅降低存储大小与内存用量,还有可能提升查询性能。可能导致精度下降。需降低存储成本与内存用量,追求一定精度与性能平衡的场景。
    二进制向量将向量各维度用 0 或 1 表示的方法。可使用汉明距离等进行高速的相似度计算。大幅减少计算时间及磁盘、内存用量,支持针对二进制向量的高速距离计算(如汉明距离)。与使用 float 型相比精度下降,且需要用于生成二进制向量的专用嵌入(Embedding)模型。可牺牲部分精度以大幅控制存储与内存用量,或需高速检索的场景。

    二进制向量详情

    二进制向量(比特向量)是一种蕴藏着大幅提升向量搜索效率潜力的技术。

    www.elastic.co

    机制

    二进制向量是基于阈值将原始向量(通常为浮点数向量)的各维度转换为 0 或 1 得到的。

    距离计算

    二进制向量间的相似度计算采用汉明距离(比特位不同的位置数量),其速度远快于浮点数向量间的余弦相似度或欧几里得距离计算。

    生成方法

    • 专用嵌入模型:使用可直接输出二进制向量的嵌入模型。
    • 现有嵌入模型 + 二值化:对通过现有嵌入模型得到的浮点数向量,采用阈值处理等方式进行二值化。

    量化 / 二值化的优势与注意事项

    向量量化与二值化是提升稠密向量存储效率与查询性能的有力手段,但在引入时需理解以下优势与注意事项。

    优势:

    1. 降低存储成本:可大幅减小索引大小,降低磁盘存储成本。
    2. 减少内存用量:向量数据更易存入内存,从而减少内存用量,提升 Elasticsearch 集群的稳定性。
    3. 提升查询性能:对量化 / 二值化后的向量进行运算速度更快,有望提升查询性能。

    注意事项:

    1. 精度的权衡:量化 / 二值化通常与精度存在权衡关系,数据压缩程度越高,检索精度下降的可能性越大。
    2. 选择合适的方法:需结合业务需求允许的精度损失与存储效率的平衡,选择合适的量化级别或二进制向量化方法。

    基于 JMTEB 数据的测试

    存在名为 JMTEB(Japanese Massive Text Embedding Benchmark,日语大规模文本嵌入基准)的嵌入精度评估基准。

    github.com

    JMTEB 通过 5 个使用各类日语开放数据的任务对嵌入模型进行评估。本次将利用部分数据集,观察修改量化选项后对磁盘用量及精度的影响程度。

    使用 Cohere 提供的嵌入 API,除了常规的 Float 型嵌入外,还可使用二进制嵌入。在验证中,我们使用 Cohere 的嵌入模型生成以下 3 种向量并注册到 Elasticsearch 中进行比较。

    1. 采用 Elasticsearch 默认设置(8 比特量化)的 float 向量
    2. 在 Elasticsearch 中进行比特量化(bbq)的 float 向量
    3. 利用 Elasticsearch 的 bit 选项注册的二进制向量

    参考:www.elastic.co

    索引大小 / 正确率

    以下展示了启用各选项并导入 Elasticsearch 后,索引的大小以及对数据集中预先定义的正确答案的匹配率。本次使用的数据集中,404 个检索查询均各自定义了 1 个正确文档。正确率指标采用精确率(precision)和归一化折损累积增益(nDCG)两项。

    • precision@1:应匹配的正确文档排在第 1 位的比例
    • nDCG@10:衡量前 10 位结果中应匹配的正确文档排名情况的指标,正确文档排名越靠前,得分越高。
    类型索引大小正确率 (precision@1)nDCG@10
    float 向量9.1MB84.41%0.9108
    量化 (bbq)8.7MB83.66%0.9024
    二进制向量2.6MB81.19%0.8889

    可以看出,直接使用 float 型向量的精度确实更高,但其他方法在减小索引大小的同时,精度仅下降了 1%~3% 左右,并未出现显著下滑。近年来也有通过与重排序(rerank)结合来保证精度的策略,因此本文介绍的选项具有实用价值。当然,精度下降幅度会因数据集不同而存在差异,建议在使用前进行验证,但仍推荐积极尝试这些选项。

    本文到此结束。感谢您读到最后。

  • 在 Azure 中使用 Elasticsearch(Elastic Cloud)的要点 (下篇 )

    在 Azure 中使用 Elasticsearch(Elastic Cloud)的要点 (下篇 )

    本文作为在 Azure 中使用 Elasticsearch(Elastic Cloud)的要点下篇,将介绍在 Elastic Cloud 中执行以下操作的步骤。

    1. 版本升级

    1. 审计日志设置

    1. 版本升级

    关于 Elastic Stack 的版本升级

    Elastic Stack 有两种版本升级方式,各自的特点如下表所示:

    序号版本升级方式特点
    1滚动升级(Rolling Upgrade)无需停止服务即可完成版本升级
    2全集群升级(Full Cluster Upgrade)需先将服务全部停止

    在 Elastic Cloud 中,版本升级采用上述第 1 种 “滚动升级” 方式,因此无需停止服务即可完成版本升级。有关升级的详细信息,请参考以下链接:Upgrade versions | Elasticsearch Service Documentation | Elastic

    此外,在 Elastic Cloud 中,只需在图形用户界面(GUI)上点击一下,即可完成版本升级。下面实际操作一下具体步骤。

    在 Elastic Cloud 中升级 Elastic Stack

    (1)根据需要将 Deployment设为维护模式

    在 Elastic Cloud 中,如果对高负载的 Deployment 应用设置变更,不仅设置变更会耗费较长时间,最坏情况下还可能导致服务响应中断、设置变更失败。因此,虽然理论上无需停止服务即可完成版本升级,但当 Deployment 处于高负载状态时,也建议先将其切换为维护模式,之后再进行升级。

    访问 Elastic Cloud 的 Deployment 页面,选择菜单中的 “Edit”

    点击“Edit”

    在页面底部的 “Extented maintenance”(扩展维护)处勾选复选框,然后点击 “Save”(保存),即可将 Deployment 设为维护模式。

    在 “Extented maintenance” 处勾选复选框,点击 “Save”

    (2)点击 Elastic Cloud 的 Deployment 页面右侧的 “Upgrade”

    点击 “Upgrade”

    (3)选择版本,点击 “Upgrade”

    (=选择版本,点击 “Upgrade”

    通过以上步骤,即可完成版本升级。无需复杂操作就能轻松升级版本,从而持续使用最新功能,这是 Elastic Cloud 的一大重要优势。

    2. 审计日志设置

    关于 Elastic Stack 的审计日志

    Elasticsearch 和 Kibana 均支持输出审计日志。通过审计日志,可监控认证失败、连接拒绝等与安全相关的事件。

    有关审计日志的详细信息,请参考以下文档:

    审计日志默认处于未启用状态,因此需按以下步骤开启。

    (1)在 Elastic Cloud 的 Deployment管理页面中,点击 “Edit”

    点击 “Edit”

    (2)点击 Elasticsearch 右侧的链接 “Manage user settings and extensions”

    点击 Elasticsearch 右侧的 “Manage user settings and extensions”

    (3)为 Elasticsearch 应用审计日志设置

    设置内容如下:

    xpack.security.audit.enabled: true

    (4)点击 Kibana 右侧的链接 “Edit user settings”

    点击 “Edit user settings”

    (5)为 Kibana 也应用审计日志设置

    设置内容如下:

    xpack.security.audit.enabled: true

    (6)点击页面下方的 “Save”,应用设置

    点击 “Save”

    (7)在 Monitoring功能的 Logs中查看审计日志

    此时会输出 Elasticsearch 和 Kibana 的审计日志。

    查看审计日志

    从上述审计日志中可以看到,“y_nomura” 用户在两次认证失败(红色高亮部分)后,最终认证成功(黄色高亮部分)。通过输出此类审计日志,能够确认 “谁在何时登录”“访问了哪些资源” 等关键信息。

    总结

    截至目前,我们已通过操作篇,讲解了使用 Elastic Cloud 的关键要点。但除此之外,针对不同使用场景,仍有许多需要考虑的事项。

  • Azure 中使用 Elasticsearch(Elastic Cloud)的要点(上篇)

    Azure 中使用 Elasticsearch(Elastic Cloud)的要点(上篇)

    本文作为Azure 中使用 Elasticsearch(Elastic Cloud)的要点上篇,将介绍操作 Elastic Cloud 所需的各类设置的实施步骤。

    本文中,Elastic Cloud(Elasticsearch Service)将统一表述为 “Elastic Cloud”。

    1. 监控设置(Metric/Logs)

    关于监控功能

    利用监控功能,可一目了然地掌握集群状态;且当发生任何问题时,能够从资源和日志两方面快速开展问题排查。

    在 Elastic Cloud 中启用监控功能

    监控功能默认未启用,需通过以下步骤进行启用:

    (1) 访问 Elastic Cloud 的 Deployment页面,点击菜单中的 “Logs and metrics”

    点击 “Logs and metrics”

    (2) 点击 “Ship to a deployment”中的 “Enable”

    点击 “Enable”

    (3) 选择已构建的 Deployment,点击 “Save”

    监控功能即启用成功。

    点击 “Save”

    查看 Metric

    通过 Metric 可查看 Elastic Stack 各组件的服务器资源占用情况:

    (1) 在 Kibana 页面左侧菜单中,点击 “Stack Monitoring”

    点击 “Stack Monitoring”

    (2) 点击 Elasticsearch 的 “Overview”

    在概览中,可实时查看 Elasticsearch 整体的搜索性能与索引性能。

    点击 “Overview”

    (3) 在 Elasticsearch 的「Nodes」中,选择一个实例并点击

    从「Nodes」(节点)中选择一个实例并点击

    可实时查看每台服务器的资源状况。

    查看 Metric

    查看 Logs(日志)

    通过 Logs 可实时查看、筛选日志并开展排查工作:

    (1) 在 Kibana 页面左侧菜单中,点击 “Logs”

    点击 “Logs”

    在 Stream(流)页面中,会实时显示已导入 Elasticsearch 的各类日志。

    日志实时显示

    (2) 在画面顶部的搜索框中输入 “error”,执行日志筛选

    可通过筛选日志开展问题排查。

    输入 “error” 并执行日志筛选

    修改 Metric(指标)的保留期限

    Metric 的默认保留期限为 3 天。由于不同需求对应的保留期限可能不同,下面我们来修改这一设置:

    (1) 在 Kibana 页面左侧菜单中,点击 “Stack Management”

    点击 “Stack Management”

    (2) 点击 “Index Lifecycle Policies”(索引生命周期策略)

    点击 “Index Lifecycle Policies”

    (3) 在搜索框中输入 “.monitoring”,点击显示结果中的 “.monitoring-8-ilm-policy”

    点击 “.monitoring-8-ilm-policy”

    Elasticsearch 会将索引按 “阶段(Phase)” 进行管理,阶段的转换条件通过 ILM(Index Lifecycle Management,索引生命周期管理)进行定义。

    详情可参考以下链接:ILM: Manage the index lifecycle | Elasticsearch Guide [8.14] | Elastic

    修改前的设置如下表所示:

    阶段设置值
    Hot 阶段索引创建后 3 天,或主分片大小达到 50GB 以上时,对索引执行 Rollover(滚动更新)
    Warm 阶段执行 Forcemerge(强制合并),将分片段数合并为 1
    Delete 阶段滚动更新后 3 天,删除该索引

    简单来说,Hot 阶段中定义的 “Rollover(滚动更新)” 是指当满足特定条件时,自动创建新索引的功能。

    详情可参考以下链接:Rollover | Elasticsearch Guide [8.14] | Elastic

    (4) 将 Delete 阶段的数值从 “3 days”修改为 “31 days”,点击 “Save Policy”

    修改设置并点击 “Save Policy”

    通过上述步骤,已完成设置修改,滚动更新后 31 天的索引将被自动删除。

    2. Snapshot设置

    关于 Snapshot设置

    在 Elastic Cloud 中,默认设置为每 30 分钟获取一次快照。下面我们对该设置进行确认与修改:

    (1) 在 Kibana 页面左侧菜单中,点击 “Stack Management”

    点击 “Stack Management”

    (2) 点击 “Snapshot and Restore”

    点击 “Snapshot and Restore”

    (3) 点击 “Policies”标签页,点击 “cloud-snapshot-policy” 右侧的 “Edit”按钮

    点击 “Edit” 按钮

    (4) 修改「Schedule」的设置值

    时间设置可通过 Cron 表达式进行配置。另外,请注意时间采用 UTC 时区。

    详情可参考:API conventions | Elasticsearch Guide [8.14] | Elastic

    修改 “Schedule” 的设置值

    (5) 根据需要修改 “Expiration”、“Snapshots to retain”的设置值

    根据需要修改设置

    (6) 点击 “Save policy”

    点击 “Save policy”

    (7) 点击 “cloud-snapshot-policy”,查看 “Summary”

    修改后,Snapshot将在每天 0 点自动获取。

    查看 “Summary”

    3. 告警设置

    关于 Elastic Cloud 的告警功能

    在 Elastic Cloud 中,可通过 Alert功能实现监控与通知。此外,系统默认提供了多个可配置的监控项,便于快速完成 Alert设置。下面我们通过创建默认规则来使用 Alert功能:

    (1) 从左侧菜单点击 “Stack Monitoring”,在监控页面右上角选择 “alerts and rules”,点击 “Create default rules”

    点击 “Create default rules”

    (2) 点击 “Create”至此,告警设置完成。最后我们来确认已创建的规则列表。

    点击 “Create”

    (3) 点击 “Stack Management”,选择 “Alerts”,然后点击页面右上角的 “Manage rules”

    点击 “Manage rules”

    此时会显示已创建的规则列表。通过编辑规则,可修改触发条件及配置通知方式。

    已创建的规则列表

    例如,“CPU Usage”规则会在 CPU 使用率 5 分钟平均值超过 85% 时触发检测并发送通知。

    CPU Usage(CPU 使用率)

    另外,默认设置下通知会输出至 Kibana 日志,但也可使用邮件、Slack 等多种连接器作为通知渠道。

    连接器列表

    总结

    在实际操作过程中,除了上述 设置外,可能还需要应对以下需求:

    • 版本升级对应
    • 审计日志

    因此,我们将在下次的文章中对上述内容进行讲解。

  • 在 Elasticsearch 中高速实现类 LIKE 搜索的部分匹配搜索方法

    在 Elasticsearch 中高速实现类 LIKE 搜索的部分匹配搜索方法

    在工作中,经常听到有人反馈关系型数据库(MySQL、PostgreSQL 等)搜索功能存在 “LIKE 搜索速度慢” 的问题。尤其是在处理大量数据的系统中,LIKE 搜索往往会导致性能下降,搜索响应延迟的问题屡见不鲜。因此,越来越多的案例开始考虑从关系型数据库迁移到 Elasticsearch 来解决这一问题。

    Elasticsearch 是一款能够实现高速、灵活全文搜索的强大搜索引擎。但要充分发挥其性能,恰当的数据设计与查询设计至关重要。

    本文将聚焦于 “如何在 Elasticsearch 中高速实现类似 SQL LIKE 搜索的部分匹配搜索” 进行讲解。

    1. 数据类型的差异

    在 Elasticsearch 中进行字符串搜索前,首先需要理解 keyword 型与 text 型的区别。向 Elasticsearch 中注册字符串型字段时,需预先设定该字段采用哪种数据类型。

    keyword 型:适用于精确字符串匹配

    keyword 型是将字符串以原始形式注册到索引中的数据类型。由于其能高速执行完全匹配搜索、排序、聚合等操作,因此像 ID、商品分类这类短字符串通常会注册为 keyword 型。

    text 型:适用于全文搜索

    text 型擅长自然语言处理与全文搜索。设置为该类型的字段在注册到索引时,会通过分析器(Analyzer)将文本按单词或短语拆分后再进行注册。

    文本按何种规则拆分为令牌(Token)由分析器决定,需根据搜索需求设计合适的分析器。

    参考文档:analyzer | Elasticsearch Guide [8.16] | Elastic

    我们可使用分析 API(Analyze API)确认字符串是如何被拆分令牌并注册的。以下是使用默认分析器(standard Analyzer)进行令牌化的示例。

    POST _analyze
    {
      "text":     "Elasticsearch is powerful"
    }
    

    从结果可以看出,文本被拆分为 “elasticsearch”“is”“powerful” 三个令牌。

    {
      "tokens": [
        {
          "token": "elasticsearch",
          "start_offset": 0,
          "end_offset": 13,
          "type": "<ALPHANUM>",
          "position": 0
        },
        {
          "token": "is",
          "start_offset": 14,
          "end_offset": 16,
          "type": "<ALPHANUM>",
          "position": 1
        },
        {
          "token": "powerful",
          "start_offset": 17,
          "end_offset": 25,
          "type": "<ALPHANUM>",
          "position": 2
        }
      ]
    }
    

    通常情况下,部分匹配搜索的目标字段会注册为 text 型。

    2. 实现部分匹配搜索的方法及特点

    keyword 型字段的部分匹配搜索

    对于 keyword 型字段,也可使用 wildcard 查询实现部分匹配搜索。wildcard 查询与 LIKE 搜索类似,是按特定模式匹配字符串的查询,其使用方式与 SQL 的 LIKE 搜索直观上较为接近。

    但需注意,wildcard 查询的计算成本极高,索引规模越大,对搜索系统产生不良影响的可能性就越高。

    wildcard 查询示例(搜索以 “Elasticsearch” 开头的字符串)

    GET test_index/_search
    {
      "query": {
        "wildcard": {
          "message": {
            "value": "Elasticsearch*"
          }
        }
      }
    }
    

    text 型字段的部分匹配搜索

    对 text 型字段进行部分匹配搜索时,通常使用 match 查询或 match_phrase 查询。与 text 型字段拆分令牌后注册到索引的逻辑相同,搜索字符串也会被拆分令牌,只要目标字段与搜索字符串的令牌能够匹配,对应的结果就会命中。其中,match 查询适用于单词搜索,match_phrase 查询适用于短语搜索。

    match 查询示例(搜索以 “Elasticsearch” 开头的字符串)

    GET test_index/_search
    {
      "query": {
        "match": {
          "message": "Elasticsearch"
        }
      }
    }
    

    3. 恰当的分析器设计

    在 Elasticsearch 中进行字符串搜索时,虽然默认使用 match 或 match_phrase 查询,但如果分析器设置不当,可能会出现无法返回预期结果、反而返回大量无关结果等问题。

    例如,在第 1 部分的示例中,若向已注册的 test_index 搜索 “power” 字符串,将无法命中结果。

    搜索 “Elastic” 的查询

    GET test_index/_search
    {
      "query": {
        "match": {
          "message": "power"
        }
      }
    }
    

    搜索结果

    {
      "took": 0,
      "timed_out": false,
      "_shards": {
        "total": 1,
        "successful": 1,
        "skipped": 0,
        "failed": 0
      },
      "hits": {
        "total": {
          "value": 0,
          "relation": "eq"
        },
        "max_score": null,
        "hits": []
      }
    }
    

    无法命中的原因是,索引中注册的令牌为 “elasticsearch”“is”“powerful”,而 “power” 这一令牌并未被注册。因此,要实现预期的搜索结果,必须分别合理设计:

    • 数据注册时使用的分析器
    • 搜索字符串使用的分析器

    4. 对 text 型字段实现类 LIKE 从句的搜索方法

    要对 text 型字段实现类似 LIKE 从句的 “搜索包含特定模式字符串” 的功能,可通过对应用了包含 N-gram 令牌生成器(tokenizer)的分析器的字段执行 match_phrase 查询来实现。

    使用 N-gram 令牌生成器时,注册的字符串会被机械地按任意长度拆分令牌。例如,将 “Elasticsearch” 这一字符串按 2 个字符(bi-gram)拆分 N-gram 令牌,会得到 “El”“la”“as”……“rc”“ch” 等令牌,这些令牌会被注册到索引中。

    可在创建索引时按如下方式设置分析器,为特定字段配置包含 N-gram 令牌生成器的分析器。

    PUT test_index
    {
      "mappings": {
        "properties": {
          "message": {
            "type": "text",
            "analyzer": "my_analyzer"
          }
        }
      },
      "settings": {
        "analysis": {
          "analyzer": {
            "my_analyzer": {
              "tokenizer": "my_tokenizer"
            }
          },
          "tokenizer": {
            "my_tokenizer": {
              "type": "ngram",
              "min_gram": 2,
              "max_gram": 2
            }
          }
        }
      }
    }
    

    即便使用 match_phrase 搜索 “lastic”,搜索字符串也会被拆分为 “la”“as”“st”“ti”“ic” 等令牌,只有包含所有这些令牌的字符串才会命中。通过这种方式,即可实现相当于 LIKE 搜索的部分匹配搜索。

    GET test_index/_search
    {
      "query": {
        "match_phrase": {
          "message": "lastic"
        }
      }
    }
    
    {
      "took": 1,
      "timed_out": false,
      "_shards": {
        "total": 1,
        "successful": 1,
        "skipped": 0,
        "failed": 0
      },
      "hits": {
        "total": {
          "value": 1,
          "relation": "eq"
        },
        "max_score": 1.1507283,
        "hits": [
          {
            "_index": "test_index",
            "_id": "ESDup5MBGJks9_KvUZZQ",
            "_score": 1.1507283,
            "_source": {
              "message": "Elasticsearch is powerful"
            }
          }
        ]
      }
    }

    5. 总结

    本次介绍了在 Elasticsearch 中实现类 LIKE 搜索的部分匹配方法。

    若仅需实现部分匹配搜索,使用 wildcard 查询即可达成,但从系统运行时的搜索性能等角度考量,尽管需要提前进行分析器(Analyzer)设置等额外工作,采用 N-gram 结合 match_phrase 查询仍是基础且推荐的方案

    当然,根据具体的搜索需求,还需要进行更细致的分析器及查询设计。尤其在搜索性能与搜索精度之间如何取得平衡,是运用 Elasticsearch 过程中无法回避的关键问题。希望本文能为 Elasticsearch 的搜索设计提供参考。

  • 在 AWS 上使用 Elasticsearch(Elastic Cloud)的要点 (下篇)

    在 AWS 上使用 Elasticsearch(Elastic Cloud)的要点 (下篇)

    本文作为在 AWS 上使用 Elasticsearch(Elastic Cloud)的要点 下篇,将介绍在 Elastic Cloud 中执行以下操作的步骤。

    1. 版本升级

    1. 审计日志设置

    本文中,将 Elastic Cloud(Elasticsearch Service)的名称统一表述为 “Elastic Cloud”。

    1. 版本升级

    关于 Elastic Stack 的版本升级

    Elastic Stack 有两种版本升级方式,各自特点如下表所示:

    序号版本升级方式特点
    1滚动升级(Rolling Upgrade)无需停止服务即可完成版本升级
    2全集群升级(Full Cluster Upgrade)需一次性停止所有服务

    在 Elastic Cloud 中,采用的是序号 1 的滚动升级方式,因此无需停止服务就能完成版本升级。

    关于升级的详细信息,可参考以下链接:Upgrade versions | Elasticsearch Service Documentation | Elastic

    此外,在 Elastic Cloud 中,只需在图形用户界面(GUI)上点击一下,即可完成版本升级。下面实际介绍操作步骤。

    在 Elastic Cloud 中升级 Elastic Stack

    (1) 根据需要将Deployment设为维护模式

    在 Elastic Cloud 中,若对高负载的Deployment应用设置变更,可能会导致设置变更耗时较长,最坏情况下会出现响应中断、设置变更失败的问题。因此,虽然原则上无需停止服务即可完成版本升级,但当部署处于高负载状态时,也可考虑先将其切换为维护模式,再进行升级。

    访问 Elastic Cloud 的Deployment页面,选择菜单中的 “Edit”。

    点击 “Edit”

    在页面底部的 “Extended maintenance”处勾选复选框,再点击 “Save”按钮,即可将 Deployment设置为维护模式。

    (2) 点击 Elastic Cloud 部署页面右侧的 “Upgrade”按钮

    (3) 选择版本后,点击 “Upgrade”按钮

    以上步骤完成后,版本升级即可执行。版本升级操作简便,能够始终使用最新功能,这是 Elastic Cloud 的一大重要优势。

    2. 审计日志设置

    关于 Elastic Stack 的审计日志

    Elasticsearch 和 Kibana 均支持输出审计日志。通过审计日志,可监控认证失败、连接拒绝等与安全相关的事件。

    关于审计日志的详细信息,可参考以下文档:

    审计日志默认处于未启用状态,因此需按以下步骤启用。

    启用审计日志的步骤

    (1) 在 Elastic Cloud 的Deployment管理页面中,点击 “Edit”

    (2) 点击 Elasticsearch 右侧的链接 “Manage user settings and extensions”

    (3) 为 Elasticsearch 应用审计日志设置

    设置内容如下:xpack.security.audit.enabled: true

    (4) 点击 Kibana 右侧的链接 “Edit user settings”

    (5) 为 Kibana 也应用审计日志设置

    设置内容如下:xpack.security.audit.enabled: true

    (6) 点击页面底部的 “Save”(保存)按钮,应用设置

    (7) 在Monitoring功能的日志Logs中查看审计日志

    此时可看到 Elasticsearch 和 Kibana 的审计日志已输出。

    从上述审计日志中可以看出,“y_nomura” 用户在两次认证失败(红色高亮部分)后,成功完成了认证(黄色高亮部分)。通过输出审计日志,能够确认 “谁在何时登录”“访问了哪里” 等信息。

    总结

    截至目前,使用 Elastic Cloud 的要点讲解完毕,但除此之外,针对不同使用场景还有许多需要考虑的事项。如果有疑问,欢迎评论。

  • 在 AWS 上使用 Elasticsearch(Elastic Cloud)的要点 (上篇)

    在 AWS 上使用 Elasticsearch(Elastic Cloud)的要点 (上篇)

    本文将介绍在 AWS 上使用 Elasticsearch(Elastic Cloud)的要点。在本文中,将统一把 Elastic Cloud(Elasticsearch Service)简称为 “Elastic Cloud”。

    1. 监控(Monitoring)设置(Metric/Logs)

    关于Monitoring功能

    通过使用Monitoring功能,可一目了然地掌握集群状态;即便发生故障,也能从资源和日志两方面快速排查问题。

    在 Elastic Cloud 中启用Monitoring功能

    Monitoring功能默认处于未启用状态,需按以下步骤启用:

    (1) 访问 Elastic Cloud 的Deployment页面,点击菜单中的 “Logs and metrics”。

    点击 “Logs and metrics”

    (2) 点击 “Ship to a deployment”下方的 “Enable”。

    点击 “Enable”

    (3) 选择已搭建的部署,点击 “Save”,Monitoring功能即启用。

    点击 “Save”

    查看指标(Metric)

    通过指标可查看 Elastic Stack 各组件的服务器资源使用情况:

    (1) 在 Kibana 页面左侧菜单中,点击 “Stack Monitoring”

    点击 “Stack Monitoring”

    (2) 点击 Elasticsearch 的 “Overview”。在概览页面中,可实时查看 Elasticsearch 整体的搜索性能与索引性能。

    点击 “Overview”

    (3) 在 Elasticsearch 的 “Nodes”中,选择并点击一个实例。

    从 “Nodes” 中选择一个实例并点击

    此时可实时查看每台服务器的资源状态。

    查看Metric

    查看日志(Logs)

    通过日志可实时查看、筛选日志并进行问题排查:

    (1) 在 Kibana 页面左侧菜单中,点击 “Logs”。

    点击 “Logs”

    在Stream页面中,会实时显示导入 Elasticsearch 的各类日志。

    日志实时显示

    (2) 在页面上方的搜索框中输入 “error”,执行日志筛选。

    可以一边筛选日志,一边开展问题排查。

    输入 “error” 并执行日志筛选

    修改指标的保留期限

    指标的默认保留期限为 3 天。由于不同需求下的保留期限可能不同,建议根据实际情况修改设置:

    (1) 在 Kibana 页面左侧菜单中,点击 “Stack Management”

    点击 “Stack Management”

    (2) 点击 “Index Lifecycle Policies”。

    点击 “Index Lifecycle Policies”

    (3) 在搜索框中输入 “.monitoring”,点击显示结果中的 “.monitoring-8-ilm-policy”。

    点击 “.monitoring-8-ilm-policy”

    Elasticsearch 会将索引按 “阶段(Phase)” 进行管理,各阶段的过渡条件通过 ILM(索引生命周期管理,Index Lifecycle Management)定义。

    详情可参考以下链接:ILM: Manage the index lifecycle | Elasticsearch Guide [8.14] | Elastic

    修改前的设置如下表所示:

    阶段(Phase)设定值
    Hot 阶段索引创建后满 3 天,或主分片(Primary Shard)大小达到 50GB 以上时,对索引执行 Rollover
    Warm 阶段执行强制合并(Forcemerge),将分片的段(Segment)数量合并为 1
    Delete 阶段索引执行 Rollover 后满 3 天,将其删除

    简单来说,Hot 阶段中定义的 “Rollover” 是指当满足特定条件时,自动创建新索引的功能。

    详情可参考以下链接:Rollover | Elasticsearch Guide [8.14] | Elastic

    (4) 将 Delete 阶段的保留时间从 “3 天” 修改为 “31 天”,点击 “Save Policy”。

    修改设置并点击 “Save Policy”

    通过上述步骤,已成功将设置修改为:索引执行 Rollover 后满 31 天自动删除。

    2. Snapshot设置

    关于Snapshot设置

    在 Elastic Cloud 中,默认设置为每 30 分钟创建一次Snapshot。下面将介绍如何确认并修改该设置:

    (1) 在 Kibana 页面左侧菜单中,点击 “Stack Management

    点击 “Stack Management”

    (2) 点击 “Snapshot and Restore”

    点击 “Snapshot and Restore”

    (3) 点击 “Policies” 标签页,点击 “cloud-snapshot-policy” 右侧的 “Edit” 按钮。

    点击 “Edit”

    (4) 修改 “Schedule” 的设置值

    时间设置支持使用 Cron 表达式,请注意时区为 UTC(世界协调时间)

    详情可参考以下文档:API conventions | Elasticsearch Guide [8.14] | Elastic

    修改 “Schedule” 的设置值

    (5) 根据需求修改 “Expiration”“Snapshots to retain” 的设置值。

    (6) 点击 “Save policy”

    点击 “Save policy”

    (7) 点击 “cloud-snapshot-policy”,查看 “Summary”。修改后,snapshot将按设置在每天 0 点创建。

    查看 “Summary”

    3. Alert设置

    关于 Elastic Cloud 的Alert功能

    在 Elastic Cloud 中,可通过 “Alert” 功能实现监控与通知。默认情况下,系统提供了多个可配置的监控项,便于快速完成Alert设置。下面将介绍如何创建默认规则并使用Alert功能:

    (1) 从左侧菜单点击 “Stack Monitoring”,在监控页面右上角选择 “alerts and rules”,点击 “Create default rules”。

    点击 “Create default rules”

    (2) 点击 “Create”。至此,Alert设置完成。最后我们来确认已创建的规则列表:

    点击 “Create”

    (3) 点击 “Stack Management”,选择 “Alerts”,然后点击页面右上角的 “Manage rules”。

    点击 “Manage rules”

    此时会显示已创建的规则列表。通过编辑规则,可修改告警条件或配置通知方式。

    显示已创建的规则列表

    例如,“CPU Usage” 规则的默认配置为:当 CPU 使用率 5 分钟平均值超过 85% 时,触发告警并发送通知。

    CPU Usage

    此外,通知的默认接收方式为 “输出到 Kibana 日志”,但系统也支持配置邮件、Slack 等多种连接器(Connector)作为通知渠道。

    连接器列表

    总结

    在实际运维过程中,除了上述 内容外,可能还需要以下操作:

    • 版本升级应对
    • 审计日志

    因此,在下次的文章中,我会对上述内容进行讲解。