• CDH集群监控方案架构与实现(一)基础监控

    背景

    大数据集群的维护本身是充满挑战的,庞大的数据量、复杂的运算逻辑、关联的大数据组件、一个企业级的集群往往有PB 级的数据、成百上千和各式运算任务 在一套集群上运行。  所以运维如果想不是很被动的话,就必须做好各式监控,预防风险、发现风险、分析问题、进而针对性的处理问题。

    因为大数据集群一旦出问题,往往就已经很难处理了 ,所以监控要前置,有趋势预测、有风险评估、才行。

    针对这些,我们要从多个维度入手对大数据集群进行基础监控:

    如下,我们对整个集群的基础监控主要分为三大维度:

    1. 底层服务监控:服务器底层的CPU、内存、IO、磁盘 等;
    2. Hadoop性能监控:各式组件各维度性能监控
    3. Runtime 监控:自定义脚本轮训服务;

    11

    底层服务监控借助 Zabbix,这个很简单,不再详赘了。

    这里主要说下第二个维度: 组件性能监控。

    CDH 组件性能监控

    对 CDH 组件的性能监控,如上图,我们借助 Prometheus + AlertManager + Grafana 的架构方式。

    • 写一个 exporter ,从 Cloudera Manager 的 API 中取出各式组件的 Metrics 。
    • 借助 Alertmanager 对需要的 metrics 进行告警。
    • 写一个 钉钉告警API 供 Alertmanager 调用。
    • 将 Prometheus data source 接入 Grafana 做报表展示。

    这里具体的代码与实现细节,不展开了,否则太多,主要是将大概的思路和实现方式以及官网地址交待清楚:

    一、明确要获取的 Metrics

    首先我们要明确有哪些Metrics 可以供我们获取,或者说我们从哪里挑到 可以获取的 Metrics 列表。 这一步我们从 Cloudera Manager 官网可以看到:

    https://docs.cloudera.com/documentation/enterprise/5-15-x/topics/cm_metrics.html

    b

    这里有所有的 CM 组件相关 Metrics,我们随便点一个进去,可以看到 组件的 Metrics 详细信息,有描述,也有单位等:

    1

    如果我们对这些 Metrics 还不是很懂的话,其实可以借助 Cloudera Manager 的图表生成器:

    1

    如上,其实这些 Metric 从 CM 的图标生成器也可以查到,并且有自动匹配功能和中文释义,非常方便。

    二、Cloudera Manager 的 API 接口交互

    与 Cloudera Manager 的接口交互当然也是看官方文档:http://cloudera.github.io/cm_api/apidocs/v19/

    1

    API 对应的官方文档里面有大量的接口调用方式,包括一些动作、状态、Metrics 获取等。这里我们暂时只关注 Metrics 获取,我们会发现,官方文档中所有的 Metrics 获取都建议我们走时序型接口:

    2

    如上,所有关于角色的 Metrics 建议我们走 时序型 API 去获取:

    3

    最简单的一个 Python 代码调用示例如下:

    得到的结果如下:

    如上,就可以获取到对应 Metrics 相关值 。

    三、自己写 Exporter 从 Cloudera Manager 获取 Metrics 数据

    这里用 Python 写一个 Exporter ,获取数据,因为涉及到的 Metrics 很多,所以采取多线程并发的方式去获取。

    这里主要借助 Python的这个库:https://github.com/prometheus/client_python#instrumenting

    1

    这个 Python 包里有大量 prometheus exporter client 方式,可以参考使用。

    这块的代码就不再这里详细赘述了,总体来说,开 30个线程并发,取 几百个 Item,最终入Prometheus 的时候大概 几万个 Metric ,总共需要约 8 s 多。

    四、搭建配置 AlertManager ,并实现自定义钉钉告警接口

    数据入到 Prometheus 之后,我们当然要去设置针对一些Metrics 的告警阈值,这里借助和Prometheus 的告警插件 AlertManager,AlertManager 的安装很简单,这里不再详赘,之前的 Prometheus初探 一文中已经说过,这里主要说下配置相关:

    关于相关配置可以参考官方文档:https://prometheus.io/docs/alerting/configuration/

    如上,我们在 AlertManager 中加了这些配置,它的配置总体来说主要是包括 routes 告警转发路由,receiver 告警接收器,inhibit_rule 告警收敛规则 等。

    如上,我们默认将报警都发给了我们自己实现的一个  http://10.25.x.x:5000/ding_alert  webhook,其实是用 Python 写的一个钉钉告警接收器。

    五、Flask 钉钉告警网关

    正如上面所说,我们自己实现一个简单的钉钉告警接收器,用 Flask 实现,可以让 AlertManager 通过 5000 端口调用发送钉钉告警,这里主要是要注意处理发送与接收格式:

    相关代码简要如下:

    六、Prometheus 中配置 AlertManager ,并添加配置告警项

    前面的准备好之后,我们还需要配置 Prometheus 告诉它哪些需要告警,并且把AlertManager 加进去:

    先是 Prometheus 的主配置文件:

    监控项我们放在单独的 rules 目录的文件下:

    七、Grafana 接入 Prometheus

    其实前六步昨晚之后,数据就已经入到我们的 Prometheus 了,可以在Prometheus 上查到:

    1

    如上图,我们点击 Graph ,然后输入 Metrics 名称或正则匹配就可以查到,点击 图片中间的 Graph还可以看到图形。

    当然,我们配置的 Alert 也是可以在这里看到的:

    2

    甚至我们可以像 Zabbix一样看到告警相关的 Reports:

    1

    当然最重要的是也能收到相关的钉钉告警:

    4

    但是单纯的收到告警信息不行,我们需要一个炫酷的,有维度的监控展示。  Grafana 是很好的选择,我们只需要将 Prometheus 作为 Datasource 纳入 Grafana,即可构建丰富的报表展示:

    4

     

    总结

    至此,我们就完成了我们的基础监控部分。 可以随着各式各样的需求逐步完善收集 Metrics 即可。 既有告警信息、又有丰富的图形展示,而且很灵活,方便调配。

    但这只是基础监控,距离我们掌控运维好集群还有很大的距离,后续还要继续补充几个维度:

    • 元数据监控。
    • 业务运行日志与任务状态监控。
    • 定时统计报表发送等。

    其实每个维度想要做好都很难,会在后续的时间过程中持续更新此系列博客。