基于Prometheus的数据库监控

作者 金 戈 沃趣科技技术专家

传统监控系统面临的问题 Prometheus的前身:Borgmon Borgmon介绍 应用埋点 服务发现 指标采集与堆叠 指标数据存储 指标 指标的查询 规则计算 Prometheus 介绍 架构 数据库监控 部署服务端 部署exporter端

传统监控系统面临的问题

传统监控系统,会面临哪些问题? 以zabbix为例

初次使用需要大量配置,随着服务器和业务的增长会发现zabbix等传统监控面临很多问题:

  1. DB性能瓶颈,由于zabbix会将采集到的性能指标都存储到数据库中,当服务器数量和业务增长快速扩张时数据库性能首先成为瓶颈。
  2. 多套部署,管理成本高,当数据库性能成为瓶颈时首先想到的办法可能时分多套zabbix部署,但是又会带来管理很维护成本很高的问题。
  3. 易用性差,zabbix的配置和管理非常复杂,很难精通。
  4. 邮件风暴,邮件配置各种规则相当复杂,一不小心可能就容易造成邮件风暴的问题。

随着容器技术的发展,传统监控系统面临更多问题

  1. 容器如何监控?
  2. 微服务如何监控?
  3. 集群性能如何进行分析计算?
  4. 如何管理agent端大量配置脚本?

我们可以看到传统监控系统无法满足,当前IT环境下的监控需求

Prometheus的前身:Borgmon

2015年Google发表了一篇论文《Google使用Borg进行大规模集群的管理》

这篇论文也描述了Google集群的规模和面临的挑战

  1. 单集群上万服务器
  2. 几千个不同的应用
  3. 几十万个以上的jobs,而且动态增加或者减少
  4. 每个数据中心数百个集群

基于这样一个规模,Google的监控系统也面临巨大挑战,而Borg中的Borgmon监控系统就是为了应对这些挑战而生。

Borgmon介绍

那么我们来看一下Google如何做大规模集群的监控系统

应用埋点

首先,Borg集群中运行的所有应用都需要暴露出特定的URL,http://<app>:80/varz 通过这个URL我们就可以获取到应用所暴露的全部监控指标。

服务发现

然而这样的应用有数千万个,而且可能会动态增加或者减少,Borgmon中如何发现这些应用呢?Borg中的应用启动时会自动注册到Borg内部的域名服务器BNS中,Borgmon通过读取BNS中应用列表信息,收集到应用列表,从而发现有哪些应用服务需要监控。当获取到应用列表后,就会将应用的全部监控变量值拉取到Borgmon系统中。

指标采集与堆叠

当监控指标收集到Borgmon中,就可以进行展现或者提供给告警使用,另外由于一个集群实在是太过庞大了,一个Borgmon可能无法满足整个集群的监控采集和展现需求,所以一个数据中心可能部署多个Borgmon,分为数据收集层和汇总层,数据收集层会有多个Borgmon专门用来到应用中收集数据,汇总层Borgmon则从数据收集层Borgmon中获取数据。

指标数据存储

Borgmon收集到了性能指标数据后,会把所有的数据存储在内存数据库里,定时checkpoint到磁盘上,并且会周期性的打包到外部的系统TSDB。通常情况下,数据中心和全局Borgmon中一般至少会存放12小时左右的数据量,以便渲染图表使用。每个数据点大概占用24字节的内存,所以存放100万个time-series,每个time-series每分钟一个数据点,同时保存12小时数据,仅需17GB内存。

指标

指标的查询

Borgmon中通过标签的方式查询指标,基于标签过滤我们可以查询到某个应用的具体指标,也可以查询更高维度的信息 基于标签过滤信息,比如我们基于一组过滤信息查询到host0:80这个app的http_requests指标

我们也可以查询到整个美国西部,job为webserver的http_requests指标

那么这个时候拿到的就是所有符合条件的实例的http_requests指标

规则计算

在数据收集和存储的基础之上,我们可以通过规则计算得到进一步的数据。 比如,我们想在web server报错超过一定比例的时候报警,或者说在非200返回码,占总请求的比例超过某个值的时候报警。

Prometheus

介绍

Borgmon是Google内部的系统,那么在Google之外如何使用它呢?这里就提到我们所描述的Prometheus这套监控系统。Google内部SRE工程师的著作《Google SRE》这本书中,直接就提到了Prometheus相当于就是开源版本的Borgmon。目前Prometheus在开源社区也是相当火爆,由Google发起Linux基金会旗下的原生云基金会(CNCF)就将Prometheus纳入其下第二大开源项目(第一项目为Kubernetes,为Borg的开源版本)。

架构

Prometheus整体架构和Borgmon类似,组件如下,有些组件是可选的:

  • Prometheus主服务器,用来收集和存储时间序列数据
  • 应用程序client代码库
  • 短时jobs的push gateway
  • 特殊用途的exporter(包括HAProxy、StatsD、Ganglia等)
  • 用于报警的alertmanager
  • 命令行工具查询
  • 另外Grafana是作为Prometheus Dashboard展现的绝佳工具

数据库监控

基于Prometheus的数据库指标采集,我们以MySQL为例,由于MySQL没有暴露采集性能指标的接口,我们可以单独启动一个mysql_exporter,通过mysql_exporter到MySQL数据库上抓去性能指标,并暴露出性能采集接口提供给Prometheus,另外我们可以启动node_exporter用于抓取主机的性能指标。

部署服务端

对于服务端配置非常简单,由于Prometheus全部基于Go语言开发,而Go语言程序在安装方面非常方便,安装服务端程序只需要下载,解压并运行即可。可以看到服务端常用程序也比较少,只需要包含prometheus这个主服务程序和alertmanager这个告警系统程序。

