容器技术是目前非常火爆的一个技术，能够大大提升工作效率。本文中，我们将描述容器本机的含义，其核心是对动态容器进行，并解决在此中完全堆栈可见性的具体挑战。当然这个解释很模糊，下文中我们会详细讨论。 在云中，经常会有“宠物与家畜”的比喻，传统服务器是你所关心的，被称作“宠物”，而在云中，你处理的是动态的实例，这些实例很容易被替换，因此表现为“家畜”。容器则是这种比喻的扩展。它们来来去去(这是个好事)，比如部署或更新服务、扩展等等。 但就像家畜一样，重要的不是个体的动物，而是更多的群体和他们的服务目的。这个目的就是容器中的“服务”。因此，容器本机(听起来可能很奇怪)不应该太关注于单个容器，但首先最重要的是它们提供的服务。当服务出现问题时，实现自动通知，此时，你会希望有能力在需要时深入到容器级别。 当然，你希望能够快速识别有问题的容器。假设目前有10个支持服务的容器，其中一个容器处理请求的时间是服务中其他容器的延迟的两倍。你希望得到关于此不同行为的通知，并详细查看该容器及其周围。例如，在同一个节点上可能会有另一个容器耗尽磁盘的I/O，并导致这种延迟的出现。 我们在CoScale中处理这个问题的方式是收集单个容器资源统计信息，并将其与我们从协调器平台获得的服务级别信息相关联。然后，我们将提供特定的可视化视图，以显示单个服务的性能和该服务的容器，使用如下的拓扑板，你可以深入到各个容器中。我们还会高亮显示有问题的容器，并自动通知异常行为。为此，我们在服务级别(考虑季节性因素)和容器级别(比较相同服务的容器) 使用异常检测技术。 容器的运作方式对收集来自它们的度量标准带来了具体的挑战。有很多方法可以解决这个问题。你可以开始公开端口、安装卷等，以便将容器的信息公开给外部世界。这不仅麻烦，而且有安全问题。例如，当您想要公开一个JMX连接以访问stats接口时，可能会通过JMX触发潜在的恶意操作。因此，理想情况下，您希望将JMX连接本地保存到容器中，这就是容器的用途。 另一种方法是在容器中开始打包代理。除了额外的开销之外，这也打破了容器的不可变性，并且与容器的单一进程是不兼容的。 我们在CoScale中处理这个问题的方式是使用一个每个节点的单一代理，它使用一组插件来容器和协调器指标，以及每个容器内的服务。代理将在容器的名称空间内启动插件，以确保插件与在容器内运行的应用程序具有相同的视图。这确保您不需要公开任何东西，并且这种方法是在框中完成的。 日志通常是获取度量标准的一个很好的信息来源。在容器中编写和存储日志文件有多种选择。与一样，你不希望在容器内放置代理，以收集日志或在容器内对您的日志聚合器有任何引用。日志应该由平台来处理。 将日志数据从容器发送到外部世界的最有效方法是通过/dev/stdout。然后，平台获取这些日志并将它们推到日志聚合器中。这使得日志访问和聚合变得简单和直接，并且确保您的容器依赖于单个进程，不需要后台工作人员或定时任务来清理他们的日志。 CoScale支持从被推到/dev/stdout和/dev/stderr的日志中提取指标和事件。但是，如果容器中有多个日志文件(例如访问日志、错误日志等)，可以配置CoScale插件，以从这些日志文件中提取度量和事件。 容器使用变量进行初始化、连接等。有状态容器，如数据库容器(如postgresql，mysql)也使用变量来初始化数据库，如果它还没有初始化。必须考虑这些变量，以便正确地这些容器和它们正在运行的服务，因此您的解决方案应该理解这一点。 一些CoScale插件需要凭证来收集运行服务的度量标准。提供给容器的变量可以在CoScale插件配置中使用。例如，Postgresql容器使用pguser和pgpassword变量，在CoScale Postgres插件配置中，您可以使用$pguser和$pgpassword作为连接到数据库的凭证。当CoScale代理检测到Postgresql容器时，它将知道使用提供给该容器的变量作为凭证来获取该容器的Postgresql统计信息。 由于您的服务是在容器中运行的，所以对您的代理执行同样的操作是有意义的。一些工具将要求您在容器中安装代理，或者在sidecar容器中安装代理，这通常会带来额外的开销。此外，必须在容器中包装额外的代理，这并不是开发人员非常喜欢的事情，因为它了容器的单一用途。在自己的容器中部署代理是一种更容器本机式的解决方案，这使得部署比其他的容器化服务更容易。此外，使用诸如deamonset和helm图表之类的概念，您可以在部署的每个新节点上快速部署具有正确配置的代理。 我们在CoScale中处理这个问题的方法是在一个容器中运行我们的代理。可以将这些容器部署到各种不同的配置器和容器平台中。我们与Kubernetes、OpenShift、Docker Swarm、Google容器引擎等进行了集成，然后我们在识别容器的名称空间中直接运行我们的各种插件，以提取相关的度量标准。 容器本机也意味着容器图像定义了应该怎么做,这个容器内部不需要一个代理,不需要引用细节,证书,等等。每个映像运行另一个服务或一个不同的版本,而这些都可以有不同的需求。例如，运行NGINX webservice的映像与运行Redis的映像具有不同的指标。 容器本机有很多方面，列出的并不是详尽，但是提供了如何利用容器技术的核心原则进行的一个好办法。这包括在容器中访问信息、设置的方式以及将低级指标转换为可操作的洞察力的方式。
|