Hacking Limbo

Reading / Coding / Hacking

新监控方案一览

需求

  • Storage - 存得快,读得也快,不要丢数据。
  • Collect - 去中心化的数据收集,要能方便扩展。
  • Alert - 发邮件,发短信,发 Pushbullet.
  • Dashboard - 看各种趋势 & 发现异常。

Storage (Time Series DB)

从最近看的几篇文章来判断,InfluxDB / Graphite 的数据存储问题让大家都很头疼,然后解决方案有以下几种方向:

  1. 怪物级存储 OpenTSDB——首先,你要有个 HBase——首先,你要把 Hadoop 搭起来。据说物超所值,但是看起来有点恐怖。
  2. 新的工具,比如 SoundCloud 的 Prometheus.
  3. 用更「成熟」的存储后端,比如 ElasticSearch / PostgreSQL / MySQL (seriously!?).

Prometheus 看起来很不错,但是它是各种组件集成在一起的方案,目测不支持 Graphite 协议。现有的 StatsD 和 collectd 什么的会比较难迁移,除非 LogStash 里的 Nginx 日志数据统计能转交给其他 plugin 来做,比如写进 Redis 然后再转发给 Prometheus? 又或者新写一个 LogStash 插件。

OpenTSDB 是个比较神奇的存在,目测有不少工具都支持写入(或者是有计划支持)。但如上所述,太折腾。

小米开源的那个 Open-Falcon,目测存储组件山寨了 Graphite 的 whisper,存储策略都是采样归档,猜测会有同样的 IO 性能问题——而且从 README 的描述来看,归档策略比 Graphite 更不灵活。

自己基于 ElasticSearch / PostgreSQL / MongoDB 瞎搞的话要做好多工作,很容易造出方轮子。

Collect

分为两部分,一是各种系统指标(health check),二是线上应用的数据打点。

系统指标目前来看 collectd 做得还算不错(虽然前阵子遇到机器数据收集中断,不知道怎么回事),比Diamond 好多了。数据传输路径是 collectd -> carbon-relay-ng -> InfluxDB,以 Graphite text protocol 通信。可以考虑在每台机器上跑一个 carbon-relay-ng 实例(开销很低),利用它的 disk spool 降低数据丢失几率。

数据打点现在的做法是写进日志扔给 LogStash 处理之后把数值转发到 StatsD,后者再写进 InfluxDB(以 Graphite text protocol 通信),路径略长,但(貌似)不可避免——除非在 Nginx 里用 log_by_lua 记录数据(好处是可以跳过 LogStash 那不太可靠的 Nginx Access Log 解析)。

Collect 环节跟 Storage 的耦合度最高,如果两端都支持 Graphite 或 StatsD 协议的话会很省事。

Alert

Nagios / Icinga2 都是 pull-based 的,每个 poll interval 去轮询所有 hosts / services,发现异常就告警——缺点在于,轮询很费时费资源(难道 1000 个指标要开 1000 个线程去查询?),而且做了很多在 Collect 环节已经做过的重复工作。

Sensu 的架构看起来很高级,但是太过累赘,一个依赖 Redis 和 RabbitMQ 才能正常工作的工具,本身就不够省心。

Riemann 大概是所有工具里最灵活的,配置文件就是 Clojure 源代码,可以写出很复杂的告警判断策略。但是:

  1. 目前好像还没有遇到这么复杂的告警需求。
  2. 它的通信协议是 protobuf,跟其他工具集成有点麻烦。
  3. 没有分布式方案,每台机器跑一个实例又浪费资源(提示:JVM)。
  4. 提供的接口太底层,需要自己封装各种上层逻辑,比如「5 分钟内失败 N 次就发告警」。

flapjack 大概是个合适的方案,初始设计基于 Nagios event broker,也有 HTTP Broker 可以接收第三方工具的 push events. 组件分成 Server 和 Receiver 两部分,中间通过 Redis 通信(呃)。亮点是自带 Web UI 可以处理告警。

Dashboard

Grafana 目前能满足「看各种趋势 & 发现异常」的需求,但是浏览器的图形渲染性能实在太糟糕,渲染一周的数据要卡差不多一分钟,看一个月的数据就跟开 Flash 一样了(可能也跟 InfluxDB 有关系)。缺少更灵活的查询入口,所有的 Graph 都是一个个提前建好的,略繁琐。另外严重依赖存储后端的计算能力,比如 Graphite 后端支持的运算明显多于 InfluxDB 后端(不知道 2.0 版本有没有改进)。

其他的 Dashboard 看起来都挺烂。