当一家公司写下他们的可观测性堆栈时，他们通常把重点放在甜蜜的可视化、高级异常检测或创新的数据存储上。这些都很好，但是今天我们想谈谈观察你的系统时的矛尖：度量管道！度量管道是我们如何从度量发生的位置快速高效地将我们的主机和服务传输到存储，以便可以查询它们，而所有这些都不会中断主机服务。首先，让我们建立一些技术背景。大约一年前，Stripe开始迁移到Datadog。Datadog是一个托管产品，提供度量存储、可视化和警报。有了它们，我们可以得到一些奇妙的仪表板来监控我们的观测系统：可观测性概述仪表板以前，我们一直在使用一些不错的开源软件，但遗憾的是它没有所有权，内部也没有维护。面对高成本的资金和人员，我们决定外包给Datadog是个好主意。将近一年后，我们对通过在这一领域的重大努力而提高的可见性和可靠性感到非常高兴。这项工作最有趣的一个方面是如何甚至度量！使用StatsD进行度量有很多方法可以检测你的系统。我们首选的方法是StatsD样式：一种简单的基于文本的协议，对性能影响最小。代码在运行时被检测为在运行时向中央服务器发送UDP。就像所有的生命一样，这个选择也有权衡。为了简洁起见，我们将很快提到与我们最相关的StatsD的两个缺点：它使用固有的不可靠UDP，以及它作为计时器聚合的单点故障的角色。如您所知，UDP是一种"即开即弃"协议，不需要接收方的任何确认。这使得UDP对于客户端来说相当快，但也意味着客户端无法确保度量被任何人接收！当与网络和主机的自然保护相结合时，会导致流量减少，这就有了问题。另一个问题是单点故障。糟糕的StatsD服务器必须处理大量UDP数据包，如果你有大量的数据源。再加上机器坏掉的噩梦，需要切分或使用其他技巧来扩展，你就可以完成你的工作了。DogStatsD和"全球"的缺失意识到中央StatsD对某些人来说可能是个问题，Datadog采取了不同的方法：每个主机运行DogStatsD的一个实例，作为Datadog代理的一部分。这巧妙地避开了大多数性能问题，但为Stripe创建了一个大的特性回归：没有更多的全局百分位。Datadog只支持针对柱状图、计时器和集合的每主机聚合。请记住，使用StatsD，每次事件发生时都向下游服务器发出一个度量。如果您正在测量API请求并在每个主机上发出该度量，那么现在您将向本地Datadog代理发送计时器度量，该代理将聚合这些请求并成批将其刷新到Datadog的服务器。对于计数器，这是伟大的，因为你可以把它们加在一起！但对于百分位，我们有问题。假设您有数百个服务器，每个服务器都在用不同的工作负载执行数量不等的API请求。我们的百分位数不能代表我们整个API的表现。更糟糕的是，一旦我们为我们的直方图生成了百分位，就没有什么有意义的方法来组合它们。（更准确地说，一个分布的任意子样本的百分位不足以满足全分布的百分位）。Stripe需要知道整个百分位，因为每个主机的直方图只有一小部分随机请求。我们需要更好的东西！进入威尼斯为了给Stripe提供这些特性，我们创建了Veneur，一个具有全局聚合功能的DogStatsD服务器。我们很高兴在生产中运行它，你也可以！它是开源的，我们希望你能看看。Veneur运行在Datadog的捆绑DogStatsD服务器上，监听同一个端口。它将度量刷新到Datadog，就像您预期的那样。然而，相似之处就在这里结束了，而魔法开始了。Veneur没有聚集直方图并在刷新时发出百分位，而是将直方图转发到一个全局Veneur实例，该实例合并所有直方图并在下一个窗口将它们刷新到Datadog。它增加了一个刷新周期的延迟，但结果是本地和全局指标的最佳组合！我们监控许多API调用的性能，例如这个创建费用的各种百分比的图表。红条是部署！近似的合并直方图如前所述，百分位数的根本问题是，一旦报告，它们就不能组合在一起。如果主机A收到20个请求，主机B收到15个请求，则可以将这两个数字相加，以确定总共有35个请求。但是如果主机A的第99百分位响应时间为8毫秒，而主机B的第99百分位响应时间为10毫秒，那么两台主机的第99百分位响应时间是多少？答案是，"我们不知道"。这两个百分位数的平均值在统计学上是没有意义的。如果我们有两个以上的宿主，我们也不能简单地取百分位数。我们甚至不能用每一个宿主的百分位数来推断全局百分位的范围，在极少数情况下，全球第99百分位可能大于任何一个单独宿主的百分位。我们需要从主机A报告的原始响应时间集和从主机B报告的原始响应时间集，并将它们组合在一起。然后，从组合的集合中，我们可以报告两个主机的实际第99个百分位。这就是转发的目的。当然，也有一些注意事项。如果每个直方图存储它收到的所有样本，则全局实例上的最终直方图可能会很大。为了避免这个问题，Veneur使用了一个近似的直方图实现，称为t-digest，它使用常量空间，而不考虑样本数量。（具体地说，我们自己编写了它的Go-port。）顾名思义，近似直方图返回近似百分位，但这一折衷确保了Veneur的内存消耗在任何负载下都处于控制之下。退化全局Veneur实例也是通过它的度量的单点故障。如果它下降，我们将失去百分位（和集合，因为这些都是转发的）。但我们不会失去一切。除了百分位数外，StatsD直方图还报告了他们收到的样本数量和最小/最大样本数的计数器。这些指标可以在不转发的情况下组合使用（如果我们知道每个主机上的最大响应时间，那么所有主机上的最大响应时间就是单个值的最大值，依此类推），因此它们可以在不进行任何转发的情况下立即得到报告。如果客户真的希望他们的百分位限制在每个主机上，那么他们可以选择完全不转发。Veneur的概览仪表盘，仪表齐全，健康！其他很酷的功能和错误威尼斯人以法国大猎人，狗的主人而命名！-还有一些其他窍门：直接替换Datadog的DogStatsD。它甚至处理事件和服务检查！写在Go中，以将部署问题最小化到单个二进制文件使用超日志在固定内存消耗的情况下有效地计算集合的唯一成员广泛的度量（natch），所以你可以观察观察者高效的压缩分块POST请求并发发送到Datadog的API非常快在Veneur的发展过程中，我们也进行了多次迭代。我们最初的实现纯粹是一个全局DogStatsD实现，没有转发或合并。它真的很快，但我们很快决定处理更多的数据包并不能让我们走得很远。接下来，我们在"智能客户端"中进行了一些曲折的尝试，这些客户机试图将指标路由到适当的位置。最初这是很有希望的，但是我们发现在我们的每一个语言运行时和用例中支持这一点是非常昂贵的，并且破坏了（Dog）StatsD的简单性。我们的一些仪器就像nc命令一样简单，这种简单性对于快速检测非常有帮助。虽然总体上我们的工作是透明的，但当我们最初重新打开全局功能时，确实造成了一些麻烦。一些团队已经开始依赖于每个主机来制定非常具体的指标。当我们不得不故障回复到主机本地进行重构时，我们给刚刚适应使用全局特性的团队带来了问题。啊！每一个都是积极的学习经验，我们发现Stripe的工程师非常乐于助人。谢谢！感谢和未来的工作可观测性团队要感谢Datadog在创建Veneur时的支持和建议。我们也要感谢我们的朋友和队友们，感谢他们的耐心等待，让我们重回今天的状态。特别是偶尔出现的图表损坏、指标中断和其他一些事后诸葛亮的问题。我们已经在生产维内尔几个月了，一直在享受我们的劳动成果。我们现在正以稳定、更成熟的速度运营，以提高从监控其生产行为中学到的效率。我们希望在未来利用Veneur继续改进我们的度量管道的特性和可靠性。我们已经讨论了附加的协议特性、统一格式、每个团队的计算，甚至包括其他传感器数据，如跟踪范围。Veneur的速度、仪表和灵活性给了我们很大的发展空间和改进空间。一定有人给那些邪恶的酷视觉化和异常探测器喂食！喜欢这个帖子吗？加入条纹工程团队。视图洞口