Prometheus＋Grafana
概述
Prometheus是一个基于Metrics的监控系统，提供通用的数据模型和便捷的数据采集、存储和查询接口，通常配合图形化工具(如Grafana)实现友好的图形化和报警
现状
当前系统及服务器实时数据，缺乏直观体现，线上承载较大或数据异常时，无法及时定位问题，各项数据核查耗时较长，影响用户体验
针对以上情况，考虑引入Prometheus+Grafana组合，添加各项服务器系统数据指标及IM后台承载数据记录，有益于线上负荷超载直观体现及处理，同时可根据Grafana数据期间起伏表现评估当前系统承载上限，用户量/消息量/用户操作等对应时段取值
IM服务器实现
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
显示分块
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，其余时候只能增加。
- 方法：
- type Counter interface { Metric Collector // 自增1 Inc() // 把给定值加入到计数器中. 若值小于 0 会 panic Add(float64)}
- 常测量对象：
- 请求的数量
- 任务完成的数量
- 函数调用次数
- 错误发生次数
- …
2.2 Gauge
- 定义：表示一个可增可减的数字变量，初值为0
- 方法：
- type Gauge interface { Metric Collector Set(float64) // 直接设置成给定值 Inc() // 自增1 Dec() // 自减1 Add(float64) // 增加给定值，可为负 Sub(float64) // 减少给定值，可为负 // SetToCurrentTime 将 Gauge 设置成当前的 Unix 时间戳 SetToCurrentTime()}
- 常测量对象：
- 温度
- 内存用量
- 并发请求数
- …
2.3 Histogram
- 定义：Histogram 会对观测数据取样，然后将观测数据放入有数值上界的桶中，并记录各桶中数据的个数，所有数据的个数和数据数值总和。
- 方法：
- 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 类似，会对观测数据进行取样，得到数据的个数和总和。此外，还会取一个滑动窗口，计算窗口内样本数据的分位数。
- 方法：
- 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 类型测量的对象是比较接近的，但根据其实现方式和其本身的特点，在性能耗费、适用场景等方面具有一定差别，本文总结如下：
具体的PromQL的语法 可参考官网 https://prometheus.io/docs/prometheus/latest/querying/functions/
https://github.com/1046102779/prometheus
参考链接：https://www.bookstack.cn/read/prometheus_practice/promql-sql.md