• Ganglia 原理


    原理

    Ganglia 项目是由加州大学发起的,现在已经成为一个应用非常广泛集群监控软件。可以监视和显示集群中的节点的各种状态信息,比如如:cpu 、mem、硬盘利用率, I/O负载、网络流量情况等,同时可以将历史数据以曲线方式通过php页面呈现。同时具有很好的扩展性,允许用户加入自己所要监控的状态信息。


    2.1      ganglia工作原理

    Ganglia:分布式监控系统 - 星星 - 银河里的星星

                                                                                  图 1  Ganglia整体结构图

    Ganglia 包括如下几个程序,他们之间通过XDL(xml的压缩格式)或者XML格式传递监控数据,达到监控效果。集群内的节点,通过运行gmond收集发布节点状 态信息,然后gmetad周期性的轮询gmond收集到的信息,然后存入rrd数据库,通过web服务器可以对其进行查询展示。

    Gmetad 这个程序负责周期性的到各个datasource收集各个cluster的数据,并更新到rrd数据库中。 可以把它理解为服务端。

    Gmond 收集本机的监控数据,发送到其他机器上,收集其他机器的监控数据,gmond之间通过udp通信,传递文件格式为xdl。收集的数据供Gmetad读取,默认监听端口8649 ,监听到gmetad请求后发送xml格式的文件。可以把它理解为客户端。

    web front-end 一个基于web的监控界面,通常和Gmetad安装在同一个节点上(还需确认是否可以不在一个节点上,因为php的配置文件中ms可配置gmetad的地址及端口),它从Gmetad取数据,并且读取rrd数据库,生成图片,显示出来。

     如上图所示,gmetad周期性的去gmond节点或者gmetad节点poll数据。一个gmetad可以设置多个datasource,每个datasource可以有多个备份,一个失败还可以去其他host取数据。

     如 果是muticast模式的话,gmond之间还会通过多播来相互传递数据。Gmond本身具有udp send和recv通道,还有一个tcp recv通道。其中udp通道用于向其他gmond节点发送或接受数据,tcp则用来export xml文件,主要接受来自gmetad的请求。Gmetad只有tcp通道,一方面他向datasource发送请求,另一方面会使用一个tcp端口,发 布自身收集的xml文件,默认使用8651端口。所以gmetad即可以从gmond也可以从其他的gmetad得到xml数据。

     Gmond节点内部模块图如下所示:

    Ganglia:分布式监控系统 - 星星 - 银河里的星星

                                                                             图 2  Gmond节点模块结构图

    如 上图所示,主要由三个模块组成,collect and publish模块,该模块周期性的调用一些内部指令获得metric data,然后将这些数据通过udp通道发布给其他gmond节点。Listen Threads,监听其他gmond节点的发送的udp数据,然后将数据存放到内存中。XML export thread负责将数据以xml格式发布出去,比如交给gmetad。

     下面重点介绍下unicast模式下ganglia系统内的数据流。

    Ganglia:分布式监控系统 - 星星 - 银河里的星星

                                                                图 3单播状况下集群节点间的数据流

    如 上图所示,多个gmond节点通过udp向单播的目标host的gmond发送数据,gmetad然后向该目标host的gmond请求xml文件,然后 存入rrdtool数据库。 在unicast模式中,图中方框内的组件通常是位于集群内的同一个节点。该节点负责收集存储 显示被监控的各节点的状态信息。

    2.2      自定义metrics

    向ganglia加入自定义metric有两种方法,一种是通过命令行的方式运行gmetric,另一种是通过ganglia提供的面向c和python的扩展模块,加入自定义的模块支持。


    2.3      优点及可能存在的问题
    2.3.1     优点

    n  自动收集数据

    集 群内各个节点的信息收集可以通过ganglia系统自动的收集起来,这个收集是独立进行地。其通信性能都是经过良好设计和优化的。具体的机制是:周期性的 将这些信息发送给gmond,这样信息就加入了ganglia监控系统。通过ganglia的监控机制完成监控数据的收集显示的功能。Ganglia系统 的机制可以参考2.1ganglia工作原理。

    n  图形界面

    数据可以通过图形显示出来。通过登录web服务器即可查看。目前可以通过该视图查看集群及单独节点的状态曲线。同时具有基本的排序机制,可以根据值降序或者升序排序。可以查看过去1小时 1天 1周 1年等时间段的状态曲线。

    n  数据库rrdtool存储了历史数据

    由 于采用了rrd存储数据,这样我们不单可以查看当前的状态,还可以查看之前的状态历史,同时可以将metrics随时间的变化以曲线的方式变现表现出来。 而单独的向文件写日志很难保存和方便地查看之前的历史记录。而且有可能使得日志文件很大。RRDtool具有如下优点:

    1)除了存储数据之外,它具有可以创建图形的工具;

    2)它的数据库文件大小是固定的,新的数据添加到已有数据的后面,当到了文件末尾的时候就开始从文件开始写数据,Round Robin就是指这个意思;

    3)一般的数据库只能存储数据本身,而rrd可以存储相对与以前的数据的变动

    4)一般的数据库是在提供数据的时候才更新,而RRD是在每一个预先设好的时间间隔都会更新,每次更新的时候,time stamp也会存储进去

     
    2.3.2     可能存在的问题及瓶颈

    n  开销估计:网络 IO CPU

    只 运行gmond进程的节点开销很小,通常需要1m左右内存,cpu大概1%不到,同时gmond只把数据保存在内存中,因此io开销可以忽略。同时向其他 节点单播本身的信息本身的网络压力也不会很大。因此对于只运行gmond的节点来说,开销很小。 如果采用了unicast模式,主要的开销就会在各节点 的gmond进程向中央节点发送的udp数据带来的网络开销,此外gmond和gmetad的通信,web服务也在该中央节点上进行。这样主要的瓶颈就在 中央节点上,其网络 IO CPU的压力都会很大。

    对于网络来说,中央节点将收到来自其他所有节点发送的udp包,如果一个节点每秒发10个包,500个节点将会发出5000个,每个包有200字节,就有1m字节,5000个包的处理所需要的cpu使用也会上升。 

    对于内存来说每个状态信息存储在内存大概要耗费300byte,如果一个job有10万个instance,每个instance又有10个状态需要监控,那么将耗费10000*10*300=30m的内存,其对应的xml文件大小也应该是10m级别的。

    对 于IO来说,Gmetad默认15秒向gmond取一次xml数据,如果gmond和gmetad都是在同一个节点,这样就相当于本地io请求。同时 gmetad请求完xml文件后,还需要对其解析,也就是说按默认设置每15秒需要解析一个10m级别的xml文件,这样cpu的压力就会很大。同时它还 有写入RRD数据库,还要处理来自web客户端的解析请求,也会读RRD数据库。这样本身的IO CPU 网络压力就很大,因此这个节点至少应该是个空闲的而且能力比较强的节点。

    n  Gmetad RRD写入瓶颈

    需 要格外注意的是gmetad守护进程使用RRDtool,会在/var/lib/ganglia/rrds/目录下的一个子目录存储这些rrd数据信息, 如果集群节点超过100个,你可能应将这个目录放在RAM文件系统上,因为这个数据库的磁盘I/O将会非常高。由于RRD特有的存储方式,它会为每个 metric存放一个文件,如果配置了多个采样频率,它还会为每个采样频率保存一个单独的文件。这就意味着gmetad将metric的值保存到rrd数 据库的操作,将是针对大量小文件的IO,假设集群有300个节点,每个节点有50个metric,那么意味着gmetad会记录15000个 metric,如果这些metric都是一秒更新一次,那么意味着每秒15000的随机写入操作,通常来说硬盘都是撑不住的。

    一 个可能的解决方法就是将集群内的节点划分为多个子集,为每个子集配置一个中央收集节点。但这样会带来部署和结果查看的不方便性。另外可以通过 RRDcached来缓解这个gmetad使用RRDTool的问题大量随机写入,它会缓存这些写入,批量进行更新。此外就是降低metric的采样频 率,减少metrics的数目,尽量减少这种写入请求量。如果机器具有多块磁盘,尽量利用多个磁盘来保存RRD数据。还有就是使用上面我们所说的将rrd 目录加载为tmpfs。

    n  使用的服务及端口以及依赖的库

    Ganglia 的gmond进程使用了udp进行单播,默认端口8649,同时还有负责tcp监控的端口8651 8652 8650也会被使用,这些端口需要在集群内部打开,这些使用的端口可以进行配置。另外apache也需要一个端口提供服务,这个端口会被从外部访问,默认 是80。

    n  同一个host的不同进程的相同Metirc可能混淆

    由 于ganglia本身是根据host+metric_name来区分不同的状态参数的,也就是它无法区分同一host内的不同进程相同的名称的状态变量。 但是对于单纯的一个状态量,虽然可能是多个进程的状态,但对它来说只能看到一个名称,所以当多个进程同时向它报告具有同一个名称的状态的value时,它 无法区分出进程间的不同。如果要区分它们,就需要加入一个命名机制区分它们。

    程 序运行完毕,该程序对应的自定义的那些metric不会消失,这意味着虽然程序运行结束,但我们依然可以查看其历史记录。但另一方面这样也会带来新的问 题,由于我们采用的针对metric的命名机制,会导致metric积累到很多,这样会导致xml变得越来越大,增加中央节点解析该文件时的压力,也不方 面查阅。目前有一个可行的方法就是修改gmetad的配置文件,减少数据的保存时间的设置。

     
    2.3.3     运行需要做的部署工作

    基于ganglia的监控运行时,需要各个客户端安装gangliang的客户端gmond。收集数据的那个节点还需要安装ganglia的服务端gmetad,为了可以从web显示结果,还需要安装http服务器。安装这些还有很多依赖软件。具体参见1环境安装配置。

     
    3         高级扩展


    3.1      直接读取xml文件
     

    除 了使用ganglia内置的网页页面外,也可以自行得到xml文件去进行自己的分析。通常需要自己编写一个脚本来完成该任务。通过直接telnet gmond或者gmetad的tcp服务监听端口,可以直接得到xml文件,然后我们就可以对该xml文件进行需要的处理了。在单播模式下,应该 telnet那个gmond的中央节点,登录该节点才能得到集群内所有节点的信息,否则只能得到单独节点的信息。

    4         参考文献

    The ganglia distributed monitoring system-design  implementation

    Wide Area Cluster Monitoring with Ganglia

    http://sourceforge.net/apps/trac/ganglia/wiki/Ganglia%203.1.x%20Installation%20and%20Configuration

     

    转自:http://duanple.blog.163.com/blog/static/70971767201183092413177/

     

  • 相关阅读:
    天平天国和诗,和远方,和苟且
    ui设计师做好这几点,产品经理准闭嘴
    谈谈个人视觉创意的学习经验
    保持觉知
    第37周本人进步点
    扒一扒万恶的导航网站
    16年第四本《简单的逻辑学》
    hey,开通个人公众号啦!
    今朝有酒今朝醉,也是一种理性-附个人心得
    元素的定位
  • 原文地址:https://www.cnblogs.com/MorZe/p/2619382.html
Copyright © 2020-2023  润新知