摘要
本文以开源项目Ganglia为例,介绍多集群环境下,利用监控系统进行故障诊断、性能瓶颈分析的一般方法。
回顾
通过前面的发布过的两篇文章,我们已经大致掌握了描述单个服务器的性能情况的方法。可以从load avgerage等总括性的数据着手,获得系统资源利用率(CPU、内存、I/O、网络)和进程运行情况的整体概念。参考CPU使用率和I/O等待时间等具体的数字,从而自顶向下快速排查各进程状态。也可以在60秒内,通过运行以下10个基本命令,判断是否存在异常、评估饱和度,度量请求队列长度等等。
在真实的工程实践中,并不能总是通过几行简单的命令,直接获得性能问题的答案。一般不会存在一台单独运行的服务器,它们一定属于某个服务集群之中,就算是同一集群的服务器,也可能属于不同建设周期、硬件配置不同、分工角色不同。或者由不同机房、不通集群的服务器共同协作完成任务。
另外,很多性能问题也需要长时间的追踪、对比才能作出判断。正如任何一个高明的医生,都需要尽可能多地了解、记录病人的病史,不掌握这些情况,盲目下药,无异于庸医杀人。诚如医者曰:
1 | 夫经方之难精,由来尚矣。今病有内同而外异,亦有内异而外, |
基于 Ganglia 项目我们可以快速搭建一套高性能的监控系统,展开故障诊断分析、资源扩容预算甚至故障预测。
Ganglia框架简析
一般应用中,需要用到两个核心组件:
Gmond (Ganglia Monitoring Daemon)
Gmond承担双重角色:1、作为Agent,部署在所有需要监控的服务器上。
2、作为收发机,接收或转发数据包。
Gmetad (Ganglia Meta Daemon)
负责收集所在集群的数据,并持久化到RRD数据库。根据集群的组网情况,可以部署1-N个。
Web frontend
Ganglia项目提供一个PHP编写的通用型的Web包,主要实现数据可视化,能提供一些简单的数据筛选UI。页面不多,大量使用了模版技术。HTTP Server方面,用Apache和Nginx都可以。
RRDTool (Round Robin Database)
Gmetad收集的时间序列数据都通过RRD存储,RRDTool作为绘图引擎使用。
插件生态
Ganglia最重要的特性之一就是提供了一个灵活的数据标准和插件API。
它使得我们可以根据系统的情况,很容易地在默认的监控指标集之上,引用或定制其他扩展指标。
这一特性在大数据领域也获得了认可,Hadoop,Spark等都开放了面向Ganglia的指标集。
在Github上也有很多现成的扩展插件。
Ganglia工作模式
项目的名称其实已经反映了作者的设计思路。
Ganglia(又作:ganglion),直译为“神经节”、“中枢神经”。在解剖学上是一个生物组织丛集,通常是神经细胞体的集合。在神经学中,神经节主要是由核周体和附随连结的树突组合而成。神经节经常与其他神经节相互连接以形成一个复杂的神经节系统。神经节提供了身体内不同神经体系之间的依靠点和中介连结,例如周围神经系统和中枢神经系统。
Ganglia的作者意图将服务器集群理解为生物神经系统,每台服务器都是独立工作神经节,通过多层次树突结构连接起来,
既可以横向联合,也可以从低向高,逐层传递信息。具体例证就是Ganglia的收集数据工作可以工作在单播(unicast)或多播(multicast)模式下,
默认为多播模式。
单播:Gmond收集到的监控数据发送到特定的一台或几台机器上,可以跨网段
多播:Gmond收集到的监控数据发送到同一网段内所有的机器上,同时收集同一网段内的所有机器发送过来的监控数据。
因为是以广播包的形式发送,因此需要同一网段内。但同一网段内,又可以定义不同的发送通道。
vi /usr/local/ganglia/etc/gmond.conf
默认配置:
1 | cluster { |
单播模式Gmetad增加配置:
1 | udp_recv_channel { |
单播模式Gmond增加配置:
1 | udp_send_channel { |
默认装载指标集:
1 | modules { |
vi /usr/local/ganglia/etc/gmetad.conf
1 | ### 配置数据源,可以多个 |
查看数据流向
1 | # netstat -an | grep 86 |
Gmetad所在位置,已经可以收到监控数据的服务器列表:
1 | # telnet localhost 8649 | grep HOST |
Gmond所在位置,收到的监控指标数据明细:
1 | # telnet localhost 8649 | grep cpu_idle |
数据可视化
扩展阅读
1 | 没有任何一个开源项目是完美的。 |
1、告警流程框架:Ganglia本身并不具备,可以选用 Nagios 补充。
https://www.ibm.com/developerworks/library/l-ganglia-nagios-1/
https://www.quora.com/Ganglia-vs-collectd-vs-cacti-advantage-and-disadvantage
2、日志管理框架:Ganglia本身并不具备,可以选用 Splunk 补充。
3、性能开销预算
对于单纯的Gmond节点来说,性能开销很低。主要的瓶颈在中央节点。
各节点的gmond进程向中央节点发送的udp数据带来的网络开销。如果一个节点每秒发10个包,
1000个节点将会发出10000个,每个包有200字节,就有2m字节,10000个包的处理所需要的cpu使用也会上升。
Gmetad默认15秒向gmond取一次xml数据,解析xml文件带来的CPU负荷也会随着管理节点数线性增长。
格外需要注意的是RRD的写入瓶颈。实际应用中需要根据资源情况,调整采样频率、权衡指标数量、引入RRDCached等方式优化。
4、网络流向监控:Ganglia原生支持sFlow
GitHub:gmond-proxy project。what are some of the benefits of using the proxy?
Firstly, the proxy allows metrics to be filtered, reducing the amount of data logged and increasing the scaleability of the Ganglia collector.
Secondly, sFlow-RT generates traffic flow metrics, making them available to Ganglia.
Finally, Ganglia is typically used in conjunction with additional monitoring tools that can all be driven using the analytics stream generated by sFlow-RT.
5、可视化
Ganglia Develop Team
- Matt Massie:UCB
- Brent Chun:Developer,UCB
- David E. Culler:Professor
读者讨论区
- 隔壁_老吴 :多播如何跨网段?因为单播需要在服务器端添加所有agent IP,上百台不现实
扩展阅读:开源架构技术漫谈
- DevOps 漫谈:基于OpenCensus构建分布式跟踪系统
- 基于Go语言快速构建一个RESTful API服务
- 基于Kafka构建事件溯源型微服务
- 远程通信协议:从 CORBA 到 gRPC
- 应用程序开发中的日志管理(Go语言描述)
- 数据可视化(七)Graphite 体系结构详解
- 动态追踪技术(一):DTrace 导论
- 动态追踪技术(二):strace+gdb 溯源 Nginx 内存溢出异常
- 动态追踪技术(三):Tracing Your Kernel Function!
- 动态追踪技术(四):基于 Linux bcc/BPF 实现 Go 程序动态追踪
- 动态追踪技术(五):Welcome DTrace for Linux
- DevOps 资讯 | LinkedIn 开源 Kafka Monitor