新监控系统技术选型

原有系统及问题

我们原有的监控体系出于稳定和可靠性考虑,采用 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

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

你可能感兴趣的:(新监控系统技术选型)