监控解决方案调研记录

为什么监控?

整个系统, 按照服务拆分, 提高内部服务的可见性. 第一时间发现问题苗头. 从系统外缘监控是不够的, 需要在系统内部继续拆分监控. 监控的重要性不用赘述, 其难度也是不低. 对于一个HTTP API 响应慢这个事实不能帮助我们定位到低慢在哪里. 对于一个请求的响应处理过程中的重要环节, 从响应时间到失败率, 都需要加以监控. 此外, 细化到模块的监控, 也可以帮助我们快速定位系统瓶颈.

监控系统, 从组成部分来分:

从监控指标来分

总览

日志, 还是监控数据 ???

日志 / logs: 最详细的数据

监控指标 / metrics: 汇总之后的数据

监控指标 + 设计良好的图表, 可以帮助我们很快的定位问题.

日志, 基于等级的告警, 类似 sentry 服务, 只能挑重要的记录, 如错误, 警告等. 一个性能要求高的接口服务, 是不可能把每个请求的详细信息全部记录下来的, 系统负担太大.

经常对于日志的某些结构化的字段, 进行汇总告警, 比如说 警告数过多等 汇总后的数据我们也可以理解为日志的监控指标.

监控指标细分:

Ganglia

传统运维使用的工具.

Ganglia 面板使用直观感受: 界面太丑陋, 使用起来不够直观方便.

底层使用了 RRD 作为数据存储和绘图工具

Ganglia 通常需要在目标机器上部署 gmond 服务, 并通过配置各种插件从目标机器采集数据; 也可以通过调用 gmetric 命令, 主动上报数据.

Graphite

严格来说, Graphite只干两件事情:

系统架构

数据格式

<key> <numeric value> <timestamp>

标签信息只能在 中体现, 查找的时候需要用到正则. 另外也相当于需要把维度预先订立好, 不能够灵活的添加标签信息. 所以实际查询的时候不够灵活, 或者需要基于正则的筛选逻辑, 性能不行.

StatsD

问题: UDP丢包的问题

client 端做采样丢弃, client 端不做聚合, 每次请求都会产生数据, 造成发送的数据量很高.

Elastic 全家桶

作为监控系统来说还是不太适合. 数据采集端比较薄弱. 由于 ElasticSearch 是全文搜索引擎, 对于监控常见的数值聚合查询很差, 数据量大时不行.

InfluxDB

InfluxDB 时间序列存储引擎, 通过 HTTP API 接受数据, 提供类似SQL的查询语法

不满足与仅仅只做存储, 也要做全栈解决方案, TICK栈:

此外, 还提供了托管的云服务.

替代 RRD 以及 Graphite

支持多种插件, collectd, opentsdb, graphite 等.

Prometheus

来源于 Google 内部的 Borgmon 监控系统.

系统架构

InfluxDB vs Prometheus

监控指标数据类型

数据格式

个人认为InfluxDB的数据解析格式更有表达力, 尤其是在收集多个指标的场景, P需要重复输出多列冗余信息, 而I只用一行就可搞掂.

数据写入

查询语句

Go Client 支持

此外, Prometheus对于写入数据时间有限制, 对于有延迟的数据采集场景不太使用.

总结

虽然 Prometheus 被钦定了, 入了CNCF, 但是从个人口味来说, 更加偏好 InfluxDB. 由于SDK实现复杂, 我们项目中基于InfluxDB自己撸了一遍监控汇总的Client, 并结合服务注册, 提供了Pull方式的数据收集, 简化业务开发.

Grafana

一统天下的前端面板, 支持各种数据源. 比其他的面板高(neng)大(zhuang)上(bi)多了, 具体不多说了.

DataDog 服务

实现原理基于 Graphite + StatsD

数据格式上做了扩展, 支持额外的标签

metric.name:value|type|@sample_rate|#tag1:value,tag2

Reference

HOME