Elastic 在 Elastic 上：我们如何监控我们自己的服务、网站和运营

作者：来自 Elastic Soham BanerjeeBrad Timmerman

摘要：客户零号 证明了统一的可观测性模型 —— ingest → detect → investigate → automate response —— 在单一平台上实现更快的端到端运维。

总结：

• 统一数据摄取：Elastic Agent、OpenTelemetry、agentless → Kibana
• 主动监控：Synthetics、TLS 检查、Stack Monitoring
• 更快响应：Elastic AI Assistant、Elastic Workflows、Connectors（例如 Slack、PagerDuty、ServiceNow）
• 客户零号：Elastic 在 Elastic Observability 上运行

Customer Zero（客户零号）

在 Elastic，我们验证可观测性能力的最佳方式之一，就是将其应用在我们自己身上。这正是 Elastic on Elastic 的理念：使用 Elastic 自身的平台来收集遥测数据、监控服务健康、及早发现问题、加速排查，并在我们的内部和外部系统中实现自动化响应。

Elastic 长期以来一直将这一理念作为 “Customer Zero（客户零号）” 思维的一部分。我们不仅验证产品能力，还能发现对客户真正重要的实际运维流程、痛点和最佳实践。这种方法推动了创新，并确保我们的平台能够在关键任务环境中实现大规模运行。

在这篇博客中，我们分享了如何使用 Elastic Observability、synthetics、connectors、Elastic AI Assistant、Elastic Workflows 和 Stack Monitoring 来构建一个统一的运维模型，覆盖数据摄取、可视化、告警、问题排查和自动化。最终形成的是一个互联的可观测性操作系统——在这里，遥测数据从各个来源无缝流动，在仪表板中完成关联，通过 AI 呈现上下文，并触发智能化操作。

构建可观测性基础

我们的环境整合了来自广泛运维和业务关键来源的数据。我们通过 agentless 集成和 Elastic Agent 同时摄取 SaaS 和平台信号，从各类服务中获取事件，例如身份平台（Okta）、开发者系统（GitHub audit logs）、AI 指标（Copilot metrics）以及其他运维工具。

该模型的一个关键点是数据采集的灵活性。一些数据源最适合通过 agentless 集成接入 —— 它们配置简单且没有运维开销。另一些则更适合使用 Elastic Agent，它为我们提供了一种统一方式，从主机、服务以及 Elastic 产品本身采集日志、指标和事件。这种双模式方法使我们能够在可能的情况下减少运维摩擦，同时对需要基于 agent 采集的基础设施和服务保持一致性。

我们还对内部服务的应用遥测数据进行了集中管理。例如，我们将来自 ElasticGPT（我们的内部生成式 AI 服务）的 OpenTelemetry 数据直接发送到 Elastic。这意味着应用日志、分布式追踪以及运行时信号都与其他运维数据一起集中在同一个平台中。团队无需在多个工具之间切换，就可以在单一环境中完成端到端的问题分析。

统一数据摄取为何重要：当来自身份系统、应用程序、基础设施以及 SaaS 平台的遥测数据都汇聚到同一个地方时，运维人员可以在几秒内从“出现了问题”转变为 “发生了什么变化、影响了什么、以及我应该首先调查什么”。

一旦数据进入 Elastic，dashboard 就成为共享的运维层。团队无需分别在一个工具中查看认证事件、在另一个工具中查看应用健康、再在第三个工具中查看可用性检测，而是可以在统一的 workflow 中关联所有信息。当底层数据已经打通时，响应人员可以更快地从服务异常定位到相关的身份变更、审计活动、synthetic 故障以及应用行为等支撑性遥测数据。这种统一体验正是 Elastic Observability 的核心优势之一。

监控数字化体验

在 Elastic on Elastic 实践中，一个最直观的部分是对我们自身网站的监控。我们使用 synthetic monitoring 来跟踪 Elastic 网站及其子域名的可用性，包括 elastic.co、buy.elastic.co、learn.elastic.co 等关键业务入口。

