编者按:随着互联网业务的迅速发展,用户对系统的要求也越来越高,而做好监控为系统保驾护航,能有效提高系统的可靠性、可用性及用户体验。监控系统是整个运维环节乃至整个项目及产品生命周期中最重要的一环。百分点大数据技术团队基于大数据平台项目,完成了百亿流量、约3000+台服务器集群规模的大数据平台服务的监控,沉淀了一套适合自身业务和技术特点的监控架构设计思路、设计方法和落地方案。
本文主要从监控系统整体设计和技术方案落地两大部分阐述了大数据监控平台的建设过程,旨在帮助大家了解监控系统设计思路,对于监控系统建设提供专业指导。
一、整体设计
在整体监控设计中,百分点科技大数据团队采用“去中心化”、“服务透明化”的设计思路,同时具备极强的扩展能力、自动化能力和高可靠性设计思路。
去中心化设计:由于要同时监控18个异地的数据中心,开始百分点科技大数据团队考虑过18个中心各自监控,但是整体性差、不直观且维护成本高。综合考虑了链路带宽、监控工具性能和数据量多维度指标,百分点科技大数据团队决定只在一个主中心建立从监控数据采集到数据可视化的能力,其它中心只是监控数据的输送者,最终形成“1 Server+18 Slaves”覆盖18个数据中心的监控框架。
服务透明化设计:通过将每个组件的存储、处理、查询能力标准量化,保证稳定可控。具体来说,对每个组件容量、每项性能指标阈值进行设计,并将组件的能力指标和当前的状态以可视化的形式展现,通过标准值建立预警机制和对应处理措施,过程对于用户是无感知的。
扩展及自动化能力设计:接入一个数据中心的监控数据并完成监控指标的调试,在0.5天即可完成,而且此设计能够无缝集成多个数据中心的监控数据。
监控设计方法
评价一个监控系统的好坏最重要三要素是:监控粒度、监控指标完整性、监控实时性,从系统分层体系可以把监控系统分为三个层次:
业务层:业务系统本质目的是为了达成业务目标,因此监控业务系统是否正常最有效的方式是从数据上监控业务目标是否达成。对业务运营数据进行监控,可及时发现程序bug或业务逻辑设计缺陷,比如数据趋势、流量大小等。业务系统的多样性决定了应由各个业务系统实现监控指标开发。
平台层:对应用的整体运行状况进行了解、把控,如果将应用当成黑盒子,开发和运维就无从知晓应用当前状态,不能及时发现潜在故障。应用监控不应局限于业务系统,还包括各种中间件和计算引擎,如ClickHouse、ElasticSearch、redis、zookeeper、kafka等。常用监控数据:JVM堆内存、GC、CPU使用率、线程数、TPS、吞吐量等,一般通过抽象出的统一指标收集组件,收集应用级指标。
系统层:实时掌握服务器工作状态,留意性能、内存消耗、容量和整体系统健康状态,保证服务器稳定运行。监控指标:内存、磁盘、CPU、网络流量、系统进程等系统级性能指标。
在重要监控指标项章节,我们将详细介绍每一层级组件的监控指标含义和阈值等。
系统设计
工欲善其事必先利其器,根据对一些监控产品的调研以及对监控的分层介绍、所需解决的问题,可以发现监控系统从收集到分析的流程架构:采集-存储-分析-展示-告警。
数据采集: 通过SNMP、Agent、ICMP、SSH、IPMI等协议对系统进行数据采集。
数据存储:主要存储在MySQL上,也可以存储在其他数据库服务。
数据分析:当事后需要复盘分析故障时,监控系统能给我们提供图形和时间等相关信息,方面确定故障所在。
数据展示: Web界面展示(移动APP、java_php开发一个web界面也可以)。
监控报警:电话报警、邮件报警、微信报警、短信报警、报警升级机制等(无论什么报警都可以)。
报警处理:当接收到报警,我们需要根据故障的级别进行处理,比如:重要紧急、重要不紧急等。根据故障的级别,配合相关的人员进行快速处理。
在整个监控方案需求中整理了基础组件、大数据组件共12个,每种组件又包含多个监控指标项,约519项。为便于查看过去90天的监控历史数据,全部采集的监控数据周期保存90天,90天的数据量在800G左右,每项指标根据其特性采集频率分为15s、30s。基于监控需求的分析结果,百分点大数据团队从源数据采集,存储并针对性的做了数据清洗、分析等开发工作,最后汇总展示到监控平台中提供告警和预警的功能,监控平台提供非常炫酷的页面展示还可投放到大屏上。
二、技术方案
1.技术架构
监控技术方案通过实时数据采集、实时数据处理可视化和高可用技术等,实现了多种大数据平台组件的性能指标的监控。监控系统由Zabbix、Prometheus + Grafana这两部分构成。Zabbix 负责服务器的硬件监控,Prometheus+Grafana负责集群状态的监控。
Zabbix通过分布式主动监控方式,对服务器进行硬件监控,Zabbix Agent通过向Zabbix Proxy请求获取监控项列表来定期发送采集到的新值给Zabbix Proxy,Proxy将多个监控设备的信息先缓存到本地,然后传输到所属的Zabbix Server。
Prometheus通过集成各类Exporter来采集组件指标,如上图所示,通过Node Exporter、Clickhouse Exporter等第三方Exporter来实现对应组件的数据采集,同时通过Jmx Exporter来实现对Oss Tomcat、HBase、业务系统、数据流的数据采集工作,并将其数据存储在本地时间序列数据库中。
Grafana通过接口调用和指标编辑来读取Prometheus所采集的数据进行可视化展示。
2.技术选型
(1)Zabbix
Zabbix是一个基于Web界面提供分布式系统监视以及网络监视功能的企业级开源解决方案,它能监视各种网络参数,保证服务器系统的安全运营,并提供柔软的通知机制以让系统管理员快速定位/解决存在的各种问题,是企业自动化运维监控的利器。Zabbix灵活的设计为用户提供了易用的二次开发接口,让用户既可以使用Zabbix本身提供的功能,又可以自定义更多的监控项功能,如硬件监控、操作系统、服务进程,以及网络设备等。值得一提的是,它所提供的Proxy分布式架构能够在监控多个远程区域设备的同时,分担server的监控压力且不增加系统的维护复杂度,为项目实施提供便利。
高可用设计图中提到,Zabbix通过Proxy收集项目中所有服务器的硬件监控指标数据并进行预警和展示,通过Ansible批量在服务器端安装Zabbix Agent 并启动,由客户端主动发起请求向Zabbix Server进行注册,自动完成服务器在Zabbix Web的配置工作。
(2)Prometheus
Prometheus是由前Google员工2015年正式发布的开源监控系统,采用Go语言开发,它不仅有一个很酷的名字,同时还有Google与K8s的强力支持,开源社区异常火爆,在2016年加入云原生基金会,是继K8s后托管的第二个项目,未来前景被相当看好。数据采集基于Pull模式,架构简单,不依赖外部存储,单个服务器节点可直接工作,二进制文件启动即可,属于轻量级的Server,便于迁移和维护。同时其监控数据直接存储在Prometheus Server本地的时序数据库中,单个实例可以处理数百万的Metrics。Prometheus灵活的数据模型和强大的数据查询语句能够在对服务内部进行详细状态监控的同时还支持数据的内部查询,帮助快速定位和诊断问题,非常适用于面向服务架构的监控。
在技术架构中,每个Prometheus负责拉取该区域所有组件的指标数据并存储在本地,通过Prometheus UI界面可以查询该区域所需指标是否收集到数据、数据是否正常,从而判断数据采集端数据收集状态。
(3)Grafana
Grafana是一个可视化仪表盘,通过整合每个区域Prometheus所采集的数据实现对该区域的集群监控目的,并将其美观、直接地展示给使用者。通过Grafana的Datasource链接Prometheus url,并对接入的数据进行分组、过滤、聚合等逻辑运算来达到在面板中直观展示指标含义的目的。
3.非功能技术实现
在大型的IT架构环境中,系统的组成部分跨区域分布在18个不同城市,跨节点、多IDC、业务类型复杂、业务需求多样,因此监控系统要能满足业务中不断变化的需求。在这种环境中构建监控系统,首先要做的事情是掌握全局信息,同时需要考虑业务未来的发展趋势。而这个环境的监控技术方案既要能满足当前业务需求,又能满足不断增长的业务需求,因此技术方案需要考虑以下三个因素:高可用性、高吞吐性、可扩展性。
4.核心组件监控指标
三、最佳实践
在面临着巨大Zabbix的使用过程中,随着监控对象的增多,Zabbix Server面临非常大的压力,出现一系列性能瓶颈问题:
Zabbix队列中有太多达到30w+,被延迟的Item会长达10分钟左右;
带有nodata()函数的触发器出现告警;
由于数据展示量大,前端界面无响应或响应很慢。
为解决以上三个问题,主要从zabbix配置参数和数据库参数两方面进行性能调优,并给出一般建议供其他技术人员做参考。
1.最佳参数优化说明
(1)Zabbix配置参数调优
HistoryStorageDateIndex=1
# 初始化时启动的pollers进程数量。由于本次采用主动式,因此该参数可以调制最小
StartPollers=1
# 预处理进程
StartPreprocessors=40
StartPollersUnreachable=1
StartTrappers=15
# 启用ICMP协议Ping主机方式启动线程数量
StartPingers=1
# 用于设置自动发现的主机线程数量
StartDiscoverers=1
# 禁用zabbix自带的housekeeping策略
HousekeepingFrequency=0
# zabbix初始化时占用多少系统共享内存用于存储配置信息
CacheSize=2G
# 将采集数据从缓存同步到数据库的线程数量
StartDBSyncers=25
# 划分2G内存用于存储采集的历史数据
HistoryCacheSize=2G
# 存储历史数据索引所占用的大小
HistoryIndexCacheSize=256M
# 分配缓存趋势数据的内存
TrendCacheSize=256M
ValueCacheSize=2G
Timeout=10
AlertScriptsPath=/usr/lib/zabbix/alertscripts
ExternalScripts=/usr/lib/zabbix/externalscripts
FpingLocation=/usr/sbin/fping
LogSlowQueries=1000
2.硬件监控实践
通过Zabbix Agent向zabbix_agentd.conf 配置文件中的ServerActive 请求获取检查清单,Server 读取Zabbix Web中的硬件监控列表进行响应,Agent解析响应中Item Name,调用相应的参数开始定期收集数据。
注:$IPMI_IP 为IPMI的IP地址,1.3.6.1.4.1.674.10892.5.5.1.20.130.1.1.37.1为dell 服务器raid卡的snmpoid。
UserParameter=RAIDControllerStatus,/etc/zabbix/scripts/zabbix_agent_snmp.shRAIDControllerStatus
cat/etc/zabbix/scripts/zabbix_agent_snmp.sh
function get_RAIDControllerStatus(){
RAIDControllerStatusvalue=`snmpwalk -v 2c -c public $IPMI_IP1.3.6.1.4.1.674.10892.5.5.1.20.130.1.1.37.1 |awk -F ‘INTEGER: ‘ ‘{print $2}’`
}
3.平台组件集群监控实践
如下图所示是所有运行在系统上的程序的总体监控列表,其中不乏业务系统、数据流,也不乏ClickHouse、Ceph、ElasticSearch等集群。
结语与展望
百分点科技希望通过本篇文章的分享,帮助大家快速了解大规模机器集群下的监控设计架构思路,以及每个核心组件重要的监控指标项含义和阈值范围,提供最佳实践的优化参数,为大家在实施过程中提供一些参考。
关于配置文件、Json面板文件和更详细的过程信息等问题,欢迎您来咨询,大家一起探讨、共同进步。
