转载

容器监控种类大盘点

当讨论容器监控时，我们需要先谈谈“监控”一词。不同的行业中监控可能代表着不同的意义，在容器以及基于云的运营世界，它有以下四个主要用途：

- 知道什么时候出现问题。

- 拥有调试问题的信息。

- 趋势和报告。

- 探测。下面就让我们来看看这些用途以及最好的实现方法。

拥有调试问题的信息

你的监控系统现在会提醒你延迟时间很长。现在你要做什么呢？你可以登录到每台机器上，运行top命令，检查syslog并开始tailing应用日志。但这样没有任何效率可言，而且随着你的数据流和机器资源的扩充，问题检查的效率会越来越低。你的监控需要提供一种方法，可以让你可以有条不紊地处理问题，为你提供缩小问题范围所需的工具。

微服务通常可以被视为树，远程过程调用（RPC）从顶部流到底部。服务中的高延迟的问题通常由该服务或其后端之一的延迟引起。比起尝试从仪表板上的数百个图表获得灵感，您可以转到根服务的仪表板，并检查其后端是否出现过载和延迟的迹象。如果延迟在后端，请重复此过程，直到找到出问题的服务。

知道什么时候出现问题

告警是监控的最关键的部分之一，但一个重要的问题是：什么样的问题值得在午夜唤醒一个工程师去看呢？可以为任何事设立告警机制的确诱人，比如设立预警线甚至为轻微的小问题创建告警，但这也可能会迅速导致警惕疲劳。

假设你正在运行一组面向用户的微服务，并且您关心请求的延迟。CPU在每台机器上的用量监控是否有用呢？监控可能会提醒你计算机上的CPU容量已用完。它同时也可能在后台进程需要比平常更长的时间时出现误报，以及在死锁或者没有足够的线程来使用所有CPU时出现漏报。

CPU是导致问题的潜在原因，高延迟才是你应该尝试监测的问题现象。在My Philosophy on Alerting, Rob Ewaschuk一书中指出造成高延迟的许多潜在原因，并且很难枚举所有原因。所以说最好监控并告警这种问题现象，因为这样你更有可能会在更少的告警页面中看到一个真正值得在深夜唤醒工程师的问题。在动态容器环境中，机器只是一个计算资源，对于现象而不是原因告警才是正道。

拥有调试问题的信息

Figure 1: 微服务中的组件数据流

这个过程可以更进一步。就像微服务组成树一样，单个微服务中的子系统，库和中间件也可以表示为树。然后可以应用相同的问题识现象别方法来进一步缩小问题范围。要继续从这里开始调试，你可能会使用各种工具挖掘流程内部，调查请求日志中的模式并跨主机交叉关联请求。

趋势和报告

告警和调试通常在几分钟到几天的时间范围内。趋势和报告关注从周到年的时间范围。

一个使用较好的监控系统收集各种信息，从原始硬件利用率和API请求数到高级业务指标。对于这些信息有明显的应用场景，比如配置和容量规划如何能够满足未来的需求，但除此之外，还有更为广泛的方面，数据可以帮助工程和业务的决策。

知道请求彼此之间有多么相似可能带来缓存的方面的益处，或者可能有助于争取移除一个缓存来简化架构简单。了解每个请求如何使用您的有限资源有助于确定你的定价模式。跨服务和跨机器统计信息可以帮助您将时间花在潜在的系统优化上。你的监控系统应能帮助你使进行这些分析成为可能。

探测

当你有一把锤子，一切都开始看起来像一个钉子。

探测与其他用途不同，因为它涉及将数据从系统A移动到系统B，而不是直接支持响应决策。一个示例可能是将每小时的销售数量的数据发送到商业智能仪表板。探测是关于建立这个管道，而不是从最终结果采取什么行动。这不一定是监控; 然而，使用监控系统将一些数据移动到需要移动的位置通常会很方便。

从头开始构建量身定制数据移动的解决方案可能需要几个星期，如果可以有效地使用你的监控系统做同样的事情，那么为什么不呢？所以，在评估监控系统时，不要仅仅要考虑其图形化和警报的能力，还要了解添加自定义数据源和稍后提取捕获的数据是否容易。

监控的类型

现在我们已经建立了监控的概念，让我们再谈谈那些插入到我们监控系统中的数据吧。

总体来说，大多数监控系统使用相同的数据：事件。事件是在观察节点之间发生的所有活动。事件可以是正在执行的指令，正在进行的函数调用，被路由的请求，接收到的远程调用过程（RPC）或返回的响应。事件具有上下文信息，例如什么数据触发它们以及什么数据它们正使用。

我们将看看使用事件的几种不同的方式; 每种方法都做出不同的折衷，并为我们展示了系统的不同角度。完整的容器监控系统将具有以下每种方式的方方面面。

度量

度量，有时称为时间序列，涉及随时间聚集的事件。它们计算每种类型的事件发生的频率，每种类型的事件需要多长时间以及不同事件类型处理多少数据。

度量不关心事件的上下文。您可以添加上下文，例如通过HTTP端点分解延迟，但是您需要为每个端点的度量消耗资源。在这种情况下，endpoint的数量需要相对较小。这限制了分析事件的个别事件的能力; 然而，好处是它允许在单个服务内跟踪成千上万的事件类型。这意味着您可以深入了解代码在整个应用程序中的表现。

我们将更深入地探讨基于度量的监控的组成部分。

Figure 2: 收集、存储、现实度量的架构图

收集

收集是将系统状态和事件转换为度量的过程，可以稍后由监视系统收集。收集可以通过下面几种方式进行：

1.完全在一个进程中。 Prometheus 和 Dropwizard instrumentation libraries就是例子; 他们将所有状态保存在进程的内存中。

2.通过将来自另一进程的数据转换为可用格式。 collectd 以及 Agentless System Crawler 通过从 proc filesystem 中提取数据来执行此操作。

3.由两个进程协作：一个捕获事件，另一个将它们转换为度量。StatsD就是一个例子，其中每个事件都是由应用程序通过网络发送到StatsD中。

摄取

摄取，从收集中获取指标，并将其送入监测系统。这可以是歌涉及排队系统（例如Apache Kafka）或直接从集合的简单数据传输的多阶段过程。在这一点上，必须提及push与Pull的争论。这两种方法都有优点和缺点，我们不会在这里做更多的讨论，但是简单来说两种方法都可以扩展，并且两种方法都可以在容器化的环境中工作。

存储

一旦数据被摄取，它通常会被存储起来。它可以是对最近结果的短期存储，但它也可以是特定分钟，小时或天的数据存储。

一旦存储的数据容量超出了在一台机器上的内存范围，就需要进行操作性和可靠性的权衡，并且这里根据组织对监控数据的需要也有利弊。磁盘上进程的生存期之外的持久数据意味着需要备份或者意味着在机器故障时丢失数据。在多台机器间传播数据带来了分布式系统的基本挑战。如果数据是安全的结束现有的系统并不难，但新的数据不能被摄取和处理。

数据处理和报警

如果你不做任何数据处理，数据就没有太大用处。大多数度量系统提供了一些方法来对接收的数据进行数学计算，通常还提供方法来对异常情况告警。这可能会发生在数据被摄取或作为单独的异步过程。

不同的数据处理解决方案中复杂性差异很大。一方面，像Graphite这样的解决方案没有第三方工具支持就没有数据处理或告警功能; 然而，在绘图时有基本的聚合和算术能力。另一方面，有像Prometheus或Sysdig这样的解决方案，不仅具有成熟的数据处理和告警系统，而且还有的额外的聚合和重复数据删除系统用于告警。

可视化

能发到手机的告警是不错，但是对于调试，报告和分析，我们希望有仪表板可以可视化这些监控数据。

可视化工具通常分为三类。低端的，有内置的方法在监控系统本身产生专门的图表。中端的，监控系统有内置的仪表板，但是内容有限或不能自定义，这是用于监控特定系统所常见的系统设计。最后，有完全可定制的仪表板，你可以创建几乎任何你喜欢的数据呈现样式。

他们如何结合在一起

现在，您已经了解了度量监控系统中涉及的组件，让我们来看看一些具体示例。

Nagios

Nagios服务器通常调用主机上的脚本（称为检查），并记录它们是否根据其退出代码正常工作。如果检查失败太多，它会发出警报。可视化部分通常由单独的内置仪表板提供。它可以从脚本中获取1KB的数据，包括度量（称为“perfdata”），并将其传递到另一个监视系统。

Figure 3: Nagios 架构

Nagios设计用于静态设置，需要重新启动才能加载新配置。其有限的数据处理，专注于基于主机的监控以及仅处理少量度量数据的能力使得它不适合于在容器环境中进行监视。但是，它仍然可用于基本黑盒监控。

Collectd, Graphite 和 Grafana

许多常见的监控栈将几个组件组合在一起。 collectd，Graphite和Grafana组合就是这样一个例子。 collectd是收集器，从内核和第三方应用程序（如MySQL）中提取数据。要从您自己的应用程序收集自定义指标，您可以使用StatsD协议，该协议会发送用户数据协议（UDP）数据包来收集个别事件。 collectd将指标发送给Carbon，后者使用Whisper数据库进行存储。最后， Graphite和Grafana本身都可以用于可视化。

Figure 4: collectd, Graphite, Grafana 组合监控方案示例

StatsD的收集方法在规模方面是有限制的; 为了获得性能，选择放弃一些事件并不少见。 Collected每机器方法在容器化环境中也是限制性的。例如，如果有动态部署的MySQL容器，那么collectd需要每次更新它的配置。

Prometheus

Prometheus采取了不同于我们之前例子的方法。监控数据收集在应用程序内部发生。每个应用程序有一个导出器，而不是每台机器有一个收集器。这种方法可以更容易管理，虽然是以以增加资源使用为代价。在像Kubernetes这样的容器化环境中，导出器将作为主容器的附属容器来管理。 Prometheus服务器处理提取，处理，告警和存储。但是，为了避免将分布式系统绑定到关键监控中，本地Prometheus存储更像是一个缓存。单独的非关键分布式存储系统处理长期存储。这种方法提供了长期数据的监测可靠性和耐久性。

Figure 5: Prometheus 架构

Prometheus决定发出什么警报，但它不会向用户发送电子邮件或信息。告警信息会被发送到Alertmanager，它对来自多个Prometheus服务器的警报进行重复数据删除和聚合，并发送通知。

Sysdig Cloud

前面的部分给出了各种开源解决方案的架构。为了比较，本节描述了Sysdig Cloud的一种商业解决方案的架构。 Sysdig Cloud使用基于每个主机的内核级别收集模型。此工具可通过单个收集点捕获应用程序，容器，统计信息和主机度量信息。它收集事件日志，如Kubernetes scaling，Docker容器事件和代码推送与度量相关联。每个主机代理可以减少监视代理的资源消耗，并且不需要修改应用程序代码。然而，它需要一个特权容器。

Figure 6: Sysdig 商业版架构

Sysdig Cloud存储后端包括Cassandra（度量），MySQL（事件）和Redis（服务内部代理）的水平可伸缩集群。基于这些组件提供高可靠性和规模来存储多年的数据用于长期趋势和分析。所有数据都可以通过REST API访问。这整个后端可以通过Sysdig的云服务使用，或作为软件部署在私有云中，以提高安全性和隔离性。此设计允许您避免运行多个系统进行实时监控和长期分析或数据保留。

除了处理度量数据之外，Sysdig Cloud还收集其他类型的数据，包括来自Kubernetes和Docker容器的事件日志，以及来自编排引擎（如Kubernetes）的元数据。这用于丰富从度量提供的信息，而且度量系统具有超出度量数据处理功能情况并不罕见。