标签: AWS

  • RAG 中的混合搜索对决!OpenSearch Serverless VS Aurora Serverless

    RAG 中的混合搜索对决!OpenSearch Serverless VS Aurora Serverless

    前言

    今天我要对可作为 Amazon Bedrock Knowledge Bases 向量数据库(搜索引擎)的工具进行对比。

    目前,Bedrock Knowledge Base 中支持混合搜索的向量数据库如下:

    • OpenSearch Serverless
    • OpenSearch Managed Cluster(OpenSearch 托管集群)
    • Aurora Serverless V2(PostgreSQL)
    • MongoDB Atlas

    本次,我将针对其中使用率较高的OpenSearch ServerlessAurora Serverless V2(PostgreSQL) ,对比二者在混合搜索中的精度表现。

    概述

    混合搜索是一种结合向量(语义)搜索关键词(全文)搜索来查找相关文档的搜索方式。这种方式既能通过向量搜索实现基于语义的检索,又能通过关键词搜索,在检索过程中纳入指定关键词的考量。

    OpenSearch Serverless 与 Aurora Serverless V2(PostgreSQL)的对比

    下面我将对本次作为数据存储使用的 OpenSearch Serverless 和 Aurora Serverless V2(PostgreSQL)进行简单对比。

    对比维度OpenSearch ServerlessAurora Serverless V2(PostgreSQL)
    混合搜索(Bedrock Knowledge Bases)支持支持
    中文支持可使用 Kuromoji 等中文形态素分析PostgreSQL 标准全文搜索(目前不支持中文形态素分析)
    向量存储格式支持浮点数 / 二进制两种格式浮点数(基于 pgvector 插件)
    计费单位OCU / 小时(最小 1 个 OCU,含 0.5 计算 OCU+0.5 存储 OCU)ACU / 小时(最小 0.5 个 ACU)
    最小配置计费示例175.22 美元(1 个 OCU:175.2 美元,存储:0.02 美元)87.83 美元(1 个 ACU:87.60 美元,I/O:0.13 美元)

    (参考链接:aws.amazon.comaws.amazon.com

    OpenSearch Serverless 支持中文形态素分析,因此即便使用中文,也能高精度地进行关键词搜索。另一方面,Aurora Serverless V2(PostgreSQL)在最小配置下的费用更具优势,但由于其默认不支持中文形态素分析,因此在中文混合搜索的精度方面存在不确定性。

    精度对比实验

    为对比 OpenSearch Serverless 与 Aurora Serverless V2(PostgreSQL)的精度,本次将开展以下两类实验:

    1. 英文数据集的搜索精度对比
    2. 中文数据集的搜索精度对比

    尤其对于中文数据集,由于 Aurora Serverless V2(PostgreSQL)不支持中文形态素分析,预计 OpenSearch Serverless 在精度上会更具优势。

    1. 实验设置

    以下是本次实验使用的基本设置。首先,Bedrock Knowledge Base 的基础设置如下,仅向量存储工具为两者的差异点。

    嵌入模型(Embedding Model)嵌入类型(Embedding Type)分块策略(Chunking Strategy)
    Titan Text Embeddings V21024 维浮点数向量嵌入分层分块(父块:2000 字符,子块:500 字符,重叠:50 字符)

    精度对比将通过 Bedrock Evaluations 完成。

    (参考链接:docs.aws.amazon.com

    本次对比将采用以下两项指标,指标取值范围均为 0~1,数值越大表示对问题的回答质量越高:

    • Context relevance(上下文相关性):衡量获取的文本与问题在上下文层面的关联程度
    • Context coverage(上下文覆盖率):衡量获取的文本对正确数据中全部信息的覆盖程度

    2. 混合搜索对比(英文数据集)

    1. 数据集

    本次实验使用的数据集如下:Amazon Reviews 2023(2023 年亚马逊评论数据集)

    (参考链接:amazon-reviews-2023.github.io

    该数据集包含约 2.8 万组 “产品 ID – 评论” 数据,示例如下:

    product/productId: B000GKXY4S
    product/title: Crazy Shape Scissor Set
    product/price: unknown
    review/userId: A1QA985ULVCQOB
    review/profileName: Carleen M. Amadio "Lady Dragonfly"
    review/helpfulness: 2/2
    review/score: 5.0
    review/time: 1314057600
    review/summary: Fun for adults too!
    review/text: I really enjoy these scissors for my inspiration books that I am making (like collage, but in books) and using these different textures these give is just wonderful, makes a great statement with the pictures and sayings. Want more, perfect for any need you have even for gifts as well. Pretty cool!
    

    2. 结果(英文)

    对比结果如下,
    数值越高,评估结果越好。

    指标类型OpenSearch无服务器Aurora Serverless V2(PostgreSQL)
    上下文相关性0.060.07
    上下文覆盖0.190.18

    3. 混合搜索对比(中文数据集)

    那么,接下来将对核心中文数据集的(检索)精度展开比较分析。​

    1. OpenSearch(中文分词设置示例)

    由于 OpenSearch Serverless 可使用 Kuromoji 形态素分析(中文分词工具),因此需进行相关配置。

    通过该配置,中文文本能被正确分割,进而有望提升关键词搜索的精度。

    配置示例

    PUT bedrock-knowledge-base-hybrid-index
    {
      "mappings": {
        "properties": {
          "AMAZON_BEDROCK_METADATA": {
            "type": "text",
            "index": false
          },
          "AMAZON_BEDROCK_TEXT_CHUNK": {
            "type": "text",
            "analyzer": "custom_kuromoji_analyzer"
          },
          "bedrock-knowledge-base-default-vector": {
            "type": "knn_vector",
            "dimension": 1024,
            "method": {
              "name": "hnsw",
              "engine": "faiss",
              "space_type": "cosinesimil"
            }
          },
          "id": {
            "type": "text",
            "fields": {
              "keyword": {
                "type": "keyword",
                "ignore_above": 256
              }
            }
          }
        }
      },
      "settings": {
        "index": {
          "knn.algo_param": {
            "ef_search": "512"
          },
          "knn": "true",
          "analysis": {
            "analyzer": {
              "custom_kuromoji_analyzer": {
                "tokenizer": "kuromoji_tokenizer",
                "filter": [
                  "kuromoji_baseform",
                  "ja_stop"
                ],
                "char_filter": [
                  "icu_normalizer"
                ]
              }
            }
          }
        }
      }
    }
    
    

    2. 插入的中文文档

    本次使用的数据集,是让 ChatGPT 输出的,具体如下。
    在混合检索时,我们期望能以 “张居正生平” 作为关键词,检索到相关信息。

    张居正像(现藏于中国国家博物馆)

    时代 明朝中后期(嘉靖、隆庆、万历年间)

    生诞 嘉靖四年五月初三日(1525 年 5 月 24 日)

    死没 万历十年六月二十日(1582 年 7 月 9 日)(58 岁卒)

    改名 无(一直以 “张居正” 为名,字叔大,号太岳)

    字:叔大

    号:太岳

    谥号:文忠(万历朝初赠,后被追夺,天启朝恢复)

    墓所:湖北省荆州市沙市区张居正墓

    官职:吏部左侍郎兼东阁大学士、礼部尚书兼武英殿大学士、少师兼太子太师、吏部尚书、中极殿大学士(内阁首辅)

    主要事迹 1. 推行 “一条鞭法”,将田赋、徭役和杂税合并,按田亩折算银两征收,简化税制,增加财政收入;2. 实施 “考成法”,考核各级官吏政绩,整顿吏治,提高行政效率;3. 重用戚继光、李成梁等将领,加强北方边防,抵御蒙古部落侵扰,稳定边疆局势;4. 主持治理黄河、淮河,任用潘季驯负责河工,疏通河道,减少水患,保障农业生产。

    评估用数据集示例

    • 问题:请告知张居正被任命为吏部尚书的年份
    • 答案:张居正于明万历元年(公元 1573 年) 正式被任命为吏部尚书。

    3. 结果(中文)

    以下是中文数据集的精度对比结果。数值越大,代表评价结果越好。

    Metric typeOpenSearch ServerlessAurora Serverless V2(PostgreSQL)
    Context relevance0.450.43
    Context coverage1.000.93

    如上表所示,尽管优势微弱,但 OpenSearch Serverless 在两项指标上均超过 Aurora Serverless V2(PostgreSQL)。尤其在衡量 “问题回答覆盖度” 的上下文覆盖率(Context coverage)指标上,OpenSearch Serverless 的优势更为明显。

    我们认为,这一差异源于 OpenSearch Serverless 通过 Kuromoji 实现了中文形态素分析支持,进而在混合搜索的关键词搜索精度上形成了优势。

    此外,我们也对比了两者的搜索速度,结果如下:我们连续执行 5 种不同查询,去除最大值与最小值后计算 “截尾平均值”(Trimmed Mean)进行对比。

    OpenSearch Serverless(秒)Aurora Serverless V2(PostgreSQL)(秒)
    0.48 秒0.55 秒

    从搜索速度来看,OpenSearch Serverless 同样具备更快的检索表现。

    总结

    本次实验对比了在 Bedrock 知识库中,分别使用 OpenSearch Serverless 与 Aurora Serverless V2(PostgreSQL)实现混合搜索的效果。结果显示,在中文搜索的精度与速度上,OpenSearch Serverless 均优于 Aurora Serverless V2(PostgreSQL)。

    需要说明的是,本次验证基于 “数据量较少” 的场景,因此两者的差距并不显著;若后续数据量增加,结果可能会发生变化。不过,从整体来看,两款工具在精度与速度上均具备较高性能,建议根据实际使用场景数据量选择合适的工具。

  • 基于 Amazon S3 Vectors 的 RAG 性能与精度评估实践

    基于 Amazon S3 Vectors 的 RAG 性能与精度评估实践

    本次想为大家介绍在 2025 年纽约 AWS Summit 上发布的 S3 Vectors,内容将包含其与现有向量存储的对比分析。

    相关参考链接:aws.amazon.com

    什么是 S3 Vectors

    S3 Vectors 是 AWS S3 推出的新功能,本质是一款向量存储服务。由于依托 S3 提供,它与 AWS 此前可用的向量存储(如 OpenSearch Serverless、Aurora 等)不同 —— 无需承担运行成本,仅需根据数据量和 API 请求量支付费用。基于这一特性,在部分使用场景中,可实现大幅成本削减。

    相关参考链接:aws.amazon.com

    1. 与其他向量存储的成本对比

    假设每月使用 1GB 存储容量、执行 30000 次检索,以下为 S3 Vectors 与其他向量存储的成本对比示例。※AWS 区域按美国弗吉尼亚北部计算。

    向量存储名称每月总成本成本明细
    S3 Vectors$2.06存储:$2.00,请求:$0.06
    OpenSearch Serverless$175.221 个 OCU:$175.2,存储:$0.02
    Aurora Serverless v2$87.831 个 ACU:$87.60,存储:$0.10,I/O:$0.13
    Pinecone$0(入门版)/$50(标准版)使用 5 个及以上索引时,必须选择标准版

    由此可见,与其他向量存储相比,S3 Vectors 的成本具有压倒性优势。

    2. 功能层面的限制事项

    S3 Vectors 虽能以低成本使用,但在以下功能上存在限制。

    向量存储名称元数据过滤检索功能块大小(Chunk Size)限制分层分块(Hierarchical Chunking)
    S3 Vectors仅支持完全匹配检索、范围检索500 tokens△(默认设置下不可用)
    OpenSearch Serverless支持部分匹配检索等灵活检索方式无限制○(可用)

    元数据过滤检索功能

    进行元数据过滤检索时,无法像 OpenSearch Serverless 那样实现部分匹配等灵活检索,仅支持完全匹配、范围检索等基础方式。

    相关参考链接:docs.aws.amazon.com

    块大小限制

    可创建的最大块大小限制为 500 tokens。

    相关参考链接:docs.aws.amazon.com

    借助 Bedrock 知识库使用分层分块

    在 Bedrock 知识库的默认设置下,同步时会出现以下错误,导致无法使用分层分块功能:

    Filterable metadata must have at most 2048 bytes (Service: S3Vectors, Status Code: 400, Request ID:XXXXXX)

    若要从 Bedrock 知识库使用分层分块,需先在 S3 Vectors 中创建以下配置的索引:

    aws s3vectors create-index \
      --vector-bucket-name "bucket-name" \
      --index-name "index-name" \
      --data-type "float32" \
      --dimension 256 \
      --distance-metric "cosine" \
      --metadata-configuration '{"nonFilterableMetadataKeys":["AMAZON_BEDROCK_METADATA"]}'
    

    出现该限制的原因是,分层分块的父块所存储的元数据,在默认设置下仅能容纳 2048 字节以内的内容。因此,需通过上述命令,将存储父块的元数据指定为 “不可过滤元数据”。

    相关参考链接:docs.aws.amazon.com

    除上述之外,由于 S3 Vectors 仅支持向量检索,因此自然无法实现 OpenSearch Serverless 等服务所支持的混合检索功能。

    3. S3 Vectors 的最佳实践

    官方文档中介绍了以下最佳实践:

    最佳实践核心要点
    重试处理为避免系统过载,推荐采用带退避策略(Backoff)的重试机制
    通过索引拆分实现扩展按租户或用途分别使用多个索引,可提升系统吞吐量
    元数据设计将仅用于参考的文本等设置为不可过滤元数据,以优化性能
    访问控制可通过索引级别的 IAM 权限控制,灵活设计租户级访问限制等权限管理规则

    参考链接:docs.aws.amazon.com

    其中,在访问控制方面,官方特别推荐使用 IAM 角色进行配置,这一点在实际运维中也颇具参考价值。

    与其他向量存储的速度对比

    接下来,我们针对实际使用中最受关注的检索速度,将 S3 Vectors 与 OpenSearch Serverless 进行对比。本次对比基于 Bedrock 知识库的检索场景,具体检索条件如下:

    • 数据源:包含以下 IPA PDF 在内,共约 800MB、1000 个文件
      • 《面向安全网站运营》
      • 《软件开发数据白皮书 2018-2019》
      • 《软件开发数据白皮书 2018-2019 金融保险业篇》
      • 《软件开发数据白皮书 2018-2019 信息通信业篇》
    • 嵌入模型(Embedding Model):Titan Text Embeddings v2
    • 嵌入类型(Embedding Type):1024 维浮点向量嵌入
    • 分块策略(Chunking Strategy):固定分块
    • 分块大小(Chunk Size):300 tokens

    为覆盖缓存生效的场景,我们共设计了 100 种不同的查询语句作为测试请求。

    查询示例

    • “制造业中新开发项目的工时与工期关系”
    • “制造业改良开发中 FP(功能点)规模与工时的关系”

    对比结果

    向量存储名称平均时间(秒)最大时间(秒)最小时间(秒)
    S3 Vectors0.6881.5990.553
    OpenSearch Serverless0.4330.5070.383

    结果显示,S3 Vectors 的平均检索速度比 OpenSearch Serverless 慢 0.2 秒左右,最大延迟甚至相差 1 秒。不过,结合官方文档中 “检索响应时间需控制在 1 秒以内” 的标准来看,S3 Vectors 基本能满足大多数 RAG 场景的速度要求。

    参考链接:docs.aws.amazon.com

    与其他向量存储的精度对比

    接下来,我们从精度维度进行对比,分别测试 S3 Vectors 的 “仅向量检索” 与 OpenSearch Serverless 的 “混合检索” 效果。

    本次精度验证采用 Bedrock Evaluations 工具完成。

    参考链接:aws.amazon.com

    1. 基于向量检索的精度对比

    首先,仅针对向量检索的精度进行验证。我们沿用上述相同的知识库配置进行测试,采用以下两项指标评估精度:

    • 上下文相关性:衡量检索到的文本与查询问题在上下文层面的关联程度
    • 上下文覆盖率:衡量检索到的文本对正确答案全部信息的覆盖程度

    对比结果

    S3 Vectors 的精度

    OpenSearch Serverless 的精度

    由于两者采用相同的检索方式,因此精度水平基本相当。这表明,在仅使用向量检索的场景下,S3 Vectors 的精度与 OpenSearch Serverless 等现有向量存储相比并无明显差距。

    2. 与混合检索的精度对比

    接下来,我们使用包含产品 ID 等信息的数据集,对比 S3 Vectors 的向量检索与 OpenSearch Serverless 的混合检索精度。

    本次测试采用新数据集 —— 按用户整理的 Amazon 评论数据。

    混合检索验证数据集

    1. 2023年亚马逊评论

    https://amazon-reviews-2023.github.io

    该数据集包含约 2.8 万组

    product/productId: B000GKXY4S product/title: Crazy Shape Scissor Set product/price: unknown review/userId: A1QA985ULVCQOB review/profileName: Carleen M. Amadio “Lady Dragonfly” review/helpfulness: 2/2 review/score: 5.0 review/time: 1314057600 review/summary: Fun for adults too! review/text: I really enjoy these scissors for my inspiration books that I am making (like collage, but in books) and using these different textures these give is just wonderful, makes a great statement with the pictures and sayings. Want more, perfect for any need you have even for gifts as well. Pretty cool!

    在精度验证时,我们准备了如下所示的 “问题 – 答案” 配对,并重点围绕混合检索的核心特征 —— 关键词检索精度展开评估。

    评估用数据集示例

    问题:请告知商品 ID 为 B000GKXY4S 的评论摘要。

    答案:Fun for adults too!

    测试时,知识库配置保持不变,仅将 OpenSearch Serverless 的检索方式指定为 “混合检索”。

    精度验证结果

    S3 Vectors 的精度

    OpenSearch Serverless 的精度

    结果显示,在 “上下文相关性” 和 “上下文覆盖率” 两项指标上,采用混合检索的 OpenSearch Serverless 精度均优于仅支持向量检索的 S3 Vectors。

    以下为 “混合检索可成功匹配,但 S3 Vectors 向量检索未匹配成功” 的查询示例:

    查询示例

    请告诉我商品 ID 为 B000GKXY4S 的评论摘要。

    S3 Vectors(向量检索)结果:未检索到查询中包含的 ID :B000GKXY4S

    返回结果为 “product/productId: B000FP553C product/title: Kinesio Scissors

    OpenSearch Serverless(混合检索)结果:成功检索到查询中包含的 ID :B000GKXY4S

    返回结果为 “product/productId: B000GKXY4S product/title: Crazy Shape Scissor Set

    由此可见,由于 S3 Vectors 仅支持向量检索,在需指定 ID、特定单词等关键词的检索场景中,其精度会出现下降。

    总结

    本文结合与现有向量存储的对比,介绍了 S3 的新功能 ——S3 Vectors。尽管 S3 Vectors 在功能上存在一定限制,但对于仅需向量检索的场景,其功能已足够满足需求;加之其成本极低,非常值得尝试应用。

  • 活用 Amazon Bedrock 的 Rerank API 提升 RAG 精度

    活用 Amazon Bedrock 的 Rerank API 提升 RAG 精度

    在 RAG(检索增强生成:Retrieval-Augmented Generation)为用户提供准确信息的过程中,检索精度尤为关键。

    而提升检索精度的方法之一便是 “重排序(Rerank)”。

    通过执行重排序操作,将检索得到的结果按相关度重新排序,能更轻松地针对用户所需信息给出回答。

    如今,Amazon Bedrock 已新增支持重排序的模型,且可与 Bedrock Knowledge Base 搭配使用。

    以往,实现这一功能需要自行托管模型等,颇为繁琐;而现在,只需在向 Knowledge Base 发起的检索请求中添加相关设置,即可一并执行检索与重排序操作,且仅能获取重排序后的结果。

    本次我们将实际使用重排序模型,验证检索结果会发生怎样的变化。

    1. 前言

    1.1 什么是重排序(Rerank)

    在包含 Bedrock Knowledge Base 在内的 RAG 检索中,向量检索的应用十分广泛。

    然而,仅依靠向量检索往往无法达到足够的检索精度,难以给出恰当的回答。

    因此,对通过向量检索获取的文档进行重排序处理,可使相关度更高的文档出现在检索结果的靠前位置。

    重新排序的图像

    1.2 以往的实现方式

    此前,要在 RAG 系统中集成重排序处理,需搭建 SageMaker 实例、托管重排序专用模型并执行推理。

    例如,在 2024 年 8 月时,若要使用 Cohere Rerank 3,就需按照下述文章的说明创建 SageMaker 实例。

    aws.amazon.com

    这种方式存在诸多问题,如需要投入精力准备 SageMaker 实例与重排序模型,且会产生运营成本。

    1.3 Bedrock 支持的重排序模型

    自 2024 年 12 月起,可通过 Bedrock 使用重排序模型。

    借助该重排序模型,无需自行托管模型,仅通过调用 API 即可执行重排序操作。

    这不仅省去了运营管理的繁琐工作,还无需一直启动服务器,只需根据使用量付费,让用户能轻松开启重排序功能的使用。

    除了可通过 Bedrock 的 InvokeModel API 调用外,还支持通过 Bedrock Knowledge Base 的 Rerank API、Retrieve API、RetrieveAndGenerate API、RetrieveAndGenerateStream API 进行调用。

    截至 2025 年 1 月,提供的模型有 Amazon Rerank 1.0(以下简称 Amazon Rerank 模型)和 Cohere Rerank 3.5(以下简称 Cohere Rerank 模型)。

    2. 尝试应用重排序模型

    本次验证将使用本文中已采用的、模拟酒店评论检索的数据。

    此次以 “烤肉好吃的酒店” 为检索词,期望 “使用本地产蔬菜和肉类制作的烤肉料理” 的第 10 条评论以及 “炭火烤制的牛排” 的第 7 条评论能出现在检索结果的靠前位置。

    重排序模型选用 Amazon Rerank 模型。

    序号内容
    1这家酒店的温泉堪称顶级疗愈。源泉直供的温泉水格外柔和,泡完后肌肤感觉滑溜溜的。从露天温泉能眺望到美丽的群山,夜晚还能一边泡澡一边欣赏满天繁星。这是一家让人想反复前往的温泉酒店。
    2酒店的温泉非常舒服,能让人彻底放松。室内温泉和露天温泉各具特色,尤其是从露天温泉看到的庭院景色美不胜收,可欣赏到四季不同的美景。水温也恰到好处,长时间浸泡也不会觉得疲惫。
    3早就听闻这是一家以温泉为特色的酒店,实际体验远超预期。因直接使用天然温泉源泉,水质极佳,泡完后身体持续暖暖的。我们还预约了私人温泉,在专属空间里度过了惬意的时光。
    4温泉区域宽敞开阔,视野极佳。从露天温泉能一览大海,可伴着海浪声悠闲度日。水温也不会过高,能慢慢暖遍全身,非常满意。此外,还支持当日往返使用,让人能轻松前来,这点很贴心。
    5温泉散发着令人舒心的硫磺香气,让人真切感受到来到了温泉胜地。温泉水功效显著,能明显感觉到肌肤变得光滑。这里有多个温泉池,有时特定时段还能独享,让人体验到奢华感。另外,泡完温泉后提供的冰镇饮品也是个惊喜服务。
    6酒店的餐食宛如艺术品。大量使用本地新鲜食材制作的怀石料理,不仅外观精美,每一道菜都能让人感受到制作的用心。尤其是用当季海鲜制作的刺身,堪称绝品,仅凭这一点就想再次前来。
    7晚餐有很多本地特色菜,非常满意。特别是炭火烤制的牛排,入口即化,美味得让人想一再续盘。早餐种类也很丰富,用本地蔬菜制作的沙拉和手工豆腐都很美味。
    8晚餐是套餐形式,每道菜都很好吃,其中最令人印象深刻的是用本地采摘的蔬菜制作的前菜和自制甜点。采用凸显食材本味的简单烹饪方式,充分展现了食材的优良品质。早餐营养均衡,刚出炉的面包尤其美味。
    9酒店的餐食超出预期。因靠近海边,大量使用新鲜海鲜,刺身和煮鱼都非常好吃。晚餐分量充足,每道菜的调味都饱含心意。早餐的日式料理也很美味,尤其是温泉蛋堪称绝品。
    10晚餐是大量使用本地食材制作的创意料理,每道菜都能感受到巧思。特别是用本地产蔬菜和肉类制作的烤肉料理,堪称绝品,充分凸显了食材本身的味道。早餐也很用心,有手工果酱和刚出炉的面包等,非常满意。

    2.1 通过 Bedrock 的 InvokeModel API 使用

    InvokeModel API 是用于调用 Bedrock 所提供模型的 API。

    在请求体(body)中输入想要进行重排序的文档列表以及用户的查询语句后,就能在响应结果中获取到按与用户查询语句相关度从高到低重新排序的文档,以及各自的相关度(分数)。

    代码

    query = "烤肉好吃的酒店"
    documents = [
        "这家酒店的温泉堪称顶级疗愈。源泉直供的温泉水格外柔和,泡完后肌肤感觉滑溜溜的。从露天温泉能眺望到美丽的群山,夜晚还能一边泡澡一边欣赏满天繁星。这是一家让人想反复前往的温泉酒店。",
        # (省略)
    ]
    
    response = bedrock.invoke_model(
        modelId="amazon.rerank-v1:0",
        body=json.dumps({
            "query": query,
            "documents": documents,
            "top_n": 3,
        }),
    )
    
    body = json.loads(response["body"].read())
    pprint.pprint(body["results"])
    

    输出

    [{'index': 9, 'relevance_score': 0.001466458403084568},
     {'index': 6, 'relevance_score': 0.0005013742398679934},
     {'index': 8, 'relevance_score': 0.0003640086870995012}]
    

    ※重排序结果中包含的索引(index)以 0 为起始,为了与上方表格保持一致,需在索引数值上加 1。

    结果

    序号内容
    10晚餐是大量使用本地食材制作的创意料理,每道菜都能感受到巧思。特别是用本地产蔬菜和肉类制作的烤肉料理,堪称绝品,充分凸显了食材本身的味道。早餐也很用心,有手工果酱和刚出炉的面包等,非常满意。
    7晚餐有很多本地特色菜,非常满意。特别是炭火烤制的牛排,入口即化,美味得让人想一再续盘。早餐种类也很丰富,用本地蔬菜制作的沙拉和手工豆腐都很美味。
    9酒店的餐食超出预期。因靠近海边,大量使用新鲜海鲜,刺身和煮鱼都非常好吃。晚餐分量充足,每道菜的调味都饱含心意。早餐的日式料理也很美味,尤其是温泉蛋堪称绝品。

    可以确认,正如预期的那样,第 10 条和第 7 条评论内容排在了靠前位置。

    2.2 通过 Bedrock Knowledge Base 的 Rerank API 使用

    Rerank API 是作为 Knowledge Base 的功能提供的,但其本质与上述的 InvokeModel 相同,输入文档列表和用户查询语句后,就能得到重排序后的文档列表。

    代码

    region = boto3.Session().region_name
    amazon_rerank_arn = f"arn:aws:bedrock:{region}::foundation-model/amazon.rerank-v1:0"
    
    response = bedrock_agent.rerank(
        queries=[
            {
                "type": "TEXT",
                "textQuery": {
                    "text": query,
                },
            },
        ],
        sources=[
            {
                "inlineDocumentSource": {
                    "textDocument": {
                        "text": document,
                    },
                    "type": "TEXT",
                },
                "type": "INLINE",
            } for document in documents
        ],
        rerankingConfiguration={
            "type": "BEDROCK_RERANKING_MODEL",
            "bedrockRerankingConfiguration": {
                "numberOfResults": 3,
                "modelConfiguration": {
                    "modelArn": amazon_rerank_arn,
                },
            },
        },
    )
    
    pprint.pprint(response["results"])
    

    输出

    [{'index': 9, 'relevanceScore': 0.0014664584305137396},
     {'index': 6, 'relevanceScore': 0.0005013742484152317},
     {'index': 8, 'relevanceScore': 0.0003640086797531694}]
    

    可以确认,得到了与使用 InvokeModel 时完全相同的结果。

    2.3 通过 Bedrock Knowledge Base 的 Retrieve API 使用

    与 InvokeModel、Rerank API 不同,在 Retrieve API 中,无需传入文档列表作为输入。

    该 API 以用户的查询语句为输入,先通过用户查询语句检索向量数据库,再将检索结果作为文档列表进行重排序。

    为了使用 Retrieve API,我们先创建了知识库,并将上述内容逐条作为一个数据块进行存储。

    首先确认不进行重排序时的结果。

    代码

    response = bedrock_agent.retrieve(
        knowledgeBaseId=knowledgebase_id,
        retrievalConfiguration={
            "vectorSearchConfiguration": {
                "numberOfResults": 3,
                "overrideSearchType": "SEMANTIC",
            },
        },
        retrievalQuery={
            "text": query,
        },
    )
    
    pprint.pprint(response["retrievalResults"])
    

    输出

    [{'content': {'text': '酒店的餐食宛如艺术品。大量使用本地新鲜食材制作的怀石料理,不仅外观精美,每一道菜都能让人感受到制作的用心。尤其是用当季海鲜制作的刺身,堪称绝品,仅凭这一点就想再次前来。',
                  'type': 'TEXT'},
      'location': {'s3Location': {'uri': 's3://xxx/006.txt'},
                   'type': 'S3'},
      'score': 0.43565163},
     {'content': {'text': '酒店的餐食超出预期。因靠近海边,大量使用新鲜海鲜,刺身和煮鱼都非常好吃。晚餐分量充足,每道菜的调味都饱含心意。早餐的日式料理也很美味,尤其是温泉蛋堪称绝品。',
                  'type': 'TEXT'},
      'location': {'s3Location': {'uri': 's3://xxx/009.txt'},
                   'type': 'S3'},
      'score': 0.435101},
     {'content': {'text': '晚餐是大量使用本地食材制作的创意料理,每道菜都能感受到巧思。特别是用本地产蔬菜和肉类制作的烤肉料理,堪称绝品,充分凸显了食材本身的味道。早餐也很用心,有手工果酱和刚出炉的面包等,非常满意。',
                  'type': 'TEXT'},
      'location': {'s3Location': {'uri': 's3://xxx/010.txt'},
                   'type': 'S3'},
      'score': 0.4281698}]
    

    结果

    序号内容
    6酒店的餐食宛如艺术品。大量使用本地新鲜食材制作的怀石料理,不仅外观精美,每一道菜都能让人感受到制作的用心。尤其是用当季海鲜制作的刺身,堪称绝品,仅凭这一点就想再次前来。
    9酒店的餐食超出预期。因靠近海边,大量使用新鲜海鲜,刺身和煮鱼都非常好吃。晚餐分量充足,每道菜的调味都饱含心意。早餐的日式料理也很美味,尤其是温泉蛋堪称绝品。
    10晚餐是大量使用本地食材制作的创意料理,每道菜都能感受到巧思。特别是用本地产蔬菜和肉类制作的烤肉料理,堪称绝品,充分凸显了食材本身的味道。早餐也很用心,有手工果酱和刚出炉的面包等,非常满意。

    当获取前 3 条结果时,第 10 条评论排在第 3 位,而第 7 条评论未出现在检索结果中。

    若使用这样的检索结果进行 RAG,恐怕难以得到高精度的回答。

    接下来,在 Retrieve API 中指定重排序模型,确认检索结果会发生怎样的变化。

    代码

    response = bedrock_agent.retrieve(
        knowledgeBaseId=knowledgebase_id,
        retrievalConfiguration={
            "vectorSearchConfiguration": {
                # (1) 首次检索时获取 10 条结果
                "numberOfResults": 10,
                "overrideSearchType": "SEMANTIC",
                "rerankingConfiguration": {
                    "bedrockRerankingConfiguration": {
                        "modelConfiguration": {
                            "modelArn": amazon_rerank_arn,
                        },
                        # (2) 对检索得到的 10 条结果进行重排序,并返回前 3 条
                        "numberOfRerankedResults": 3,
                    },
                    "type": "BEDROCK_RERANKING_MODEL",
                },
            },
        },
        retrievalQuery={
            "text": query,
        },
    )
    
    pprint.pprint(response)
    

    输出

    [{'content': {'text': '晚餐是大量使用本地食材制作的创意料理,每道菜都能感受到巧思。特别是用本地产蔬菜和肉类制作的烤肉料理,堪称绝品,充分凸显了食材本身的味道。早餐也很用心,有手工果酱和刚出炉的面包等,非常满意。',
                  'type': 'TEXT'},
      'location': {'s3Location': {'uri': 's3://xxx/010.txt'},
                   'type': 'S3'},
      'score': 0.0014721895568072796},
     {'content': {'text': '晚餐有很多本地特色菜,非常满意。特别是炭火烤制的牛排,入口即化,美味得让人想一再续盘。早餐种类也很丰富,用本地蔬菜制作的沙拉和手工豆腐都很美味。',
                  'type': 'TEXT'},
      'location': {'s3Location': {'uri': 's3://xxx/007.txt'},
                   'type': 'S3'},
      'score': 0.0004994205664843321},
     {'content': {'text': '酒店的餐食超出预期。因靠近海边,大量使用新鲜海鲜,刺身和煮鱼都非常好吃。晚餐分量充足,每道菜的调味都饱含心意。早餐的日式料理也很美味,尤其是温泉蛋堪称绝品。',
                  'type': 'TEXT'},
      'location': {'s3Location': {'uri': 's3://xxx/009.txt'},
                   'type': 'S3'},
      'score': 0.0003640086797531694}]
    

    结果

    序号内容
    10晚餐是大量使用本地食材制作的创意料理,每道菜都能感受到巧思。特别是用本地产蔬菜和肉类制作的烤肉料理,堪称绝品,充分凸显了食材本身的味道。早餐也很用心,有手工果酱和刚出炉的面包等,非常满意。
    7晚餐有很多本地特色菜,非常满意。特别是炭火烤制的牛排,入口即化,美味得让人想一再续盘。早餐种类也很丰富,用本地蔬菜制作的沙拉和手工豆腐都很美味。
    9酒店的餐食超出预期。因靠近海边,大量使用新鲜海鲜,刺身和煮鱼都非常好吃。晚餐分量充足,每道菜的调味都饱含心意。早餐的日式料理也很美味,尤其是温泉蛋堪称绝品。

    通过执行重排序,第 10 条和第 7 条内容占据了前 2 位。

    这样一来,就能为用户提供更多其所需的信息了。

    3. Amazon Rerank 模型与 Cohere Rerank 模型的对比

    接下来,我们使用同样可在 Bedrock 上使用的 Cohere Rerank 模型对相同内容进行测试。

    只需将 modelArn 替换为 Cohere Rerank 模型对应的 ARN,就能切换所使用的重排序模型。

    操作起来非常简便。

    代码

    cohere_rerank_arn = f"arn:aws:bedrock:{region}::foundation-model/cohere.rerank-v3-5:0"
    # (省略)
    

    输出

    [{'content': {'text': '晚餐是大量使用本地食材制作的创意料理,每道菜都能感受到巧思。特别是用本地产蔬菜和肉类制作的烤肉料理,堪称绝品,充分凸显了食材本身的味道。早餐也很用心,有手工果酱和刚出炉的面包等,非常满意。',
                  'type': 'TEXT'},
      'location': {'s3Location': {'uri': 's3://xxx/010.txt'},
                   'type': 'S3'},
      'score': 0.3279808461666107},
     {'content': {'text': '酒店的餐食宛如艺术品。大量使用本地新鲜食材制作的怀石料理,不仅外观精美,每一道菜都能让人感受到制作的用心。尤其是用当季海鲜制作的刺身,堪称绝品,仅凭这一点就想再次前来。',
                  'type': 'TEXT'},
      'location': {'s3Location': {'uri': 's3://xxx/006.txt'},
                   'type': 'S3'},
      'score': 0.1456373631954193},
     {'content': {'text': '晚餐有很多本地特色菜,非常满意。特别是炭火烤制的和牛牛排,入口即化,美味得让人想一再续盘。早餐种类也很丰富,用本地蔬菜制作的沙拉和手工豆腐都很美味。',
                  'type': 'TEXT'},
      'location': {'s3Location': {'uri': 's3://xxx/007.txt'},
                   'type': 'S3'},
      'score': 0.11919290572404861}]
    

    结果

    序号内容
    10晚餐是大量使用本地食材制作的创意料理,每道菜都能感受到巧思。特别是用本地产蔬菜和肉类制作的烤肉料理,堪称绝品,充分凸显了食材本身的味道。早餐也很用心,有手工果酱和刚出炉的面包等,非常满意。
    6酒店的餐食宛如艺术品。大量使用本地新鲜食材制作的怀石料理,不仅外观精美,每一道菜都能让人感受到制作的用心。尤其是用当季海鲜制作的刺身,堪称绝品,仅凭这一点就想再次前来。
    7晚餐有很多本地特色菜,非常满意。特别是炭火烤制的和牛牛排,入口即化,美味得让人想一再续盘。早餐种类也很丰富,用本地蔬菜制作的沙拉和手工豆腐都很美味。

    与使用 Amazon Rerank 模型时相比,第 7 条的排名下降了一位,但仍在前三之列。

    第 6 条内容虽然是关于海鲜料理而非肉类料理的评论,但它是关于美味料理的评论,而非温泉相关,因此我认为其得分较高。

    这样一来,在 RAG 生成回答时,也能在不缺失信息的情况下进行内容生成了。

    4. 其他

    4.1 调用速度

    我们对 Amazon Rerank 模型与 Cohere Rerank 模型的响应速度是否存在差异进行了验证。

    针对俄勒冈区域的模型,我们分别对相同请求各执行 5 次,通过比较响应时间的平均值来分析差异。

    Amazon Rerank 模型

    序号响应时间(秒)
    10.895
    20.687
    30.734
    40.828
    50.775
    平均0.784

    Cohere Rerank 模型

    序号响应时间(秒)
    10.454
    20.508
    30.533
    40.495
    50.453
    平均0.489

    对比结果显示,Cohere Rerank 模型的速度约为 Amazon Rerank 模型的 1.5 倍。

    4.2 费用

    本次使用的模型费用如下表所示。

    虽然相较于非重排序模型(例如 Amazon Nova Lite 为每 1000 个输出令牌 0.00024 美元),这些重排序模型的费用略显偏高,但这也意味着仅通过 API 调用就能使用到如此复杂的功能。

    序号模型费用
    1Amazon Rerank 模型1 美元 / 1000 次查询
    2Cohere Rerank 模型2 美元 / 1000 次查询

    总结

    我们对 Bedrock 新增的重排序模型进行了验证,确认其对改善检索结果具有实际作用。

    实验表明,通过执行重排序操作,能够使更贴合用户输入的内容出现在检索结果的靠前位置。

    此外,Bedrock Knowledge Base 的优势在于,无需自行开发实现,仅通过修改设置就能实现检索效果的大幅提升。

    本次验证仅进行到检索(retrieve)阶段,而若使用 retrieve_and_generate 功能,还可将回答生成的过程也交由 Bedrock 完成。

    未来,我希望活用 Bedrock 的重排序功能,开发出更贴合用户意图的 RAG 系统。

  • 使用 Aurora Serverless v2 作为 Amazon Bedrock Knowledge Bases 的向量数据库

    使用 Aurora Serverless v2 作为 Amazon Bedrock Knowledge Bases 的向量数据库

    今天我尝试了使用 Amazon Bedrock Knowledge Bases,并将 Amazon Aurora PostgreSQL 用作向量数据库。

    去年 12 月,Amazon Bedrock Knowledge Bases 新增了可快速创建 Aurora PostgreSQL 作为向量数据库的功能,大幅简化了设置流程。

    本次我也将利用这一快速创建功能进行设置。

    aws.amazon.com

    1. 将 Aurora PostgreSQL 配置为向量存储

    事前准备

    本次将 S3 用作 RAG(检索增强生成)的外部数据源。之后,我们会确认 LLM(大语言模型)的回答是否参考了存储在 S3 中的资料。

    Knowledge Bases 的创建

    在 AWS 管理控制台中,进入 Bedrock 页面,仅通过 GUI 操作即可轻松创建 Knowledge Bases。

    点击 “Knowledge Base with vector store”(带向量存储的知识库),即可跳转至 Knowledge Bases 创建页面。

    在 “步骤 2 配置数据源” 中,指定事前准备好的 S3 的 URI。而 “步骤 3 选择嵌入模型并配置向量数据库” 则是本次的核心内容。

    向量数据库的选项中新增了 “Amazon Aurora PostgreSQL Serverless” 这一项目,请选择此项。

    ※向量数据库的可选范围因区域而异,本文中测试使用的是东京区域。

    之后点击 “下一步”,确认创建内容后即可完成设置。仅需通过 GUI 操作即可完成,直观又简单!

    在 RDS 控制台中可以确认已创建的数据库。

    数据库表的创建情况如下所示。

    Bedrock_Knowledge_Base_Cluster=> \d bedrock_knowledge_base
            Table "bedrock_integration.bedrock_knowledge_base"
      Column   |        Type         | Collation | Nullable | Default
    -----------+---------------------+-----------+----------+---------
     id        | uuid                |           | not null |
     embedding | public.vector(1536) |           |          |
     chunks    | text                |           |          |
     metadata  | jsonb               |           |          |
    Indexes:
        "bedrock_knowledge_base_pkey" PRIMARY KEY, btree (id)
        "bedrock_knowledge_base_embedding_idx" hnsw (embedding public.vector_l2_ops)
    

    Knowledge Bases 的测试

    选择已创建的 Knowledge Bases 后,会出现 “测试知识库”页面。在此处向 LLM 提问,测试是否能返回预期的回答。

    本次我提出了 “敏捷开发的优势是什么?“ 这一问题。结果如预期般返回了参考了事前准备并存储在 S3 中的资料的回答,看起来运行正常。

    2. 与 OpenSearch Serverless 的对比

    OpenSearch Serverless 是被广泛用作向量数据库的代表性服务。此处将整理其与 Aurora Serverless v2 在实际使用中的差异。

    功能

    当使用 Aurora PostgreSQL 作为向量数据库时,仅支持语义搜索这一种检索类型。

    而使用 OpenSearch Serverless 时,则可在混合搜索与语义搜索之间进行选择。

    • 语义搜索:并非简单的关键词匹配,而是检索语义上相关的信息。
    • 混合搜索:将关键词检索与语义搜索相结合进行信息检索。

    从检索功能性来看,OpenSearch Serverless 更具优势。若需融入关键词检索功能,建议选择 OpenSearch Serverless。

    成本

    OpenSearch Serverless 的计算费用采用计时收费模式,即便处于未使用状态,仍会产生每小时的费用。以美国东部(弗吉尼亚北部)区域为例,每个单位的费用为 0.24 美元 / 小时。根据文档说明,至少会按 2 个单位计费,因此每月的费用约为 0.24 美元 / 小时 × 720 小时 × 2 = 345 美元。

    相比之下,Aurora Serverless v2 不仅单价低廉(0.12 美元 / 单位 / 小时),还支持缩容至 0 个单位。因此,能够有效控制未使用状态下的成本。

    aws.amazon.com

    查看此前通过快速创建功能搭建的 Aurora PostgreSQL 实例配置,确认其确实支持缩容至 0 个单位,与预期一致。

    在 CloudWatch 中查看单位使用率(ACU),可以确认实例在未使用时会自动缩容至 0 个单位。

    3. 检索速度确认

    最后,我们将验证文档数量增加时的检索速度及 ACU(Aurora 计算单位)变化情况。数据源采用 Kaggle 上的 “BBC News Summary” 数据集,将约 9000 条数据存储至 S3 中。

    参照 “1. 将 Aurora PostgreSQL 配置为 Bedrock Knowledge Bases 的向量数据库” 中的方法,向 LLM 发起提问。结果显示,与文档数量较少时相同,回答在数十毫秒内即可返回。对于本次使用的数据集规模而言,检索速度似乎不存在明显问题。

    查看 ACU 数据可知:文档导入时的 ACU 使用率约为 30%(16(最大扩容单位数)× 0.3 = 5 个单位),LLM 生成回答时的 ACU 使用率约为 15%(16 × 0.15 = 2.5 个单位)。

    向量数据库的 ReadLatency(读取延迟)控制在 0.01 秒以内,使用体验较为流畅。

    4. 总结

    本次尝试了在 Bedrock Knowledge Bases 中使用 Aurora Serverless v2 作为向量数据库。

    借助快速创建功能,仅需几次 GUI 点击操作,即可轻松完成向量数据库的搭建。对于 “控制未使用状态下成本” 这一需求,也能够轻松实现。

    最后提醒

    仅删除 Bedrock Knowledge Bases,并不能移除通过快速创建功能生成的向量数据库等其他关联资源。若不再需要这些资源,请务必手动删除,避免遗漏。

  • Amazon Bedrock Flows 尝试实现交互式流程

    Amazon Bedrock Flows 尝试实现交互式流程

    前言

    Amazon Bedrock Flows 新增支持了多轮对话功能这一新特性。(参考链接:aws.amazon.com

    以往,用户需要在单次提示词中输入处理所需的全部信息,而借助多轮对话形式,AI 能够轻松实现适时追问缺失信息的功能。此次,我们就利用这一多轮对话功能来实现交互式流程。

    1. 概述

    Amazon Bedrock Flows 是什么?

    Amazon Bedrock Flows 是 AWS 提供的基于 GUI 的生成式 AI 框架。借助它,我们可以轻松构建专属的 AI 代理及聊天机器人。

    多轮对话功能是什么?

    此次新增支持的多轮对话功能,能够实现对话式流程,即向用户追问缺失的信息。

    例如,以旅行计划的建议与预订流程为例,单次对话与多轮对话存在如下区别:

    单次对话与多轮对话示例对比

    在以往的单次对话中,若要从输入文本中提取必要信息并进行处理,输入文本必须包含所有必要信息。倘若输入中缺少必要信息,流程会直接进入后续处理环节。因此,可能会导致无法处理,或者 AI 自行推测生成必要信息,从而出现非预期的行为。

    而使用多轮对话功能后,若存在信息缺失,流程不会进入下一步,而是会向用户进行追问。如此一来,借助多轮对话功能,能够轻松实现更自然的对话流程。

    在 Amazon Bedrock Flows 中创建多轮对话流程

    接下来,为大家介绍在 Amazon Bedrock Flows 中使用多轮对话功能的方法。本次将以示例形式,创建一个基于预算、PC 用途、台式机或笔记本电脑等条件推荐 PC 的流程。

    流程概述

    首先,本次创建的流程整体结构如下:

    PC 推荐流程

    用户输入由代理节点接收。提示词节点虽也能以文本形式接收用户输入,但由于多轮对话功能是代理独有的功能,因此此处使用代理。

    随后,代理提取预算、PC 用途、台式机或笔记本电脑这三类信息,并将其传递给后续的 AWS Lambda 函数以进行 PC 推荐。

    Lambda 函数的推荐逻辑较为简单,仅返回与提取的信息组合相对应的 PC 名称。

    创建支持多轮对话的代理

    首先,创建用于接收用户输入并提取 PC 推荐所需信息的代理。本次传递给代理的指令如下:

    请分析用户输入,并提取以下 3 个参数。
    
    # 需提取的信息
    1. 价格区间(price_range)
       - 若用户预算低于 15 万日元,返回 "lower_than_150000yen"
       - 若用户预算高于或等于 15 万日元,返回 "higher_than_150000yen"
    
    2. 用途(use_case)
       - 若需要游戏用 PC,返回 "game"
       - 若用于工作、文档制作、邮件等商务用途,返回 "business"
    
    3. PC 类型(pc_type)
       - 若需要台式机,返回 "desktop"
       - 若需要笔记本电脑,返回 "laptop"
    
    # 输出格式
    提取所需信息后,请以以下 JSON 格式返回结果。
    
    {
      "price_range": "lower_than_150000yen",
      "use_case": "game",
      "pc_type": "laptop"
    }
    

    接下来,进行多轮对话的设置:在 “其他设置” 中将 “用户输入” 设为 “启用”。这样即可实现多轮对话功能。

    (此处对应 “代理的多轮对话功能设置” 相关内容)

    创建 PC 推荐 Lambda 函数

    接下来,创建用于接收代理输出的 JSON 并返回推荐 PC 的 Lambda 函数。本次在函数中简单定义了一份 PC 列表。

    运行

    # PC 推荐映射表
    PC_RECOMMENDATION_MAP = {
        "lower_than_150000yen.game.desktop": "ASUS ROG Strix G15",
        "lower_than_150000yen.game.laptop": "Dell G15 Ryzen Edition",
        "lower_than_150000yen.business.desktop": "HP Pavilion Desktop TP01",
        "lower_than_150000yen.business.laptop": "Lenovo ThinkPad E14",
        "higher_than_150000yen.game.desktop": "Alienware Aurora R15",
        "higher_than_150000yen.game.laptop": "Razer Blade 15 Advanced",
        "higher_than_150000yen.business.desktop": "Apple Mac Studio",
        "higher_than_150000yen.business.laptop": "Apple MacBook Pro 16-inch",
    }
    
    def lambda_handler(event, context):
        # 获取输入参数
        input_str = event.get("node", {}).get("inputs", [])[0].get("value", "")
    
        # 从代理输出的文本中提取 JSON 并解析
        match = re.search(r'\{.*?\}', input_str, re.DOTALL)
        json_str = match.group(0) if match else None
        pc_params = json.loads(json_str)
    
        # 推荐 PC
        recommend_key = f"{pc_params['price_range']}.{pc_params['use_case']}.{pc_params['pc_type']}"
        recommended_pc = PC_RECOMMENDATION_MAP.get(recommend_key, "no_recommended_pc")
    
        if recommended_pc == "no_recommended_pc":
            response = "暂无推荐的 PC。"
        else:
            response = f"推荐您选择 {recommended_pc}。"
    
        return response
    

    尝试进行多轮对话

    下面,我们来与创建好的流程进行对话测试。

    面对模糊问题时,是否会追问具体内容?

    测试面对用户的模糊问题时,系统是否会追问具体内容。

    首先,来看多轮对话功能关闭时的结果,以及此时代理传递给后续环节的输出。

    此处,我们输入模糊的价格表述:“想要一台价格亲民的 PC”。

    多轮对话功能关闭时的结果

    从这一结果来看,即便多轮对话功能处于关闭状态,代理似乎也试图进行追问,但追问的内容并未传递给用户,而是直接发送至后续处理环节,进而导致了错误。

    另一方面,多轮对话功能开启时的结果如下:

    多轮对话功能开启时的结果

    从结果可以看出,代理并未进入下一步处理,而是针对用户的模糊提问追问了具体信息。

    此外,Lambda 中定义的推荐 PC 如下表所示,符合预期的 “Lenovo ThinkPad E14” 被成功推荐。

    价格区间用途PC 类型推荐 PC
    7000元以下游戏台式机ASUS ROG Strix G15
    7000元以下游戏笔记本电脑Dell G15 Ryzen Edition
    7000元以下商务台式机HP Pavilion Desktop TP01
    7000元以下商务笔记本电脑Lenovo ThinkPad E14
    7000元以下游戏台式机Alienware Aurora R15
    7000元以下游戏笔记本电脑Razer Blade 15 Advanced
    7000元以下商务台式机Apple Mac Studio
    7000元以下商务笔记本电脑Apple MacBook Pro 16-inch

    能否基于多次交互而非单次交流给出回答?

    接下来,我们测试当对话发生多次往复时,系统是否能基于此前的全部对话内容给出回答。

    以下测试中,我们将 PC 相关信息分多次提供给系统。

    往复对话的回答结果

    从结果可见,尽管信息被拆分成了 3 次对话传递,但系统依然包含了首个用户消息中 “预算控制在9000 元以内” 这一信息,并成功推荐了符合预期的 PC。

    总结

    通过 Amazon Bedrock Flows 的多轮对话功能,我们发现:即便用户输入模糊,或对话发生多次往复,系统也能准确提取所需信息。借助该功能,我们可以轻松构建自然对话形式的 AI 服务,建议大家务必尝试一下。

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

    连接器列表

    总结

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

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

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

  • 在 AWS 上使用 Elastic Cloud

    在 AWS 上使用 Elastic Cloud

    各位是否使用过 Elastic Cloud 呢?Elastic Cloud 是 Elastic 公司提供的 SaaS 服务,支持 AWS、Azure、GCP 这三大云服务提供商。由于只需点击几次鼠标,就能完成最新版本集群的搭建以及现有集群的版本升级,因此非常易于部署使用。

    但在实际使用时,需要考虑的事项其实有很多,比如访问限制、与 Cognito 的联动等。我认为这其中有不少容易让人 “踩坑” 的地方,所以整理了相关操作步骤和注意事项。

    本文将介绍如何通过 AWS Marketplace 搭建集群,以及后续的安全设置 / 认证设置步骤。

    1. 前言

    本文中,将统一把 Elastic Cloud(Elasticsearch Service)简称为 “Elastic Cloud”。

    在 AWS 上搭建 Elastic Cloud 的步骤

    通过 AWS Marketplace,可按照以下 4 个步骤在 AWS 上搭建 Elastic Cloud:

    1. 通过 Marketplace 搭建集群
    2. 安全强化(IP 过滤设置)
    3. 安全强化(Private Link 设置)
    4. 为 Kibana 添加 Cognito 认证

    架构示意图如下:

    架构示意图

    接下来,将分别说明每个步骤的搭建 / 设置方法。

    2. 通过 Marketplace 搭建集群

    Elastic Cloud 账号创建

    首先需要注意的是,无法将已有的 Elastic Cloud 账号与 AWS Marketplace 上的 Elastic Cloud 进行关联使用,请务必留意。因此,本次将通过 “Sign up with email(使用邮箱注册)”,使用新的邮箱地址创建账号。

    Elastic Cloud 账号注册页面

    登录成功后的页面如下:

    通过 Marketplace 的部署步骤

    第一步,我们将通过 AWS Marketplace 搭建 Elastic Cloud。

    (1) 访问 AWS Marketplace 上的 Elastic Cloud 页面,点击 “View purchase options(查看购买选项)”

    aws.amazon.com

    (2) 在购买页面点击 “Subscribe(订阅)”

    点击后,页面顶部会显示如下提示信息,请点击 “Set up your account(设置您的账号)”。

    (3) 按照页面显示的步骤完成各项设置在步骤 2 中,需关联此前创建的 Elastic Cloud 账号。

    关联成功后,将显示如下页面。

    在步骤 3 中,可通过 CloudFormation 部署 Elastic Cloud。

    此时需要注意,需提前创建好 CloudFormation 在搭建过程中要使用的角色。
    所需的权限策略可通过页面上的 “View required IAM permission” 进行确认。

    只需设置 CloudFormation 的堆栈名称、要创建的Deployment名称、搭建所在的Region以及 CloudFormation 在搭建时使用的角色名称,即可在 AWS 上搭建Deployment。

    当页面显示 “CREATE_COMPLETE” 时,即表示搭建成功。

    在步骤 4 中,点击 “Launch software”,即可在 Elastic Cloud 控制台中查看已创建的Deployment。

    (4) 确认登录已部署的 Kibana

    已成功创建的 Deployment,其 Kibana可正常登录。

    URL的格式为「https://<Deployment 名>.kb.us-east-2.aws.elastic-cloud.com/app/home」,其中会包含创建 Deployment 时所设定的名称。

    2. 安全强化(IP 过滤设置)

    接下来,为已搭建的 Deployment 配置 IP 过滤规则。

    IP 过滤的作用与优势

    通过配置 IP 过滤,可对 Deployment(包含 Elasticsearch、Kibana)的访问进行限制。有关详细信息,请参博客:www.elastic.co

    下面实际操作配置步骤。

    IP 过滤配置方法

    (1) 在已创建的 Deployment 管理页面中,点击 “Features”

    (2) 点击 “Add traffic filters”,再点击 “Create filter”

    (3) 输入 IP 地址等条件后,点击 “Create filter”创建成功后,页面将显示已创建的 IP 过滤规则定义,如下所示。

    (4) 在 Deployment 的安全设置页面中,点击 “Apply filter”,将创建的规则应用到该 Deployment

    将已创建的 IP 过滤规则定义应用到 Deployment。

    至此,已成功为在 Elastic Cloud 上搭建的 Deployment 应用 IP 过滤规则。

    3. 安全强化(Private Link 设置)

    接下来配置 Private Link。通过配置 Private Link 实现 VPC(虚拟私有云)之间的连接,可使通信无需经过互联网,从而提升安全性。

    Private Link 配置方法

    (1) 创建 AWS 的 Endpoint(终端节点)有关创建方法,请参考以下链接:docs.aws.amazon.com

    (2) 点击 “Add traffic filters”,再点击 “Create filter”

    与配置 IP 过滤时相同,将打开过滤规则创建页面。

    (3) 在 “Filter type” 中选择 “Private link endpoint”,在 “Endpoint ID” 中输入步骤 (1) 创建的 Endpoint ID,然后点击 “Create filter”

    选择过滤类型并输入终端节点 ID

    (4) 与配置 IP 过滤时的操作相同,将创建的规则应用到 Deployment

    此时,IP 过滤和 Private Link 这两项安全设置已成功应用。

    应用过滤规则后的页面

    4. 为 Kibana 添加 Cognito 认证

    Elasticsearch 支持通过 OIDC(OpenID Connect,开放身份连接)实现认证。通过 OIDC 联动实现认证的优势在于,可将用户管理集中到一个服务中,从而简化管理与运维工作。

    因此,最后为 Kibana 添加 Cognito 认证。

    基于 Cognito 的 Kibana 认证配置方法

    配置 OIDC 认证需执行以下步骤,详细内容请参考官方文档:www.elastic.co

    1. SSL/TLS 配置
    2. Token Service启用
    3. OIDC 认证配置
    4. role mapping(Kibana 操作权限配置)

    在上述步骤中,步骤 1 和步骤 2 在 Elastic Cloud 中默认已配置完成,因此本次操作将从步骤 3 “OIDC 认证配置” 开始。

    (1) 创建 AWS Cognito 的用户池,并注册用户

    本次将同时使用 Cognito 作为 OP(OpenID Provider)和 RP(Relying Party)。

    本文将省略 Cognito 自身的配置与搭建方法。需特别注意的一点是:由于 OIDC 认证配置需要,需在 RP 侧创建客户端密钥(Client Secret)。

    (2) 在已创建的 Deployment 管理页面中,点击 “Security”

    (3) 在 Elasticsearch keystore区域,点击 “Add settings”

    (4) 在 “Setting name” 中输入xpack.security.authc.realms.oidc.oidc1.rp.client_secret,在 “Secret” 中输入步骤 (1) 创建的客户端密钥

    (5) 点击 “Save”,将客户端密钥注册到 Elasticsearch keystore 中

    (6) 在已创建的 Deployment 管理页面中,点击 “Edit”

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

    (8) 为 Elasticsearch 应用 OIDC 配置

    配置内容如下:

    xpack:​
      security:​
        authc:​
          realms:​
            oidc:​
              oidc1:​
                order: 2​  
                rp.client_id: "<RP客户端ID>"​  
                rp.response_type: code​ 
                rp.redirect_uri: https://<Kibana URL>/api/security/oidc/callback  
                op.issuer: https://cognito-idp.<区域名>.amazonaws.com/<OP用户池ID>​  
                op.authorization_endpoint: https://<OP域名>/oauth2/authorize​ 
                op.token_endpoint: https://<OP域名>/oauth2/token​ 
                op.userinfo_endpoint: https://<OP域名>/oauth2/userInfo​  
                op.jwkset_path: "https://cognito-idp.<区域名>.amazonaws.com/<OP用户池ID>/.well-known/jwks.json"​  
                claims.principal: sub
    

    (9) 点击页面底部的 “Save”,将配置应用到 Elasticsearch

    (10) 点击 Kibana 页面左侧菜单的 “Stack management”,随后点击 “Role mappings”

    通过定义 Role mappings,可为经 Cognito(OIDC)认证的用户配置 Kibana 操作权限。

    (11) 点击 “Create role mapping”,将权限与 OIDC 账号关联

    在 Role Mapping 页面点击 “Create role mapping”

    按以下方式,为通过 OIDC 登录的用户配置权限

    为通过 OIDC 登录的用户配置权限

    登录 Kibana

    配置完成后,可使用已注册用户的邮箱地址和密码登录 Kibana。

    登录后的页面

    总结

    Elastic Cloud 不仅搭建简便,后续的安全设置与认证设置也十分容易。在使用 Elasticsearch 时,不妨考虑选择 Elastic Cloud。

  • 轻松开启 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)的优势在于,能够聚合其他云环境、本地环境的信息,统一实现资源指标监控、日志监控与存活监控。