移动端
构建基于容器的本机监控系统 应该注意什么?
  • 关键词:视频监控,摄像头
  • 资料类型:
  • 上传时间:2017-08-10
  • 上传人:
  • 下载次数:4352
  • 需要积分:0

暂无上传相关文件

资料简介

  容器技术是目前非常火爆的一个技术,能够大大提升工作效率。本文中,我们将描述容器本机监控的含义,其核心是对动态容器环境进行监控,并解决在此环境中*堆栈可见性的具体挑战。当然这个解释很模糊,下文中我们会详细讨论。
 
  单个容器并不重要
 
  在云环境中,经常会有“宠物与家畜”的比喻,传统服务器是你所关心的,被称作“宠物”,而在云中,你处理的是动态的实例,这些实例很容易被替换,因此表现为“家畜”。容器则是这种比喻的扩展。它们来来去去(这是个好事),比如部署或更新服务、扩展等等。
 
  但就像家畜一样,重要的不是个体的动物,而是更多的群体和他们的服务目的。这个目的就是容器环境中的“服务”。因此,容器本机监控(听起来可能很奇怪)不应该太关注于监视单个容器,但首先zui重要的是它们提供的服务。当服务出现问题时,实现自动通知,此时,你会希望有能力在需要时深入到容器级别。
 
  当然,你希望能够快速识别有问题的容器。假设目前有10个支持服务的容器,其中一个容器处理请求的时间是服务中其他容器的延迟的两倍。你希望得到关于此不同行为的通知,并详细查看该容器及其周围环境。例如,在同一个节点上可能会有另一个容器耗尽磁盘的I/O,并导致这种延迟的出现。
 
  我们在CoScale中处理这个问题的方式是收集单个容器资源统计信息,并将其与我们从协调器平台获得的服务级别信息相关联。然后,我们将提供特定的可视化视图,以显示单个服务的性能和该服务的容器,使用如下的拓扑指示板,你可以深入到各个容器中。我们还会高亮显示有问题的容器,并自动通知异常行为。为此,我们在服务级别(考虑季节性因素)和容器级别(比较相同服务的容器) 使用异常检测技术。
 

 
  容器只显示需要显示的内容
 
  容器的运作方式对收集来自它们的度量标准带来了具体的挑战。有很多方法可以解决这个问题。你可以开始公开端口、安装卷等,以便将容器的信息公开给外部世界。这不仅麻烦,而且有安全问题。例如,当您想要公开一个JMX连接以访问stats接口时,可能会通过JMX触发潜在的恶意操作。因此,理想情况下,您希望将JMX连接本地保存到容器中,这就是容器的用途。
 
  另一种方法是在容器中开始打包监视代理。除了额外的开销之外,这也打破了容器的不可变性,并且与限制容器的单一进程是不兼容的。
 
  我们在CoScale中处理这个问题的方式是使用一个每个节点的单一监控代理,它使用一组插件来监控容器和协调器指标,以及每个容器内的服务。代理将在容器的名称空间内启动插件,以确保插件与在容器内运行的应用程序具有相同的视图。这确保您不需要公开任何东西,并且这种方法是在框中完成的。
 

  访问用于数据检索的容器日志文件
 
  日志通常是获取度量标准的一个很好的信息来源。在容器环境中编写和存储日志文件有多种选择。与监视一样,你不希望在容器内放置代理,以收集日志或在容器内对您的日志聚合器有任何引用。日志应该由平台来处理。
 
  将日志数据从容器发送到外部世界的zui有效方法是通过/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的映像具有不同的监视指标。
 
  结论
 
  容器本机监控有很多方面,上面列出的并不是详尽,但是提供了如何利用容器技术的核心原则进行监视的一个好办法。这包括在容器环境中访问信息、监视设置的方式以及将低级指标转换为可操作的洞察力的方式。
版权与免责声明: 凡本网注明“来源:智慧城市网”的所有作品,均为浙江兴旺宝明通网络有限公司-智慧城市网合法拥有版权或有权使用的作品,未经本网授权不得转载、摘编或利用其它方式使用上述作品。已经本网授权使用作品的,应在授权范围内使用,并注明“来源:智慧城市网www.afzhan.com”。违反上述声明者,本网将追究其相关法律责任。

本网转载并注明自其它来源(非智慧城市网www.afzhan.com)的作品,目的在于传递更多信息,并不代表本网赞同其观点或和对其真实性负责,不承担此类作品侵权行为的直接责任及连带责任。其他媒体、网站或个人从本网转载时,必须保留本网注明的作品第一来源,并自负版权等法律责任。

编辑精选

更多

本站精选

更多

名企推荐

更多

浙公网安备 33010602000006号