★ FEATURED ARTICLE 1. 为什么要给Flume加监控核心需求拆解1.1 Flume的特殊地位不显眼但非常致命在这个系列前面的文章里我们把Flume的Source、Channel、Sink三大件都聊了个遍配置了一个又一个数据采集Agent把业务日志从应用服务器搬到了HDFS或者Kafka里。但只要你真正在生产环境跑过一段时间Flume你就会发现一个扎心的事实Flume本身是个非常闷的组件。它不像应用服务那样有接口压力、慢查询、异常堆栈这些明显信号也不像HDFS那样有NameNode Web UI可以直观看到集群状态。Flume的Agent进程挂掉之前往往没有任何预兆——大多数时候就是某一天下游数仓的同事跑过来问你怎么今天的用户行为日志少了一大截你这才发现采集服务器上的Agent进程不知道什么时候悄悄退出了或者Source还在拉数据但Sink写不进去了Channel里的数据积压到JVM OOM整个Agent直接崩掉。说句难听的Flume是数据管道里最容易无声死亡的环节。它上游是各种业务日志源源不断地产生下游是批处理任务固定时间拉起计算中间这个Agent一旦出问题数据不会重新生成时间窗口错过了就是永久丢失。这就是必须给Flume上监控的最核心原因。1.2 监控要回答的核心问题清单准备搭建Flume监控之前先想清楚监控到底要回答哪些问题。不是简单地挂了给我告警就行一套合格的Flume监控至少要在下面几个维度给出答案进程存活与资源维度。Agent进程是否在运行JVM的堆内存、GC频率是否正常所在服务器的CPU、磁盘IO、网络带宽是否成为瓶颈这是最基础的一层。吞吐量维度。每个Source每秒接收了多少条事件每个Sink每秒成功写出多少条事件与历史同时段相比有没有明显下降这个数字往往是最早暴露问题的信号。Channel水位维度。Channel里面的队列积压了多少数据占Channel总容量的百分比是多少这个指标可以理解成下水道的水位传感器——水位持续走高说明下游排水不畅即将漫出来。事务成功与失败维度。Flume的事务提交次数、回滚次数、事件写入失败次数。不要等数据丢了才追查失败计数持续增长时就必须介入。1.3 为什么监控方案最终落在Ganglia上给Flume上监控可选的方案其实不少。后来我们团队也做过一次选型讨论最后确定用Ganglia主要原因是Flume的原生代码里自带了对Ganglia上报协议的支持不需要在Flume Agent上额外安装任何插件更不需要为了监控去改业务配置和埋点逻辑。对于当时那个已经跑了好几个采集任务的非标准化环境来说改动面小、风险可控是最重要的。另外一点Ganglia是分布式监控系统天然适合Flume这种多Agent分散部署的形态。一台采集服务器部署三四个不同Agent做不同日志的采集任务一台机甚至一个机架上几十个Agent要统一看板监控Ganglia的多集群聚合能力非常顺手。2. 方案选型Ganglia与主流监控方案对比2.1 Flume自身带的那点监控能力Flume并不是完全裸奔的它的监控API是开放出来的提供了HTTP和Ganglia两种内置上报插件。所谓HTTP方式就是Flume启动时开启一个端口把各种监控指标以JSON格式暴露出来你通过HTTP请求去拉取这些数据。配置方式是在启动脚本里加一行参数-Dflume.monitoring.typehttp -Dflume.monitoring.port3456启动后用curl和jq看指标会有类似这个结构的数据curl -s http://localhost:3456/metrics | python -m json.tool这种方式对快速验证某个Agent状态是够用的但说实话非常原始。第一它没有一个可视化的历史趋势图你看到的永远只是一瞬间的数值快照第二你得自己写定时任务去轮询采集这些接口还要自己存历史数据不然数据一直在内存里刷新转瞬即逝第三当Agent数量多起来以后每台机器、每个Agent都要分别去curl非常繁琐。HTTP方式适合单机调试和临时验证不适合运营一个真正需要长期监控的生产集群。这也是后面我们坚持要上集中式监控的驱动力。2.2 Ganglia、Prometheus、Zabbix怎么选当时我们内部争论过到底是用Ganglia还是Prometheus全家桶。这里我把几个方案的优劣梳理一下因为现在很多人一上来就提Prometheus实际上对老集群来说未必是最优选关键要看你的环境约束和运维习惯。Prometheus Grafana是当前很流行的一套方案优势是生态好、查询语法灵活PromQL、告警规则强大、图表美观。缺点是部署组件比较多需要一个专门的Prometheus服务端节点较多时还要考虑VictoriaMetrics这类兼容层做存储扩展运维成本并不低。Zabbix在传统企业运维里部署很广但它更侧重主机层面的监控对Flume这种应用级的Metrics上报需要自己去写监控模板和脚本和Flume内置上报机制的集成度没有Ganglia高。Ganglia最突出的特色在于Flume内置直接支持往Ganglia的gmond节点上报数据几乎零集成成本Ganglia的RRD存储天然适配长时间趋势查看适合看最近一周、一个月这种粗粒度变化它在很多大数据发行版里默认就是基础组件很多Hadoop集群本身就装有Ganglia在这个基调上扩展Flume监控非常自然。当然Ganglia的短板也很明显告警能力很弱几乎只能做到阈值报警比Prometheus的Alertmanager差得远图表偏老气没有Grafana好看后端是RRD单机文件存储规模化到上万台节点时需要调优。所以最终的判断是如果你的集群里已经有Ganglia基础设施或者你对部署改动要求比较小、以看趋势为主Ganglia就是Flume监控的最优解。如果是从零建设一套完整可观测体系并且团队精力允许那么上Prometheus是长期更优的选择。这篇系列既然讲的是Ganglia那就把这条路线做到位。2.3 Ganglia的架构gmond、gmetad、RRD与Web前端怎么分工Ganglia的架构可以用一句话概括每个被监控节点上跑一个gmond负责收集和上报本机指标一个中心节点跑gmetad负责从各节点的gmond拉取数据并存入RRD数据库最后由Web前端读取RRD画出曲线图。具体拆开来看**gmondGanglia Monitoring Daemon**是部署在每一个需要监控的主机上的轻量级守护进程。它会采集CPU、内存、磁盘、网络这类操作系统层面的基础指标也能通过统一的协议接收应用层主动上报的自定义指标。gmond之间的数据交换默认走UDP协议可以组播也可以在节点之间单播传输。Flume上报监控数据时实际对接的就是本机或同网段内的gmond。**gmetadGanglia Meta Daemon**通常部署在一台独立的监控服务器上。它轮询各个gmond节点或gmond集群的聚合端口把拿到的指标写入RRD文件。RRD是Round-Robin Database一种固定大小环形数据库按时间周期聚合并存储历史数据磁盘占用非常稳定这也是Ganglia能常年累积监控数据而不爆磁盘的原因。ganglia-web是一个PHP编写的Web应用运行在Apache或Nginx后面读取gmetad写出的RRD文件渲染成监控大屏和图表页。整条链路跑通之后你在浏览器上就能看到类似于Hadoop集群所有节点CPU使用率仪表盘这种效果而Flume各Agent的上报指标也混在里面以flume前缀的Metric名出现。理解这套架构很重要因为后面排障的时候问题可能出现在任何一层——Flume侧的上报配置错了、gmond的端口不通、gmetad的信任列表没加、Web前端的权限不对都会导致图表出不来。先有全局认知后面排查才不至于瞎子摸象。3. Ganglia部署全流程从服务端到Flume接入3.1 环境规划与版本说明先交代一下我当时部署的软件环境你可以按自己的集群做类比。操作系统是主流的Linux发行版JDK用的是服务商标准化的1.8版本Flume是1.9.0这是目前生产环境里比较常见的一组组合。Ganglia当时用的是3.7.2版本它的安装包里已经包含了gmetad、gmond和web前端三部分组件安装方式用的是各发行版自带的包管理器没有走源码编译。需要特别提醒的是Ganglia的Web前端对Apache和PHP的版本组合有一定要求PHP 5.x和7.x都支持但8.x刚出来的时候兼容性有些坑。如果看到PHP版本较新建议先查一下官方文档的兼容列表或者直接锁定一个确认能跑起来的版本组合。我在实际部署时就吃过亏一开始用的是系统源里最新的PHP 8.0装了最新版ganglia-web结果页面白屏查了半天日志发现是PHP 8里废弃了一些老函数导致的。为了让你对这套东西的目录有个整体认知我把自己当时整理的部署规划表列出来供参考组件部署位置职责说明gmond所有Flume Agent所在主机 监控服务器采集主机指标接收Flume上报的自定义指标gmetad监控服务器独立节点轮询gmond聚合指标写入RRDganglia-web监控服务器与gmetad同居Web展示读取RRD渲染图表Flume Agent各日志采集主机修改启动脚本通过Ganglia协议上报指标3.2 gmetad和gmond的安装配置安装过程并不复杂核心在于把架构理清楚。先看监控服务器这边需要安装gmetad和gmond。使用系统包管理器装好之后配置文件分别在/etc/ganglia/gmetad.conf和/etc/ganglia/gmond.conf。gmetad.conf配置如下data_source flume-cluster 10 localhost gridname company-data rrd_rootdir /var/lib/ganglia/rrds case_sensitive_hostnames 0简单解释一下每个参数的含义。data_source是gmetad监听的数据源列表双引号里的flume-cluster是自定义的集群名称后面的10是轮询间隔秒数localhost表示数据源在本机此时gmond也跑在监控服务器上如果gmond分布在其他机器就写那台机器的IP。gridname是网格名称可以理解成更上一层的逻辑分组多个集群可以归到一个网格下面统一展示。rrd_rootdir指定了RRD数据文件的存放路径这个目录如果不存在gmetad启动时会自动创建但你最好手动建好并确认权限。gmond.conf最关键的几个配置段cluster { name flume-cluster owner 数据平台组 latlong unspecified url unspecified } udp_send_channel { mcast_join 239.2.11.71 host localhost port 8649 ttl 1 } udp_recv_channel { mcast_join 239.2.11.71 port 8649 bind 0.0.0.0 } tcp_accept_channel { port 8649 }注意两点。第一gmond.conf里的cluster.name必须和gmetad.conf里的data_source名字保持一致这样才能正确对接到同一个集群下。第二udp_send_channel中如果指定了mcast_join就是走组播模式要求所有节点在同一个二层网络里如果网络环境不允许组播很多云环境的二层隔离是做死了的就把mcast_join注释掉改为直接指定host为gmetad所在机器的IP也就是改用单播模式。生产环境强烈建议直接用单播模式省去一堆组播路由的排障时间。配置完成后在监控服务器上依次启动gmond和gmetadsystemctl start gmond systemctl start gmetad systemctl enable gmond systemctl enable gmetad3.3 部署ganglia-web前端ganglia-web可以走包管理器安装也可以用官方源码包解压到Web目录。我当时直接用系统源里的版本装完后再检查一下Apache配置中是否包含了ganglia的别名配置。通常在/etc/httpd/conf.d/下会有一个ganglia.conf文件内容类似这样Alias /ganglia /usr/share/ganglia Location /ganglia Require all granted /Location把这个配置文件放好重启Apache然后浏览器访问http://监控服务器IP/ganglia能看到Ganglia的界面就说明Web层已经通了。第一次打开的时候界面会比较朴素左边是集群列表中间是各节点的CPU负载曲线。启动完成之后在监控服务器本机的gmond已经上报了主机层面的指标这时候打开Web页面应该能看到监控服务器自己的CPU和内存曲线。如果这一层没有曲线别急着接Flume先排查清楚网络、端口、配置名这几个最容易出错的地方后面接Flume才会有参考基准。3.4 其他被监控节点安装gmond每台运行着Flume Agent的主机上都需要安装并启动gmond这是Flume上报指标所依赖的本地代理。安装方式和监控服务器上的gmond是一样的配置也几乎相同唯一要调整的是udp_send_channel里的目标地址指向监控服务器的IP。如果组播能用就保持默认单播模式下就把send channel改为如下形式udp_send_channel { host 10.10.0.22 port 8649 }配置完成后启动gmond过一两分钟打开Ganglia页面刷新一下集群节点列表新建的节点主机名应该出现在列表里并且能看到它的基础系统指标曲线。Graph的更新周期通常在一分钟到几分钟不等有点延迟是正常的。4. Flume接入Ganglia配置与运行细节4.1 修改Flume启动脚本接入监控前面铺垫了这么多现在到了实操的核心环节。让Flume往Ganglia上报监控指标不用改Agent本身的配置文件只需要在启动脚本中设置JVM系统属性。打开Flume安装目录下的conf/flume-env.sh在JAVA_OPTS变量中加入监控相关参数。JAVA_OPTS-Dflume.monitoring.typeganglia -Dflume.monitoring.hosts10.10.0.22:8649 -Dflume.monitoring.interval60这里的参数含义如下flume.monitoring.typeganglia告诉Flume使用Ganglia上报类型与之对应的是之前提过的http类型这两者只能选其一不然会冲突。flume.monitoring.hosts指定gmond监听端口所在的主机和端口格式是IP:8649。8649是Ganglia默认端口如果你的gmond改过端口就写自定义端口。注意这里可以写多个地址用逗号分隔Flume会轮流上报起到简单的冗余效果。flume.monitoring.interval设置监控指标的上报周期单位是秒。默认值如果是60秒其实已经够用。你可以调整到30秒让曲线更平滑但也会增加一点网络和gmond的负载生产环境60秒是一个相对稳妥的折中值。考虑到每个Agent的配置略有不同我在实际运维中习惯把监控参数单独抽出来当成环境变量维护或直接写入Agent的systemd管理文件里这样重启Agent时不会丢失配置。4.2 验证Flume上报数据的思路配置完成后重启Flume Agent。接着通过Ganglia的Web界面进入对应主机页面的Metric搜索框输入flume关键词应该能看到一条或多条以flume.开头的新指标曲线。常用指标大致有这些具体名称以你看到的实际上报为准Metric名称含义说明flume.SRC.source名.EventReceivedCountSource累计接收的事件总数flume.SRC.source名.EventAcceptedCountSource成功写入Channel的事件总数flume.CH.channel名.ChannelSizeChannel当前积压的事件数flume.CH.channel名.ChannelCapacityChannel总容量flume.CH.channel名.ChannelFillPercentageChannel已用容量百分比flume.SINK.sink名.EventDrainSuccessCountSink成功写出的事件总数flume.SINK.sink名.ConnectionFailedCountSink连接失败次数这些计数器是累计值需要结合上报间隔来算速率。比如查看EventDrainSuccessCount在一分钟内的增长量就能算出当前的写出速率TPS每秒事务数。Ganglia自带的图表就支持看趋势把时间范围拉长可以看出数据量是否有异常波动。如果你在Web页面上搜不到这些指标别着急大概率是Flume上报的数据没有被gmond接收。这种问题很常见因为gmond收到的自定义指标如果命名带特殊字符或者层级太多可能不会立刻被gmetad拉取。先确认gmond进程活着再用命令行工具gmetric手动发一条测试指标看看Web端能不能搜到。如果gmetric手动发能搜到说明gmond没问题问题出在Flume侧的配置或网络。4.3 一个容易漏掉的细节监控指标的图名和hostnameGanglia的Web页面展示节点时默认使用gmond上报的主机名来标识节点。如果主机名是带域名后缀的FQDN显示出来会很长页面布局会不太好看。如果主机名相同导致冲突多个节点会显示在一个曲线图里那监控数据的分类就乱了。解决方案是在gmond.conf里把host_dn属性关闭或用override_hostname强制指定一个短名称。例如globals { ... override_hostname log-node-01 }这个设置在所有Flume Agent所在机器的gmond.conf中都要统一维护好不然换个机房或者重装机器后主机名一变化历史曲线就和新数据断开了对排查昨天数据量和今天对比这类问题非常不便。5. 监控指标体系与常见问题排障实录5.1 读懂Flume监控指标从曲线判断健康状况Ganglia上的曲线都出来了接下来才是真正考验基本功的地方——从指标曲线上解读系统的健康状况。我总结了几类最常见的病相对应关系如下ChannelFillPercentage持续走高逼近80%以上。这说明Sink的下游写了一部分数据但没有完全跟上Source的接收速度积压数据步步逼近Channel容量上限。此时应该优先检查下游系统比如HDFS是不是在做安全模式Kafka是不是出现分区Leader不可用数据库是不是连接池打满。不要急着动Flume的配置下游恢复了积压自然会消除。EventReceivedCount和EventAcceptedCount出现明显差值。Source端接收了1000条但只有900条成功写进Channel说明Channel写入过程中有失败发生可能是Channel满导致事件被拒绝也可能是批量写入时事务回滚。这个差值往往出现在尖峰流量或者Channel被撑爆的时候。EventDrainSuccessCount曲线长时间水平无增长。Sink持续没有成功写出事件但Source可能还在不停接收说明数据正在Channel里越积越多。这种情况下首先要检查Sink连接的组件地址、端口、认证信息大概率是下游凭证过期或者磁盘空间爆了。5.2 排障实录监控图表出不来时的排查流程部署Ganglia监控后新人同事遇到最多的就是图表明明配了怎么还是没曲线这类问题。这里我把我实践中总结的排查顺序整理出来按这个顺序走命中率最高第一步查gmond进程状态。在Flume Agent所在主机上执行查看进程是否存在。gmond进程挂掉是常见现象很多发行版是独立init脚本而非systemd管理机器重启后不会自动拉起。第二步查8649端口连通性。在监控服务器上执行探测命令确认到Agent主机的8649端口网络是否通畅。很多云环境的防火墙策略默认只放行少数端口8649的UDP是容易被漏掉的那一个。注意gmond用的是UDP 8649和TCP 8649两种都要放行。第三步查gmetad指向的数据源是否有数据。在监控服务器上查看RRD目录是否有该Agent主机的数据文件产生或者直接在命令行执行gstat查看当前是否有节点在上报。如果RRD目录下根本没有对应的主机文件夹说明gmetad根本没有从gmond拉到任何数据问题出在gmetad到gmond这一层。第四步查Web前端权限。如果前面都通了但页面仍然不显示多半是Web对RRD目录的读权限不足或者Apache配置的路径不对。直接看一下Apache错误日志通常有很明确的提示。5.3 容易踩坑的几个细节与注意事项整理了几个实际运维中容易踩的坑很多都是文档里不会专门写的但遇到了会花掉不少排查时间。坑一gmetad的数据源配置里多个集群名的空格处理。data_source flume-cluster 10 localhost这个配置里集群名必须用双引号引起来不然gmetad解析时会按空格拆成多个字段导致集群名错乱。如果你的集群名里本身带了空格麻烦更大建议干脆不要用空格命名集群。坑二Flume进程的JAVA_OPTS配置覆盖。不同版本的Flume启动脚本JAVA_OPTS的赋值方式可能不一样。有些写JAVA_OPTS$JAVA_OPTS -D...是追加有些是直接等号覆盖。如果你在一个有多个启动参数的复杂环境里务必确认flume-env.sh里的JAVA_OPTS不是覆盖式的覆盖式会把原有的堆内存参数、GC参数全部清掉引发JVM配置问题。追加式的写法更安全。坑三指标里EventReceivedCount和EventDrainSuccessCount的基数差异。Flume从不同版本开始对EventDrainSuccessCount的统计口径有时会调整尤其是多路复用、扇出等复杂拓扑下Sink的计数可能不是严格对应Source的接收数。不要把这两个值直接拿来做等号判断而应该关注它们各自的速率变化趋势是否异常。坑四gmond上报周期和gmetad轮询周期的匹配。如果你把Flume的monitoring.interval改成30秒gmond的指标上报周期也要相应缩短否则gmetad轮询到的数据可能仍然是旧的。实际操作中改完Flume的采集中隔后建议同时查看gmond.conf里的cleanup_threshold和report_by_name配置确保过期的指标会被及时清理和覆盖。5.4 报警机制怎么补前面说过Ganglia的告警能力偏弱实际运行时不可能时刻盯着曲线看所以报警这一环必须另外补。运维实践中我们用的是两种方式组合一种是在Ganglia Web前端自带的报警规则里配置简单的阈值条件比如ChannelFillPercentage大于80持续一段时间就触发通知。Ganglia的阈值报警虽然朴素但胜在不用额外部署组件配置起来也简单。另一种是把Ganglia的数据通过gmetric主动推送到企业级的监控中心比如对接现有的Prometheus或自研运维平台。这个方案灵活性更高能够基于历史数据做同比、环比判断但对研发和运维投入的要求高一些。6. 实操总结从0到1完成Flume与Ganglia集成6.1 完整的操作流程速查清单按照从零开始的顺序整理一份速查清单方便你对照操作第1步监控服务器准备。安装gmetad、gmond、ganglia-web及Web依赖组件确认Apache能正常启动。第2步配置gmetad。编辑/etc/ganglia/gmetad.conf配置data_source确保集群名与后续gmond的cluster.name一致。第3步配置gmond。在监控服务器上编辑/etc/ganglia/gmond.conf确认udp_recv_channel监听了8649端口。第4步启动监控服务器上的gmond和gmetad。打开Web页面确认监控服务器自身的曲线已出现。第5步在所有Flume Agent所在主机上安装gmond。将udp_send_channel指向监控服务器IP或保持组播配置。第6步启动各主机上的gmond确认各主机出现在Ganglia节点列表里。第7步修改每台Agent的flume-env.sh加入JAVA_OPTS监控参数重启Flume进程。第8步打开Web页面搜索flume关键词确认各项指标曲线出现。对于规模较大的集群第5、6、7步的重复操作可以编写脚本批量执行把配置文件分发到各主机后再逐个启动。6.2 对这套方案的一些个人体会Ganglia上Flume监控这套组合我前后在多个项目环境里实践过。我个人的整体感觉是Ganglia的部署门槛是几个主流监控系统里最低的低到完全可以作为Flume监控方案的第一选择。它和Flume之间的数据链路很短Flume进程只要按约定往gmond丢指标剩下的路由、存储、展示都由Ganglia接管几乎不需要额外编码。但从长期演进的角度讲Ganglia的告警和查询分析能力偏弱当集群规模上了一定量级、监控诉求从看趋势逐渐升级为快速定位根因时往往需要叠加其他工具。这时候比较稳妥的路线是把Ganglia作为基础监控层保留再在它外面套一层专门针对Flume应用数据的可观测平台用轻量级的日志采集和链路追踪能力补充其短板。数据管道这个东西平时没人注意它出了问题往往就是大事故。监控的价值不在于你能画出多漂亮的仪表盘而在于你能否在上游数据还在源源不断产生的时候第一时间感知到下游已经悄悄堵住了。把Flume接入Ganglia只是第一步更重要的是养成每天打开监控页面看一眼曲线走势的习惯。曲线会告诉你数据管道正在经历什么及时干预大概率能把那些潜在的故障消灭在发生之前。
阅读完成 · 觉得有帮助？
