Prometheus+Grafana

概述

Prometheus是一个基于Metrics的监控系统,提供通用的数据模型和便捷的数据采集、存储和查询接口,通常配合图形化工具(如Grafana)实现友好的图形化和报警

现状

当前系统及服务器实时数据,缺乏直观体现,线上承载较大或数据异常时,无法及时定位问题,各项数据核查耗时较长,影响用户体验

针对以上情况,考虑引入Prometheus+Grafana组合,添加各项服务器系统数据指标及IM后台承载数据记录,有益于线上负荷超载直观体现及处理,同时可根据Grafana数据期间起伏表现评估当前系统承载上限,用户量/消息量/用户操作等对应时段取值

IM服务器实现

1.引入第三方库https://github.com/deadtrickster/prometheus.erl

2.确定各项指标及类型(4种类型,下面会简单介绍),获取服务器实时数据,加入metrics统计

 

ps: 

在msync中的metrics, 对应的是easemob_metrics_statisti.erl 模块,首先在常量宏 METRICS添加配置,再到需要调用的模块添加即可(

inc_counter/2,  observe_summary/2,  observe_histogram/2 ) ,

granfana的效果,根据promql 调整需要即可。   参考: https://www.bookstack.cn/read/prometheus_practice/promql-sql.md

而直方图的纵坐标默认值是配的常量宏 INITBUCKETS,

-define(INITBUCKETS, [1000, 2000, 3000, 4000, 5000, 6000]).

可在app.config配置文件,根据实际情况添加对应的步阶,如{shumei_http_request_time,[100,200,400,800,1000,3000]},

表示请求数美接口的响应时长的分段,再在grafana 添加heatmap图。

 

3.提供http服务,暴露metrics接口,供grafana拉取数据(自定义间隔时间,循环拉取)

Metrcs引入服务器版本

Msync18.4.1/Ejabberd 18.4.1

目前集成数据项(数据项:关键字/类型)

消息相关

上行消息累计:outgoing/counter

下行消息累计:incoming/counter

离线消息累计:offline/counter

ACK消息累计:ack/counter

连接相关

单机连接:user_clients/gauge

登录累计:login/counter

登出累计:logout/counter

好友操作相关(release-18.6.1添加)

好友操作:roster_operation/counter

好友操作延时:roster_operation_time/summary

好友操作失败累计:roster_operation_fail/counter

好友操作(add/accept/remove/decline/ban),好友操作error统计

网络数据相关

数据包发送大小:sp_size_sum/summary (byte)

数据包收取大小:rp_size_sum/summary(byte)

服务器状态

消息队列堆积:message_queue_len/gauge

错误日志统计:error_log/counter

Pika访问延时:invoke_pika_time/summary(μs)

Ejabberd功能节点rpc延时:rpc_time_sum/summary(μs)

Ejabberd功能节点rpc延时:rpc_time_dis/histogram

Msync客户端sync操作延时:msync_sync_time/histogram

ErlangVM数据

虚拟机进程数:erlang_vm_process_count/gauge

虚拟机端口占用:erlang_vm_port_count/gauge

虚拟机系统/进程内存消耗:erlang_vm_memory_bytes_total/gauge

数美:

数美http接口请求数量 : shumei_http_requests_total

数美http接口请求延迟 : shumei_http_response_time

登录鉴权验证:auth_error

服务器Metrics拉取接口

msync: curl -i -X GET "http://hostname:8083/api/metrics"

 

 ejabberd: curl -i -X GET -H "Authorization: Bearer Token" "http://hostname:5280/api/metrics" 

Grafana

地址:http://39.106.255.7:81

显示分块

IM服务器单机信息:ebs|vip6 im单机信息

IM ebs信息汇总:ebs im 汇总

IM vip6信息汇总:vip6 im 汇总

线上故障示例

1.关注信息汇总模块,总览节点信息(节点连接数是否均衡/CPU使用是否超载),筛选是否个别节点异常(线上异常多由单个或几个节点异常导致)

2.针对异常节点,筛选单机信息模块,关注"服务器状态"指标,对比正常时段与故障时段数据是否存在明显偏差(主要关注消息队列,线上负载多由消息队列堆积导致)

3.若发现异常项,则针对异常项,对症下药

Prometheus Metrics 是整个监控系统的核心,所有的监控指标数据都由其记录。Prometheus 中,所有 Metrics 皆为时序数据,并以名字作区分,

即每个指标收集到的样本数据包含至少三个维度的信息:名字、时刻和数值。

Prometheus有4大指标类型(Metrics Type),分别是Counter(计数器)、Gauge(仪表盘)、Histogram(直方图)和Summary(摘要):

  • Counter: 只增不减的单变量
  • Gauge:可增可减的单变量
  • Histogram:多桶统计的多变量
  • Summary:聚合统计的多变量

