标签: Elastic Cloud

  • 在 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)作为通知渠道。

    连接器列表

    总结

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

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

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

  • 轻松开启 Elastic Cloud 可观测性(2024 年版)

    轻松开启 Elastic Cloud 可观测性(2024 年版)

    Elastic Cloud 是 Elastic 公司提供的 SaaS 服务,支持 AWS、Azure、GCP 等云服务提供商。只需点击几下,即可完成最新版本集群的搭建以及现有集群的版本升级,因此非常易于上手使用。

    本文将以步骤为基础,介绍如何利用 Elastic Cloud 轻松开启 AWS 资源指标监控、日志监控和存活监控。

    前言

    在本文中,Elastic Cloud(Elasticsearch Service)将统一称为 “Elastic Cloud”。此外,关于 Elastic Cloud 与待监控的各 AWS 服务的搭建步骤及权限设置,本文将予以省略。

    架构示意图

    本次将利用 Elastic Agent 实现对 AWS 资源指标、日志及存活状态的监控。

    1. Elastic AWS Integration 的安装

    (1)安装相关仪表盘等组件

    点击 “Install AWS” 按钮,安装相关资源。

    安装完成后,会显示相关仪表盘、API 参考文档等内容。

    (2)在 EC2 上安装 Elastic Agent

    点击 “Add Amazon EC2”,跳转页面后,点击页面底部的 “Install Elastic Agent”,开始安装 Agent。

    按照 “①在主机上安装 Elastic Agent” 的步骤,在 EC2 上执行命令,完成 Elastic Agent 的安装。按照步骤执行后,Agent 会如以下所示完成注册。

    (3)AWS Integration 的设置

    直接点击页面底部的 “Add the integration”,跳转至 AWS Integration 的设置页面。本次将进行以下设置:

    • 开启 “Collect EC2 logs from CloudWatch”(从 CloudWatch 收集 EC2 日志)
    • 设置 CloudWatch Logs 中已注册的待监控日志的 ARN
    • 将 “Collect EC2 metrics”(收集 EC2 指标)的 “Collection Period”(收集周期)设置为 “1m”
    • 从 “Advanced Setting”(高级设置)中输入访问密钥(Access Key)和秘密密钥(Secret Key)

    点击 “Save and Continue”(保存并继续)后,再点击 “Save and deploy changes”(保存并部署更改),将 AWS Integration 的设置同步到 Elastic Agent 中。

    (4)确认通过 AWS Integration 注册的数据

    完成上述操作后,即可通过 Elastic Agent 查看 EC2 的指标以及存储在 CloudWatch Logs 中的 EC2 日志。

    2. 资源指标监控

    首先,我们来确认已注册的 EC2 资源指标。

    (1)访问 Kibana 仪表盘页面

    从 Kibana 页面左侧菜单中选择「Dashboards」(仪表盘),点击「[Elastic Agent] Input Metrics」,即可显示以下仪表盘。

    通过该仪表盘可以跳转到各服务对应的仪表盘。本次仅针对 EC2 和 CloudWatch 收集资源指标,但 Elastic Cloud(Elastic Stack)的优势在于,还能聚合其他云环境、本地环境的资源信息,进行统一监控与分析。

    (2)确认 EC2 的资源指标

    同样,使用「[Metrics AWS] EC2 Overview」([AWS 指标] EC2 总览)仪表盘,能够更详细地查看各 EC2 实例的 CPU 使用率等指标。

    3. 日志监控

    日志监控将使用 Logs Explorer(日志探索器)。

    (1)通过 Logs Explorer 进行日志监控

    在 Logs Explorer 中,会显示日志的时间戳及其摘要(Summary),如下所示。当发生问题时,可以通过筛选日志消息、状态等信息进行分析,从而确认问题状况。截图中仅显示了特定主机的错误(Error)日志。

    Elasticsearch 的一大特点是,即便对大量日志进行筛选,也能快速返回结果,这在业务操作中非常便捷。如此一来,通过 Logs Explorer 就能轻松实现日志的确认与分析。

    但在实际运维中,无法做到时刻监控仪表盘和 Logs Explorer。因此,通过设置 Alerts(告警),可以在满足特定条件时实现检测与通知。有关告警的详细信息及设置方法,请参考以下文档:《Create and manage rules | Elastic Observability [8.16] | Elastic》

    4. 存活监控

    最后,我们来实施存活监控。存活监控将使用 Synthetic monitoring(合成监控)功能。有关合成监控的详细信息,请参考以下文档:Synthetic monitoring | Elastic Observability [8.16] | Elastic

    (1)访问 Synthetic monitoring 页面

    从 Kibana 页面左侧菜单中选择「Applications」(应用)⇒「SYNTHETICS」(合成监控)⇒「Monitors」(监控器),跳转到 Synthetic monitoring 页面。

    (2)设置监控对象

    点击页面顶部的「select a different monitor type」(选择其他监控器类型),按照以下内容进行设置,然后点击「Create Monitor」(创建监控器)。

    项目名(Item Name)说明(Description)本次设置值(Current Setting)
    Select a monitor typeHTTP Ping、TCP Ping 等HTTP Ping
    URL<监控对象 URL>Logstash 服务器 URL
    Monitor name任意名称LogstashServer
    Locations监控对象运行的地域US East(美国东部)

    (3)确认监控结果

    监控对象的存活状态会如下所示进行显示。

    通过 Synthetic monitoring,仅需在 Kibana 页面进行设置,即可实现对目标主机的存活监控,轻松达成存活监控需求。(此前需要在监控对象服务器上安装名为 Heartbeat 的 Beats 组件)

    (4)设置检测与通知

    在 Synthetic monitoring 中,可从 Kibana 页面轻松开启或关闭告警。点击页面中的「LogstashServer」,会显示如截图所示的详情页面。

    点击详情页面右上角「Enable (all location)」(启用 [所有地域])的开关,即可启用或禁用告警。还能便捷地通过邮件、Slack 等方式发送通知。

    总结

    借助 Elastic Cloud,我们能够轻松实现对 AWS 上服务的可观测性。正如前文所提及的,Elastic Cloud(Elastic Stack)的优势在于,能够聚合其他云环境、本地环境的信息,统一实现资源指标监控、日志监控与存活监控。