Elastic synthetics 同时支持轻量级监控和基于浏览器的监控，这些监控可以直接在 UI 中管理，也可以通过 synthetics projects 在外部管理。这使我们既能监控简单的 uptime（例如快速的 HTTP 检查），也能模拟用户真实访问路径，从而观察客户如何与我们的网站交互。

将证书健康作为一等运维关注点

仅有可用性还不够。我们还使用与 synthetics 相关的能力来监控 TLS 和证书健康。Elastic 支持 TLS 证书规则，当被监控的证书接近过期或超过配置的使用期限时，会通知相关团队。

这看似是一个小细节，但实际上非常关键。证书过期是可预测的，但每年仍会在整个行业中引发意外故障。通过将证书健康视为一等运维信号（与 uptime 和 endpoint 可用性并列），我们确保它能够被监控、告警并及时处理，而不是作为一个隐藏在某人任务列表中的手动流程。

同一个平台既可以检测服务故障，也可以预防凭证失效。这正是统一可观测性的力量。

从检测到行动

当可观测性能够直接连接到行动时，其价值会大大提升。Elastic 在 Kibana 中提供了一个 connector 框架，用于集中集成下游工具，例如 Slack、PagerDuty、ServiceNow 等。我们使用这些 connectors 来推送通知、触发事件，并将问题路由到响应人员已经在使用的系统中。

我们并不将 dashboard 视为可观测性的终点，而是将其作为运维 workflow 的起点。当 Elastic 中触发一个告警时，在同一时刻：

• 通知会发送到值班团队的 Slack 频道
• 在 PagerDuty 中自动创建包含完整上下文的事件
• ServiceNow 会收到通知以创建 ITSM 工单用于跟踪
• 相关响应人员会根据升级策略被自动通知

这减少了在多个工具之间手动复制数据的低效操作，并使调查、沟通和修复过程保持一致。Elastic 的 connector 和告警模型正是为这种集成化响应路径而设计的。

结果是更快的事件响应。响应人员无需再去查找告警细节；上下文会随着通知一同到达。而且由于一切都源自 Elastic，数据的唯一事实来源始终保持在同一个平台上。

AI 辅助调查

对于我们的事件管理团队来说，Elastic AI Assistant 增加了另一层运维效率。响应人员无需在多个界面之间来回切换（例如查看 dashboard、检查日志和分析 trace），只需在 Elastic 中提问即可获取相关信息。

考虑一个没有 AI assistant 的典型事件处理流程：

• 告警触发：“Service latency 超过阈值”
• 响应人员进入服务 dashboard 查看现象
• 响应人员检查基础设施指标以判断资源是否受限
• 响应人员搜索日志中的错误或警告
• 响应人员查看分布式 trace 以理解代码路径
• 响应人员关联信息并形成假设
• 响应人员开始排查根因

而使用 Elastic AI Assistant 时：

• 告警触发：“Service latency 超过阈值”
• 响应人员打开 Elastic 并提问：“过去一小时 checkout service 发生了什么？有什么变化？”
• Elastic AI Assistant 返回：“在 14:23 UTC 延迟增加了 40%。数据库查询次数翻倍。14:20 有一次新的部署上线。以下是相关错误。”
• 响应人员在已有上下文的基础上直接开始有针对性的调查

这在快速变化的事件中尤为重要。当团队处于压力之下时，能够请求相关信号、总结活动或快速获取上下文，可以将从检测到理解的时间缩短数分钟。AI assistant 并不是替代专家分析，而是减少收集分散信息所需的时间，让团队能够专注于决策和响应。

自动化响应路径

我们也在 Elastic 内部使用 Elastic Workflows 来自动化运维任务。Elastic 将 workflows 描述为可复用、可版本化的一组 “步骤”，用于将输入转换为具体行动。

对于运维或事件管理团队来说，这为标准化重复性任务提供了可能性：

