使用 Elastic Observability 排查你的 Agents 和 Amazon Bedrock AgentCore

原创 于 2025-12-10 15:03:18 发布 · 710 阅读 · 8 ·
CC 4.0 BY-SA版权
本文为博主原创文章，未经博主允许不得转载。
文章标签：

#elasticsearch #大数据 #搜索引擎 #数据库 #全文检索 #ai #人工智能

作者：来自 Elastic Daniela Tzvetkova，Agi K Thomas，Ishleen Kaur 及 Bahubali Shetti

了解如何为 Amazon Bedrock AgentCore 实现端到端可观测性：从跟踪服务健康状况和 token 成本，到使用分布式追踪调试复杂的推理循环。


介绍

我们很高兴推出 Elastic Observability 的 Amazon Bedrock AgentCore 集成，它让用户能够端到端地观察 Amazon Bedrock AgentCore 以及 agents 的 LLM 交互。Agentic AI 标志着应用构建方式的一次根本性转变。

与只会生成文本的标准 LLM 聊天机器人不同，agents 能够推理、规划，并自主执行多步工作流来完成复杂任务。很多时候这些 agents 运行在 Amazon Bedrock AgentCore 这样的平台上，它帮助开发者构建、部署并扩展 agents。Amazon Bedrock AgentCore 是 Amazon Bedrock 的平台，提供安全、可扩展、模块化的基础设施服务（例如 agent runtime、memory、identity），让开发者能够使用任何框架或模型来部署和运行高能力 AI agents。

使用 Amazon Bedrock Agentcore 这样的平台很容易，但排查一个 agent 却比调试标准微服务复杂得多。主要挑战包括：

  • 非确定性行为：agent 对同一个 prompt 可能选择不同的工具或推理路径，使得问题难以复现。
  • “黑盒” 执行：当 agent 失败或产生幻觉答案时，通常难以判断问题来自 LLM 的推理、提供的上下文，还是工具执行失败。
  • 成本与延迟盲点：单个用户查询可能触发递归循环或昂贵的多步工具调用，导致 token 使用量和延迟意外飙升。

要有效观测这些系统，你需要关联来自两个不同层面的信号：

  1. 平台层（Amazon Bedrock AgentCore）：你需要了解托管服务的整体健康状况，包括调用次数、延迟、限流以及影响 AgentCore 上所有 agents 的平台级错误等高层指标。
  2. 应用层（你的 Agentic 逻辑）：你需要了解行为背后的细粒度 “原因”。这包括分布式追踪（通常使用 OpenTelemetry），可视化完整请求生命周期（例如瀑布图），精确找出推理链中的哪个步骤失败或耗时过长。

Elastic 的 Agentic AI Observability 通过结合来自 Amazon Bedrock AgentCore 的平台级洞察（通过新的 Amazon Bedrock AgentCore 集成）和来自 agent 的 OpenTelemetry （OTel）追踪、日志、指标的深度应用级可见性，为你的 agentic 部署提供端到端的统一视图。这个统一视图让你能够在 Elastic 中观察、排查并优化你的 agentic 应用，而无需切换工具。此外，Elastic 提供 Agent Builder，让你可以创建 agents 来分析来自 Amazon Bedrock AgentCore 以及其上运行的 agents 的任何数据。

Elastic 中的 Agentic AI Observability

