实战ganglia分布式的监控系统(2)——集成nagios报告Ganglia指标

简介:

本次实验紧接上次实验,ganglia节点需要开启,且已经安装Nagios,Nagios安装可参考我前面关于nagios的博客:实战Nagios网络监控(1)——监控本机运行状态和Mysq主机

注:ganglia与nagios可以部署在不同的主机


主机nagios状态如下:

wKioL1gSp9KAHjdHAAKfKFi_oNU988.png

主机ganglia状态如下:


server1

wKioL1gSqk7iFdV3AAEd9BZdVhA356.png

server2

wKioL1gSqnKTTPl0AAERibGH19U241.png



        nagios监控远程主机的方式为nagios+nrpe,而ganglia可以使用客户端daemon(Ganglia Monitoring Daemon(gmond))监控远程主机,本次实验为server1上只装有nagios,server1和server2上没有装nrpe服务,服务端server1无法获取server2的主机资源。添加ganglia服务,ganglia集群资源中有server1和server2服务。利用server1上的nagios集成ganglia服务从而让server1上的nagios监控远程主机server2上的资源。


1.ganglia配置

[root@server1 html]# cp /root/ganglia-3.4.0/contrib/check_ganglia.py   /usr/local/nagios/libexec/

[root@server1 html]# cd /usr/local/nagios/libexec/

[root@server1 libexec]# chown nagios.nagios check_ganglia.py 

    注:check_ganglia.py 命令仅在阈值过高时发出警告。如果希望在阈值过低时发出警告(在disk_free 中是这样),则需要修改代码。我更改了文件的最后部分,如下所示:

[root@server1 libexec]# vim check_ganglia.py 


89 if critical > warning:

 90   if value >= critical:

 91     print "CHECKGANGLIA CRITICAL: %s is %.2f" % (metric, value)

 92     sys.exit(2)

 93   elif value >= warning:

 94     print "CHECKGANGLIA WARNING: %s is %.2f" % (metric, value)

 95     sys.exit(1)

 96   else:

 97     print "CHECKGANGLIA OK: %s is %.2f" % (metric, value)

 98     sys.exit(0)

 99 else:

100   if critical > value:

101     print "CHECKGANGLIA CRITICAL: %s is %.2f" % (metric, value)

102     sys.exit(2)

103   elif warning >= value:

104     print "CHECKGANGLIA WARNING: %s is %.2f" % (metric, value)

105     sys.exit(1)

106   else:

107     print "CHECKGANGLIA OK: %s is %.2f" % (metric, value)

108     sys.exit(0)


[root@server1 libexec]# /usr/local/nagios/libexec/check_ganglia.py -h server2.example.com -m disk_free -w 20 -c 10

CHECKGANGLIA CRITICAL: disk_free is 6.36


2.nagios配置

[root@server1 ~]# cd /usr/local/nagios/etc/objects/

[root@server1 objects]# vim commands.cfg 

添加如下内容:

# 'check_ganglia' command definition

                    define command {

                            command_name check_ganglia

                            command_line $USER1$/check_ganglia.py -h $HOSTNAME$ -m $ARG1$ -w                              $ARG2$ -c $ARG3$

                    }

[root@server1 objects]# vim templates.cfg 

添加如下内容:

define service {

use generic-service

name ganglia-service

hostgroup_name ganglia-servers

service_groups ganglia-metrics

}

[root@server1 objects]# vim hosts.cfg

添加如下内容:

define host{

        use                     linux-server       

        host_name               server2.example.com

        alias                   server2

        address                 172.25.254.2

        icon_image              switch.gif

        statusmap_image         switch.gd2

        2d_coords               400,100

        3d_coords               400,200,100

        }


define hostgroup {

        hostgroup_name ganglia-servers

        alias ganglia-servers

        members server2.example.com

}

[root@server1 objects]# vim services.cfg 

添加如下内容:

define servicegroup {

        servicegroup_name       ganglia-metrics

        alias                   Ganglia Metrics

}


define service{

        use                     ganglia-service

        service_description     根分区

        check_command           check_ganglia!disk_free_percent_rootfs!20!10

}


define service{

        use                     ganglia-service

        service_description     系统负载

        check_command           check_ganglia!load_one!4!5

}


define service{

        use                     ganglia-service

        service_description     内存空闲

        check_command           check_ganglia!mem_free!50000!30000

}

[root@server1 objects]# /etc/init.d/nagios restart


浏览器端刷新查看,servre2端的资源被监控:


wKiom1gSrNmx9bM-AAHWREVYg-g491.png


等一段时间,状态都变成了OK:



wKioL1gSrZSRqigmAAGxd3yq6O4346.png



本文转自willis_sun 51CTO博客,原文链接:http://blog.51cto.com/willis/1866634,如需转载请自行联系原作者

