日志处理中的设计问题
我们很少谈项目究竟是如何开始的。
如何设计尚未完全存在的功能？
如何将 AI 能力、系统限制、真实用户痛点整合成一个连贯的体验？
Streams 就给了我们这样的挑战。
日志是 observability 中最丰富的信号之一------但也是最混乱的之一。Streams 是一个 agentic AI 驱动的解决方案，重新思考团队如何处理日志，以支持快速的 incident 调查和解决。
Streams 使用 AI 对原始日志进行分区和解析，提取相关字段，减少 schema 管理开销，并突出关键事件，如 critical errors 和 anomalies。
这让日志从一开始就可以直接用于调查，而无需 Site Reliability Engineer 与数据斗争。但为了实现这种体验，我们必须仔细重新思考流程中的核心概念和步骤 ------ Processing。
Elastic Streams 中的 Processing UX 设计
日志强大，但前提是它们结构正确。今天，用户通过 Elastic Agent 上线日志，使用自定义 integration，提取像 IP 字段这样简单的信息需要：
- 编写 GROK patterns
- 创建 pipelines
- 管理 mappings
- 测试 transformation
- 反复迭代
听起来简单的步骤实际上需要 20+ 个步骤 ------ 而且大多数团队不应该需要如此深厚的专业知识。我们的目标很简单：让这一过程大幅简化。
我们早期的设计问题是：
"我们能否将这个体验从 20 个技术步骤缩减到 2 个有意义的步骤？"
这个问题塑造了我们对 Streams UX 的设计方法。
基础
在我们开始设计 Kibana 中的 UI 之前，我们先定义了一个核心心理模型。
一个 Stream 是一组存储在一起的 documents，它们共享：
- Retention
- Configuration
- Mappings
- Processing rules
- Lifecycle behaviour
关键设计原则：
"一个 Stream 应该包含行为一致的数据。"
为什么数据一致性重要？
我们从一个示例开始来测试我们的想法。以 Nginx 的 access 和 error logs 为例。
Access logs 描述请求/响应事件：
192.168.1.10 - - [16/Feb/2026:12:32:10 +0000] "GET /api/orders/123 HTTP/1.1" 200 532 "-" "Mozilla/5.0"Error logs 描述诊断事件：
2026/02/16 12:32:10 [error] 2719#2719: *342 connect() failed (111: Connection refused) while connecting to upstream…
如果两者都存在于同一个 Streams 中，可能导致：
- Processing logic 冲突
- Field divergence
- Mapping 冲突
- 调查工作将变得更困难
这个洞察明确了一点关键：
"Processing 不仅仅是提取字段。它是为了保护一致性。"
让复杂性可管理
Ingest 生态系统并不小、简单或假设性。真实的 pipelines 使用数十种 processors ------ 从常见的 rename、set、convert 和 append，到小众类型如 urldecode 和 network_direction。
UI 必须同时支持高频操作和长尾边缘案例，同时保持结构完整。目前 Elasticsearch 支持40 多种不同的 ingest processors。我们必须确保界面能够处理这些不同类型。
我们引入了清晰的、嵌套的 pipeline 步骤结构。用户可以自信地创建、重新排序、编辑或删除单个步骤或分组步骤。嵌套的拖放功能也作为模式被加入到我们的 EUI 库中。
这为我们提供了上下文和基础，使我们能够将这些概念整合到一个对 Streams 中所有内容都具有决定性的模型中。
页面原型
Processing 功能强大 ------ 但也有风险。更改解析条件或步骤可能影响：
- Field 可用性
- Search 行为
- Alerts
- AI Insights
- 调查工作
因此我们问自己：如何让这样强大且重要的功能对用户安全？答案引出了一个核心页面原型：
Create > Preview > Confirm
这不是后期添加的 UI 模式。它直接源自我们的概念设计工作，以及对用户需要处理内容的理解。
为了支持这个原型和核心理念，我们还引入了分屏结构。
左侧：Build
这里用户可以：
- 添加 processing 步骤
- 定义条件
- 应用规则
- 利用 AI 建议，无论是整个 pipeline 创建，还是单个步骤如 GROK processor
界面保持专注、有意图且结构化。
右侧：Preview
这里用户可以：
- 查看真实日志样本
- 查看上下文中的提取字段
- 对更改立即反馈，包括文档匹配和未匹配比例的洞察
- 可选的右侧 drilldown 面板
Preview 面板成为了信心的锚点。这不仅仅是为了视觉上的对称，而是为了强化实验、控制错误并减少失误。考虑到用户可能希望在交互与详细 preview 之间切换焦点，我们为两个面板引入了可调整大小功能，从而解锁了更多的灵活性和对使用场景的控制。
AI 自动化
Streams 是智能 agent 驱动的 AI 解决方案。这为设计增加了复杂性，但也提供了从用户日志数据中解锁更多能力和洞察的机会。
AI 引入了新的矛盾：如何加速处理，同时不让它变成一个黑箱？
我们建立了几个 guardrails：
- 清晰、简明的建议
- 通过匹配文档指标可见的影响
- 可检视性
- 与 Create → Preview → Confirm 模型保持一致
Processing UX 成为 automation 与 human in the loop 之间的桥梁。日志数据是最强大的调查信号之一。每一个设计决策都强化了这一信念。
我们学到的
为未来设计并不是从屏幕开始。它从以下内容开始：
- 边缘案例测试
- 清晰的 mental models
- 强有力的指导原则
- 行为一致性
- 可扩展且经过压力测试的 archetypes
我们知道，为了让用户能够从日志中发现有价值的洞察，他们需要有效地处理和管理数据。我们清楚自己在塑造他们整个 observability 基础。
Processing 关乎 trust、control 和可扩展的数据管理。
- Trust 促进调查速度。
- 调查速度促进韧性。