结合项目本身情况，对开源监控系统进行了一些筛选；

SAAS

首先是SAAS级别的监控工具，市场上比较流行的有Datadog和Cloud Insight；由于是SAAS监测工具，这类系统都有着很丰富全面的功能（包含数据集成、可视化、数据存储、事件流处理于一体），它们对众多云服务与开源项目都进行了整合，可以很方便的使用它们提供的接口来对各种指标进行监控；但是使用这类产品意味着自己产品的各种数据会暴露给服务提供者，而且还需要考虑到服务的价格问题

Datadog

Datadog是国外很有名的一体化监控SAAS监控工具，它基于Statsd开发，整合了Redis、Nginx、Slack等服务，提供应用级别的监控，数据库的监控等服务，安装快捷方便；不过Datadog只提供了数据的收集与聚合统计以及相应图形展示，不提供数据分析的功能；价格方面有免费版本和15美元/台/月的标准版本，而且由于服务器在国外，如果要使用需要考虑网速因素

Cloud Insight

Cloud Insight与Datadog功能类似，同样基于Stasd开发，可以监控 Redis、Nginx、MongoDB、MySQL、Docker 等几十种基础组件，相比于Datadog的数据只读，cloud insight采用时序数据库（使用的OpenTSDB），可以对数据进行一些分析，而且由于在国内，不需要太考虑网络问题；价格方面提供免费版与360元/台/年的专业版。

自己实现

除开SAAS级别的监控工具，现在还有许多开源监控系统可以让我们自定义部署，下面选取了一些常见的开源系统：nagios，cacti，zabbix，statsd，prometheus

• 对于nagios，由于其主要功能是做IT设备的监控，对于服务级别的监控（例如监控nginx和数据库等）需要自己写插件写脚本，所以排除。
• 对于cacti，它主要是用snmp服务获取数据，然后用rrdtool储存和更新数据，当用户需要查看数据的时候用rrdtool生成图表呈现给用户，不能对数据进行分析，同样对于那些snmp服务获取不到的数据需要工程师自己去自定义收集脚本（用php写的），可以说cacti主要是用来监控流量方面的东西，但是用来监控其他的就有些不合适了，所以排除。
• 对于zenoss，主要功能是做企业级设备监控，与项目本身情况不符合，所以排除。
• 对于zabbix，他可以通过SNMP，zabbix agent，ping，端口监视等方法对远程服务器/网络状态进行数据收集与监视并进行报警，数据收集方式支持的较多，可以监控应用级别的的监控与服务器方面的监控，因此可以考虑。
• 对于statsd，它是一个 NodeJs 的 daemon 程序，简单轻巧，使用 UDP 协议，专门用来收集数据，收集完数据就发送到其他服务器进行处理，可以和其他服务整合来做监控，例如statsd加graphite来实现一个智能监控并进行可视化图形的输出；stasd支持多种数据指标收集，其中应用程序的指标通过特定语言的客户端库进行检测，然后这些库用很简单的协议和 Statsd 后台守护进程进行通信，后台进程汇集指标并把他们传递到绘图软件或监控后台；因此可以考虑。
• 对于prometheus，它和statsd一样都是监控metric，它提供了开箱即用的客户端库；它来源于SoundCloud针对StatsD和Graphite所提供的改善监控系统。Prometheus能够按照给定的时间间隔收集所配置目标的指标、执行规则表达式、展现结果，如果某些条件判断结果为真的话，将会触发告警；可以做到应用级别的监控，因此可以考虑。

综上所述，可以详细考虑一下zabbix，statsd加graphite，prometheus这三种方案

zabbix

zabbix是一个企业级开源监控解决方案，主要是用来监控网络和应用的，它有着丰富的监控指标；它提供了十几种监控类型，包括Zabbix agent, Simple checks, SNMP, Zabbix internal, IPMI, JMX monitoring等等；每种监控类型可以用于不同的监控情境中；下面对它的监控做一些简单介绍：