如前所述，Elastic 中实现端到端 Agentic AI 可观测性主要由两部分组成。

  • Amazon Bedrock AgentCore 平台可观测性 —— 通过平台日志和指标，Elastic 通过摄取 AWS 提供的日志和指标，为 AgentCore 服务四个关键组件提供全面的高层健康状况可见性：
    • Runtime：监控核心性能指标，例如 agent 错误、总体延迟、限流次数和每个 endpoint 的调用速率。
    • Gateway：提供关于 gateway 和工具调用性能的特定洞察，包括调用次数、错误率和延迟。
    • Memory：跟踪短期和长期 memory 操作，包括事件创建、检索和列表，并伴随性能分析、错误和延迟指标。
    • Identity：通过成功和失败的访问尝试日志来审计安全性和访问健康状况。
  • 使用 APM、日志和指标的 Agent 可观测性 —— 为了理解你的 agent 如何运行，Elastic 从运行在 AgentCore 内的应用中摄取 OTel 原生 traces、metrics 和 logs。这让你可以在详细的瀑布图中可视化完整的执行路径，包括 LLM 推理步骤和工具调用。
  • Agentic AI 分析 —— 来自 Amazon Bedrock AgentCore 和其上运行的 agent 的所有数据，都可以使用 Elastic 的 AI 驱动能力进行分析。这包括：
  • 基于 Elastic Agent Builder 构建的 Elastic AgentCore SRE Agent —— 我们不仅监控 agents，还提供一个 agent 来协助你的团队。AgentCore SRE Agent 是一个使用 Elastic Agent Builder 构建的专业助手，具备对在 Elastic 中观测到的 AgentCore 应用的专业知识。
    • 它的作用：你可以询问关于 AgentCore 环境的具体问题，例如如何解读复杂错误日志，或为什么某条 trace 显示延迟。
    • 获取 agent：你可以从我们的 GitHub 仓库自行部署这个 agent。
  • Elastic Observability AI Assistant —— 在 Elastic 的 UI 中任何地方使用自然语言，帮助你定位问题、分析具体内容，或通过 LLM 知识库了解问题的根源。此外，SRE 可以解读日志消息、错误、指标模式，优化代码、撰写报告，甚至识别和执行 runbook，或查找相关的 github issue。
  • Streams —— AI 驱动的日志分析 —— 当你将来自已注入应用的 AgentCore 日志发送到 Elastic 后，你可以解析并分析它们。此外，Streams 会在日志流中发现 Significant Events，让你能立刻关注最重要的内容。
  • Dashboards 和 ES|QL ——  数据只有在你能付诸行动时才真正有价值。Elastic 提供开箱即用（out-of-the-box - OOTB）资产，加速你的平均修复时间（MTTR）。Elastic 还提供 ES|QL 帮助你对任何信号进行 ad-hoc 分析。
    • OOTB Dashboards：基于 AgentCore 服务信号的预构建可视化。这些仪表盘立即提供 runtime、gateway、memory、identity 组件的使用情况、健康状况和性能的高层概览。
    • OOTB Alert Templates：预配置的常见 agentic 问题告警（例如高错误率、延迟激增、token 使用异常），让你能立刻从被动排查转向主动预防。

将 Amazon Bedrock AgentCore 信号接入 Elastic

Amazon Bedrock AgentCore 集成

要开始平台级可见性，首先需要在 Elastic 中启用 Amazon Bedrock AgentCore 集成。这个集成会通过 Amazon CloudWatch 自动收集来自 AgentCore runtime、gateway、memory、identity 组件的指标和日志。

设置步骤：

1）准备 AWS 环境：确保你的 AgentCore agents 已部署并在运行，并且你已在 AWS 控制台为 AgentCore 资源开启日志。

2）添加集成：

  • 在 Elastic（Kibana）中进入 Integrations。
  • 搜索 “ Amazon Bedrock AgentCore ”。选择 Add Amazon Bedrock AgentCore。

3）配置并部署：

 配置 Elastic 的 Amazon Bedrock AgentCore 集成，从你选择的 AWS 区域按指定的采集间隔收集 CloudWatch metrics。日志会在本博客发布后不久加入。

使用 OTel Instrumentation 接入 Agent

下一步是观察应用程序自身的逻辑。Amazon Bedrock AgentCore 的好处在于运行时通常已经预先完成了自动埋点。你只需要告诉它遥测数据应该发送到哪里。

在这个示例中，我们会使用 Elastic Observability examples 中的 Travel Assistant。

