百分点大数据技术团队：万亿级大数据监控平台建设实践

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

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

整体设计

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

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

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

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

监控设计方法

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

业务层：业务系统本质目的是为了达成业务目标，因此监控业务系统是否正常最有效的方式是从数据上监控业务目标是否达成。对业务运营数据进行监控，可及时发现程序 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。基于监控需求的分析结果，百分点大数据团队从源数据采集，存储并针对性的做了数据清洗、分析等开发工作，最后汇总展示到监控平台中提供告警和预警的功能，监控平台提供非常炫酷的页面展示还可投放到大屏上。

技术方案

技术架构

监控技术方案通过实时数据采集、实时数据处理可视化和高可用技术等，实现了多种大数据平台组件的性能指标的监控。监控系统由 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 来采集数据，直接从社区网站下载启动即可，通过指标筛选和聚合，最终效果图如下所示：

结语与展望

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

关于配置文件、Json 面板文件和更详细的过程信息等问题，欢迎您来咨询，大家一起探讨、共同进步。

本文转载自：百分点（ID：baifendian_com）

原文链接：百分点大数据技术团队：万亿级大数据监控平台建设实践