• zabbix agent
  zabbix自带的客户端程序（被动模式），zabbix server主动向它收集监控数据。agent提供丰富的key，包括不限于cpu、内存、网络、磁盘、web等等
• zabbix agent（active）
  和上一个相同。但是数据由zabbix agent主动提交至zabbix server
• simple check
  基本的检测，可以检测网络、端口、fping这些，功能很少并且无需安装客户端
• snmp check
  对于支持snmp协议的情景都可以使用这个进行监控
• zabbix aggretage
  aggregate checks是一个聚合的检测，例如我想知道某个组的host负载平均值，硬盘剩余总量，或者某几台机器的这些数据，简单的说，这个方法就是用来了解一个整体水平，而不需要我们一台台看过去。这个方法的数据全部来之数据库，所以它不需要agent
• database monitor
  zabbix通过调用ODBC来获取数据库的数据以及数据库状态等等信息

在一般情况下，推荐使用zabbix agent方式，可以监控应用（应用响应，应用状态等），监控nginx，监控数据库（）等；可以给zabbix设置监控阈值，当监控指标值超过阈值时zabbix还提供报警功能。不过zabbix的缺点是只能做到数据的收集和罗列以及报警，对于数据聚合做的不是特别好

statsd加graphite

statsd加graphite是一个比较流行的监控解决方案；对接所有监控对象（例如监控主机的操作系统，以及中间件、数据库、服务器的 API 接口等）至 StatsD，再由 StatsD 传递给 Graphite 做集中的展现；

StatsD就是一个简单的网络守护进程，通过UDP进行监听，使用计数器和定时器，并发送聚合信息给graphite；不过因为StatsD本身不负责定义指标的涵义，所以从数据库或者操作系统中采集的工作，需要进行脚本的开发。

Graphite是一套图形库，负责对数据进行保存以及视觉显示渲染（Python编写）；它主要做两件事：存储时间序列数据，根据需要呈现数据的图形；它由三部分组成：监听器carbon、时序数据库whisper、图形展示django-webapp；carbon接收到数据，再将数据写入到whisper数据库文件中，然后django-webapp去读取这个数据，然后显示出图形

• 监听器carbon
  Carbon是一套面向Graphite配置的存储后端。单一Graphite配置中将包含一个或者多个Carbon守护进程，其负责由其它进程收集并传输的统计数据（只是监听时间序列数据而不参与收集）

• 时序数据库whisper
  一个简单的数据库库，用来存储时间序列数据；它能够以非常详尽的方式存储时间序列数据。它能够立足于不同细节层级创建不同归档副本，从而满足特定使用需求，并在特定信息超出保留时间阈值后降低其详尽程度；它还能够根据指标的不同特性采用其它低详尽度计算方式。例如，部分数据属于平均取值，另一些则需要追踪其最大值。对于平均值数据，whisper会根据高详尽度数据点计算低详尽度值。而对于最大值数据，whisper则保留其最大值并舍弃其余值，从而保持平均计算结果的正确性

• 图形展示django-webapp
  对读取的数据进行图形渲染

该方案一个缺点就是数据的各种收集需要自己去写脚本定义指标，而且还得找到每个后台对应的api，不过statsd本身支持了大部分的后台；

prometheus

Prometheus是一套开源的监控系统，它将所有信息都存储为时间序列数据；因此实现一种Profiling监控方式，实时分析系统运行的状态、执行时间、调用次数等；其结构如下图所示：

程序代码收集运行数据写入到redis，通过API接口开放给Prometheus，Prometheus定时去抓取接口上的数据，形成时间系数据存入到本地。同时通过promql与开放接口可视化数据到前端

相比于statsd加graphite的方式，prometheus可以说是二者的整合以及进一步开发，因此使用起来相对会更简单一些；它提供的客户端API也支持很多语言，可以考虑