作者来自 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 平台的遥测数据都汇聚到同一个地方时运维人员可以在几秒内从“出现了问题”转变为 “发生了什么变化、影响了什么、以及我应该首先调查什么”。一旦数据进入 Elasticdashboard 就成为共享的运维层。团队无需分别在一个工具中查看认证事件、在另一个工具中查看应用健康、再在第三个工具中查看可用性检测而是可以在统一的 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 监控 ElasticElastic 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