要为这个 agent 做埋点，你不需要修改源代码。相反，当你使用 agentcore CLI 调用 agent 时，只需将 Elastic 连接信息作为环境变量传入即可。这样 OTel 信号（traces、metrics、logs）就会直接发送到 Elastic EDOT collector。

示例调用命令：运行以下命令来启动 agent，并开始将遥测数据流式发送到 Elastic：

    agentcore launch \
    --env BEDROCK_MODEL_ID="us.anthropic.claude-3-5-sonnet-20240620-v1:0" \
    --env OTEL_EXPORTER_OTLP_ENDPOINT="https://<REPLACE_WITH_ELASTIC_ENDPOINT>.region.cloud.elastic.co:443" \
    --env OTEL_EXPORTER_OTLP_HEADERS="Authorization=ApiKey <REPLACE_WITH_YOUR_API_KEY>" \
    --env OTEL_EXPORTER_OTLP_PROTOCOL="http/protobuf" \
    --env OTEL_METRICS_EXPORTER="otlp" \
    --env OTEL_TRACES_EXPORTER="otlp" \
    --env OTEL_LOGS_EXPORTER="otlp" \
    --env OTEL_RESOURCE_ATTRIBUTES="service.name=travel_assistant,service.version=1.0.0" \
    --env AGENT_OBSERVABILITY_ENABLED="true" \
    --env DISABLE_ADOT_OBSERVABILITY="true" \
    --env TAVILY_API_KEY="<REPLACE_WITH_YOUR_TAVILY_KEY>"

关键配置参数：

  • OTEL_EXPORTER_OTLP_ENDPOINT：你的 Elastic OTLP 端点（确保指定 443 端口）。
  • OTEL_EXPORTER_OTLP_HEADERS：包含你的 Elastic API Key 的 Authorization 头。
  • DISABLE_ADOT_OBSERVABILITY=true：这确保原生 AgentCore 信号只被路由到你定义的端点（Elastic），而不是默认的 AWS 路径。

在 Elastic Observability 中分析 Agentic 数据

在下面演示分析功能时，我们将使用之前仪表化的 Travel Assistant agent，以及你可能在 AgentCore 上运行的其他应用。作为示例中的第二个 agent，我们将使用 AWS Labs AgentCore 样例中的 Customer Support Assistant。

开箱即用（OOTB）仪表板

Elastic 基于 Amazon Bedrock AgentCore 服务日志和指标生成了一套全面的仪表板。这些仪表板以统一视图显示，并提供标签页，形成对平台运行健康的“单一视窗”。

该视图分为四个关键区域，每个区域对应 AgentCore 的特定组件 —— Runtime、Gateway、Memory、Identity。请注意，并非所有 agentic 应用都使用全部四个组件。在我们的示例中，只有 Customer Assistant 使用全部四个组件，而 Travel agent 仅使用 Runtime。

Runtime 健康状况

可视化 agent 调用、会话指标、错误趋势（系统错误 vs. 用户错误）以及性能统计信息，如延迟和限流，并按端点拆分。该仪表板帮助你回答如下问题：

“我的 Travel Assistant agent 和 Customer Support agent 在整体流量和延迟方面表现如何，是否存在错误或限流的峰值？”

Gateway 性能

分析 Lambda 和 MCP（Model Context Protocol）的调用情况，并对工具调用与非工具调用进行详细拆分。仪表板突出显示限流检测、目标执行时间，并区分系统错误和用户错误。

回答的问题：“我的外部集成（Lambda、MCP）运行效率如何，是否有特定工具调用出现高延迟、限流或系统级错误？”

Memory 操作

跟踪核心操作，如事件创建、检索和列表，同时深入分析长期内存处理。这包括按策略类型划分的提取和整合指标，以及对限流和系统错误 vs. 用户错误的特定监控。

  • 回答的问题：“内存整合策略失败或高检索延迟是否妨碍了 agent 有效回忆用户上下文？”

身份与访问

