前言
随着Devops、云计算、微服务、容器等理念的逐步落地和大力发展，机器愈来愈多，应用愈来愈多，服务愈来愈微，应用运行基础环境越来多样化，容器、虚拟机、物理机不一而足。面对动辄几百上千个虚拟机、容器，数十种要监控的对象，现有的监控系统还可否支撑的住？来自于容器、虚拟机、物理机、网络设备、中间件的指标数据如何采用同一套方案快速、完整的收集和分析告警？怎样的架构、技术方案才更适合如此庞大繁杂的监控需求呢？前端
上篇文章《建设DevOps统一运维监控平台，先从日志监控提及》主要从日志监控的方面进行了分享，本篇文章则是重点在系统监控层面进行分享。mysql
目录：ios
1、统一监控平台架构解析git
2、系统监控的技术栈github
3、开源系统监控软件 Zabbix VS Nagios VS Open-Falconweb
4、基于k8s容器云背景下的系统监控实践：cAdvisor+Heapster+Influxdbsql
5、容器时代的监控利器： Prometheusdocker
1、统一监控平台架构解析数据库
先作一下回顾，统一监控平台由七大角色构成：监控源、数据采集、数据存储、数据分析、数据展示、预警中心、CMDB(企业软硬件资产管理)。apache
- 监控源：
从层次上来分，大体能够分为三层，业务应用层、中间件层、基础设施层。业务应用层主要包括应用软件、企业消息总线等，中间件层包括数据库、缓存、配置中心、等各类系统软件，基础设施层主要有物理机、虚拟机、容器、网络设备、存储设备等等。
- 数据采集：
数据源如此多样，数据采集的任务天然轻松不了。数据采集从指标上划分能够分为业务指标、应用指标、系统软件监控指标、系统指标。应用监控指标如：可用性、异常、吞吐量、响应时间、当前等待笔数、资源占用率、请求量、日志大小、性能、队列深度、线程数、服务调用次数、访问量、服务可用性等，业务监控指标如大额流水、流水区域、流水明细、请求笔数、响应时间、响应笔数等，系统监控指标如：CPU负载、内存负载、磁盘负载、网络IO、磁盘IO、tcp链接数、进程数等。
从采集方式来讲一般能够分为接口采集、客户端agent采集、经过网络协议主动抓取（http、snmp等）
- 数据存储：
采集到的数据通常都会存储到文件系统（如HDFS）、索引系统（如elasticsearch）、指标库（如influxdb）、消息队列（如kafka，作消息临时存储或者缓冲）、数据库（如mysql）
- 数据分析：
针对采集到的数据，进行数据的处理。处理分两类：实时处理和批处理。技术包括Map/Reduce计算、全日志检索、流式计算、指标计算等，重点是根据不一样的场景需求选择不一样的计算方式。
- 数据展示：
将处理的结果进行图表展示，在多屏时代，跨设备的支持必不可少。
- 预警：
若是在数据处理过程发现了问题，则须要进行异常的分析、风险的预估以及事件的触发或告警。
- CMDB(企业软硬件资产管理):
CMDB在统一监控平台中是很重要的一环，监控源虽然种类繁多，可是他们大都有着关系，如应用运行在运行环境中，应用的正常运行又依赖网络和存储设备，一个应用也会依赖于其余的应用（业务依赖），一旦其中任何一个环节出了问题，都会致使应用的不可用。CMDB除了存储软硬件资产外，还要存储这样一份资产间的关联关系，一个资产发生了故障，要能根据这个关系迅速得知哪些其余的资产会被影响，而后逐一解决问题。
OK，回顾到此为止，进入正题，系统监控。
2、系统监控的技术栈
系统监控的部分技术栈以下图所示，监控技术众多，这里天然不可能列出全部的技术，选择了部分比较经典、受欢迎的开源技术。
系统监控不一样于日志监控，有不少开源软件把数据库采集、数据存储、数据展示、事件告警的任务都完成了，因此对于系统监控的技术栈中，将这些开源软件暂且排除，待后面章节再进行讲解。此处主要关注于如何自建一个统一系统监控平台。
- 数据采集：
系统监控数据采集通常分为两种方式：主动采集、客户端采集。主动采集通常是经过SNMP、SSH、Telnet、IPMI、JMX等手段进行远程采集，客户端采集则是须要在每个要监控的主机中部署一个客户端进行数据采集并发送到远程服务端进行接收。
- 数据缓冲：
和日志监控同样，在面临海量监控时，考虑到网络的压力和数据处理的瓶颈，能够在数据存储前先通过一层数据缓冲，将采集到的数据先放置到消息队列中，而后再从分布式队列中读取数据并存储。若是数据量不大的话，则能够不考虑此层。
- 数据存储：
对于系统监控数据，一般采用时序数据库来存储，时序数据库全称为时间序列数据库。时间序列数据库主要用于指处理带时间标签（按照时间的顺序变化，即时间序列化）的数据，带时间标签的数据也称为时间序列数据。如influxdb和opentsdb，是其中翘楚。
OpenTSDB是用hbase存储全部的时序（无须采样）来构建的一个分布式、可伸缩的时间序列数据库，能够从大规模的集群（包括集群中的网络设备、操做系统、应用程序）中获取相应的metrics并进行存储、索引以及服务，从而使得这些数据更容易让人理解，如web化，图形化等。用JAVA语言实现，对于JAVA系的同窗们是一个福音,不过其依赖hbase也许会让一部分同窗望而却步，毕竟还要先去维护hbase。
Influxdb是新兴的一个时序数据库，用go语言编写，无需外部依赖，发展很快，最新版本已经到了1.2。提供类sql的查询语法，安装方便，单点便可使用，虽然有集群的能力，不过该特性是非开源的（不过单点性能基本也都能知足企业需求了）。提供Http API，便于调用和封装。对于想基于influxdb自行进行数据处理和展示的同窗们而言非常友好。
- 数据展示：
说到时序数据的图形化展示，Grafana是一个不得不提的利器。Grafana是一个开源的时序数据的查询和展示软件，提供了灵活丰富的图形化选项；能够混合多种风格，有着功能齐全的度量仪表盘和图形编辑器。支持与Graphite、Elasticsearch、CloudWatch、Prometheus、InfluxdbDB等众多数据存储对接，进行数据的查询和图表展示。一些开源的监控软件如zabbix、Graphite、Prometheus也都有着本身的数据图形化展示能力，可是通常也都是建议使用
Grafana来代替它们的页面。可想而知Grafana的优秀。
固然，Grafana的数据源都是来自时序数据库，在实际场景中，可能你想要查看的报表的一部分数据还来自于业务系统，这就是Grafana或者其余的监控软件作不到的了，去扩展是一种方式，另一种方式就是结合本身的需求实现图表展示,经过对时序数据的计算分析以及结合业务数据，使用如echarts等开源图表前端框架进行展示。这时候Influxdb的优点就体现出来了，对外提供http api很是适合自主封装图形化页面。
- 告警：
在日志监控的分享中，确实没有对告警进行说明。像Zabbix、Nagios、Open-Falcon、Prometheus等开源监控软件，都是有些本身的告警能力的。若是你采用了他们做为监控平台，实际上告警能力就已经有了。若是是纯自建统一监控平台的话，也能够本身实现告警中心。咱们本身的作法是，在数据处理时，根据配置的事件触发规则，生成相应事件扔到kafka中，事件处理引擎监听kafka中的事件数据，进行解析并根据事件处理策略进行告警通知等处理。
3、开源系统监控软件
Zabbix VS Nagios VS Open-Falcon
上面大体介绍了运维监控的技术栈，可是实际上已经有些开源监控软件功能都很全面，从数据采集到数据展示都提供了支持，若是是小团队，不想自建监控平台的话，选择这些开源软件实际上是一个很好的选择。
Zabbix
Zabbix是一个企业级的开源分布式监控解决方案，支持实施从数以万计的服务器、虚拟机、网络设备等收集百万的指标数据，具有常见的商业监控软件所具有的功能（主机的性能监控、网络设备性能监控、数据库性能监控、FTP等通用协议监控、多种告警方式、详细的报表图表绘制）支持自动发现网络设备和服务器；支持分布式，能集中展现、管理分布式的监控点；扩展性强，server提供通用接口，能够本身开发完善各种监控。
Zabbix重要组件说明：
- zabbix server：负责接收agent发送的报告信息的核心组件，全部配置、统计数据及操做数据都由它组织进行；
- database storage：专用于存储全部配置信息，以及由zabbix收集的数据；
- web interface：zabbix的GUI接口；
- proxy：可选组件，经常使用于监控节点不少的分布式环境中，代理server收集部分数据转发到server，能够减轻server的压力；
- agent：部署在被监控的主机上，负责收集主机本地数据如cpu、内存、数据库等数据发往server端或proxy端；
优势：
- All in One：部署至关便捷
- Server对宿主机性能要求很低。
- 自动发现服务器与网络设备
- 分布式监控，以及WEB集中管理功能
- 同时支持agent采集和无agent采集，主机经过agent 或者ipmi采集数据，网络设备、存储设备等经过 SNMP 客户端采集数据，agent支持经常使用的UNIX和Windows操做系统
- 功能全面，数据采集、数据存储、数据展示、事件告警。
- 开放式接口，扩展性强，插件编写容易
不足：
- 数据库瓶颈，使用mysql做为底层存储，大数据读写的时候，对于数据库的压力很是大
- 须要在主机中安装agent
- 对容器监控支持很差，须要本身扩展。
Nagios
Nagios 全名为（Nagios Ain’t Goona Insist on Saintood），最初项目名字是 NetSaint。它是一款免费的开源 IT 基础设施监控系统，其功能强大，灵活性强，能有效监控 Windows 、Linux、VMware 和 Unix 主机状态，交换机、路由器等网络设置等。Nagios核心功能是监控报警，告警能力很不错，可是图形展现效果不好。同时nagios更加灵活，不少功能都要经过插件化来实现，对于技术能力没那么强的同窗，上手会有些困难。固然，对于运维老手，上手会很快。
Nagios 的功能特性以下：
- 监控网络服务（SMTP、POP三、HTTP、NNTP、PING等）；
- 监控主机资源（处理器负荷、磁盘利用率等）；
- 简单地插件设计使得用户能够方便地扩展本身服务的检测方法；
- 并行服务检查机制；
- 具有定义网络分层结构的能力，用"parent"主机定义来表达网络主机间的关系，这种关系可被用来发现和明晰主机宕机或不可达状态；
- 当服务或主机问题产生与解决时将告警发送给联系人（经过EMail、短信、用户定义方式）；
- 能够定义一些处理程序，使之可以在服务或者主机发生故障时起到预防做用；
- 自动的日志滚动功能；
- 能够支持并实现对主机的冗余监控；
- 可选的WEB界面用于查看当前的网络状态、通知和故障历史、日志文件等；
Open-Falcon
Open-Falcon是小米运维部门开源出来的互联网企业级监控系统，目前包括小米、金山云、美团、京东金融、赶集网等都在使用Open-Falcon。Open-Falcon 总体能够分为两部分，即绘图组件、告警组件。“绘图组件”负责数据的采集、收集、存储、归档、采样、查询、展现（Dashboard/Screen）等功能，能够单独工做，做为time-series data的一种存储展现方案。“告警组件”负责告警策略配置（portal）、告警断定（judge）、告警处理（alarm/sender）、用户组管理（uic）等，能够单独工做。架构以下：
关键特性有：
- 数据采集免配置：agent自发现、支持Plugin、主动推送模式
- 容量水平扩展：生产环境每秒50万次数据收集、告警、存储、绘图，可持续水平扩展。
- 告警策略自发现：Web界面、支持策略模板、模板继承和覆盖、多种告警方式、支持回调动做。
- 告警设置人性化：支持最大告警次数、告警级别设置、告警恢复通知、告警暂停、不一样时段不一样阈值、支持维护周期，支持告警合并。
- 历史数据高效查询：秒级返回上百个指标一年的历史数据。
- Dashboard人性化：多维度的数据展现，用户自定义Dashboard等功能。
- 架构设计高可用：整个系统无核心单点，易运维，易部署。
缺点：
- 支持的监控类型较少，不支持经常使用应用服务器如tomcat、apache、jetty等的监控。
- 没有专门的运维支持，代码更新较少，没有一个较大的社区来维护，后续想要有什么新的能力基本只能期望本身扩展。
Zabbix、Nagios、Open-Falcon的总体对好比下：
4、基于k8s容器云背景下的系统监控实践：
cAdvisor+Heapster+Influxdb
上面介绍的都是比较传统的系统监控架构，在容器时代到来后，对于容器的支持就显得差强人意了。下面介绍下咱们基于k8s容器云背景下的系统监控方案，首先仍是介绍下咱们的DevOps平台架构，平台运行在由kubernetes+docker构建的容器云中，kubernetes、docker等服务运行在IaaS平台上（咱们的生产环境是阿里云）。
咱们的统一监控平台，在系统监控上，采用了cAdvisor+Heapster+Influxdb的方案。架构以下：
为何采用这种方案呢？先来了解下这三个工具。
cAdvisor 是谷歌公司用来分析运行中的Docker容器的资源占用以及性能特性的工具, cAdvisor部署为一个运行中的daemon，它会收集、汇集、处理并导出运行中容器的信息。这些信息可以包含容器级别的资源隔离参数、资源的历史使用情况、反映资源使用和网络统计数据完整历史情况。对docker的监控能力很是强大。同时还提供了本身的web页面，用户能够经过web页面直接查看该宿主机上全部容器的监控数据。cAdvior功能已经被集成到了kubelet组件中，也就是说，安装好kubernetes后，cAdvisor就已经安装到了每个计算节点上。在每个计算节点上均可以经过IP+端口（默认为4194）访问cAdvisor的页面了。
Heapster一样是Google提供的，用于对k8s集群的监控。Heapster能够经过容器启动，传入kubernetes master的地址，heapster会经过调用kubernetes api获取全部kubernetes计算节点，而后经过kubelet的外部调用端口号（默认为10250）调用kubelet的http api，kubelet会进行调用cAdvisor接口获取当前计算节点上的容器数据以及当前主机的性能数据，返回给heapter。这样heapster就收集到了kubernetes集群的全部容器数据以及主机数据。Heapster支持数据传输到Influxdb中进行存储。数据展示咱们就是本身调用influxdb的api获取数据，结合咱们的业务相关数据进行计算，用echarts进行前端图表展示。
可能有的同窗会问，这样只是监控到了全部计算节点的容器数据和主机性能数据，这样有些非计算节点的主机监控该怎么办？确实，由于Heapster只是针对于kubernetes集群去监控，非kubelet节点确实是拿不到数据的，而咱们又不想再用另一种方式去单独监控主机，那样获得的数据格式也不同。因而咱们采起了折中的办法，在每一个非k8s集群节点上，也安装kubelet，而且加入到kubernetes集群中，可是配置成不参与集群调度，也就是容器不会被部署到这些机器上。这样，heapster就能够采集到这些主机的性能数据了。
5、容器时代的监控利器： Prometheus
除了咱们实践的cAdvisor+Heapster+Influxdb方案能够作到容器和主机性能数据同时监控外，其实还有一个相对而言更好的方案，那就是Prometheus。Prometheus是一套开源的监控&报警&时间序列数据库的组合，由社交音乐平台SoundCloud在2012年开发。随着发展，愈来愈多公司和组织接受采用Prometheus，社区也十分活跃，他们便将其独立成开源项目，而且不依赖于任何公司。Prometheus最初是参照google内部监控系统BorgMon开发的，如今最多见的Kubernetes容器管理系统中，一般会搭配Prometheus进行监控。
2016年Prometheus正式成为Cloud Native Computing Foundation的孵化项目，该基金会是在Google的支持下由一群IT行业巨头建立并指导Kubernetes容器管理系统的开发。在CNCF的主导下，Prometheus成为该开放平台栈的第二个正式的组件。特性以下：
- 高维度数据模型
- 高效的时序数据存储能力
- 查询语言灵活
- 具体时序数据图形化展示的能力
- 易于运维
- 提供丰富的客户端开发库
- 告警中心功能全面
Prometheus的架构图以下：
- Prometheus Server : Prometheus主服务器，用来收集和存储时间序列数据
- client libraries : 客户端库
- push gateway : 短时jobs的中介网关
- GUI-based dashboard builder : 基于Rails/SQL的GUI dashboard
- Exporters ： 数据采集探针，支持包括数据库、主机、消息队列、存储、应用服务器、github等软件、其余监控系统等多种类的探针。
- Alertmanager ：告警中心
Prometheus 是google力捧的监控方案，社区很是活跃，发展非常迅速，功能在不断的飞速补充和完善。一个监控范围覆盖容器、主机、存储、数据库、各类中间件，同时还具体完善的时序数据存储、告警中心等能力，发展又很迅速，相信Prometheus会愈来愈火热。
6、总结
系统监控的方案有不少，甚至优秀的开源兼容软件也有不少，若是需求不高，也许zabbix就很合适，若是想要带上容器监控，那么Prometheus也许是个较好的方案。总之，适合本身的才是最好的。
关于做者
王海龙