万亿级大数据监控平台建设实践

文章目录

1 整体设计
- 1.1 1.1监控设计方法
- 1.2 1.2 系统设计
2 技术方案
3 最佳实践
4 结语与展望

导语：随着互联网业务的迅速发展，用户对系统的要求也越来越高，而做好监控为系统保驾护航，能有效提高系统的可靠性、可用性及用户体验。监控系统是整个运维环节乃至整个项目及产品生命周期中最重要的一环。百分点大数据技术团队基于大数据平台项目，完成了百亿流量、约3000+台服务器集群规模的大数据平台服务的监控，沉淀了一套适合自身业务和技术特点的监控架构设计思路、设计方法和落地方案。

本文主要从监控系统整体设计和技术方案落地两大部分阐述了大数据监控平台的建设过程，旨在帮助大家了解监控系统设计思路，对于监控系统建设提供专业指导。

整体设计

在整体监控设计中，百分点大数据团队采用“去中心化”、“服务透明化”的设计思路，同时具备极强的扩展能力、自动化能力和高可靠性设计思路。

去中心化设计：由于要同时监控18个异地的数据中心，开始百分点大数据团队考虑过18个中心各自监控，但是整体性差、不直观且维护成本高。综合考虑了链路带宽、监控工具性能和数据量多维度指标，百分点大数据团队决定只在一个主中心建立从监控数据采集到数据可视化的能力，其它中心只是监控数据的输送者，最终形成“1 Server+18 Slaves”覆盖18个数据中心的监控框架。

服务透明化设计：通过将每个组件的存储、处理、查询能力标准量化，保证稳定可控。具体来说，对每个组件容量、每项性能指标阈值进行设计，并将组件的能力指标和当前的状态以可视化的形式展现，通过标准值建立预警机制和对应处理措施，过程对于用户是无感知的。

扩展及自动化能力设计：接入一个数据中心的监控数据并完成监控指标的调试，在0.5天即可完成，而且此设计能够无缝集成多个数据中心的监控数据。

1.1监控设计方法

评价一个监控系统的好坏最重要三要素是：监控粒度、监控指标完整性、监控实时性，从系统分层体系可以把监控系统分为三个层次：

业务层：业务系统本质目的是为了达成业务目标，因此监控业务系统是否正常最有效的方式是从数据上监控业务目标是否达成。对业务运营数据进行监控，可及时发现程序bug或业务逻辑设计缺陷，比如数据趋势、流量大小等。业务系统的多样性决定了应由各个业务系统实现监控指标开发。

平台层：对应用的整体运行状况进行了解、把控，如果将应用当成黑盒子，开发和运维就无从知晓应用当前状态，不能及时发现潜在故障。应用监控不应局限于业务系统，还包括各种中间件和计算引擎，如ClickHouse、ElasticSearch、redis、zookeeper、kafka等。常用监控数据：JVM堆内存、GC、CPU使用率、线程数、TPS、吞吐量等，一般通过抽象出的统一指标收集组件，收集应用级指标。

系统层：实时掌握服务器工作状态，留意性能、内存消耗、容量和整体系统健康状态，保证服务器稳定运行。监控指标：内存、磁盘、CPU、网络流量、系统进程等系统级性能指标。

在重要监控指标项章节，我们将详细介绍每一层级组件的监控指标含义和阈值等。

1.2 系统设计

工欲善其事必先利其器，根据对一些监控产品的调研以及对监控的分层介绍、所需解决的问题，可以发现监控系统从收集到分析的流程架构：采集－存储－分析－展示－告警。

数据采集: 通过SNMP、Agent、ICMP、SSH、IPMI等协议对系统进行数据采集。

数据存储：主要存储在MySQL上，也可以存储在其他数据库服务。

数据分析：当事后需要复盘分析故障时，监控系统能给我们提供图形和时间等相关信息，方面确定故障所在。

数据展示： Web界面展示(移动APP、java_php开发一个web界面也可以)。

监控报警：电话报警、邮件报警、微信报警、短信报警、报警升级机制等（无论什么报警都可以）。

报警处理：当接收到报警，我们需要根据故障的级别进行处理，比如：重要紧急、重要不紧急等。根据故障的级别，配合相关的人员进行快速处理。

在整个监控方案需求中整理了基础组件、大数据组件共12个，每种组件又包含多个监控指标项，约519项。为便于查看过去90天的监控历史数据，全部采集的监控数据周期保存90天，90天的数据量在800G左右，每项指标根据其特性采集频率分为15s、30s。基于监控需求的分析结果，百分点大数据团队从源数据采集，存储并针对性的做了数据清洗、分析等开发工作，最后汇总展示到监控平台中提供告警和预警的功能，监控平台提供非常炫酷的页面展示还可投放到大屏上。

技术方案

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="/"})

实际效果如下图所示：