此外,Prometheus Metrics 中有一种将样本数据以标签(Label)为维度作切分的数据类型,称为向量(Vector)。四种基本类型也都有其 Vector 类型:

  • CounterVec
  • GaugeVec
  • HistogramVec
  • SummaryVec

Vector 相当于一组同名同类型的 Metrics,以 Label 做区分。Label 可以有多个,Prometheus 实际会为每个 Label 组合创建一个 Metric。Vector 类型记录数据时需先打 Label 才能调用 Metrics 的方法记录数据。

如对于 HTTP 请求延迟这一指标,由于 HTTP 请求可在多个地域的服务器处理,且具有不同的方法,于是,可定义名为 http_request_latency_seconds 的 SummaryVec,标签有region和method,

以此表示不同地域服务器的不同请求方法的请求延迟。

以下将对每个类型做详细的介绍。

2.1 Counter

  • 定义:是单调递增的计数器,重启时重置为0,其余时候只能增加。
  • 方法:
  1. type Counter interface { Metric Collector // 自增1 Inc() // 把给定值加入到计数器中. 若值小于 0 会 panic Add(float64)}
  • 常测量对象:
  • 请求的数量
  • 任务完成的数量
  • 函数调用次数
  • 错误发生次数

2.2 Gauge

  • 定义:表示一个可增可减的数字变量,初值为0
  • 方法:
  1. type Gauge interface { Metric Collector Set(float64) // 直接设置成给定值 Inc() // 自增1 Dec() // 自减1 Add(float64) // 增加给定值,可为负 Sub(float64) // 减少给定值,可为负 // SetToCurrentTime 将 Gauge 设置成当前的 Unix 时间戳 SetToCurrentTime()}
  • 常测量对象:
  • 温度
  • 内存用量
  • 并发请求数

2.3 Histogram

  • 定义:Histogram 会对观测数据取样,然后将观测数据放入有数值上界的桶中,并记录各桶中数据的个数,所有数据的个数和数据数值总和。
  • 方法:
  1. type Histogram interface { Metric Collector // Observe 将一个观测到的样本数据加入 Histogram 中,并更新相关信息 Observe(float64)}
  • 常测量对象:
  • 请求时延
  • 回复长度
  • …各种有样本数据
  • 具体实现:Histogram 会根据观测的样本生成如下数据:

inf 表无穷值,a1,a2,…是单调递增的数值序列。

  • [basename]_count: 数据的个数,类型为 counter
  • [basename]_sum: 数据的加和,类型为 counter
  • [basename]_bucket{le=a1}: 处于[-inf,a1]的数值个数
  • [basename]_bucket{le=a2}: 处于[-inf,a2]的数值个数
  • [basename]_bucket{le=<+inf>}:处于[-inf,+inf]的数值个数,prometheus默认额外生成,无需用户定义
  • Histogram 可以计算样本数据的百分位数,其计算原理为:通过找特定的百分位数值在哪个桶中,然后再通过插值得到结果。比如目前有两个桶,分别存储了[-inf, 1]和[-inf, 2]的数据。然后现在有20%的数据在[-inf, 1]的桶,100%的数据在[-inf, 2]的桶。那么,50%分位数就应该在[1, 2]的区间中,且处于(50%-20%) / (100%-20%) = 30% / 80% = 37.5% 的位置处。Prometheus计算时假设区间中数据是均匀分布,因此直接通过线性插值可以得到 (2-1)*3/8+1 = 1.375.

2.4 Summary

  • 定义:Summary 与 Histogram 类似,会对观测数据进行取样,得到数据的个数和总和。此外,还会取一个滑动窗口,计算窗口内样本数据的分位数。
  • 方法:
  1. type Summary interface { Metric Collector // Observe 将一个观测到的样本数据加入 Summary 中,并更新相关信息 Observe(float64)}
  • 常测量对象:
  • 请求时延
  • 回复长度
  • …各种有样本数据
  • 具体实现:Summary 完全是在client端聚合数据,每次调用 obeserve 会计算出如下数据:
  • [basename]_count: 数据的个数,类型为 counter
  • [basename]_sum: 数据的加和,类型为 counter
  • [basename]{quantile=0.5}: 滑动窗口内 50% 分位数值
  • [basename]{quantile=0.9}: 滑动窗口内 90% 分位数值
  • [basename]{quantile=0.99}: 滑动窗口内 99% 分位数值

实际分位数值可根据需求制定,且是对每一个 Label 组合做聚合。

 

2.5 Histogram 和 Summary 简单对比

可以看出,Histogram 和 Summary 类型测量的对象是比较接近的,但根据其实现方式和其本身的特点,在性能耗费、适用场景等方面具有一定差别,本文总结如下: