构建基于容器的本机监视系统时应注意什么？

　　构建基于容器的本机监视系统时应注意什么？

　　容器技术是当前非常流行的技术，可以大大提高工作效率. 在本文中，我们将描述容器本机监视的含义，其核心是监视动态容器环境并解决在此环境中完整堆栈可见性的特定挑战. 当然，这种解释很模糊，我们将在下面详细讨论.

　　单个容器并不重要

　　在云环境中，通常有“宠物和家畜”的比喻. 传统服务器就是您所关心的，称为“宠物”. 在云中，您处理动态实例. 这些实例非常易于替换，因此显示为“牲畜”. 容器是这个隐喻的扩展. 它们来来去去（这是一件好事），例如部署或更新服务，扩展等.

　　但是，像家畜一样，重要的不是个人动物，而是更多的群体及其服务目的. 此目的是容器环境中的“服务”. 因此，容器本机监视（听起来可能很奇怪）不应太集中于监视单个容器，但最重要的是它们提供的服务. 服务出现问题时，请实现自动通知. 此时，您将需要能够在需要时降至容器级别.

　　当然，您希望能够快速识别出问题的容器. 假设当前有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 chart之类的概念，您可以在部署的每个新节点上以正确的配置快速部署监视代理.

　　在CoScale中处理此问题的方法是在容器中运行监视代理. 这些容器可以部署到各种不同的配置器和容器平台. 我们已经与Kubernetes，OpenShift，Docker Swarm，Google Container Engine等集成在一起，然后直接在标识容器的名称空间中运行我们的各种插件以提取相关指标.

　　基于容器映像的监视

　　容器本机监视还意味着容器映像定义应如何进行监视. 容器内不需要代理，也无需引用监视详细信息，证书等. 每个映像运行另一个服务或不同的版本，并且它们可能具有不同的监视要求. 例如，运行NGINX Web服务的映像和运行Redis的映像具有不同的监视指标.

　　结论

　　容器本机监视有很多方面. 上面的列表并不详尽，但是它提供了一种监视容器技术核心原理的好方法. 这包括访问信息，监视容器环境中的设置以及将低级指标转换为可行的见解的方法.