监控身份令牌获取操作（工作负载、OAuth、API keys）以及实时认证成功/失败率。仪表板按提供商划分活动，并突出显示限流或容量瓶颈。

  • 回答的问题：“特定提供商的认证失败或令牌获取瓶颈是否妨碍了 agent 访问所需资源？”

开箱即用（OOTB）告警模板

可观测性不仅仅是查看仪表板，还包括知道何时采取行动。为了从被动检查转向主动监控，Elastic 提供了 OOTB 告警规则模板（从 Elastic 版本 9.2.1 开始）。

这些模板通过预先选择最佳监控指标并应用合理阈值，消除了猜测。该配置专注于对真实异常的高保真告警，帮助你及早发现关键问题，同时减少告警疲劳。

建议的 OOTB 告警：

  • Agent Runtime 系统错误：检测 agent runtime 调用期间的服务器端错误（500 Internal Server Error），指示 AWS Bedrock AgentCore 的基础设施或服务问题。
  • Agent Runtime 用户错误：标记 agent runtime 调用期间的客户端错误（4xx），包括验证失败（400）、资源未找到（404）、访问被拒（403）和资源冲突（409）。这有助于及早发现权限配置错误、无效输入或缺失资源。
  • Agent Runtime 高延迟：当 agent runtime 调用的平均延迟超过 10 秒（10,000ms）时触发。延迟衡量从接收请求到发送最终响应 token 的时间。

APM Tracing

日志和指标可以告诉你问题存在，但 APM Tracing 告诉你问题确切发生的位置和原因。通过采集已仪表化 agent 的 OpenTelemetry 信号，Elastic 为每次交互生成详细的分布式追踪（如瀑布图）。若需进一步了解 LLM 信息，如 prompts、responses、token 使用等，可以查看 APM 日志。

这让你能够窥视 agent 执行流程的 “黑箱”：

  • 可视化思路链：查看从用户初始 prompt 到最终响应的完整事件序列，包括所有中间推理步骤。
  • 精确定位工具失败：确定具体哪个外部工具（如用于预订航班的 Lambda 函数或知识库查询）失败或超时。
  • 分析延迟来源：区分由 LLM 生成时间导致的延迟与下游 API 调用缓慢导致的延迟。
  • 带上下文调试：深入查看单个 span，查看具体错误信息、属性和元数据，以解释特定步骤失败的原因。

结论

随着组织从实验性 chatbots 转向生产环境中的复杂自主 agents，对强大可观测性的需求比以往任何时候都更迫切。Agentic 应用引入了新的复杂层次 —— 非确定性行为、多步推理循环和成本影响 —— 标准监控工具无法检测到。

Elastic 对 Amazon Bedrock AgentCore 的 Agentic AI Observability 弥补了这一差距。通过将 AgentCore 的平台级健康指标与 OpenTelemetry 提供的深层事务级分布式追踪统一，Elastic 为 SRE 和开发人员提供了完整的视图。无论你是在调试失败的工具调用、优化延迟，还是控制 token 成本，都拥有运行 agentic AI 所需的可见性。

完整可见性：AgentCore + Amazon Bedrock
为了获得最全面的视图，我们建议将 Elastic 的 Amazon Bedrock 集成与 AgentCore 一起启用。AgentCore 集成关注编排层——监控 agent 错误、工具延迟和调用，而 Bedrock 集成则提供对底层 foundation model 的深入可见性，包括跟踪模型特定的延迟、token 使用、完整 prompts 和 responses，甚至 Guardrails 的使用和效果。结合两者，可确保从高级 agent 工作流到原始模型推理的完整覆盖。

立即开始

准备好查看你的 agents 运行情况了吗？

原文：https://www.elastic.co/observability-labs/blog/llm-agentic-ai-observability-amazon-bedrock-agentcore

