这是我在2018年Promcon大会上的一次演讲的改编本。您可以在这里找到有关我们的Prometheus部署和演示者注释的幻灯片。还有一段视频。提示：你可以点击图片看到原来的大版本。![1](https://blog.cloudflar在Cloudflare，我们使用普罗米修斯收集运营指标。我们在数百台服务器上运行它，每秒接收数百万个指标，以便深入了解我们的网络，并为我们的客户提供尽可能最好的服务。普罗米修斯度量格式已经足够流行了，它现在被标准化为云计算基础下的OpenMetrics。在长时间分散的度量环境中看到融合是令人兴奋的。在这篇博文中，我们将讨论如何度量低级别的度量，并共享一个工具，它可以帮助您对您的系统获得类似的理解。![2](https://blog.cloudflar有两个主要的导出器可以用来深入了解Linux系统的性能。第一个是node_exporter，它提供有关基本信息，如按类型划分的CPU使用情况、内存使用情况、磁盘IO统计信息、文件系统和网络使用情况。第二个是cAdvisor，它提供了类似的度量，但深入到容器级别。您可以看到哪些容器（和systemd单元也是cAdvisor的容器）使用了多少全局资源，而不是查看CPU的总使用量。这是你应该知道的关于你的系统的最起码的知识。如果你没有这两个，你应该从那里开始。让我们看看你能从中得到的图表。![3](https://blog.cloudflar我应该提到，这篇文章中的每一个截图都是来自一台真正的生产机器，它在做一些有用的事情。我们有不同代的硬件，所以不要试图得出任何结论。在这里，您可以看到从node\u exporter获得的CPU和内存的基础知识。您可以看到利用率和空闲资源的数量。![4](https://blog.cloudflarnode\u exporter提供了更多指标，这次是磁盘IO。网络也有类似的面板。在基本的层次上，您可以做一些关联来解释为什么当您看到更高的网络和磁盘活动时CPU会上升。![5](https://blog.cloudflar使用cAdvisor，这会变得更有趣，因为您现在可以看到全局资源（如CPU）是如何在服务之间分割的。若CPU或内存使用量增加，您可以确定负责的确切服务，还可以了解它对其他服务的影响。如果全局CPU数量变化不大，您仍然可以看到服务之间的变化。所有这些信息都来自最简单的计数器和它们的一阶导数（利率）。![6](https://blog.cloudflar计数器很好，但它们缺少关于单个事件的详细信息。以磁盘io为例。我们从node_exporter获得设备io时间，其派生值不能超过每秒一秒的实时时间，这意味着我们可以在1s处画一条粗红线，看看我们从磁盘中获得了什么样的利用率。我们得到了一个代表工作量的数字，但这根本不足以理解它。我们正在进行许多快速IO操作吗？我们是不是在做一些慢动作？我们得到了什么样的慢和快的组合？写和读有何不同？![7](https://blog.cloudflar这些问题需要一个柱状图。上面是一个计数器，下面是一个柱状图。请记住，普罗米修斯柱状图是累积的，le label统计所有小于或等于标签值的事件。![8](https://blog.cloudflar好吧，想象一下我们有这个柱状图。为了直观地显示这两种类型的度量之间的差异，这里有同一事件的两个屏幕截图，这是生产中的SSD替代品。我们更换了一个磁盘，这就是它如何影响线条和柱状图的。在新的Grafana 5中，你可以把直方图绘制成热图，它给你比一条线更多的细节。下一张幻灯片有一张更大的屏幕截图，在这张幻灯片上你应该可以看到详细的变化。![9](https://blog.cloudflar在这里，您可以看到用颜色编码的bucket，并且每个时隙在工具提示中都有自己的分布。用条形高亮显示和双Y轴可以让它更容易理解，但这是一个很大的进步，从一条线尽管如此。除了漂亮的可视化效果外，您还可以在Xms上方绘制事件的数量，并在上面设置警报和slo。例如，如果块设备的读取延迟超过10毫秒，则可以发出警报。![10](https://blog.cloudfla如果你仔细观察这些直方图，你可能已经注意到Y轴上的值有点高。在更换之前，您可以看到0.5s到1.0s bucket的值。左侧磁盘的技术规格为50微秒的读/写延迟，右侧磁盘的读/写延迟稍微降低到36微秒。我们在柱状图上根本看不到这一点。有时您可以在测试中使用fio发现这一点，但是生产工作负载可能具有难以复制的模式，并且具有非常不同的特性。柱状图显示了情况。如果不小心IO，即使是一些缓慢的请求也会影响到总体数字。我们在博客中记录了这对缓存延迟的影响，以及我们最近如何解决这个问题。到现在为止，你应该确信，直方图对于那些你关心单个事件的时间的事件来说显然是优越的。![11](https://blog.cloudfla如果您想将所有的存储延迟度量转换为直方图，我有一个坏消息要告诉您：Linux内核只为node_exporter提供计数器。你可以尝试用blktrace来解决这个问题，但它看起来既不实用也不高效。让我们稍微换一下，看看计数器的汇总统计数据是如何骗人的。![12](https://blog.cloudfla这是Autodesk的一项研究。左边的生物叫做数据宝库。然后是目标人物在中间，动画在右边。令人惊奇的是，右边的形状和所有中间动画帧的X轴和Y轴的平均值和标准差都是相同的。从汇总统计的角度来看，右边的每个方框都是一样的，但是如果你绘制单个事件，就会出现一幅截然不同的画面。![13](https://blog.cloudfla![14](https://blog.cloudfla这些动画来自同一个研究，在这里你可以清楚地看到框图（mean+stddev）是如何不代表原始事件的。相反，柱状图给出了一个准确的图像。我们确定柱状图是你想要的，但是你需要单独的事件来制作这些柱状图。假设我们要测量Linux内核中的io操作，那么对于处理这个任务的系统有什么要求？它必须是低开销的，否则我们不能在生产中运行它它必须是通用的，所以我们不能仅仅局限于io跟踪它必须得到开箱即用的支持，第三方内核模块和补丁并不十分实用最后，它必须是安全的，我们不想让我们负责的大部分互联网崩溃来获取一些指标，即使它们很有趣![16](https://blog.cloudfla事实证明，有一种解决方案叫做eBPF。这是一个运行在内核中的低开销的用户定义字节码。它永远不会崩溃、挂起或对内核造成负面影响。这听起来有点含糊，但这里有两个链接可以深入到解释这是如何工作的细节。主要的部分是它已经包含在Linux内核中了。它用于网络子系统和seccomp规则，但作为一个通用的"在内核中运行安全的代码"，它还有很多其他用途。
