运维监控-Open-Falcon介绍

                  运维监控-Open-Falcon介绍

                                           作者:尹正杰

版权声明:原创作品,谢绝转载!否则将追究法律责任。

 

 

一.Open-Falcon 介绍

   监控系统是整个运维环节,乃至整个产品生命周期中最重要的一环,事前及时预警发现故障,事后提供翔实的数据用于追查定位问题。监控系统作为一个成熟的运维产品,业界有很多开源的实现可供选择。当公司刚刚起步,业务规模较小,运维团队也刚刚建立的初期,选择一款开源的监控系统,是一个省时省力,效率最高的方案。之后,随着业务规模的持续快速增长,监控的对象也越来越多,越来越复杂,监控系统的使用对象也从最初少数的几个SRE,扩大为更多的DEVS,SRE。这时候,监控系统的容量和用户的“使用效率”成了最为突出的问题。

  监控系统业界有很多杰出的开源监控系统。我们在早期,一直在用zabbix,不过随着业务的快速发展,以及互联网公司特有的一些需求,现有的开源的监控系统在性能、扩展性、和用户的使用效率方面,已经无法支撑了。因此,我们在过去的一年里,从互联网公司的一些需求出发,从各位SRE、SA、DEVS的使用经验和反馈出发,结合业界的一些大的互联网公司做监控,用监控的一些思考出发,设计开发了小米的监控系统:open-falcon。

 

二.Open-Falcon 特点

1>.强大灵活的数据采集:

  自动发现,支持falcon-agent、snmp、支持用户主动push、用户自定义插件支持、opentsdb data model like(timestamp、endpoint、metric、key-value tags)

2>.水平扩展能力:

  支持每个周期上亿次的数据采集、告警判定、历史数据存储和查询

3>.高效率的告警策略管理:

  高效的portal、支持策略模板、模板继承和覆盖、多种告警方式、支持callback调用

4>.人性化的告警设置:

  最大告警次数、告警级别、告警恢复通知、告警暂停、不同时段不同阈值、支持维护周期

5>.高效率的graph组件:

  单机支撑200万metric的上报、归档、存储(周期为1分钟)

6>.高效的历史数据query组件:

  采用rrdtool的数据归档策略,秒级返回上百个metric一年的历史数据

7>.dashboard:

  多维度的数据展示,用户自定义Screen

8>.高可用:

  整个系统无核心单点,易运维,易部署,可水平扩展

9>.开发语言:

  整个系统的后端,全部golang编写,portal和dashboard使用python编写。

 

三.Open-Falcon

 

备注:虚线所在的aggregator组件还在设计开发阶段。

每台服务器,都有安装falcon-agent,falcon-agent是一个golang开发的daemon程序,用于自发现的采集单机的各种数据和指标,这些指标包括不限于以下几个方面,共计200多项指标。

  • CPU相关
  • 磁盘相关
  • IO
  • Load
  • 内存相关
  • 网络相关
  • 端口存活、进程存活
  • ntp offset(插件)
  • 某个进程资源消耗(插件)
  • netstat、ss 等相关统计项采集
  • 机器内核配置参数

只要安装了falcon-agent的机器,就会自动开始采集各项指标,主动上报,不需要用户在server做任何配置(这和zabbix有很大的不同),这样做的好处,就是用户维护方便,覆盖率高。当然这样做也会server端造成较大的压力,不过open-falcon的服务端组件单机性能足够高,同时都可以水平扩展,所以自动多采集足够多的数据,反而是一件好事情,对于SRE和DEV来讲,事后追查问题,不再是难题。

另外,falcon-agent提供了一个proxy-gateway,用户可以方便的通过http接口,push数据到本机的gateway,gateway会帮忙高效率的转发到server端。

falcon-agent,可以在我们的github上找到 : https://github.com/open-falcon/agent

 

四.数据模型

 

Data Model是否强大,是否灵活,对于监控系统用户的“使用效率”至关重要。比如以zabbix为例,上报的数据为hostname(或者ip)、metric,那么用户添加告警策略、管理告警策略的时候,就只能以这两个维度进行。举一个最常见的场景:

 

hostA的磁盘空间,小于5%,就告警。一般的服务器上,都会有两个主要的分区,根分区和home分区,在zabbix里面,就得加两条规则;如果是hadoop的机器,一般还会有十几块的数据盘,还得再加10多条规则,这样就会痛苦,不幸福,不利于自动化(当然zabbix可以通过配置一些自动发现策略来搞定这个,不过比较麻烦)。

 

open-falcon,采用和opentsdb相同的数据格式:metric、endpoint加多组key value tags,举两个例子:

 

{
    metric: load.1min,
    endpoint: open-falcon-host,
    tags: srv=falcon,idc=aws-sgp,group=az1,
    value: 1.5,
    timestamp: `date +%s`,
    counterType: GAUGE,
    step: 60
}
{
    metric: net.port.listen,
    endpoint: open-falcon-host,
    tags: port=3306,
    value: 1,
    timestamp: `date +%s`,
    counterType: GAUGE,
    step: 60
}

 

通过这样的数据结构,我们就可以从多个维度来配置告警,配置dashboard等等。 备注:endpoint是一个特殊的tag。

 

 

五.数据收集

 

  transfer,接收客户端发送的数据,做一些数据规整,检查之后,转发到多个后端系统去处理。在转发到每个后端业务系统的时候,transfer会根据一致性hash算法,进行数据分片,来达到后端业务系统的水平扩展。

 

  transfer 提供jsonRpc接口和telnet接口两种方式,transfer自身是无状态的,挂掉一台或者多台不会有任何影响,同时transfer性能很高,每分钟可以转发超过500万条数据。

 

  transfer目前支持的业务后端,有三种,judge、graph、opentsdb。judge是我们开发的高性能告警判定组件,graph是我们开发的高性能数据存储、归档、查询组件,opentsdb是开源的时间序列数据存储服务。可以通过transfer的配置文件来开启。

 

  transfer的数据来源,一般有三种:

 

    1. falcon-agent采集的基础监控数据
    2. falcon-agent执行用户自定义的插件返回的数据
    3. client library:线上的业务系统,都嵌入使用了统一的perfcounter.jar,对于业务系统中每个RPC接口的qps、latency都会主动采集并上报

 

  说明:上面这三种数据,都会先发送给本机的proxy-gateway,再由gateway转发给transfer。

 

基础监控是指只要是个机器(或容器)就能加的监控,比如cpu mem net io disk等,这些监控采集的方式固定,不需要配置,也不需要用户提供额外参数指定,只要agent跑起来就可以直接采集上报上去; 非基础监控则相反,比如端口监控,你不给我端口号就不行,不然我上报所有65535个端口的监听状态你也用不了,这类监控需要用户配置后才会开始采集上报的监控(包括类似于端口监控的配置触发类监控,以及类似于mysql的插件脚本类监控),一般就不算基础监控的范畴了。

 

 

  更多资料请参考官网链接:http://book.open-falcon.org/zh/intro/.

  博主推荐阅读:http://book.open-falcon.org/zh_0_2/faq/

 

posted @ 2018-11-12 15:14  尹正杰  阅读(3103)  评论(0编辑  收藏  举报