博客
Elastic 线下 Meetup 将于 2026 年 1 月 10 号下午在北京举行
11-24 1938
2026年ElasticMeetup北京站将于1月10日在腾讯北京总部举办。活动邀请Elastic、腾讯及新智锦绣专家分享前沿技术，包括Elasticsearch向量搜索与AI应用、MCP超级大脑在智能运维中的实践、腾讯云ES的AI能力建设，以及搜索范式从排序到过滤的转变等主题。现场提供茶歇交流机会，并有抽奖环节。报名需实名登记，成功报名后需联系工作人员获取访客码。活动详情及报名链接：https://elastic.huodongxing.com/event/5835577361800
博客
Elastic：如何成为一名 Elastic 认证工程师，Elastic 认证分析师及 Elastic 认证可观测性工程师
10-28 2万+
Elasticsearch 无疑是是目前世界上最为流行的大数据搜索引擎。根据 DB - Engines 的统计，Elasticsearch 雄踞排行榜第一名，并且市场还在不断地扩大：能够成为一名 Elastic 认证工程师也是很多开发者的梦想。这个代表了 Elastic 的最高认证，在业界也得到了很高的认知度。得到认证的工程师，必须除了具有丰富的 Elastic Stack 知识，而且必须有丰富的操作及有效的解决问题的能力。拥有这个认证证书，也代表了个人及公司的荣誉。针对个人的好处是，你可以..
博客
Elastic：开发者上手指南
02-25 16万+
你们好，我是Elastic的刘晓国。如果大家想开始学习Elastic的话，那么这里将是你理想的学习园地。在我的博客几乎涵盖了你想学习的许多方面。在这里，我来讲述一下作为一个菜鸟该如何阅读我的这些博客文章。我们可以按照如下的步骤来学习：1)Elasticsearch简介：对Elasticsearch做了一个简单的介绍2)Elasticsearch中的一些重要概念:cluster,n..........................................................
博客
Elastic：培训视频 - ​在生产环境中配置 Fleet Server 和 Elastic Agent 之间的安全
01-06 1万+
在这篇文章中，我将会把我写的有些内容录制成视频，供大家参考。希望对大家有所帮助。优酷的视频频道地址在这里。Elastic 简介及Elastic Stack 安装：优酷，腾讯 Elastic Stack docker 部署：优酷，腾讯 Elasticsearch中的一些重要概念（Cluster/Shards/Replica/Document/Type/Index）：优酷，腾讯 开始使用El...............
博客
Elasticsearch 简介
08-08 17万+
Elasticsearch是一个非常强大的搜索引擎。它目前被广泛地使用于各个IT公司。Elasticsearch是由Elastic公司创建并开源维护的。它的开源代码位于https://github.com/elastic/elasticsearch。同时，Elastic公司也拥有Logstash及Kibana开源项目。这个三个开源项目组合在一起，就形成了 ELK软件栈。他们三个共同形成了一个强大的...
博客
在 Google MCP Toolbox for Databases 中引入 Elasticsearch 支持
12-13 798
本文介绍了Google MCP Toolbox新增的Elasticsearch支持功能，演示了如何通过ES|QL工具安全地将Elasticsearch索引与MCP客户端集成。文章详细说明了安装Elasticsearch实例和示例数据集的方法，并展示了如何配置MCP Toolbox连接到Elasticsearch进行自然语言查询。通过Gemini CLI等MCP客户端工具，用户可以轻松查询电商订单数据。该集成提供了轻量级工具定义和安全基础设施，为构建数据感知型AI应用提供了新可能。
博客
Streams 处理：告别 Grok 的困扰 - 在 Streams 中解析你的日志
12-12 952
Elastic 9.2推出的Streams功能革新了日志解析体验，将复杂的数据处理转变为直观的UI操作。该功能支持AI自动生成Grok规则、实时模拟测试、条件处理等，能快速解决非结构化日志问题。用户无需离开Kibana即可完成解析规则的创建、测试和部署，特别适合处理混合数据流和遗留系统日志。Streams基于Elasticsearch ingest pipeline构建，既支持ECS也兼容OTel模式，是日志处理的"全能解决方案"。
博客
从数据到部署：推进美国州政府中 AI agent 的负责任使用
12-12 670
美国州政府正积极运用AI技术提升公共服务效率，AIagent成为继聊天机器人后的新焦点。弗吉尼亚州率先推出监管分析AI工具，展示创新应用前景。成功部署AI需三大支柱：高质量数据基础（目前仅23%州有数据治理计划）、系统互操作性和安全保障。工具如Elastic Agent Builder能帮助机构安全协作、自动化流程。专家建议通过公私合作模式，结合技术专业与政策监管，推动负责任AI发展。本文强调数据治理是AI应用的核心，良好数据实践将奠定可信AI基础，但提醒需注意第三方AI工具的数据安全风险。（149字）
博客
Elasticsearch：使用判断列表评估搜索查询相关性
12-12 697
本文介绍了如何使用判断列表(Judgment Lists)来系统评估Elasticsearch搜索查询的相关性。判断列表包含固定查询及其对应相关结果，通过计算recall等指标客观衡量搜索性能改进。文章详细说明了构建判断列表的三种方法（显式、隐式和AI生成判断）及适用场景，并以电影评分应用为例，演示如何通过Ranking Evaluation API计算指标。最后提出建议：从小规模关键查询开始，结合A/B测试验证，定期更新列表，并将其集成到开发流程中，从而实现从技术指标到业务价值的闭环评估。
博客
2026 年的可观测性趋势：成熟度、成本控制与推动业务价值
12-11 593
​过去几年，可观测性领域经历了根本性变革。在最近由 Dimensional Research 进行、Elastic 赞助的报告《2026 年的可观测性格局：平衡成本与创新》中，对 500 多名 IT 决策者进行了调查。结果显示，可观测性已经从可选能力明确转变为关键的业务职能。这一转变在帮助组织优化投资和将可观测性效益延伸到传统 IT 运维之外的同时，也带来了机遇与挑战。以下是未来一年的趋势预测。
博客
Elastic 推出按需免费培训
12-11 1133
摘要：Elastic宣布将付费培训改为免费开放，推出按需学习模块，包含短视频、动手练习等灵活形式。新培训涵盖ES|QL安全查询、AI助手等主题，并推出免费认证考试（含GenAI认证）。未来将扩展更多模块，优化学习路径。用户可通过Elastic Training官网立即开始学习。注意：功能发布时间以Elastic官方为准。
博客
如何通过个性化、分群感知排序来提升电商搜索相关性
12-11 1204
本文介绍了在Elasticsearch中实现电商个性化搜索的方法。通过为商品添加分群标签（如"luxury"、"budget"），并结合用户画像，使用乘法提升策略来优化搜索结果排序。这种方法避免了加法式提升的不稳定性，确保相关性高的商品始终优先，同时根据用户偏好给予适度提升。文章详细展示了如何通过function_score查询实现这一策略，包括索引设计、查询构建和权重调整。该方法简单易行，无需机器学习模型，就能实现可预测、可解释的个性化搜索体验。
博客
快速找到答案，将 OpenTelemetry traces 与 Elastic Observability 中现有的 ECS 日志关联起来
12-10 753
摘要：本文介绍了如何通过Elastic Observability将OpenTelemetry traces与ECS日志关联，实现现代可观测性与传统ECS系统的兼容。使用Elastic Distribution of OpenTelemetry(EDOT)的Java SDK注入trace.id和span.id到ECS日志中，并通过EDOT Collector采集处理，确保数据在Kibana中的关联性。文章演示了从混合架构到纯OTel的过渡方案，既保留现有ECS投资，又支持向OTel原生标准的平滑迁移。
博客
AutoOps 实际应用：调查 ECK 上的 Elasticsearch 集群性能
12-10 914
Elastic的InfoSec团队在多集群ECK环境中部署AutoOps，显著提升了运维效率。通过实时问题检测和可视化分析，将集群性能调查时间从30分钟缩短至5分钟。团队采用Helm chart实现基础设施即代码管理，利用Cloud Connect功能简化安装流程。实际案例显示，AutoOps能快速定位写入拒绝问题，提供分片热点可视化，并通过集群重路由即时解决问题。该方案为云和本地部署提供统一运维体验，大幅降低了Elasticsearch的运维复杂度。
博客
Jina-VLM：小型多语言视觉语言模型
12-09 1139
Jina-VLM是一款2.4B参数的视觉语言模型，在多语言视觉问答(VQA)任务中达到SOTA水平。该模型创新性地采用attention-pooling连接器，将视觉tokens减少4倍，同时保持性能，使其可在消费级硬件运行。通过两阶段训练流程，模型在29种语言中表现出色，并避免了纯文本能力的灾难性遗忘。目前支持通过API、CLI和Transformers库使用，但存在tiling开销和多图像推理的局限性。
博客
为什么统一的数据、搜索和互操作性对国防任务至关重要
12-09 869
摘要：本文探讨了在多域作战中实现数据敏捷性与主权控制的方法。通过采用开放标准、数据网格架构和AI技术，国防组织可以在保持数据主权的同时实现跨领域安全访问。Elasticsearch平台提供了跨集群搜索、向量搜索等功能，帮助快速分析大规模数据，缩短决策时间。开放标准确保了系统互操作性，支持不同保密级别的数据关联。AI驱动的检索生成技术可在低带宽环境中提供准确情报。这些技术与国防数据战略相契合，为未来作战提供了灵活、可扩展的数据解决方案。
博客
Elasticsearch：过多的副本数量会如何降低性能，以及该如何解决它
12-09 943
摘要：Elasticsearch中合理设置副本数量对集群稳定性至关重要。虽然副本能提高可用性和搜索扩展性，但过多副本会导致写入放大、内存压力、缓存抖动等问题，影响性能。文章分析了高副本数量的适用场景与负面影响，提供了诊断症状和优化建议，强调应根据实际需求而非猜测设置副本数量。通过真实案例说明合理减少副本可显著改善集群稳定性，并澄清了关于副本减少导致节点过载的常见误解。
博客
Elasticsearch：数据脱节如何破坏现代调查
12-07 678
当每分钟都很重要时，调查人员不应该花上数小时去寻找系统已经知道的内容。执法调查越来越受到碎片化数据系统、叙述性证据和无法跟上现代信息量的人工关联流程的阻碍。关键背景分散在不相连的系统和格式中，包括：记录管理系统（ RMS ）计算机辅助调度（ CAD ）平台数字证据存储库车牌识别（ LPR ）数据访谈开源情报调查数据通常包括大量非结构化数据，例如手写现场笔记、音频记录、监控视频等。
博客
使用 LangGraph.js 和 Elasticsearch 构建一个金融 AI 搜索工作流
12-06 1005
本文介绍了如何使用LangGraph.js和Elasticsearch构建AI驱动的金融搜索工作流。该系统能将自然语言查询转换为动态条件过滤器，用于投资和市场分析。文章详细阐述了工作流程设计，包括五个核心节点：策略决策、参数准备（投资导向/市场导向）、搜索执行和结果可视化。通过条件分支和混合检索技术，系统能自动选择最优搜索路径，提高查询准确性和效率。作者分享了实践中的关键发现，如过滤器取值展示的重要性、搜索模板的稳定性优势等，并展示了实际应用效果。该方案显著降低了复杂查询构建难度，为金融分析提供了更智能的搜
博客
用变量控件提升 Kibana 仪表板的互动性
12-05 984
Kibana 8.18+版本引入了变量控件功能，为用户提供更灵活的仪表板交互体验。这些控件可直接嵌入ES|QL查询中，允许对单个可视化进行筛选、调整时间间隔或更改分组字段，而不会影响其他面板。用户可以通过查询编辑器快速创建控件，支持多值选择、函数切换等操作。该功能不仅适用于仪表板，也能在Discover中使用。变量控件采用服务器端验证确保安全性，未来还将增加更多功能如链式操作、新控件类型等。这一增强功能显著提升了数据分析和监控效率。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值