技术方案

2.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.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,并对接入的数据进行分组、过滤、聚合等逻辑运算来达到在面板中直观展示指标含义的目的。

2.3非功能技术实现

在大型的IT架构环境中,系统的组成部分跨区域分布在18个不同城市,跨节点、多IDC、业务类型复杂、业务需求多样,因此监控系统要能满足业务中不断变化的需求。在这种环境中构建监控系统,首先要做的事情是掌握全局信息,同时需要考虑业务未来的发展趋势。而这个环境的监控技术方案既要能满足当前业务需求,又能满足不断增长的业务需求,因此技术方案需要考虑以下三个因素:高可用性、高吞吐性、可扩展性。

(1)高可用性

基础架构使用LAMP环境,采用Keepalived实现Zabbix、Grafana服务器高可用,保证主Server的Mysql或者httpd宕掉后能切换到从Server。同时数据库做主主同步,保证两边服务器数据的一致性,实现数据库的高可用,Zabbix和Grafan数据库选用的磁盘类型均为Raid5,保证在一块盘离线的情况下保证数据的正常访问。下图为Zabbix高可用分布式架构流程。

(2)高吞吐性

Zabbix、Grafana及Prometheus联合监控3000+台服务器,实现从硬件层到应用层共计23万+Items、17万+Triggers的全方位监控,每秒更新2.43+万条数据,每天共计产生1.1T+数据量。

(3)可扩展性

Zabbix Proxy可以代替Zabbix Server 收集性能和可用性数据,然后将数据汇报给 Zabbix Server,并且在一定程度上分担了Zabbix Server 压力的同时,不增加监控系统的维护复杂度。

每个Prometheus负责收集一个地区所有服务器服务的运行时状态数据,Grafana则通过插件调用API接口来对数据进行可视化展示。下图为Ansible批量安装Proxy节点代码:

2.4核心组件监控指标

做好一款监控系统,其中最重要的一项是服务的监控项和每个监控项对应的多个指标,需要明白它的具体含义,设定好其阈值,阈值的准确性决定了监控系统的质量。

Zabbix通过ICMP ping、磁盘、风扇、内存、电源、主板温度、CPU温度、电压、Raid状态、电池、网卡等方面对服务器进行硬件监控,同时通过对组件的进程监控来实现应用程序的存活状态检测。

Grafana+Prometheus主要负责业务系统、CK、ES、Ceph、Oss、Kafka、ZK、数据流等服务或组件的状态监控。

(1)ElasticSearch监控项

ES监控主要针对两个级别,分别是集群级别和节点级别。集群级别的监控主要是针对整个ES集群来说,包括集群的健康状况、集群的状态等。节点级别的监控主要是针对每个ES实例的监控,其中包括每个实例的查询索引指标和物理资源使用指标。集群级别指标获取ES集群的运行状态;节点级别指标则更多的用于问题的排查,当发现集群出现问题时更可能多的时候会直接定位到具体的ES实例,通过查看单台实例的资源使用情况或者其他指标进行问题排查。

(2)ClickHouse监控项

通过慢查询、拒绝写入、QPS、读写压力、Http & Tcp 连接数、Zookeeper状态等各项监控指标实时的反映出用户最原始的读写请求及ClickHouse 集群的读写性能。

(3)Kafka监控项

当Kafka集群出现异常时,Kafka Controller的存活状态、副本Leader的选举延迟时间、Follower和Leader的同步消息长度、Broker端关键JMX指标等监控指标结合历史状态数据能够帮助快速定位和分析问题。

(4)Ceph监控项

当Ceph集群信息状态异常时,需要通过查看集群细节来判断出现故障的集群节点。因此Ceph集群主要从以下几个方面进行监控:集群状态、OSD状态、集群容量、OSD利用率、延迟数量、恢复进度、Objects状态。

(5)HBase监控项

HBase采集的监控数据主要包括以下几个方面:所有Regionserver、Master机器 JVM的状态,例如关于线程的信息,GC 的次数和时间,内存使用状况,ERROR、WARN、Fatal事件出现的次数,以及Regionserver、Master进程中的统计信息。

(6)Zookeeper监控项

Zookeeper主要从系统监控、Zookeeper节点这两个方面进行监控,系统监控包含内存使用量,网路带宽占用,磁盘使用量等;Zookeeper节点包含节点活跃数、延时时间、收发包数、连接数、临时节点数量等方面。

最佳实践