相关文章
|
5月前
|
人工智能 Kubernetes 数据可视化
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
本文回顾了一次关键词监测任务在容器集群中失效的全过程,分析了中转IP复用、调度节奏和异常处理等隐性风险,并提出通过解耦架构、动态IP分发和行为模拟优化采集策略,最终实现稳定高效的数据抓取与分析。
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
|
7月前
|
消息中间件 运维 Kafka
直播预告|Kafka+Flink双引擎实战:手把手带你搭建分布式实时分析平台!
在数字化转型中,企业亟需从海量数据中快速提取价值并转化为业务增长动力。5月15日19:00-21:00,阿里云三位技术专家将讲解Kafka与Flink的强强联合方案,帮助企业零门槛构建分布式实时分析平台。此组合广泛应用于实时风控、用户行为追踪等场景,具备高吞吐、弹性扩缩容及亚秒级响应优势。直播适合初学者、开发者和数据工程师,参与还有机会领取定制好礼!扫描海报二维码或点击链接预约直播:[https://developer.aliyun.com/live/255088](https://developer.aliyun.com/live/255088)
529 35
直播预告|Kafka+Flink双引擎实战:手把手带你搭建分布式实时分析平台!
|
7月前
|
Kubernetes 大数据 调度
Airflow vs Argo Workflows:分布式任务调度系统的“华山论剑”
本文对比了Apache Airflow与Argo Workflows两大分布式任务调度系统。两者均支持复杂的DAG任务编排、社区支持及任务调度功能,且具备优秀的用户界面。Airflow以Python为核心语言,适合数据科学家使用,拥有丰富的Operator库和云服务集成能力;而Argo Workflows基于Kubernetes设计,支持YAML和Python双语定义工作流,具备轻量化、高性能并发调度的优势,并通过Kubernetes的RBAC机制实现多用户隔离。在大数据和AI场景中,Airflow擅长结合云厂商服务,Argo则更适配Kubernetes生态下的深度集成。
859 34
|
7月前
|
消息中间件 运维 Kafka
直播预告|Kafka+Flink 双引擎实战:手把手带你搭建分布式实时分析平台!
直播预告|Kafka+Flink 双引擎实战:手把手带你搭建分布式实时分析平台!
225 12
|
2月前
|
存储 Prometheus 监控
136_生产监控:Prometheus集成 - 设置警报与指标选择与LLM部署监控最佳实践
在大语言模型(LLM)部署的生产环境中,有效的监控系统是确保服务稳定性、可靠性和性能的关键。随着LLM模型规模的不断扩大和应用场景的日益复杂,传统的监控手段已难以满足需求。Prometheus作为当前最流行的开源监控系统之一,凭借其强大的时序数据收集、查询和告警能力,已成为LLM部署监控的首选工具。
|
3月前
|
存储 算法 安全
“卧槽,系统又崩了!”——别慌,这也许是你看过最通俗易懂的分布式入门
本文深入解析分布式系统核心机制:数据分片与冗余副本实现扩展与高可用,租约、多数派及Gossip协议保障一致性与容错。探讨节点故障、网络延迟等挑战,揭示CFT/BFT容错原理,剖析规模与性能关系,为构建可靠分布式系统提供理论支撑。
219 2
|
9月前
|
数据采集 存储 数据可视化
分布式爬虫框架Scrapy-Redis实战指南
本文介绍如何使用Scrapy-Redis构建分布式爬虫系统,采集携程平台上热门城市的酒店价格与评价信息。通过代理IP、Cookie和User-Agent设置规避反爬策略,实现高效数据抓取。结合价格动态趋势分析,助力酒店业优化市场策略、提升服务质量。技术架构涵盖Scrapy-Redis核心调度、代理中间件及数据解析存储,提供完整的技术路线图与代码示例。
883 0
分布式爬虫框架Scrapy-Redis实战指南
|
3月前
|
机器学习/深度学习 算法 安全
新型电力系统下多分布式电源接入配电网承载力评估方法研究(Matlab代码实现)
新型电力系统下多分布式电源接入配电网承载力评估方法研究(Matlab代码实现)
127 3
|
5月前
|
数据采集 缓存 NoSQL
分布式新闻数据采集系统的同步效率优化实战
本文介绍了一个针对高频新闻站点的分布式爬虫系统优化方案。通过引入异步任务机制、本地缓存池、Redis pipeline 批量写入及身份池策略,系统采集效率提升近两倍,数据同步延迟显著降低,实现了分钟级热点追踪能力,为实时舆情监控与分析提供了高效、稳定的数据支持。
166 1
分布式新闻数据采集系统的同步效率优化实战
|
6月前
|
缓存 NoSQL 算法
高并发秒杀系统实战(Redis+Lua分布式锁防超卖与库存扣减优化)
秒杀系统面临瞬时高并发、资源竞争和数据一致性挑战。传统方案如数据库锁或应用层锁存在性能瓶颈或分布式问题,而基于Redis的分布式锁与Lua脚本原子操作成为高效解决方案。通过Redis的`SETNX`实现分布式锁,结合Lua脚本完成库存扣减,确保操作原子性并大幅提升性能(QPS从120提升至8,200)。此外,分段库存策略、多级限流及服务降级机制进一步优化系统稳定性。最佳实践包括分层防控、黄金扣减法则与容灾设计,强调根据业务特性灵活组合技术手段以应对高并发场景。
1595 7

热门文章

最新文章