服务端配置也非常简单,常用配置包含拉取时间和具体采集方式,就我们监控mysql数据库来讲,只需要填入mysql_exporter地址即可。

部署exporter端

对于mysql采集只需要配置连接信息,并启动mysql_exporter即可

完成配置之后即可通过mysql_exporter采集mysql性能指标

然后我们在prometheus服务端也可以查询到采集的mysql性能指标

基于这些采集指标和Prometheus提供的规则计算语句,我们可以实现一些高纬度的查询需求,比如用这个语句,increase(mysql_global_status_bytes_received{instance="$host"}[1h]) 我们可以查询MySQL每小时接受到的字节数,然后我们将这个查询放到Grafana中,就可以展现出非常酷炫的性能图表。

而目前结合Prometheus和Grafana的MySQL监控方案已经有开源实现,我们很轻松可以搭建一套基于Prometheus的监控系统

对于告警方面我们也可以基于Prometheus丰富的查询语句实现复杂告警逻辑 比如我们要对MySQL备库进行监控,如果复制IO线程未运行或者复制SQL线程未运行并且持续2分钟就发送告警我们可以使用如下这条告警规则。

# Alert: The replication IO or SQL threads are stopped.ALERT MySQLReplicationNotRunning  IF mysql_slave_status_slave_io_running == 0 OR mysql_slave_status_slave_sql_running == 0  FOR 2m  LABELS {    severity = "critical"  }  ANNOTATIONS {    summary = "Slave replication is not running",    description = "Slave replication (IO or SQL) has been down for more than 2 minutes.",  }

在比如,我们要监控MySQL备库延迟大于30秒并且预测在未来2分钟之后大于0秒持续1分钟,则告警

# Alert: The replicaiton lag is non-zero and it predicted to not recover within#        2 minutes.  This allows for a small amount of replication lag.ALERT MySQLReplicationLag  IF      (mysql_slave_lag_seconds > 30)    AND on (instance)      (predict_linear(mysql_slave_lag_seconds[5m], 60*2) > 0)  FOR 1m  LABELS {    severity = "critical"  }  ANNOTATIONS {    summary = "MySQL slave replication is lagging",    description = "The mysql slave replication has fallen behind and is not recovering",  }

当然在数据库方面不只是有MySQL的监控实现,目前业界也有很多其他开源实现,所以在数据库监控方面也能实现开箱即用的效果

  • mysql_exporter

https://github.com/prometheus/mysqld_exporter

  • redis_exporter

https://github.com/oliver006/redis_exporter

  • postgres_exporter

https://github.com/wrouesnel/postgres_exporter

  • mongodb_exporter

https://github.com/percona/mongodb_exporter

原文发布于微信公众号 - 沃趣科技(woqutech)

原文发表时间:2017-04-21

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Golang语言社区

Terratest:一个用于自动化基础设施测试的开源Go库

Gruntwork开源了他们的Go框架Terratest。该框架可以用于编写测试基础设施的自动化测试。该库内置了对Terraform和Packer的支持。

23030
来自专栏程序员的知识天地

为何Node.js 能成为 Web 应用开发最佳选择?【强推理由】

一项颠覆性的技术进入技术市场总会带来一阵震惊,但随之而来往往是被放弃。然而,Node.js 当然不是这样的情况,它是一个开源的、跨平台的基于 Chrome 的 ...

16610
来自专栏java一日一条

大型分布式网站架构技术总结

本文是学习大型分布式网站架构的技术总结。对架构一个高性能,高可用,可伸缩,可扩展的分布式网站进行了概要性描述,并给出一个架构参考。一部分为读书笔记,一部分是个人...

10020
来自专栏Netkiller

打破软件自动化测试的格局

打破软件自动化测试的格局 自动化测试的误区 自动化测试仅仅被认为是替代人工,所以我们看到很多企业实施自动化测试仅仅是将现有的 Test Case 转换成自动化脚...

42050
来自专栏Java技术交流群809340374

最新鲜的美团现场面试41题(三面技术+HR面):Redis+Kafka+分布式

互联网特别是电商平台,阿里双11秒杀、还有12306春运抢票、以及平时各种节假日抢购活动等,都是典型的高并发场景。

43900
来自专栏日暮星辰

Cloudflare 1.1.1.1公共DNS上线Cloudflare Public DNS

31620
来自专栏Java编程技术

乐观锁原理与实战演练

最近在做一个简单审批流程的项目,由于只有固定二级审批所以没有工作流组件,然后就遇到一个审批节点捞单时候,多个人同时审批时候如何保证业务正常运行的问题,我采用的就...

11120
来自专栏CSDN技术头条

实用简介:MQTT协议及其在物联网中的应用

MQTT (Message Queuing Telemetry Transport,消息队列遥测传输) 是一种标准化的发布/订阅消息传输协议,设计于1999年,...

47660
来自专栏架构师小秘圈

存储的瓶颈--大型网站技术演进思考

作者:夏天的森林 出处:cnblogs.com/sharpxiajun/p/4237704.html 一,题记 前不久公司请来了位互联网界的技术大牛跟我们做了一...

41480
来自专栏杨建荣的学习笔记

关于PV,流量和带宽(r5笔记第37天)

参加了DTCC归来之后,各大电商技术大牛都会自豪的分享一下自己公司网站的PV,流量等等。当时也是一知半解,回来之后赶紧查了查,也算是扫扫盲。 以下摘自网络中,自...

43640

扫码关注云+社区

领取腾讯云代金券