当您看到您的组织为进入或扩展云原生领域所做的努力时,您是否对围绕云原生可观察性的大量信息感到有点畏惧?当您在 DevOps、SRE 和平台工程团队中快速推进敏捷实践时,难怪这看起来有点令人困惑。不幸的是,所做的选择会对您的业务、预算以及云原生计划的最终成功产生巨大影响,而提前做出的仓促决策会很快导致令人头疼的问题。

在之前的介绍中,我们研究了每个人面临的问题云原生可观察性。这是本系列的第一篇文章。在本文中,您将找到第一个陷阱讨论,这是组织所犯的另一个常见错误。通过分享本系列中的常见陷阱,希望我们能够从中学习。

在上一篇文章中奠定基础之后,是时候解决第一个陷阱了,我们需要研究如何控制成本以及我们在云原生可观察性方面遇到的损坏的成本模型。

O11y 成本被打破

去年最大的话题之一是云原生可观测性的成本模型是如何被打破的。我之前写过为什么云原生可观察性需要阶段,详细说明了第二个阶段如何可观测性工具的一代受到了这种损坏模型的影响。

<块引用>
“第二代由应用程序性能监控(APM)以及使用虚拟机和后来的云平台的基础设施组成。这些第二代监控工具已经无法跟上云原生架构的数据量和大规模…… ”

结可观测性指标数据的成本吗?

它们存储我们所有的云原生可观测性数据并为此收费,随着我们的业务取得成功,扩展数据量意味着昂贵的可观测性工具、降低的可视化性能以及缓慢的数据查询(规则、警报、仪表板等)。 )。

如果组织能够获得更好的结果、更满意的客户、更高水平的可用性、更快的问题修复以及最重要的是更多的收入,他们就不会关心存储了多少数据或成本是多少。不幸的是,正如 所指出的新堆栈

<块引用>

“值得注意的是,这种情况非常普遍,组织为其可观测数据支付的费用比为其生产基础设施支付的费用还要多。”

问题很快就围绕问题的答案得到了解决,我们需要存储所有可观测性数据吗?快速而肮脏的答案当然是, 不是!几乎没有任何工具供应商愿意深入了解我们正在获取的数据,了解哪些数据正在实际使用,哪些没有使用。

事实证明,当您仔细查看传入的数据并能够在摄取时过滤所有数据,以找出任何用户未触及、未临时查询、不属于任何仪表板的数据,不属于任何规则,也不用于任何警报。事实证明,这对数据成本产生了很大的影响。

专为服务状态概览而设计的仪表板,最初在摄取超过 280K 数据点时

在上面的示例中,我们设计了一个用于服务状态概览的仪表板,最初是在获取超过 28 万个数据点时进行的。通过检查并澄清其中许多数据点未在组织中使用,相同的摄取流减少到仅存储 390 个单个数据点。这里的成本降低取决于您的供应商定价,但从这里显示的效果来看,它显然将成为一个巨大的成本控制工具。

重要的是要了解我们需要摄取我们可以收集的内容,但我们实际上只想存储我们实际要用于查询、规则、警报和可视化的内容。下面是一个架构视图,展示了如何通过在数据摄取和数据存储之间拥有控制平面功能和工具来帮助我们。如果未来的项目需要,我们未存储的任何数据都可以稍后传递到存储。

通过在数据摄取和数据存储之间拥有控制平面功能和工具来帮助我们的架构视图

最后,如果组织中没有成本控制流程的标准和所有权,控制成本的希望就很小。为此,FinOps 的角色对于许多组织来说变得至关重要,整个领域于 2019 年成立了一个名为 FinOps 基金会的社区。云原生可观测性供应商加入这些向前发展的努力非常重要,这应该成为评估新工具时的一个关注点。如今,90% 的财富 50 强企业都拥有 FinOps 团队。

通向云原生成功之路有很多陷阱,了解如何避免支柱并专注于可观察性阶段的解决方案将节省大量浪费的时间和精力。

接下来

另一个陷阱是组织在其可观测性解决方案中关注支柱。在本系列的下一篇文章中,我将分享为什么这是一个陷阱,以及我们如何避免它对我们的云原生可观测性工作造成严重破坏。

Comments are closed.