监控实时的可行性

监控

为什么要监控

引自《SRE:Google运维解密》的为什么要监控? + 商业产品在客户环境的可观测性增强

  • 分析长期趋势
    数据库目录数据量及增长速度

  • 构建监控指标
    根据下面介绍的4个黄金指标, 预警某指标设施出现故障或长期趋势会有潜在的问题

  • 预警、自愈及回溯
    发生阈值指标或故障主动通知进行报警, 或自启自愈方案
    回溯问题减少客户的操作性,提高用户体验感
    增强了监控指标,极大提升了可观测性, 回溯问题的处理会极大缩小员工的排错时间

4个黄金指标

《SRE:Google运维解密》的4个黄金指标

延迟

服务处理某个请求所需时间,区分成功和失败请求; “慢”错误要比“快”错误更糟

流量

某个高层次的指标针对系统负载需求所进行的度量
例如Web上的Qps、音频流媒体的网络IO速率、并发会话数量、存储系统的每秒事务数及读取操作数

错误

错误分显示(非200状态码),隐式(200码的包中含错误内容); 或者根据其他协议抓取内部错误异常

饱和度

内存受限中的使用情况、IO受限的IO情况、Cpu的利用率情况、磁盘空间饱和度预测
复杂场景高层次如Api负载率承接应对百分之多少的额外流量
延迟是增加饱和度的前导现象, 99%的请求延迟(例如分钟维度)可作为饱和度早期预警指标

度量四个黄金指标,某个指标出现故障发生报警,能做到这些,服务的监控就差不多了


长尾问题

定义

长尾请求一般是指请求时间明显高于均值的那部分占比较小的请求。 业界关于延迟有一个常用的P99标准,也就是99%的请求延迟要满足在一定耗时以内,1%的请求会大于这个耗时, 而这1%就可以认为是长尾请求。

危害举例

假设一个服务B，有1%的可能性响应时间大于1s，如果此刻一个上游服务A需要完成一次查询，需要同时查询100次的话，那么服务A响应时间超过1s的概率是63%。
怎么算的？ 0.99的概率是小于1s，100次的概率是0.99^100 = 0.37，小于1s响应的时间是37%的概率。

如何解决长尾

传统解决接口超时问题可能通过重试，在一次请求发送之后等待指定的超时时间，如果没有返回则再请求一次，最差情况下要消耗2倍的超时时间。
而双发机制则不然，在发送一次请求后等待 P90(在 T1 时间内有 90% 的请求都能返回则称 P90=T1，通常系统的 P90 和程序设置的超时时间相比小很多)时间。
如果请求没有返回则在此刻再次发送一次请求，在超时时间内，这两个请求中取最快返回的那个。

当然这里有个防雪崩机制，假如超过一定数量的请求(比如15%)都在进行双发，则认为服务整体有问题，会自动停止双发。实践证明，双发机制的去长尾效果非常明显
这里如果我们服务全部迁移成功, 可使用Dubbo的衍生ForkingClusterInvoker


Metric 时序指标

基本介绍

时序数据介绍

时序数据: 一种随着时间推移而发生各种变化事件的数据;常见于各种机器的用量监控、行为监控、金融的股票记录

这类的数据场景特性

  • 必带发生时间点
  • 数据量巨大以时间维度产生
  • 更关注变化趋势而不是数据本身
  • 实时性比较高不允许等待

时序数据模型->关系型数据模型

关系模型 时序模型 含义
table metric / measurement 表 → 指标（时间序列集合）
column value / field 列 → 值（无索引列）
index tag 索引 → 标签（索引列）
row point 记录行 → 数据点（时间序列中某个时刻的数据）
primary key timestamp 行主键 → 点时间戳（时间序列内唯一标识）

业务方向【业务层Agent单独埋点搜集】

  • 各业务Jvm jmx内存情况: Jvm Memory、Memory Pool、Gc、 线程及ClassLoad、物理内存情况
  • API方向侧: Api进入Broker的速度、Api进入Broker的大小、Api进入Broker的数量、消费单条Api消息的速率、消费单条Api的大小、消费单条Api的数量、Api处理异常次数搜集
  • 漏洞方向侧: 漏洞上报进Broker的速度、漏洞进入Broker的大小、漏洞进入Broker的数量、消费单条漏洞消息的速率、消费单条漏洞的大小、消费单条漏洞的数量、漏洞处理异常搜集
  • 三方组件侧: 三方组件上报进Broker的速度、三方组件进入Broker的大小、三方组件进入Broker的数量、消费单条三方组件消息的速率、消费单条三方组件的大小、消费单条三方组件的数量、三方组件处理异常次数搜集
  • 配置下发侧:

基础设施方向【基建设施层Categraf 开源Agent搜集】

  • Kafka: Topic数量情况、Partitions分区情况、Broker服务器情况、磁盘吞吐量情况、每个Topic(总消息数、未消费消息、剩余量)、消费偏移调整
  • Redis: redis连接数情况、现使用内存、最大内存限额、命令执行时序情况(执行频率top、命令种类时序、命中情况)、关键Key的时许情况(Key总量、过期&淘汰)
  • Pgsql: Qps时序、sharedBuffer、连表产生的临时对象、Select查询计划时序情况、慢查询Top10、当前LockWait语句Top5、连接数、client线程活动情况、网络流量、OpenFile打开句柄情况、OpenTable打开表情况
  • 主机: 总Cpu使用率、总内存使用率、总磁盘分区使用率、总设备io吞吐Top10、FD使用率、OOM次数、网络(出入流量时序、error、drop、tcp、socket)、磁盘(磁盘空间、fd使用、inode、读写错误、io await)、进程维度(进程数、每个进程的Cpu、每个进程的内存、每个进程的Swap内存、每个进程的磁盘IO写、每个进程的磁盘IO读、每个进程的线程数、每个进程的上下文切换、每个进程文件描述符打开数，每个进程文件描述符使用率(访问过/总打开Fd)、)
  • Es:Es集群、Es节点数、Es数据节点、EsCPU平均使用率、存活的所有分片、存活的主分片、Unassigned分片、Gc的次数和时间、事务日志操作时间、事务日志操作大小、Cpu和内存情况、每个节点文档数量、文档倒排索引率、文档删除率、文档merge合并率、文档merge大小、文档查询时间、文档索引时间、文档merge时间、Es各操作类型时间占比、Es各操作类型数量比率(flus\fetch\query\indexing\get_exists\get_missiong\refres、merges)、Segment段的数量

Log 日志【日志与漏洞业务共享Es】

业务的es承担日志集中化存储 + 日志周期性清理

服务端日志集中化【开源filebeat搜集】

Es承担proxy、core、data的业务日志

Agent实时日志集中化【自研Agent实时日志方案】

Es承担各个Agent的实时日志搜集

Error级别日志报警联动

Es遇到Error级别的日志,联动告警

告警管理

告警规则&生效条件【开源嵌套】

  • 自定义Metric的规则
  • Error级别的Log日志
  • 生效时间范围段

通知媒介【开源嵌套】

  • 通知配置: 通知媒介(dingtalk\email\feishu)
  • 警报接受组 —> Astp管理员?用户组关联?孝道开发人员?
  • Webhook回调地址

自愈管理【开源嵌套】

  • HPA 实现单词扩容消除警报, 若扩容超过一次未解决则报警
  • HPA所适用于(Kafka\Es)

开源参考