最初由Nav公司高级工程总监Travis Jeppson在Medium上发表
在任何应用程序中，缺乏可观察性就像骑自行车时蒙上眼睛一样。唯一不可避免的结果就是崩溃，而崩溃总是伴随着代价。当我们获得可观察性时，这个代价往往是我们唯一关注的，但这不是唯一的代价。可观察性的另一个成本通常一开始不会被解决，直到它变得比崩溃的成本更令人痛苦，这是指维护成本和适应性成本。
我听过，也看过很多关于这个主题的会议；我也和供应商进行了公平的交流。一般没有提到维护和适应性。我只是在和其他公司谈论他们采用的平台时才会提到这些话题，他们是如何将可观察性融入现实运作的，以及我自己的经验。这些主题在实际应用之后出现的原因是我们都遇到了众所周知的瓶颈。
我们都遇到过问题，或者不兼容，或者供应商锁定，这些都让我们觉得几乎无法摆脱。我们的观察力开始下降，眼罩开始落在我们的眼睛上，我们再次走向一个不可避免的命运。我们能做些什么？重新审视整个场景？等待重大崩溃，并创建ROI语句来表明我们必须重新投资于应用程序的主要部分？这不可能是解决这个问题的唯一方法。这是我们构建软件的一种反模式（anti-pattern）。可观察性应该增强速度和敏捷性，而不是阻碍它。
还有另一种方法，首先确定你不会做出让步的关键因素。在上一个迭代中，我们围绕之前的尝试进行了很多讨论。第一次尝试的解决方案，我们最初认为有无限的集成；结果它没有我们需要的，Kubernetes。我们也不能从我们的应用程序中生成自定义的度量，所以这个解决方案必须取消。我们不会等着他们告诉我们整合已经准备好了，我们已经准备好行动了。我们决定采用一个端到端可定制的解决方案，我们可以花时间开发我们的遥测数据，以及如何解释它。不幸的是，这迫使我们陷入了维护噩梦。然而，在第三次迭代中，我们决定在中间的某个地方安顿下来。我们坐下来，确定了我们“不妥协”的优先事项，并开始寻找合适的解决方案。以下是我们如何看待Nav的优先级。
1. 定制！我们需要适应性，而不是等待集成
首先，也是最重要的是，解决方案需要允许自定义度量，并像一流公民一样处理它们。对于我们的基础设施指标，以及来自我们的应用程序的任何东西来说，这都是必须的。适应性是我们决策的关键：如果我们选择的解决方案是适应性的，那么我们应该可以自由地调整基础设施的任何组件，而不必检查我们的可观察性是否会受到影响。
2. 我们的应用程序中没有特定于供应商的代码，甚至库中也没有
乍一看，这似乎有点苛刻，但事实是我们不想依赖于供应商。我们在Nav使用多种语言 — Ruby、Elixir、Go、Python、Javascript、Java等等。几乎不可能找到一个可以使用所有这些语言的供应商解决方案。我们决定语言必须是无关的（agnostic），这意味着我们的应用程序中不能有任何供应商代码或库。另一方面，我们不希望被锁定在解决方案上，因为我们以前遇到过这个问题。
3. 帮助！维护不可能是压倒性的
这意味着在某种程度上，我们可能需要一个供应商来帮助我们。我们不想让可观察性平台的正常运行时间成为我们关注的焦点，我们想要关注的是应用程序的正常运行时间。我们也不想担心可观察性平台的基础设施，我们想要担心我们自己的。明白我的意思吗？我们还需要一些关于注意事项的指导。我们想要一种构建仪表板的简单方法，并且能够允许几乎每个工程师围绕自己的度量构建自己的仪表板。
接下来是我们的第二优先级
现在我们进入“喜欢拥有”优先级。以下是更多的愿望清单，前三点是我们提出的解决方案的关键要求。幸运的是，正如稍后将说明的，我们不需要在任何优先事项上妥协。
4. 警报需要易于实现，并与我们的随叫随到解决方案集成
使用我们的端到端自定义解决方案（在可观察性方面尝试#2），警报是非常繁琐的。这是一个JSON文档，它有很多定义部分，我们从来没有真正设置过任何良好的警报。由于大量的误报，我们也造成了大量的随叫随到的疲劳。我们不想重复这个。
5. 我们不想为非生产环境付出与生产环境相同的代价
仅仅因为环境的大小是一样的，就要求任何人为可观察性付出同样的代价，这是我最大的不满。为什么会这样呢？实际上，如果开发环境宕机5分钟，我并不太在意；但我绝对关心生产是否宕机5分钟。
最后的决定：Nav的三产品解决方案
有了这些优先级，我们开始创建一个有效的解决方案。长话短说，最终并没有完美的解决方案，也没有一个方案能满足我们自己前三项优先要求。事实证明，我们需要多个部件无缝地工作在一起。
Prometheus
Prometheus是一个开源的度量聚合服务。Prometheus的神奇之处在于，它是围绕着一个标准建造的，他们也创造了这个标准。这个标准称为暴露格式。你可以提供一个基于文本的端点，Prometheus将经过，并“刮掉”（scrape）该端点的数据，并将其提供给一个时间序列数据库。这简直太棒了！我们的开发者能够在他们自己的代码库中编写这个端点，并发布任何他们想要的定制度量。
StatsD
StatsD最初是Etsy编写的一个解决方案，它为我们提供了一种方法，可以在软件上推送与web服务器无关的指标，比如短期任务或事件驱动计算。
在StatsD和Prometheus之间，我们几乎可以在任何地方发布定制的度量标准。另一件伟大的事情是，由于这两个解决方案都是开源的，已经有一个蓬勃发展的社区为这两个库构建了辅助组件。
对我们来说，最后一块拼图是供应商在哪里发挥作用。通过我们的优先级设置，我们找到了一家与Prometheus metrics无缝集成的供应商，他们甚至可以为我们收集这些指标，所以我们甚至不需要运行Prometheus，只需要使用他们的标准。他们也很顺利地接受了我们的StatsD指标。
SignalFx
SignalFx是我们最终选择的供应商，这是最终对我们有用的，也合乎我们的优先级。供应商选择的关键组件是，解决方案从托管的、易于使用的角度满足你的需求。话虽如此，我将说明SignalFx是如何为我们实现这一点的。
我们第三个重点的后续部分是我们想要一些关于应该注意什么的指导，SignalFx有一些非常有用的指示板，它们使用Prometheus度量来精确定位我们的一些关键基础设施组件，比如Kubernetes和AWS。
他们还有一个非常强大的报警系统，这个系统非常简单，只需识别我们想要注意的“信号”，并为其添加一个特定的约束。这些约束可以是介于静态阈值、异常值和历史异常之间的任何东西。这比我们的第二次尝试要简单得多，而且这是围绕自定义度量构建的！双赢！
最后，SignalFx以你发送的每个度量值来收费，关于这一点，最重要的是我们的非生产环境非常安静，我们将它们的分辨率降低到一两分钟，因此不断生成的度量值，比如CPU或内存，不会花费太多。这实现了我们最后的优先级，并使我们比其他供应商的解决方案节省了大量的资金。
所有这些的结论是，我们使用的可观察性平台，如果是围绕标准化系统构建的，并不一定是痛苦的。事实上，情况可能正好相反。我们能够加速我们的开发，并且由于我们的可观察性平台的可维护性和适应性，我们从来没有遇到过意外。
要了解更多关于Nav云原生旅程的信息，请查看案例研究和视频。
