美文网首页DevTestOps开发测试运维监控
Open-falcon、Prometheus、Zabbix监控告

Open-falcon、Prometheus、Zabbix监控告

作者: Sunrise95 | 来源:发表于2019-08-12 11:45 被阅读0次

    选型背景

    这次采用开源监控系统主要是为了监控一些自定义业务并进行告警,所以重点关注了上传自定义数据、监控、显示、存储、告警四个方面,由于公司运维已经有监控机器指标的工具,所以监控机器指标这方面不是重点。

    各监控告警系统简介

    Zabbix

    官方文档:https://www.zabbix.com/documentation/3.4/zh/manual

    官方文档比较详细,中英文都有。

    后端用C开发,界面用PHP开发。

    图形化界面比较成熟,界面上基本能完成全部的配置操作。

    Prometheus

    官方文档:https://prometheus.io

    第三方中文文档:https://songjiayang.gitbooks.io/prometheus/content/introduction/what.html

    go语言开发,前端支持Grafana展示

    抓取数据是通过node_exporter插件,这些插件有官方的也有第三方的。引入插件的同时必须配置监控的指标。

    与其他监控框架显著的不同是支持灵活的查询语句(PromQL)

    在常用查询和统计方面,PromQL 比 MySQL 简单和丰富很多,而且查询性能也高不少。

    注意

    • Prometheus 的数据是基于时序的 float64 的值,如果你的数据值有更多类型,无法满足。
    • Prometheus 不适合做审计计费,因为它的数据是按一定时间采集的,关注的更多是系统的运行瞬时状态以及趋势,即使有少量数据没有采集也能容忍,但是审计计费需要记录每个请求,并且数据长期存储,这个 Prometheus 无法满足,可能需要采用专门的审计系统。
    openfalconarch.png

    open-Falcon

    官方文档:http://book.open-falcon.com/zh_0_2/dev/support_grafana.html

    后台是go语言开发,前端支持Grafana展示

    抓取数据通过脚本插件抓取日志或调用CLI,脚本组装数据发送给主服务端,配置是可选项,在脚本插件处进行配置。

    • 现在的策略表达式中只能配置一条规则,此处应该支持配置多条,任何一条触发,就要发报警,不同规则之间应该支持覆盖
    PrometheusPushData.png

    监控自定义指标

    prometheus

    Pushgateway是prometheus的一个重要组件,利用该组件可以实现自动以监控指标,从字面意思来看,该部件不是将数据push到prometheus,而是作为一个中间组件收集外部push来的数据指标,prometheus会定时从pushgateway上pull数据。

    img

    pushgateway并不是将Prometheus的pull改成了push,它只是允许用户向他推送指标信息,并记录。而Prometheus每次从 pushgateway拉取的数据并不是期间用户推送上来的所有数据,而是client端最后一次push上来的数据。因此需设置client端向pushgateway端push数据的时间小于等于prometheus去pull数据的时间,这样一来可以保证prometheus的数据是最新的。

    需要注意的点

    如果client一直没有推送新的指标到pushgateway,那么Prometheus获取到的数据是client最后一次push的数据,直到指标消失(默认5分钟)。
    Prometheus本身是不会存储指标的,但是为了防止pushgateway意外重启、工作异常等情况的发送,在pushgateway处允许指标暂存,参数--persistence.interval=5m,默认保存5分钟,5分钟后,本地存储的指标会删除。

    prometheus官方提供了Java工具类用来上传自定义指标到pushgateway

    特点

    1. prometheus默认采用pull模式,由于不在一个网络或者防火墙的问题,导致prometheus 无法拉取各个节点的数据。
    2. 监控业务数据时,需要将不同数据汇总,然后由prometheus统一收集

    缺陷

    1. 将多个节点数据汇总到 pushgateway, 如果 pushgateway 挂了,受影响比多个 target 大。

    2. Prometheus 拉取状态 up 只针对 pushgateway, 无法做到对每个节点有效。

    3. Pushgateway 可以持久化推送给它的所有监控数据。

    因此,即使你的监控已经下线,prometheus 还会拉取到旧的监控数据,需要手动清理 pushgateway 不要的数据。

    Open-falcon

    如果需要监控自定义指标,有两种方式

    1. 需要自己通过Http Push指标数据到Client的Agent组件提供的接口,再通过组件Agent上报数据到open-falcon主服务上的Transfer组件做一个汇总。
    2. 编写采集脚本,用什么语言写没关系,只要目标机器上有运行环境就行,脚本本身要有可执行权限。采集到数据之后直接打印到stdout即可,agent会截获并push给server。数据格式是json。

    官方推荐把采集脚本放到业务程序发布包中,随着业务代码上线而上线,随着业务代码升级而升级,这样会比较容易管理。

    Agent上传数据的间隔时间是可配置的。

    image-20190806143954300

    transfer是数据转发服务。它接收agent上报的数据,然后按照哈希规则进行数据分片、并将分片后的数据分别push给graph&judge等组件。

    Transfer接收数据时会做少量缓存,提供重试机制。

    自定义数据格式

    [
        {
            "endpoint": "test-endpoint",
            "metric": "test-metric",
            "timestamp": ts,
            "step": 60,
            "value": 1,
            "counterType": "GAUGE",
            "tags": "idc=lg,loc=beijing",
        }
    ]
    

    字段说明:

    • metric: 最核心的字段,代表这个采集项具体度量的是什么, 比如是cpu_idle呢,还是memory_free, 还是qps
    • endpoint: 标明Metric的主体(属主),比如metric是cpu_idle,那么Endpoint就表示这是哪台机器的cpu_idle
    • timestamp: 表示汇报该数据时的unix时间戳,注意是整数,代表的是秒
    • value: 代表该metric在当前时间点的值,float64
    • step: 表示该数据采集项的汇报周期,这对于后续的配置监控策略很重要,必须明确指定。
    • counterType: 只能是COUNTER或者GAUGE二选一,前者表示该数据采集项为计时器类型,后者表示其为原值 (注意大小写)
      • GAUGE:即用户上传什么样的值,就原封不动的存储
      • COUNTER:指标在存储和展现的时候,会被计算为speed,即(当前值 - 上次值)/ 时间间隔
    • tags: 一组逗号分割的键值对, 对metric进一步描述和细化, 可以是空字符串. 比如idc=lg,比如service=xbox等,多个tag之间用逗号分割

    说明:这7个字段都是必须指定

    Zabbix

    zabbix中监控项叫做item,监控项的取值方法叫做key。

    item: Items是从agnet主机里面获取的所有数据。通常情况下我叫itme为监控项,item由key+参数组成。

    Key:我们可以理解为key是item的唯一标识,在agent端有很多监控项,zabbix-server根据key区分不同的监控项。

    img

    zabbix_server通过发送key给zabbix_agent,然后agent端口根据key执行设定好的sheel脚本,把所要监控的item的最新数据返回给server端。同Open-falcon的第二种方式大致相同,不同点在于数据格式。zabbix是k-v键值串。value支持五种格式:数字(无正负)、浮点数、字符、日志、文本。

    总结

    Zabbix创建自定义监控任务,获取自定义数据指标只能通过执行设定好的脚本获取脚本print出的值,如果希望实现java业务上的监控,没有现成的插件或Api调用,只能通过调用脚本(比如脚本调用Mysql客户端直接查库或者Curl访问)的方式,比较迂回,没有像Prometheus直接调用官方Java的Api、Open-falcon通过Http上传数据这样来的方便且安全。

    显示

    Open-falcon

    前后端组件可以分开部署

    默认的Dashboard监控指标效果图

    image-20190808142551469 image-20190808142702605

    除了默认的之外,支持Grafana视图展现,Grafana可以很有弹性的自定义图表,并且可以针对Dashboard 做权限控管、上标签以及查询,图表的展示选项也更多样化。

    Grafana监控指标效果图

    image-20190808144407393 image-20190808144039864

    Prometheus

    Prometheus 自带了 Web Console, 安装成功后可以访问 http://localhost:9090/graph 页面,用它可以进行 PromQL 查询和调试工作

    效果图

    prometheus-web-console.png prometheus-web-graph.png

    Prometheus同样支持Grafana数据展示。

    Zabbix

    Zabbix的使用手册文档很全面,页面的功能及使用方式介绍的很清晰。

    默认的页面显示效果图

    zabbixweb.png img

    Zabbix也支持Grafana视图展示。

    存储

    Open-falcon

    Open-falcon存储数据用了三个数据库分别是MySQL、Redis、RRDTool(一种时序数据库)。

    Open-falcon存储过程主要是靠Graph组件,将索引部署保存在MySQL中,监控数据保存在RRD中,使用一致性哈希来对数据做均匀的分片。

    Redis主要用于存储judge产生的报警event,alarm从redis读取处理event,已经发送的报警事件会写入MySQL。

    数据存储的流程大致为:

    大致流程为:

    1. 接收数据=>保存监控数据=>保存索引=>保存历史数据
    2. 定期将内存数据GraphItems写入磁盘
    3. 定期更新索引到mysql

    1、2、3这三个过程并行运行。

    流程图:

    img

    Prometheus

    Prometheus内部主要分为三大块,Retrieval是负责定时去暴露的目标页面上去抓取采样指标数据,Storage是负责将采样数据写磁盘,PromQL是Prometheus提供的查询语言模块。

    img prometheusarch2.png

    通过这张架构图可以看出,Prometheus的本地存储使用了tsdb时序数据库。本地存储的优势就是运维简单,缺点就是无法海量的metrics持久化和数据存在丢失的风险。

    为了解决单节点存储的限制,prometheus没有自己实现集群存储,而是提供了远程读写的接口,让用户自己选择合适的时序数据库来实现prometheus的扩展性。

    Prometheus通过下面两种方式来实现与其他的远端存储系统对接

    • Prometheus 按照标准的格式将metrics写到远端存储
    • Prometheus 按照标准格式从远端的url来读取metrics
    远程读写架构

    Zabbix

    数据存储在Mysql中,Zabbix 3.4.6版本开始支持历史数据存储到Elasticsearch。

    总结

    如果只是短期存储和查询,那么Prometheus、Open-falcon、zabbix现有的都能满足要求。但如果要对大量数据进行分析预测等过程,则三者都需要转用其他可接入spark、mapreduce等的数据库。Open-falcon需要进行二次开发,Prometheus提供了远程读写的接口。Zabbix网上没查到二次开发使用MySQL、ES外其他数据库的,而且Zabbix后台用C开发,二次开发的难度也比较大。

    报警

    Open-falcon

    Open-falcon的报警主要通过judge、Alarm、AlarmManager三个组件来实现。

    Judge用于告警判断,agent将数据push给Transfer,Transfer不但会转发给Graph组件来绘图,还会转发给Judge用于判断是否触发告警。

    alarm模块是处理报警event的,judge产生的报警event写入redis,alarm从redis读取处理,并进行不同渠道的发送。

    AlarmManager模块主要有两大功能,一个用于注册告警数据接收服务、提供告警事件多条件查询功能;另外一个是针对告警事件升级为故障,定制化处理功能。

    目前功能有:

    • 可配置报警级别,比如P0/P1/P2等等,每个及别的报警都会对应不同的redis队列
    • 报警消息聚类,针对同一个策略发出的多条报警,在MySQL存储的时候会聚类
    • 报警合并,有的时候报警短信、邮件太多,对于优先级比较低的报警,希望做报警合并,这些逻辑都是在alarm中做的。
    • 针对告警信息生成一个跟进事件(事件定义为故障),可以将告警事件的处理过程通过时间轴管理起来,可新增、更改故障、增加告警时间、关注、状态变更(关闭、废弃、重新打开)、输出故障时间轴
    • 告警管理,可指定接收者和其他条件快速过滤关注的告警、告警数量、已经添加至故障的告警信息等

    目前告警管理数据来源于alarm组件推的方式。alarm-manager组件实现告警数据的自管理,组件提供专门的接收数据接口,其它告警数据通道可按照一定数据格式进行推动,用于其它监控平台的数据流入、告警管理。

    配置报警策略的时候open-falcon支持多种报警触发函数,比如all(#3) diff(#10)等等。 这些#后面的数字表示的是最新的历史点,比如#3代表的是最新的三个点。该数字默认不能大于10,大于10将当作10处理,即只计算最新10个点的值。(#后面的数字的最大值,即在 judge 内存中保留最近几个点,是支持自定义的,)

    报警策略:

    all(#3): 最新的3个点都满足阈值条件则报警
    max(#3): 对于最新的3个点,其最大值满足阈值条件则报警
    min(#3): 对于最新的3个点,其最小值满足阈值条件则报警
    sum(#3): 对于最新的3个点,其和满足阈值条件则报警
    avg(#3): 对于最新的3个点,其平均值满足阈值条件则报警
    diff(#3): 拿最新push上来的点(被减数),与历史最新的3个点(3个减数)相减,得到3个差,只要有一个差满足阈值条件则报警
    pdiff(#3): 拿最新push上来的点,与历史最新的3个点相减,得到3个差,再将3个差值分别除以减数,得到3个商值,只要有一个商值满足阈值则报警
    lookup(#2,3): 最新的3个点中有2个满足条件则报警;
    stddev(#7) = 3:离群点检测函数,取最新 **7** 个点的数据分别计算得到他们的标准差和均值,分别计为 σ 和 μ,其中当前值计为 X,那么当 X 落在区间 [μ-3σ, μ+3σ] 之外时,则认为当前值波动过大,触发报警;更多请参考3-sigma算法:https://en.wikipedia.org/wiki/68%E2%80%9395%E2%80%9399.7_rule。
    

    支持的通知方式:

    • 短信
    • 微信
    • 邮件
    • 电话

    需要提供Http的发送接口。

    Prometheus

    Prometheus的告警通过组件AlertManager来实现。报警过程分为两步,根据创建的告警规则发送警报给Altermanager。Altermanager然后管理这些警告,包括沉默,禁用,聚合和通过各种方式例如email,pagerDuty和HipChat发送通知。

    配置配置报警和发送通知的主要步骤有:

    1. 设置和配置Alertmanager。
    2. 配置Prometheu去通知Alertmanager。
    3. 在Prometheus中创建报警规则。

    告警流程图:

    image-20190810152117029

    目前功能有:

    • 告警分组,作为用户同类报警只想看到单一的报警页面,同时仍然能够清楚的看到哪些实例受到影响,因此,人们通过配置Alertmanager将警报分组打包,并发送一个相对看起来紧凑的通知。
    • 抑制,抑制是指当警报发出后,停止重复发送由此警报引发其他错误的警报的机制。
    • 静默,其实就相当于限流,一定时间内不再为满足设定规则的用户发送告警。
    • 告警延时,假设系统发生故障产生告警,每分钟发送一条告警消息,这样的告警信息十分令人崩溃。Alertmanager提供第一个参数是repeat interval,可以将重复的告警以更大频率发送。

    通知方式则是使用WebHook来实现,支持钉钉机器人、企业微信、电话、短信、邮件等,资料比较少。

    Zabbix

    报警流程:

    首先item(监控项)拿到server端的数据,收集到数据后,如果它和一个trigger(触发器)绑定了,那么会检查trigger的状态。

    是否变成异常状态,然后按照trigger的状态生成一个事件(无论状态变与不变都会生成),最后检查报警动作。其实也就是满足Trigger的触发条件便会执行绑定的Action(动作)

    8750a90a24887c7f54e9ec1d70b8b78b.png

    定义触发器的表达式,其实就是配置报警的触发条件,定义页面如下图

    img

    配置触发器页面

    img

    选择触发器级别

    img

    创建Action的页面大同小异。

    总结

    Zabbix文档资料较少,配置项不多,功能不够丰富,优点是直接可以在页面上进行配置;Prometheus功能比Zabbix多,比Open-falcon少,配置项多但文档不够详细;Open-falcon功能丰富,官方文档也比较详细。

    整体总结

    这次采用开源监控系统主要是为了监控一些自定义业务并进行告警,所以重点关注了上传自定义数据、监控、显示、存储、告警五个方面,由于公司运维已经有监控机器指标的工具,所以监控机器指标这方面不是重点。

    Zabbix后台采用了C语言,监控数据存储在关系型数据库内,如MySQL,很难从现有数据扩展维度,定制化难度较高,自定义监控指标的接入只能依靠shell脚本的运行,监控及告警的配置功能不够丰富,所以优先排除。

    Prometheus和Open-falcon后台都是采用Go编写,相对C而言要好二次开发一些。Prometheus支持PromQL数据查询语言,对比常用的SQL语言而言查询性能高、Prometheus在集群存储方面官方提供了接口方便扩展对流处理有优势的数据库,如果需要对数据进行预测的话Prometheus有着较大的优势,Open-falcon虽然不方便扩展,但目前功能也足够使用。监控自定义指标Prometheus官方也提供了对应的Java接口,Open-falcon虽然没有提供,但是编写上传数据接口的难度也不大。Open-falcon在报警规则、告警通知配置方面功能要比Prometheus丰富。

    最后总结,如果有需要对监控指标趋势进行预测的话,选择Prometheus。如果不需要预测的话,选择Open-falcon。

    文中如果有错误,欢迎批评指正。

    相关文章

      网友评论

        本文标题:Open-falcon、Prometheus、Zabbix监控告

        本文链接:https://www.haomeiwen.com/subject/ixwyjctx.html