如果你正在读这篇文章，你可能意识到数字海洋是一家基础设施公司。（如果你不知道的话：惊喜！）作为一个云平台提供商，我们有各种各样的技术组合，从驱动云的许多服务，从硬件到虚拟化软件，甚至容器编排工具。但随着许多运动部件的出现，一个至关重要的需求就是：可观察性。可观测性通常被定义为由三个"支柱"组成：日志记录、度量和跟踪。然而，在这篇文章中，我将重点介绍度量，即我们DigitalOcean如何利用Prometheus和Alertmanager监控我们的服务和容器集群。无论您是编写服务的软件工程师还是维护容器编排解决方案的操作工程师，这些监视和警报示例都应该证明有用。更多但是，在深入研究监控的内容和方式之前，我将首先关注为什么要进行监控，而不是"知道什么时候出了问题"，为什么工程师应该监视应用程序或基础结构堆栈。直接的答案可能是"知道什么时候出问题了"，当然，在停机或其他指标问题时发出警报是设置监控的重要原因。事实上，DigitalOcean的大多数应用程序都有一个白盒监控或黑盒监控设置和一些基本的停机警报（有时，我们两者都有）。但除了警报之外，适当的监控还允许人们识别长期趋势，分析性能问题，并设置可视化。例如，部署在DigitalOcean的Kubernetes集群上的每个集装箱化应用程序都有一个自动仪表板，其中包含基本的统计信息，如内存、CPU使用率以及流量。我们的集群本身也有仪表盘。这些对于可视化总体趋势和在随叫随到过程中的调试非常重要旋转：图1：doccserver应用程序仪表盘我还提到，我们目前使用Prometheus和Alertmanager进行监视和警报：我们的监视方法。使用这个工具的过程也是非常有趣的，这也是我有机会见证的。DigitalOcean最初利用Chef和各种各样的脚本或CI/CD工具进行资源调配、更新和部署。Nagios通常用于（现在仍然是）在主机上执行blackbox监视。然而，这还不够。虽然blackbox监视是难题的一部分，但它不能提供对应用程序的足够的内省，也不能真正帮助调试各种问题。由于一些工程师一直在尝试其他解决方案，所以他们总是在尝试其他解决方案。有些很难设置和操作维护，而另一些没有提供有用的可视化或用户体验。此外，事实证明利用数据进行分析是困难的…但是普罗米修斯和警报管理器。四个基本度量类型是普罗米修斯的核心——计数器、量具、摘要和柱状图，它们可以与强大的查询语言组合在一起，具有各种分析和调试功能。普罗米修斯被证明是非常容易安装，无论是通过一个简单的Go二进制或Docker容器。此外，事实证明，时间序列数据是多维的这一事实证明是非常有帮助的，因为我们采用普罗米修斯的同时，我们也朝着集装箱化的方向发展；有了标记数据的能力，当使用Kubernetes等工具时，分析和聚合就变得更加简单。因此，普罗米修斯很快成为我们的白盒监控工具，与Alertmanager一起警报。指标：利用这四个黄金信号，我们确定了监控的原因和方式；现在让我们看看是什么。我们在DigitalOcean利用的两类指标是我们基于请求的微服务的四个黄金信号（Google SRE book fame），以及我们大量使用的指标，以监控我们的容器编排集群，如Kubernetes或梅索斯四个黄金信号包括延迟、饱和、流量和错误。延迟是指请求的持续时间；需要注意的一点是，考虑请求持续时间的分布是至关重要的，尤其是长尾或第99百分位。毕竟，只有少数用户会受到影响，这往往是一个即将饱和的信号，另一个黄金信号。饱和本身被定义为一个系统的"满度"；它表示某事物等待服务的时间。因此，我们通常根据95%或99%的请求仔细跟踪警报延迟：图2：Kube dns第95个百分位请求延迟（以msn表示）注意，使用Prometheus直方图度量生成这些度量并随后配置警报相当容易类型：直方图分位数（0.95，sum（rate（kubedns_probe_kubedns_latency_ms_bucket[1m]）BY（le，kubernetes_pod_name））>1000作为直方图度量在不同存储桶中收集，我们只需指定要计算的百分位测量值，并利用直方图分位数函数。通过指定我们希望跟踪的精确分位数，也可以使用摘要度量来计算延迟分位数。虽然这可以减少分位数估计误差，但它是一个更昂贵的客户端计算。现在最后两个金色信号！流量是指系统上的需求量。在基于请求的系统中，这通常以每秒的HTTP请求数来衡量。为了使用Prometheus来测量流量，我们经常让应用程序暴露出单调递增的请求计数度量，然后计算每秒的速率。为什么？单看不断增加的计数不能提供任何异常流量增加或减少：图3注意：不断地计算请求增加。但是，查看请求速率可以让我们对流量有一个有意义的概念；然后，我们可以为每秒超过或低于某个特定值的速率设置警报值：图4：通过在15分钟的窗口中应用rate（），我们可以得到一个有意义的想法交通。错误最后一个黄金信号失败或成功请求的比率也同样计算。对应用程序进行检测，以使用指示状态代码或其他信息的标签显示错误计数；然后计算每秒的速率，以提供有意义的公制：图5：cassandran的每秒错误率注意到，每秒的错误率突然上升，但下降了。但是，由于这低于下面配置的警报（每秒50个错误），因此没有警报触发：sum（rate（cassandra_query_latency_count{docc_app=~"timeseries摄取索引[0-9]+"，result="error"}[5m]）>50使用这四个黄金信号，我们可以了解基于请求的服务的健康状况以及最终用户的体验。我们既可以在仪表板上可视化这些指标，也可以为任何异常情况设置警报指标。英寸除了监控我们的服务，我们还监控我们的基础设施。作为维护容器集群的团队的前成员，我注意到利用USE方法的巨大好处：利用率、饱和度和错误。由Brendan Gregg首创的USE方法允许我们用5%的精力解决80%的服务器问题，让我们看看我们是如何利用这些指标来监控我们的Kubernetes集群的。每个集群由多个称为kubelets的工作节点组成。监视这些节点上的总体CPU、内存利用率和保留已得到证明基本要求：图6：Kubernetes单个工作节点的工作节点CPU利用率表示CPU利用率以CPU秒为单位进行测量，这是一个不断增加的计数器。因此，计算每秒CPU秒数的速率可以得到给定时间内正在使用的CPU核心数。我们可以进一步调整此计算，以创建一个警报，以检测工作节点上超过给定百分比的CPU利用率。（如果您对如何做到这一点感兴趣，请一定查看这篇博文。）我们Kubernetes架构的另一个关键组件是我们的HAProxy入口负载平衡器；这些是我们网络堆栈中的组件，将大量外部流量引导到集群内的适当服务。可以想象，负载平衡器连接利用率和饱和因此对测量：图7：入口负载平衡器连接利用率（%）如果所有连接都用于入口负载平衡器，则在某些连接断开之前，无法进行其他连接。因此，我们还选择对超过50%的负载平衡器连接ut发出警报ilization:最大（haproxy_frontend_current_sessions/haproxy_frontend_limit_sessions）作者（kubernetes_node_name，frontend）*100>50个结论，这是我们在DigitalOcean的监控和警报设置的一小部分！通过这几个例子，希望您能够了解我们是如何和为什么选择利用这四个黄金信号和USE方法来监视和警告我们的微服务和容器集群。这样做可以让运营团队和服务所有者保持运行中应用程序和关键基础设施的可观察性。我们还利用这些数据来跟踪长期趋势，并着眼于改进性能。希望你也能这么做！来源：[1]日志和指标，Cindy Sridharan。https://medium.com/@copyconstruct/logs-and-metrics-6d34d3026e38[2]第6章：监控分布式系统。谷歌网站可靠性工程。https://landing.google.com/sre/book/index.html[3] 使用方法。布伦丹·格雷格。[4] 量度的适当使用。马丁·福勒。https://martinfowler.com/articles/useOfMetrics.html[5] 监视和可观测性。辛迪·斯里德哈兰。https://medium.com/@copyconstruct/monitoring-and-observability-8417d1952e1cSneha-Inguva是一位热心的软件工程师，致力于在DigitalOcean构建开发人员工具。此前，斯内哈曾在多家初创公司工作。从教育到3D打印到