原有系统及问题

我们原有的监控体系出于稳定和可靠性考虑，采用 mysql 存储，再加 python 开发分析与报警逻辑。好处是技术成熟，灵活可控，少坑。随着业务发展，这套方案逐渐难以应付更加复杂、多样化的监控需求。
监控数据往往都带有时间戳，其实就是一种典型时间序列数据，而这方面已经有很多专门的存储系统，如 opentsdb，influxdb。相比 mysql 这样的传统数据库，这类系统在存储、查询上针对时间序列数据都做了特别的优化。当然对于需要复杂查询的报表类数据，mysql 也有它的优势。为了支持丰富的监控指标，我们希望找到更加合理的存储方案。
此外，监控系统存在失效问题，而且在保持监控系统足够简单的前提下，很难同时保证低误报（假阳性）与不漏报（假阴性）告警。结合业务特点，比较稳妥的方式是人工与自动化监控相结合。告警与展示数据同源，所有的告警指标都能在监控页面上反映出来，这样一方面人工能做交叉验证，另外一方面收到告警信息之后也能方便地查看相关数据。

需求

在系统选型前，有必要先梳理我们的需求：

业务指标类数据，需要表格展示，一般只关心最新状态
时间序列数据，按时间轴展开分析，如各种系统延时
开源，易扩展，方便二次开发
能够直观展示告警数据

技术框架选型

主流方案比较

Graphite

前几年开始流行的监控架构，由于其架构的开放性，软件生态相当丰富，每个主功能都能找到不同的替代品，其数据协议甚至已成为事实上的监控数据协议标准。但由于其低效的存储格式（见下文存储部分）及简陋的展示页面，给我们带来的潜在工作量可能更大。

TICK

TICK 是 influxdata 公司搞的一套开源监控软件栈 Telegraf, InfluxDB, Chronograf, Kapacitor 的缩写，分别与 Graphite 架构中的数据采集、存储、展示和告警模块对应，且与主流 Graphite 生态兼容。TICK 的核心在于 InfluxDB，一个高效且功能丰富的时间序列数据库；而 Chronnograf 与 Kapacitor 则相对没有那么惊艳；如果不考虑对 InfluxDB 的原生支持，Telegraf 也没有太突出的特点。

Prometheus

一套开箱即用型系统，但生态链并不如 Graphite 系完备，在存储、展示、二次开发等各方面也没有明显优势。

ELK

ELK 是 Elasticsearch, LogStash, Kiban 这一套日志分析软件栈的缩写。可对任意数据字段索引，适合多维度的数据查询，因此在存储时间序列数据方面与 InfluxDB 相比会有额外的性能和存储开销。强大的功能都是有代价的，我们暂时无此类需求。

open-falcon

小米的开源监控系统，使用者较少，且采用微服务架构，理解及部署都略显复杂，不过文档中提到的一些运维经验还是值得借鉴的。

分模块选型

为了避免绑死在一条船上，我们希望监控系统能采用开放性的架构，各个部件可以根据业务需要、开源社区发展程度进行调整。一般来说监控系统都有如下五个功能模块，我们将分别讨论。

收集
存储
展示
告警
分析

存储

首先最核心的是存储模块，数据的存储基本决定了展示和分析的形态。根据之前的运维经验，mysql 不是很适合大量的时间序列类数据的频繁写入存储，所以为了监控系统的方方面面，存储必须足够高效。其次，由于我们人手有限，不可能在一开始就大量投入开发时间，所以要求存储系统 简单易用 ，且 表达能力 足够满足基本查询、分析需要。
influxdb 采用简洁而高效的 TSM 文件结构，查询语言基本与 sql 一致，而且用 go 语言实现的程序效率和易用性都挺有保障：）
另外一个选择是 graphite，但由于其存储格式是固定时间间隔都要占坑，对于稀疏数据非常浪费空间；且每个 metric 都对应于一个独立的文件，同时写入多个 metric 会产生很多零碎的文件 IO 操作，已经有不少关于这方面性能问题的吐槽。
所以我们最后选择了 influxdb 作为存储系统。

采集

采集这方面已经有很多成熟的项目，如 collectd/stats/diamond，大同小异。然而，telegraf 是 influxdata 的亲儿子，它支持 influxdb 特有的 key 与 field 格式。毫无悬念的，既然上了 influxdb 的船，那就用 telegraf 呗。当然对于业务系统数据，可能会考虑直接往 influxdb 发送数据；telegraf 只负责采集系统级别的监控数据。

展示

TICK 架构里的 Chronogra 作为展示模块，功能过于简单，无法满足需求。而另外一个成熟的 Grafana 项目，从 Graphite 时代就发展起来，拥有丰富的展示功能，强大而方便的可配置界面和插件系统，且可以批量创建管理展示配置，最关键的是与 influxdb 适配也非常成熟稳定（influxdata 的支持），让我们别无选择。

告警

监控系统的成败就在于能否恰当地告警了。Grafana 自带报警功能，报警内容能在图标上直观地展示，这样出报警时可以方便查看报警情况，同时也方便运营同学平时有事没事 double check，避免因报警渠道阻塞而造成故障不能及时处理。不过 Grafana 的报警功能比较简单，只支持简单的阈值检查，所以这里还需要我们实现一些辅助分析，把复杂的报警需求转化成可以做简单阈值检查的指标书数据。
虽然 TICK 架构包含了 Kapacitor 这一告警子系统，但它并不能直接支持展示，且使用的是自己的 dsl，虽然足够强大但表达能力毕竟还是受限，学习成本过高却没有解决我们的问题。

分析

暂无复杂需求，沿用现有系统。

最终架构

Telegraf + Influxdb + Grafana + 二次开发，如图所示。

+--------+    +--------+   +-------+
|Telegraf+-+-->Influxdb+--->Grafana|
+--------+ |  +-+---+--+   +---+---+
           |    |   ^  |       v
+--------+ |    |   |  |   +---+---+
|Services+-+    +---+  +-->+ Alarm |
+--------+     Analyze     +-------+

监控内容

基础设施：硬件及操作系统
基础软件
- 服务存活：如 consul / airflow
- 服务健康度：如 apahce / mysql
业务系统
- 服务存活及资源使用情况
- 业务指标

坑（持续补充中）

influxdb

查询 / 插入语法中引号的用法非常魔性，一定要充分测试