• 丰富告警信息：当告警触发时，自动查询相关服务、依赖关系以及最近变更
• 收集上下文：自动查询相关的 logs、metrics 和 traces，并将其附加到事件中
• 智能路由：根据服务归属、升级策略或值班安排，将事件分配到正确团队
• 触发后续动作：创建 ITSM 工单、发送到沟通渠道，或触发修复脚本
• 标准化响应：确保每个事件都遵循一致的分诊与调查流程

这是 Elastic on Elastic 中非常重要的一部分，因为可观测性的成熟度不仅仅是收集更多 telemetry，而是让这些 telemetry 在运维上真正可用。Workflows 将团队原本需要手动执行的步骤进行编码，使平台不仅支持检测与调查，也支持可重复、一致的响应流程。

随着时间推移，设计良好的 workflows 能降低平均恢复时间（MTTR）和平均发现时间（MTTD），因为团队无需频繁切换上下文或手动收集数据 —— 这些工作都由平台自动完成。

使用 Elastic 监控 Elastic

Elastic on Elastic 当然也包括使用 Elastic 来监控 Elastic 自身平台。我们依赖 Stack Monitoring 功能，将其他 Elastic deployment 的健康状态反馈回平台。

Stack Monitoring 提供了专门的仪表板，帮助团队理解 Elastic 服务的健康状况与性能：

• Elasticsearch 集群健康：节点状态、分片分配、索引与搜索性能
• Kibana 性能：响应时间、请求量、错误率
• Logstash pipeline 健康：吞吐量、延迟、处理时间
• Agent 连接情况：连接状态、掉线情况、版本分布

这在逻辑上形成了闭环。我们不仅使用 Elastic 观察网站、SaaS 平台和内部应用，也在使用 Elastic 观察可观测性本身。这强化了 customer zero 模型：用于检测其他系统问题的平台，同时也用于保障支撑这些洞察的平台本身的可靠性。

为什么这种模型有效？

这种方法之所以强大，并不是因为某一个单独功能，而是因为整个生命周期是连续贯通的：

• 从各种来源摄取数据（例如 agentless、基于 agent、OpenTelemetry、API）
• 在同一平台中通过统一 dashboards 关联这些 telemetry
• 使用 synthetics 验证面向用户的可用性
• 主动监控证书健康状态
• 通过规则检测异常和阈值告警
• 通过集成 connectors 通知响应人员
• 借助 AI Assistant 加速问题排查
• 通过 Workflows 自动化重复性任务
• 使用 Stack Monitoring 监控 Elastic stack 本身

Elastic Observability 被明确设计为支持从检测、理解到响应的统一生命周期。这就是 Elastic on Elastic 在实践中的含义：不仅仅把 Elastic 当作日志工具或 dashboard 层，而是在其之上运行一个连接性的运维模型。

当 telemetry、上下文、告警、调查和自动化都存在于同一个生态系统中时，团队可以更快行动并且更有信心地运维。你不会在不同工具之间丢失上下文，不需要重复做数据收集，也不会因为不同工具的数据保留策略或延迟差异而产生盲区。

你拥有一个唯一事实来源、一个提问的地方、一个执行动作的地方。这就是在大规模运维中推动卓越运营的模型。

对平台的信任

Elastic on Elastic 本质上是对平台的信任。我们用 Elastic 来监控我们的服务、网站、connectors、workflows、synthetic checks、应用 telemetry 以及 Elastic deployments，因为当平台成为运维的核心支柱而不是众多工具之一时，它才最强大。

它让我们能够在同一个环境中从数据收集直接走向行动。这正是让可观测性在规模化场景中真正有价值的原因。如果你想在自己的组织中尝试这种方法，可以很容易开始：

• 从 agentless integrations 开始接入 SaaS 平台（如 Okta、GitHub）
• 为基础设施和应用监控部署 Elastic Agent
• 将 OpenTelemetry 数据流入自定义应用
• 为关键端点配置 synthetics 进行外部监控
• 配置 connectors 将告警路由到现有工作流
• 启用 Elastic AI Assistant 加速排查
• 构建 Workflows 自动化事件响应
• 通过 Stack Monitoring 监控你的平台

原文：https://www.elastic.co/blog/how-we-monitor-at-elastic