跳到主要内容
博客计算为什么可观察性工具在大规模使用时往往会失败?

为什么可观察性工具在大规模使用时往往会失败?

为什么可观测工具在大规模使用时会失败?

可观察性不再仅仅是捕捉错误或检查服务器是否正常运行。在现代分布式系统中,它需要了解数十种甚至数千种服务的行为,这些服务都运行在不同的环境中,并产生大量数据。

这种复杂程度正是选择正确的可观测性工具如此重要的原因。错误的决定不仅会拖慢您的速度。它可能会耗尽你的预算,影响你的规模性能,并在你的产品起飞后将你锁定在一个不再适用的系统中。

任何一位优秀的架构师都会告诉你,要在产品中构建出色的可观察性,就必须具备易上手性、高性能(即使在大规模使用时)以及使其独立于应用程序本身的系统。以后再更换可观察性工具既痛苦又昂贵。最好从一开始就避免被供应商锁定,并选择能与您共同成长的工具。

第三阶段的扩展问题

但说起来容易做起来难。大多数团队直到为时已晚才会考虑长期的可观察性需求。根据我们从Akamai客户那里了解到的情况,真正的问题开始于公司发展的早期阶段,当时团队选择的工具现在感觉很简单,但到了后期就会变得昂贵而僵化。

第 1 阶段--开放源代码 

这时,你的重点是速度和低成本。您需要验证您的想法,并让它发挥作用。像 ELK Stack 这样的开源工具在这方面大放异彩:灵活、便宜(至少在前期是这样),而且非常适合将 MVP 整合在一起。

第 2 阶段 - 黑盒

现在,产品在不断成长,您需要保持系统的正常运行和稳定。可观察性变得至关重要,许多团队默认使用像 Snowflake 这样易于管理的黑盒子工具,它们既快速又易于使用。不幸的是,这些工具也非常昂贵,尤其是当使用量增加时。

第 3 阶段--可扩展

随着流量和数据量的增长,在第二阶段做出的工具决策开始适得其反。第 3 阶段是黑盒解决方案的可观测性费用变得过于昂贵的阶段。公司会陷入两种糟糕的选择。要么继续支付高昂的费用,继续使用方便的黑盒工具,要么用更便宜的工具取代它,但这需要时间,会带来风险,而且往往会延误核心产品工作。

我们认为,第三阶段的问题实际上源于第二阶段,即企业做出错误决定,转而采用黑盒解决方案。相反,如果有一种解决方案,企业可以从开源过渡到该解决方案,并在其产品的整个生命周期内持续使用,那又会怎样呢?

最佳可观测性解决方案

因此,真正的问题应该是,从长远来看,哪种解决方案能够为公司提供最佳服务?在Akamai,我们从许多客户那里了解到,他们遇到了第三阶段的问题,即在第二阶段过渡到黑盒子解决方案的后果。为此,我们与Hydrolix合作推出了一种介于这两种方案之间的解决方案:TrafficPeak。TrafficPeak 是一种云原生解决方案,具有自动扩展和集成流量观测功能。在保持简单易用的同时,TrafficPeak 还为微服务、CDN 或边缘网络等大流量环境设计,为用户提供了很大程度的控制权。TrafficPeak 具有开源的控制性和 SaaS 的简易性,但没有黑盒工具的成本冲击。

让我们深入了解 ELK 栈(开源)、Snowflake(黑盒)和 TrafficPeak(可扩展)在设置和基础设施复杂性、规模性能、成本管理、定制、安全性和维护方面的优势。 

正面交锋:ELK Stack vs. Snowflake vs. TrafficPeak

1.设置和基础设施的复杂性

ELK Stack 为团队提供了高度的控制能力,但也带来了极大的操作复杂性。构建一个完整的 ELK 管道(Elasticsearch、Logstash、Beats 或 Agents 以及 Kibana)需要周到的配置、依赖关系管理以及对每个组件如何相互配合的深入了解。第 3 阶段的扩展带来了更多挑战,例如管理分片、索引和跨节点的可用性。对于快速发展的企业来说,这些基础设施要求可能会成为瓶颈。

相比之下,Snowflake 是完全可管理的原生云。它抽象了基础架构,让团队专注于数据而不是服务器。不过,可观测性用例需要建立摄取管道,将日志和度量指标输入 Snowflake,通常是通过 Snowpipe、Kafka 或 ETL 框架。虽然初始设置看起来简单明了,但要在数据仓库模型中实现可观察性数据的可查询性和可操作性,工程设计工作会带来延迟和复杂性。它功能强大,但并不是为实时操作可视性而构建的。

TrafficPeak 在设计之初就考虑到了部署的简便性。作为一个云原生解决方案,它可无缝集成到 Kubernetes 环境中,并可作为 SaaS 或容器化平台进行部署。不需要复杂的队列系统或自定义摄取层。数据收集、处理和可视化内置于同一管道中。其设计可在数小时而非数周内启动并运行,因此没有专门运营或数据工程资源的团队也能使用。

2.大规模数据输入和性能

在 ELK 中,大规模的高吞吐量摄取需要谨慎的架构。通常需要引入 Kafka 或其他队列系统来处理突发事件,而且必须对摄取管道进行调整,以避免日志丢失或索引更新失败。如果分片和大小不正确,Elasticsearch 本身可能会成为大负载下的瓶颈。这些问题都可以解决,但需要时间、技能和持续的关注。

Snowflake 擅长扩展,这是其核心优势之一。它可以摄取和处理 PB 级的数据,而且存储和计算分离,可以灵活扩展。但是,数据摄取并不是一蹴而就的。在数据可供查询之前,可观察性管道通常涉及缓冲、批量加载或转换。这使得 Snowflake 不太适合实时警报或调试,因为在这种情况下,亚分钟级的延迟至关重要。

TrafficPeak 专为大流量实时环境而设计。它具有自动扩展摄取管道和内置缓冲与负载分流机制,可动态适应流量变化。无论您运行的是微服务舰队、全球 CDN,还是来自边缘设备的流数据,TrafficPeak 都能处理高吞吐量工作负载,并迅速获得洞察力。

3.成本管理

虽然 ELK 一开始具有成本效益,特别是对于试图避免 SaaS 账单的团队而言,但总体拥有成本会迅速膨胀。随着水平扩展,基础架构成本会上升,尤其是当日志、指标和跟踪都集中在 Elasticsearch 中时。维护、调整和事件响应会消耗宝贵的工程时间。一开始免费的堆栈往往会成为隐藏的成本中心。

Snowflake 带来了另一种成本挑战。虽然其按使用付费的模式允许对计算和存储进行精确控制,但可观测性数据是出了名的高容量和尖峰数据。查询成本会迅速上升,尤其是在数据长期保留或频繁查询的情况下。如果没有严格的管理和优化,成本可能会意外上升,尤其是当可观测性数据与分析工作负载混合在一起时。

TrafficPeak 从一开始就考虑到了成本效益。它的定价模式具有使用感知功能,旨在避免成本失控。数据压缩、分层保留和智能采样等功能有助于控制流量和支出,而自动扩展则确保您只需为实际使用的资源付费。TrafficPeak 让您在系统健康状况和系统成本出现问题之前就能一目了然。

4.定制化和可扩展性

ELK 的最大优势之一是其灵活性。您可以构建自定义管道、应用过滤器、定义模式,并为特定用例创建高度定制的仪表盘。这使其功能强大,但也很复杂。定制需要了解 Lucene 查询、管道语法和索引映射。对于需要精细控制的团队来说,它是无与伦比的。对于其他团队来说,这可能会成为维护的负担。

Snowflake 以模式为先,围绕 SQL 构建,这使得它对于希望将可观察性与业务数据结合起来的数据分析师和团队来说具有很强的可扩展性。不过,它不支持日志解析、跟踪缝合或警报。这限制了它在实时可观察性工作流中的使用。您通常需要在其上添加额外的工具,以获得仪表盘或操作视图。

TrafficPeak 采用 "恰到好处 "的定制方法。它配备了现成可用的仪表盘和工作流,还为希望根据自身环境定制洞察力的团队提供了 API、标签和过滤工具。它的设计旨在最大限度地缩短价值实现时间,同时在日志丰富、标记和数据关联等重要方面提供可扩展性。

5.安全与合规

ELK Stack 提供安全性,但不是交钥匙工程。基于角色的访问控制(RBAC)、TLS 和审计日志可通过插件或配置实现,但需要持续维护。对于受监管的行业而言,实现 ELK 部署的完全合规性需要勤奋和严谨。

Snowflake 开箱即提供企业级安全性,包括 RBAC、行级安全性、静态和传输中加密,并支持各种合规标准。它非常适合必须满足严格要求并希望由供应商管理这些功能的团队。

TrafficPeak 从一开始就内置了安全功能。RBAC、审计和数据驻留控制等功能是平台的原生功能,而非附加功能。无论您是在金融、医疗保健还是政府部门,TrafficPeak 都能让您轻松满足现代合规性要求,而无需拼凑不同的工具。

6.维护和支持

ELK 是完全自主管理的,除非您支付 Elastic Cloud 或第三方提供商的费用。这意味着您的团队需要负责扩展、打补丁、性能调整和故障排除。对于许多团队来说,如果没有深厚的基础架构专业知识,这种负担是难以承受的,尤其是随着环境的增长。

Snowflake 采用完全托管方式,完全消除了维护负担。它可以在幕后处理升级、打补丁和扩展。但是,由于可观察性支持并不是它的主要用途,因此支持票据可能会通过工作流程进行路由,而这些流程并没有针对调试实时系统进行优化。

TrafficPeak 提供由供应商管理的可观测性,具有实时支持和可选 SLA。该平台旨在最大限度地降低运营成本,同时提供与了解特定观测问题的工程师的联系。因此,该平台可帮助您进行运输和扩展,而无需时刻担心遥测堆栈。

那么,哪个最合适呢?

考虑到所有这些优缺点,对于处于成长第一阶段的公司来说,当灵活性和低成本非常重要时,我们同意开源解决方案的现状是最佳选择。对于处于第一阶段的公司、内部部署或混合环境,或者拥有丰富基础架构经验的团队来说,ELK Stack 是一个很好的选择。

但是,对于处于第二阶段的大多数公司来说,我们认为,与其立即默认使用像 Snowflake 这样的黑盒子解决方案来应对突如其来的复杂的日常可观测性任务,不如选择一种简单、可调整、同时可扩展的解决方案,这样会有更长久的生命力。 

我们正是针对这种情况建立了TrafficPeak,希望您能就我们是否成功解决了第 3 阶段问题提出反馈意见。 

要了解 TrafficPeak 的实际应用,请查看我们对海军联邦信用合作社的案例研究

注释

留下回复

您的电子邮件地址将不会被公布。 必须填写的字段被标记为*