PS:监控系统是整个运维环节,乃至整个产品生命周期中最重要的一环。
监控的价值与体系
在运维体系中, 监控是非常重要的组成部分。通过监控可以实时掌握系统运行的状态,对故障的提前预警,历史状态的回放等,还可以通过监控数据为系统的容量规划提供辅助决策,为系统性能优化提供真实的用户行为和体验。
这几年互联网业务的迅速发展,用户对系统的要求也越来越高,而做好监控成能为系统保驾护航,能有效提高系统的可靠性,可用性及用户体验。监控的价值体现主要体现在以下几点:
1、节约成本
在生产环境中故障是避免不了的,如果能够通过精确的监控提前发现异常提前进行预警,就可以在故障发生前就解决故障或实施应急预案,从而减少因故障带来的经济损失。还可以通过监控了解系统资源的使用情况,对空闲的资源可以进行重新规划,也能帮助节约成本。
2、提高效率
运维过去都是救火队员,而且因为缺少系统运行数据,在做故障处理时效率很慢,而通过监控可以回放系统的历史状态,保存故障现场。当需要对系统进行分析时直接拉取监控数据生成趋势图,可以很清晰的展示系统存在什么样的问题。比如访问连接突增,内存回收异常,数据库连接异常等问题,可以帮助快速定位到故障原因,解决故障。
3、提高质量
可以通过对系统运行的历史监控数据进行分析,及时找到系统的性能瓶颈进行优化,可以提高系统的运行质量。不仅可以从基础设施的性能角度,还可以从应用性能的角度进行端到端的性能优化,有效提高用户的体验。
但是要做好监控并不容易,一个好的监控系统需要做到以下几点:
完整的监控体系
一个企业的监控体系包括以下几个组成部分:
- 监控数据采集的时效与精确
- 监控数据采集存储与归档
- 监控数据的图形化展示
- 监控数据的自动化分析与联动处理
- 监控的告警及自动化处理
- 监控工具自身的安全控制
- 监控告警的响应及跟踪
从上图我们可以看到,一个完整的监控体系是从监控数据的采集开始,再将数据进行存储,处理从而产生价值。比如智能生成分析报告,可图形化展示,通过监控联动完成高可用,伸缩,限流等事件处理,还有就是监控告警了。对于运维人员而言最高兴的莫过于由于一条告警短信后马上又再收到一条自动恢复的短信了,所以在监控体系里,故障告警的自动化处理也是非常重要的。
目前监控数据的采集方式有以下几种:
- 主动输出
提前在应用中埋点,应用主动上报。比如一些应用系统的业务状态,可以通过在日志中主动输出状态用于采集。
- 远程接入
通过对应用进程接口调用获取应用的状态。比如使用JMX的方式连接到java进程中,对进程的状态进行采集。
- 嵌入式
通过在进程中运行agent的方式获取应用的状态。如目前的APM产品都是通过将监控工具嵌入到应用内部进行数据采集。
- 旁路式
通过外部获取的方式采集数据。比如对网站url的探测,模拟业务的报文 ,对服务器的ping,流量的监控。可以通过在交换机上将流量进行端口复制,将源始流量复制到另一个端口后再进行处理,这样这业务系统是完全没有侵入。
- 入侵式
不同于嵌入式,入侵式的agent是独立运行的进程,而不是运行在进程中。这个目前监控工具比较常用的方式,比如zabbix,在主机上运行一个进程进行相关数据的采集。
- CLI方式
命令行的方式是最基本的方式,比如在linux系统上使用top,vmstat,netstat写一些shell脚本进行数据的采集,再把数据存储在文本文件中进行处理。
在不同的场景可以选用不同的数据采集方式,比如要实时看主机的CPU使用情况,登陆到主机用CLI方式用top命令就可以看到系统CPU的使用和进程CPU的使用情况。比如有一些应用的状态需要记录,就一定要在日志里输出相应的数据。而在数据采集时需要注意以下三个问题:
1、采集的时间间隔
对应用平台的监控数据采集的频率非常重要,关系到数据的及时性,有效性。在做监控数据采集时,也是根据不同的监控对象设定不同的时间间隔。比如对日志的监控是实时的,对实例的状态也是实时的,而对于一些后期用来分析的状态性数据则采集的时间间隔会长一些,3-5分钟的样子。
2、监控工具自身的安全控制
有些监控工具可能是时时运行,特别是侵入式监控,如果运行不当,自身就可能造成故障,比如执行过程异常不释放资源,造成高CPU占用;比如进程结束异常,不停的重启相同的进程;比如日志级别设置过低,大量日志输出,影响进程性能和占用大量磁盘空间。所以做监控时一定要遵循有自我安全控制的能力。监控工具在拿到生产环境中运行前,一定要先在测试环境中进行一段时间的试运行 。
3、触发式的数据采集
需要关注异常点的现场数据采集,比如threaddump,heapdump,主机的性能数据等。这些故障点的数据重启后就会失去,有些故障不能重现时,相关的分析数据就很重要了,所以对于这些数据,需要进行触发式的数据采集。当满足某些条件时触发采集,而在平常不运行。
容器的监控方案
传统的监控系统大多是针对物理机或虚拟机设计的,物理机和虚拟机的特点是静态的,生命周期长,一个环境安装配置好后可能几年都不会去变动,那么对监控系统来说,监控对像是静态的,对监控对象做的监控配置也是静态的,系统上线部署好监控后基本就不再需要管理。
虽然物理机,虚拟机,容器对于应用进程来说都是host环境,容器也是一个轻量级的虚拟机, 但容器是动态的, 生命周期短,特别是在微服务的分布式架构下,容器的个数,IP地址随时可能变化。如果还采用原来传统监控的方案,则会增加监控的复杂度。比如对于一个物理机或虚拟机,我们只要安装一个监控工具的agent就可以了,但如果在一个物理机上运行了无数个容器,也采用安装agent的方式,就会增加agent对资源的占用,但因为容器是与宿主机是共享资源,所以在容器内采集的性能数据会是宿主机的数据,那就失去在容器内采集数据的意义了。
而且往往容器的数量比较多,那么采集到的数量也会非常多,容器可能启动几分钟就停止了,那么原来采集的数据就没有价值了,则会产生大量这样没有价值的监控数据,维护起来也会非常的复杂。那么应该如何对容器进行监控呢?答案是在容器外,宿主机上进行监控。这样不仅可以监控到每个容器的资源使用情况,还可以监控到容器的状态,数量等数据。
单台主机上容器的监控
单台主机上容器的监控实现最简单的方法就是使用命令Docker stats,就可以显示所有容器的资源使用情况,如下输出:
虽然可以很直观地看到每个容器的资源使用情况,但是显示的只是一个当前值,并不能看到变化趋势。而谷歌提供的图形化工具不仅可以看到每个容器的资源使用情况,还可以看到主机的资源使用情况,并且可以设置显示一段时间内的越势。以下是cAdvisor的面板:
而且cAdivsor的安装非常简单,下载一个cAdvisor的容器启动后,就可以使用主机IP加默认端口8080进行访问了。
跨多台主机上容器的监控
cAdivsor虽然能采集到监控数据,也有很好的界面展示,但是并不能显示跨主机的监控数据,当主机多的情况,需要有一种集中式的管理方法将数据进行汇总展示,最经典的方案就是 cAdvisor+ Influxdb+grafana,可以在每台主机上运行一个cAdvisor容器负责数据采集,再将采集后的数据都存到时序型数据库influxdb中,再通过图形展示工具grafana定制展示面板。结构如下:
这三个工具的安装也非常简单,可以直接启动三个容器快速安装。如下所示:
在上面的安装步骤中,先是启动influxdb容器,然后进行到容器内部配置一个数据库给cadvisor专用,然后再启动cadvisor容器,容器启动的时候指定把数据存储到influxdb中,最后启动grafana容器,在展示页面里配置grafana的数据源为influxdb,再定制要展示的数据,一个简单的跨多主机的监控系统就构建成功了。下图为Grafana的界面:
Kubernetes上容器的监控
在Kubernetes的新版本中已经集成了cAdvisor,所以在Kubernetes架构下,不需要单独再去安装cAdvisor,可以直接使用节点的IP加默认端口4194就可以直接访问cAdvisor的监控面板。而Kubernetes还提供一个叫heapster的组件用于聚合每个node上cAdvisor采集的数据,再通过Kubedash进行展示,结构如下:
在Kubernetes的框架里,master复杂调度后有的node,所以在heapster启动时,当heapster配合k8s运行时,需要指定kubernetes_master的地址,heapster通过k8s得到所有node节点地址,然后通过访问对应的node ip和端口号(10250)来调用目标节点Kubelet的HTTP接口,再由Kubelet调用cAdvisor服务获取该节点上所有容器的性能数据,并依次返回到heapster进行数据聚合。再通过kubedash进行展示,界面如下:
Mesos的监控方案
而Mesos提供一个mesos-exporter工具,用于导出mesos集群的监控数据prometheus,而prometheus是个集 db、graph、statistic、alert 于一体的监控工具,安装也非常简单,下载包后做些参数的配置,比如监控的对象就可以运行了,默认通过9090端口访问。而mesos-exporter工具只需要在每个slave节点上启动一个进程,再mesos-exporter监控配置到prometheus server的监控目标中就可以获取到相关的数据。架构如下:
在Prometheus的面板上我们可以看到Prometheus的监控对象可以为mesos-export,也可以为cAdvisor。
下面为Prometheus的展示界面:
采集工具的对比
cAdvisor 可以采集本机以及容器的资源监控数据,如CPU、 memory、filesystem and network usage statistics)。还可以展示Docker的信息及主机上已下载的镜像情况。因为cAdvisor默认是将数据缓存在内存中,在显示界面上只能显示1分钟左右的趋势,所以历史的数据还是不能看到,但它也提供不同的持久化存储后端,比如influxdb等。
Heapster的前提是使用cAdvisor采集每个node上主机和容器资源的使用情况,再将所有node上的数据进行聚合,这样不仅可以看到整个Kubernetes集群的资源情况,还可以分别查看每个node/namespace及每个node/namespace下pod的资源情况。这样就可以从cluster,node,pod的各个层面提供详细的资源使用情况。默认也是存储在内存中,也提供不同的持久化存储后端,比如influxdb等。
mesos-exporter的特点是可以采集 task 的监控数据。mesos在资源调度时是在每个slave上启动task executor,这些task executor可以是容器,也可以不是容器。而mesos-exporter则可以从task的角度来了解资源的使用情况,而不是一个一个没有关联关系的容器。
以上从几个典型的架构上介绍了一些监控,但都不是最优实践。需要根据生产环境的特点结合每个监控产品的优势来达到监控的目的。比如Grafana的图表展示能力强,但是没有告警的功能,那么可以结合Prometheus在数据处理能力改善数据分析的展示。下面列了一些监控产品,但并不是严格按表格进行分类,比如Prometheus和Zabbix都有采集,展示,告警的功能。都可以了解一下,各取所长。
http://www.dockerinfo.net/1718.html
相关推荐
针对分布式系统的APM(应用性能监控)系统,特别针对微服务、cloud native和容器化(Docker, Kubernetes, Mesos)架构, 其核心是个分布式追踪系统。
随着微服务架构的兴起,容器化技术如Docker及其相关的集群管理工具(如Mesos、Kubernetes等)得到了广泛应用。这些技术为应用部署提供了极大的灵活性,同时也带来了新的挑战,特别是在监控方面。本文将详细介绍如何...
incubator-skywalking, 分布式跟踪系统和 APM ( 应用性能监控) SkyWalking | 中文 为分布式系统,云原生和基于容器的( Docker,Kubernetes,Mesos ) 体系结构设计的 SkyWalking ( 应用程序性能监视器) 工具,为...
8. **Mesos监控和日志管理**:了解如何利用Mesos的监控工具和日志收集机制,对集群进行性能监控和问题排查,是管理和优化Mesos集群的关键。 9. **Mesos与大数据处理**:Mesos与Apache Hadoop、Spark等大数据处理...
Prometheus 应该是为数不多的适合 Docker、Mesos、Kubernetes 环境的监控系统之一。 二、Prometheus 优势 易于管理: Prometheus核心部分只有一个单独的二进制文件,不存在任何的第三方依赖(数据库,缓存等等); ...
编织范围-Docker和Kubernetes的故障排除和监控 Weave Scope会自动生成您的应用程序图,使您能够直观地理解,监视和控制基于容器的,基于微服务的应用程序。 实时了解您的Docker容器 选择您的容器基础架构的概述,...
Kubernetes的普及也带动了其他相关技术的发展,例如Docker Swarm和Apache Mesos等,它们提供了与Kubernetes类似或互补的容器管理解决方案。Kubernetes的生态非常丰富,为用户提供灵活的选择,满足各种不同的需求。...
标题中的“docker_heapster.tar.gz”是一个针对Docker容器监控工具Heapster的压缩包文件,其版本标识为“canary”。在软件开发中,“canary”通常指的是非正式发布的、用于测试新功能或修复的早期版本,它允许开发者...
### 从OpenStack到Kubernetes:云平台日志监控的新挑战 #### 一、引言 随着云计算技术的发展,从传统的虚拟化管理平台OpenStack到更先进的容器编排平台Kubernetes,云基础设施经历了显著的变化。这些变化不仅影响...
SkyWalking 是一款强大的开源性能监控系统,专门针对微服务、云原生以及基于容器的环境如 Docker、Kubernetes 和 Mesos 设计。该系统不仅能够监控应用指标,还具有分布式追踪功能,与其他如 Zipkin、Pinpoint 和 CAT...
SkyWalking :一个APM(应用程序性能监视器)系统,专门为微服务,云原生和基于容器(Docker,Kubernetes,Mesos)的体系结构而设计。 抽象 SkyWalking是一个开源APM系统,包括对Cloud Native体系结构中的分布式...
除了Kubernetes,还有其他一些容器编排工具,如Docker Swarm、Apache Mesos以及HashiCorp的Nomad。每种工具都有其特定的功能和优势,选择哪一个取决于具体的业务需求和环境。了解这些工具的工作原理和最佳实践是...
5. 容器技术在构建PaaS平台方面的优势:容器技术如Docker、Mesos和Kubernetes在构建PaaS平台方面的优势体现在能够标准化高可用、监控运维等方面,打破应用与平台的耦合状态。 6. 国内外企业对容器技术的应用:不仅...
3. **容器编排**:结合 Kubernetes 或 Docker Swarm,Mesos 提供了一种高效的容器编排解决方案。 五、未来展望 随着云计算和大数据技术的发展,Mesos 的重要性日益凸显。Apache Mesos 1.4.3 版本不仅提升了性能和...
Gilbert Song,一位Apache Mesos项目管理委员会成员和Mesosphere的分布式系统工程师,分享了他对云计算和分布式系统的热情,并通过演讲内容为我们揭示了从单体架构到微服务架构的转变,以及Mesos在这一过程中扮演的...