在面临着巨大Zabbix的使用过程中,随着监控对象的增多,Zabbix Server面临非常大的压力,出现一系列性能瓶颈问题:

  • Zabbix队列中有太多达到30w+,被延迟的Item会长达10分钟左右;
  • 带有nodata()函数的触发器出现告警;
  • 由于数据展示量大,前端界面无响应或响应很慢。
  • 为解决以上三个问题,主要从zabbix配置参数和数据库参数两方面进行性能调优,并给出一般建议供其他技术人员做参考。下面为Zabbix 队列积压图:

    3.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)数据库参数调优

  • 遵从MySQL性能调优说明。
  • 对于MySQL,使用InnoDB表结构。如果使用InnoDB,ZABBIX的运行速度至少要快1.5倍。
  • 对常用表进行数据库表分区并执行定期清理策略,常用表:‘history’,‘history_str’,‘items’,‘functions’,‘triggers','trends’。
  • (3)性能优化一般建议

  • 仅监控所需参数;
  • 调整所有项目的“更新间隔”;
  • 调整默认模板的参数;
  • 调整housekeeping参数;
  • 避免使用长期给出的触发器作为函数参数,例如,max(3600)的计算速度明显比max(60)慢。
  • zabbix性能调优前后的对比效果如下所示:

    性能调优前

    性能调优后

    3.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}'`

    }

    通过Zabbix Agent收集到的硬件监控指标数据如下图所示:

    虽然Zabbix能通过Zabbix Agent对每台服务器的硬件情况进行监控并及时报警,但是对整个项目的某个区域的情况没有很好的汇总展示和反馈,因此百分点大数据团队将Prometheus与Grafana结合,实现对当前区域所有服务器所有磁盘空间、内存使用率的降序排序来实现该需求。

    Grafana中根目录下磁盘使用率的metric指标如下:

    node_filesystem_size_bytes{IP_Range="$IP_Range",fstype="xfs",mountpoint="/"}-node_filesystem_free_bytes{IP_Range="$IP_Range",fstype="xfs",mountpoint="/"}

    1-(node_filesystem_free_bytes{IP_Range="$IP_Range",fstype="xfs",mountpoint="/"}/node_filesystem_size_bytes{IP_Range="$IP_Range",fstype="xfs",mountpoint="/"})

    实际效果如下图所示:

    为了快速定位和解决问题,除对整个项目所有服务器常用指标有整体的概览和了解外,只对每台服务器的硬件层有详细的监控是不够的,仍需对它的系统层运行情况有大体且直观的了解。如下图所示是单台服务器系统层的运行情况展示:

    3.3平台组件集群监控实践

    如下图所示是所有运行在系统上的程序的总体监控列表,其中不乏业务系统、数据流,也不乏ClickHouse、Ceph、ElasticSearch等集群。

    (1)ElasticSearch集群监控

    通过ES数据采集程序将每个ES集群的监控数据汇总到ES监控集群中,Grafana接入ES监控集群链接进行展示。

    采集端部分代码如下:

    效果图如下所示:

    (2)ClickHouse集群监控

    ClickHouse数据采集由两部分组成:①Prometheus主动拉取Ck_exporter所采集的数据;②Pushgateway将自定义指标推入Prometheus。

    Pushgateway自定义指标部分展示如下:

    最终展示效果图:

    (3)Kafka集群监控

    通过Kafka集群中的JMX来解析Kafka部分监控指标,开放Kafka的JMX端口,在./bin/kafka-server-start.sh中插入如下内容,位置如下图所示,同时将jar和yml文件放入相应位置并重启Kafka集群。

    JMX监控效果图如下所示:

    (4)Ceph集群监控

    单个Ceph Exporter可以对整个Ceph集群的数据进行采集,而为了防止单点故障,故在此处做了Ceph exporter的高可用。Ceph Exporter从社区网站直接下载并启动,通过Promtheus拉取Ceph Exporter中的数据并进行分组、汇总等运算呈现如下效果图:

    (5)Hbase集群监控

    由于HBase是集成在Ambari中,因此需要在Ambari Web界面开启HMaster和HRegionServer的jmx端口进行展示。在HBase-env.sh配置文件中插入如下内容:

    HBase效果图如下所示:

    (6)Zookeeper集群监控

    Prometheus通过接入Zookeeper的第三方工具zk_exporter来采集数据,直接从社区网站下载启动即可,通过指标筛选和聚合,最终效果图如下所示:

    结语与展望

    百分点科技希望通过本篇文章的分享,帮助大家快速了解大规模机器集群下的监控设计架构思路,以及每个核心组件重要的监控指标项含义和阈值范围,提供最佳实践的优化参数,为大家在实施过程中提供一些参考。

    本博客文章除特别声明,全部都是原创!
    原创文章版权归过往记忆大数据(过往记忆)所有,未经许可不得转载。
    本文链接: 【万亿级大数据监控平台建设实践】(https://www.iteblog.com/archives/10039.html)
    喜欢 (4)
    分享 (0)
    发表我的评论
    取消评论

    表情
    本博客评论系统带有自动识别垃圾评论功能,请写一些有意义的评论,谢谢!