java诊断与链路追踪监控
2023-03-25 22:12:01 2 举报AI智能生成
java代码链路追踪，系统APM,系统级别监控如何实现
作者其他创作
大纲/内容
CAT（Central Application Tracking）是一个实时和接近全量的监控系统
侧重于Java应用的监控
产品定位
mvc框架
rpc框架
持久层框架
分布式缓存框架
提供各项性能监控，健康检查，自动报警
应用场景
时间越久，监控的信息价值会锐减
实时处理
监控的是所有的请求数据
应用服务挂了，监控还在，可以辅助排查定位问题
高可用
全量数据的接收和处理能力
高吞吐
全量数据
监控本身的故障不会影响业务代码的正常运行
故障容忍
支持分布式，跨IDC部署，横向扩展的监控系统
可扩展
cat监控系统的可靠性可以做到四个九
不保证可靠
cat系统的设计要求
应用应用埋点的底层sdk，的客户端
CAT-client
实时消费，处理客户端提供的数据
CAT-consumer
给用户展示的控制端平台
CAT-home
结构展示
主要分为三个模块
1、为每一个线程创建一个ThreadLocal(线程局部变量)；
请求对应的上下文其实是一个监控树的结构
2、执行业务逻辑的时候，就把请求对应的监控信息存储在线程的局部变量中
3、业务线程执行结束之后，将监控对象放入一个异步内存队列中；
4、cat会有一个消费线程将异步队列中的信息发送给服务端；
客户端信息收集
一段代码运行时间，次数
Transaction
一行代码的执行次数
Event
jvm内部的一些状态信息，Memory.Thread等
Heartbeat
一个请求调用的链路统计
Metric
核心监控对象
cat序列化协议是cat自己自定义的协议
序列化
netty来实现nio
通信
序列化和通信设计
cat报表数据
cat原始logview数据
存储设计
子主题
设计图
1、客户端向服务端发送消息基于netty-nio实现
2、服务端接受消息放入内存队列，开起一个线程消费来分发这个内存队列中的消息
3、消息解析完成站会，存入本地磁盘，然后再异步上传到HDFS
流程说明
总个数
总和
均值
最大，最小
吞吐
95线，99线，999线
实时分析
整体架构设计图
cat整体设计
cat
链路追踪工具
链路追踪
通俗来讲，ELK就是
ELK
分布式日志系统
线上监控诊断产品
大大提升线上问题排查效率
产品自我定位
性能剖析（performance profiling）和代码优化
Perf
新名词学习
https://blog.csdn.net/web18224617243/article/details/123953692
https://blog.csdn.net/Cr1556648487/article/details/126816451
https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html
https://arthas.aliyun.com/doc/getstatic.html
指标参数说明参考文档
jit编译花费的总时间
java.ci.totalTime
统计指标项目学习
logger
查看 logger 信息，更新 logger level
perfcounter
查看当前 JVM 的 Perf Counter 信息
profiler
生成发放火焰图
heapdump /tmp/dump.hprof
下载当前内存信息到某个目录下
heapdump
下载当前内存信息
jvm
查看当前 JVM 信息
查看jvm当前内存信息
memory
查看 JVM 内存信息
最忙的几个
所有
查看当前线程信息，查看线程的堆栈
内存相关
dump
dump 已加载类的 bytecode 到特定目录
反编译指定已加载类的源码
编译.java文件生成.class
sc
查看 JVM 已加载的类信息
sm
查看已加载类的方法信息
vmtool 利用JVMTI接口，实现查询内存对象，强制 GC 等功能。
编译文件相关
monitor
方法执行监控
stack
输出当前方法被调用的调用路径
trace
方法内部调用路径，并输出方法路径上的每个节点上耗时
tt
方法执行数据的时空隧道，记录下指定方法每次调用的入参和返回信息，并能对这些不同的时间下调用进行观测
watch
函数执行数据观测
方法监控
查看当前 JVM 的环境属性
查看当前 JVM 的系统属性
vmoption
查看指定参数
更新指定的 option
查看，更新 VM 诊断相关的参数
参数查看
常用命令
dashboard
当前系统的实时数据面板，按 ctrl+c 退出
当前系统的实时数据面板
getstatic
预览
查看当前类静态属性
查看 classloader 的继承树，urls，类加载信息
输出当前目标 Java 进程所加载的 Arthas 版本号
预览命令
打印文件内容，和 linux 里的 cat 命令类似
history
打印命令历史
文件相关
命令列表
和linux系统类似
一段采样间隔时间内，当前 JVM 里各个线程的增量 cpu 时间与采样间隔时间的比例
首先第一次采样，获取所有线程的 CPU 时间(调用的是java.lang.management.ThreadMXBean#getThreadCpuTime()及sun.management.HotspotThreadMBean.getInternalThreadCpuTimes()接口)
然后睡眠等待一个间隔时间（默认为 200ms，可以通过-i指定间隔时间）
再次第二次采样，获取所有线程的 CPU 时间，对比两次采样数据，计算出每个线程的增量 CPU 时间
线程 CPU 使用率 = 线程增量 CPU 时间 / 采样间隔时间 * 100%
具体步骤
把统计的时间拉长可以降低命令本身执行的时间损耗
注意事项
cpu 使用率是如何统计出来的？
实现原理
1:查看应用 load、内存、gc、线程的状态信息
查看方法调用的出入参
查看方法异常
监测方法执行耗时
类加载信息
2:可在不修改应用代码的情况下，对业务问题进行诊断
功能概述
arthas-阿尔萨斯
诊断工具
1、快速发现故障
2、快速定位故障
3、辅助进行程序性能优化
监控系统的要求
Overview
Threading
GC
CPU
Heap
jvm监控
基础资源监控
接口路径
调用总数
最大并发
平均QPS
总耗时
平均耗时
99线
95线
999线
最快
最慢
错误数
接口链路
接口入参回参
接口调用
连接池中链接数
连接池链接数峰值
池中连接数峰值时间
活跃连接数
活跃连接数峰值
数据源监控
SQL语句
执行数
执行时间
读取行数
更行行数
慢SQL
JDBC访问监控
异常类型
异常方法：
异常时间
异常数量
堆栈信息
Exception监控
应用监控
订单数量，支持成功数，点击次数，下载次数
Cache命中率
队列大小
业务自定义
业务监控
监控维度
应用自监控，就是每个应用实例的监控数据存放在应用本身，比如一个Map。然后通过JMX或者其他方式暴露出去。然后开发人员可以通过JConsole或者API（一般是Web界面）得到这些监控数据。比如Druid就是这种做法。访问: hk01-xxxx-mob03.hk01:8090/druid/index.html 得到hk01-xxxx-mob03.hk01:8090这个应用的监控数据。
自监控
统一上报监控方式，就是所有的应用监控数据都上报到监控中心，由监控中心负责接收、分析、合并、存储、可视化查询、报警等逻辑。这种方式是瘦客户端模型，客户端的职责就是埋点上报监控数据。所有的监控逻辑都在中心处理
统一监控
自监控的话实现起来简单，并且没有与监控中心的网络交互，性能也会好很多。但是缺点就是缺乏全局的统计和监控。从实用角度来说还是集中式监控好一些。
结论
1、每个应用自监控或者统一上报监控？
一个物理机上的多台服务器通过一个统一的agent向监控中心上报监控数据
agent上报
一个物理机上的多台服务器各自向监控中心上报统计数据
独立上报
网络通常的情况下，直接独立上报
2、监控中心与客户端应用之间要不要通过本地Agent上报？
经过业务逻辑的处理，得到相关的统计数据，然后再做储存
最终状态
直接就存储上报的统计信息本身的数据
事件序列
最终状态还是弱了一些，事件序列会好一些，存储可以采用HBase这样的分布式存储系统，性能问题可以采用预聚合等方式解决
3、存储最终状态还是事件序列
因为Events或者Metrics的特殊性，一般都会采用一种专门的存储结构——Distributed time series database
RRD(round-robin-database): RRDtool使用的底层存储。C语言编写的。性能比较高
prometheus: An open-source service monitoring system and time series database. 目前只有单机版本。
OpenTSDB: 基于HBase编写的Time Series Database
如果要存储事件序列，那么InfluexDB和OpenTSDB是个非常不错的选择。都是可扩展，分布式存储，文档很详细，还是开源的。 influexDB 0.9.0之后支持tag，使用风格跟Google Cloud Monitor很相似，而且支持String类型。并且最重要的是不需要额外搭建HBase(Thus Hadoop & Zookeeper)，看起来非常值得期待，不过截至今天0.9.0还是RC阶段(非Stable)。OpenTSDBvalue不支持String类型，这意味着日志不能上报到OpenTSDB，需要另外处理。
4、数据存储
前期可以先丢弃，后续要缓存起来。受影响比较大的是counter接口。
5、如果服务器挂掉了，统计数据怎么处理？缓存本地，等服务器起来再发送？还是丢弃？
同时要考虑同步和异步接口
如何高性能的接收大量客户端的上报请求。以及使用什么通讯协议
6、网络通信和协议
监控方案设计
redis自带的info命令和monitor命令的相关信息
redis监控实现原理
应用
jdk1.5版本之后引入的特性
jdk1.6可以支持更加强大的Instrument
历史
在class被加载之前对其进行拦截，然后插入自定义的监听代码
无需对原有的应用做出任何代码修改，可以实现对类的动态修改和增强
可以理解是jvm级别的AOP
作用
1、jvm启动的时候会伴随一个java-agent的jar包附加程序启动
2、这个java agent保中的配置文件中指定代理类，代理类中会有一个premain方法
3、jvm在类加载的时候会执行代理类的premain方法，再执行java程序本身的main方法
4、prmain方法可以对加载前的class文件进行修改
详细流程
详细流程图
java-agent实现监听流程
1、通过Java Instrumentation 接口进行变成
2、Instrumentation接口的实现是通过jvm虚拟机提供的native接口来实现
java-agent实现
https://blog.csdn.net/m0_69305074/article/details/124504419
实战demo
java agent技术
链路追踪实现原理
全称Java Management Extensions，jdk5引进的技术
获取类装载信息，已装载、已卸载量
ClassLoadingMXBean
获取编译器信息
CompilationMXBean
获取GC信息，但他仅仅提供了GC的次数和GC花费总时间
GarbageCollectionMXBean
提供了内存管理和内存池的名字信息
MemoryManagerMXBean
提供整个虚拟机中内存的使用情况
MemoryMXBean
提供获取各个内存池的使用信息
MemoryPoolMXBean
提供操作系统的简单信息
OperatingSystemMXBean
提供运行时当前JVM的详细信息
RuntimeMXBean
提供对线程使用的状态信息
ThreadMXBean
接口功能
java.management包下提供接口
JMX 提供了简单、标准的监控和管理资源的方式
概述
包含 MBean 及其可管理的资源
提供了实现 JMX 技术可管理资源的规范
资源层
充当 MBean 和应用程序之间的中介
代理层
为远程程序提供Connector 和 Adapter访问 MBean Server
远程管理层
分层
架构图
JMX架构
实现对运行时应用程序动态资源查询
利用JMX创建javaBean规则
修改对运行时应用程序动态资源配置
核心功能
1、创建需要被存入进程的对象；
2、对象必须是接口，且必须以MBean结尾
具体规则
public interface BlackListMBean { // 获取黑名单列表 public String[] getBlackList(); // 在黑名单列表中添加一个用户 public void addBlackItem(String uid); // 判断某个用户是否在黑名单中 public boolean contains(String uid); // 获取黑名单大小 public int getBlackListSize();}
创建接口
public class BlackList implements BlackListMBean { private Set<String> uidSet = new HashSet<>(); @Override public String[] getBlackList() { return uidSet.toArray(new String[0]); } @Override public void addBlackItem(String uid) { uidSet.add(uid); } @Override public boolean contains(String uid) { return uidSet.contains(uid); } @Override public int getBlackListSize() { return uidSet.size(); }}
实现接口
// 获取 MBean ServerMBeanServer platformMBeanServer = ManagementFactory.getPlatformMBeanServer();// 创建 MBean 初始黑名单用户为 a 和 bBlackList blackList = new BlackList();blackList.addBlackItem(\"a\");blackList.addBlackItem(\"b\");// 注册ObjectName objectName = new ObjectName(\
MBean 注册到 MBeanServer
String hostname = \"localhost\
演示
开通远程接口调用权限
-Dcom.sun.management.jmxremote.port=8888 --表示远程jmx的端口-Dcom.sun.management.jmxremote.authenticate=false --是否要使用用户名和口令验证-Dcom.sun.management.jmxremote.ssl=false --是否使用安全socket
添加jvm配置
登录远程jvm
demo
JMX创建javaBean规则
Java内置的实现监控工具 jconsole
jconsole
已经实现的应用
https://blog.csdn.net/weixin_35346265/article/details/114064440
https://blog.csdn.net/SunnyYoona/article/details/125154198
https://blog.csdn.net/weixin_42741805/article/details/116855285
https://blog.csdn.net/vincentff7zg/article/details/54582549
参考文档
JMX
jvm内存监控实现原理
公开了节点、连接、队列、消息速率等的RabbitMQ指标
监控系统与被监控系统交织在一起
占用系统一定的开销
它只存储最近的数据（最多一天，不是几天天或几个月）
它有一个基本的用户界面
它的设计强调易用性，而不是最佳可用性
管理UI访问通过RabbitMQ权限标记系统（或JWT令牌作用域的约定）进行控制
限制
RabbitMq自带管理平台
后端命令行工具
rabbitmqctl命令
直接通过接口查询各种相关的监控信息
REST API
监控工具实现
rabbitMq
mqadmin–提供一套命令行工具
RocketMQ
消息队列监控实现原理
监控系统实现底层技术总结
Prometheus是一个开源的系统监控和警报工具包
最初由SoundCloud构建。自2012年成立以来，许多公司和组织都采用了Prometheus，该项目拥有非常活跃的开发人员和用户社区。它现在是一个独立的开源项目，独立于任何公司进行维护
Prometheus于2016年加入了云原生计算基金会，成为Kubernetes之后的第二个托管项目
1、一个多维数据模型，其时间序列数据由度量名称和键/值对标识
2、有自己独有的的查询语言，PromQL
Prometheus有具体的接口可以提供查询指标数据
对应的第三方的支持将数据导入到第三方
但是可以把采集到的数据再次被同步到其他平台，或者数据存储库
3、不依赖分布式存储;单个服务器节点是自治的
4、(统计指标)收集通过HTTP上的拉模型进行
5、通过中间网关支持推送(统计指标)时间序列
6、被采集的服务是通过服务发现或者静态配置的
7、支持多种模式的图形化和仪表板
特点
1、主服务器，用于采集存储统计指标数据
2、搭载在各种客户端库数据采集器
3、数据推送网关
4、各种导出组件
5、告警组件
6、支持各种第三方工具
具体组件
架构
1、以机器为核心的监控
2、多维度手机和查询数据
3、可靠性
使用场景
Prometheus收集到的数据并不是非常详细完整
1、需要百分之百保证数据准确性
不适合的场景
Prometheus相关介绍
例如，您可以使用计数器来表示服务的请求、完成的任务或错误的数量
计数器是一种累积度量，表示一个单调递增的计数器，其值只能在重新启动时增加或重置为零
总和 Counter
内存使用的最大子，最小值
度量是指表示单个数值的度量，该数值可以任意上下波动
Gauge
直方图对观测值进行采样(通常是请求持续时间或响应大小)，并将它们计数在可配置的桶中
Histogram
与直方图类似，摘要对观察结果进行抽样(通常是请求持续时间和响应大小)。虽然它也提供了观测的总数和所有观测值的总和，但它可以在滑动时间窗口上计算可配置的分位数。
Summary
Prometheus客户端库提供了四种核心指标类型
Prometheus统计指标
广义上讲所有可以向Prometheus提供监控样本数据的程序都可以被称为一个Exporter，Exporter的一个实例称为target
数据导出器
社区
需要根据基于Prometheus提供的Client Library创建自己的Exporter程序
Promthues社区官方提供了对以下编程语言的支持：Go、Java/Scala、Python、Ruby
用户自定义
导出器来源
需要独立部署的
MySQL Exporter、Redis Exporter等都是通过这种方式实现
独立使用
为了能够更好的监控系统的内部运行状态，有些开源项目如Kubernetes，ETCD等直接在代码中使用了Prometheus的Client Library，提供了对Prometheus的直接支持。这种方式打破的监控的界限，让应用程序可以直接将内部的运行状态暴露给Prometheus，适合于一些需要更多自定义监控指标需求的项目。
集成到应用中
导出器的运行方式
需要在自定义的程序中引入prometheus的依赖包，且需要和prometheus定义通讯连接
自定义export
Exporter
这种方式一般都是新项目
使用官方提供的jar包，然后嵌入到应用中
prometheus的jmx_exporter
https://blog.csdn.net/qq_25934401/article/details/82185236
https://blog.csdn.net/penngo/article/details/126982183
具体监控实施文档
监控方式
Prometheus 监控 Java 应用
CAdvisor是Google开源的一款用于展示和分析容器运行状态的可视化工具
通过在主机上运行CAdvisor用户可以轻松的获取到当前主机上容器的运行统计信息，并以图表的形式向用户展示
CAdvisor默认只保存2分钟的监控数据
CAdvisor已经内置了对Prometheus的支持
介绍
用户不用再登录到服务器中即可以可视化图表的形式查看主机上所有容器的运行状态
相对于docker命令行工具
container_cpu_load_average_10s gauge 过去10秒容器CPU的平均负载container_cpu_usage_seconds_total counter 容器在每个CPU内核上的累积占用时间 (单位：秒)container_cpu_system_seconds_total counter System CPU累积占用时间（单位：秒）container_cpu_user_seconds_total counter User CPU累积占用时间（单位：秒）container_fs_usage_bytes gauge 容器中文件系统的使用量(单位：字节)container_fs_limit_bytes gauge 容器可以使用的文件系统总量(单位：字节)container_fs_reads_bytes_total counter 容器累积读取数据的总量(单位：字节)container_fs_writes_bytes_total counter 容器累积写入数据的总量(单位：字节)container_memory_max_usage_bytes gauge 容器的最大内存使用量（单位：字节）container_memory_usage_bytes gauge 容器当前的内存使用量（单位：字节container_spec_memory_limit_bytes gauge 容器的内存使用量限制machine_memory_bytes gauge 当前主机的内存总量container_network_receive_bytes_total counter 容器网络累积接收数据总量（单位：字节）container_network_transmit_bytes_total counter 容器网络累积传输数据总量（单位：字节）
典型指标
先启动cadvisor
Prometheus配置文件中配置cadvisor的ip地址和端口
然后启动Prometheus
和Prometheus集成
cAdvisor
监控容器
该引用并不是和mysql整合在一起
1、先部署MySQL_Exporter
2、在Prometheus配置MySQL_Exporter的IP和端口
监控步骤
监控mysql数据库
同mysql监控类似，通过redis_export
redis监控
Prometheus监控
将2小时作为一个时间窗口产生的数据放在一个数据块里面，保存在本地磁盘上
单个Prometheus Server基本上能够应对大部分用户监控规模的需求。
核心设计思想：内置了一个本地数据序列数据库
1、可降低部署和管理复杂性
2、减少高可用带来的复杂性
优点
本地存储无法将数据持久化，无法存储大量的数据，无法做到灵活扩展和迁移
缺点
优缺点
Prometheus数据序列数据库设计
本地存储
解决数据无法持久化问题
Prometheus定义两个标准接口（读写），让用户基于这两个接口保存到任意第三方存储服务，这就是远程存储
远程写
远程读
读写
远程存储
数据的采集和数据存储是分开的
利用数据是做远程存储，可以在每一个数据监控中安装一个监控实例，这个监控实例从公用的远程存储中心获取数据。
一个实例已经处理处理上千规模的集群
1、在每一个数据监控中心部署一个实例
2、由中心的实力负责聚合多个数据中心的监控数据
示意图
原理
联邦集群
Prometheus数据存储
prometheus本身有自己的大盘数据，但是不太好用，一般是与grafana集成在一起
所以prometheus可以将数据导入到grafana大盘中
grafana
数据可视化
1、部署多台服务器
2、多台服务器都会向同样的一批被监控的应用或者服务采集数据
3、数据展示的时候通过nginx负载均衡后从其中一台服务器拉取数据
确保Promthues服务的可用性问题
Prometheus Server之间的数据一致性问题
持久化问题(数据丢失后无法恢复)
无法进行动态的扩展
适合监控规模不大
Promthues Server也不会频繁发生迁移的情况
保存短周期监控数据
适用场景
基本HA：服务可用性
相对于基础的服务可用性，此种部署方式，让数据在远程
确保了数据持久化，增加了系统可扩展性
Promthues宕机后，可以快速回复
可进行数据迁移
用户监控规模不大，但是希望能够将监控数据持久化，同时能够确保Promthues Server的可迁移性的场景
基本HA + 远程存储
将不同的采集任务划分到不同的Promthues
场景一：单数据中心 + 大量的采集任务
场景二：多数据中心
基本HA + 远程存储 + 联邦集群
极端情况下，采集的目标数量过大，通过联邦集群进行功能分区，也无法有效处理，考虑按照被采集的对象的级别，进行区分采集
按照实例进行功能分区
Promthues高可用部署
服务注册中心存储所有监控目标的访问信息，Promthues只需要去访问服务注册中心就知道需要对那些目标进行监控，这种模式成为服务发现
Promthues服务发现概述
很多云平台的服务，可以创建销毁应用，在这个过程被监控的对象的信息都是在变化中，但是Promthues无法动态感知到这些信息的变化，需要有一个外部注册中心来感知这个，然后Promthues通过统一的调用注册中心的信息得到这些变化的信息；
为什么需要有服务发现注册
不同的场景下，会有不同的东西来扮演注册中心
AWS公有云平台
平台级别的公有云
OpenStack的私有云平台
平台级别的私有云
Kubernetes容器管理平台
容易云
文件
DNS解析
注册中心举例
注册中心
Promthues通过读取文件中的被监控者的信息，来动态更新监控对象的信息
可以不依赖第三方的平台
基于文件的服务发现
Consul本身是一个支持多数据中心的分布式服务发现和键值对存储服务的开源软件
被监控的服务的信息会被注册到Consul
Promthues去Consul拉取对应的被监控的信息
基于Consul的服务发现
通过自定义标签，来区分不同环境的被监控对象的信息
服务发现与Relabeling
服务发现实战
Promthues服务发现
Prometheus
Nagios
Zabbix
开源监控系统
Java Profiler
java内存分析
MAT
偏向jvm监控
VisualVM
Java Mission Control与Java Flight Recorder一起，允许分析和事件收集有关Java虚拟机(JVM)和Java应用程序行为的低级信息。与Oracle JDK一起打包的这组工具还提供了对收集的数据的详细分析。
Oracle Java Mission Control
监控相关工具
CPU状态（user、system、iowait&idle percentages
内存使用率（used、buffered、cached & free percentages）
装载上用于节点数据目录的可用磁盘空间
beam.smp使用的文件描述符与最大系统限制
网络延迟（集群中所有RabbitMQ节点之间以及客户端之间）
基础设施和核心指标
请求集群中的任意节点获取
该节点在声场响应之前，需要收集组合来自其他节点的数据
集群指标获取
cluster_name
集群名称
message_stats
集群范围的消息速率
object_totals.connections
生产者，消费者和服务端的链接数量
总连接数量
object_totals.channels
消息通道是轻量级的连接
总消息通道数量
object_totals.queues
总队列数量
object_totals.consumers
总的消费者数量
queue_totals.messages
消息总数（ready+unacked）
queue_totals.messages_ready
准备交付的消息数量
queue_totals.messages_unacknowledged
未确认消息总量
message_stats.publish
最近发送消息数量
message_stats.publish_details.rate
消息发布的速度
message_stats.deliver_get
最近给消费者消息数量
message_stats.deliver_get.rate
消息发送速度
Other message stats
集群指标
集群信息获取
可以对任意节点请求获取统计指标
mem_used
总的内存使用大小
统计历史
内存使用大小的最高水位
内存使用阈值
以上两种理解？如何选择
Memory usage high watermark
Is a memory alarm in effect?
mem_alarm
当内存使用超过阈值时将触发报警memory alarm
disk_free_limit
剩余磁盘空间阈值
当空闲磁盘空间低于配置的限制时，将触发报警
可用文件描述符总数
已经使用的文件描述符大小
尝试打开的文件描述符数量
socket 系统连接最大值
socket 连接已经使用数量
?
Message store disk reads
Message store disk writes
Inter-node communication links
垃圾回收次数
垃圾回收内存大小
erlang 最大进程数量
已经使用的erlang 进程数量
正在运行的队列
节点指标
节点指标获取
内存大小
消息总数（ready+unacknowledged）
总的消息大小
准备传送的消息数量
未确认的消息数量
最近发布的消息数量
消息发布速度
最近交付的消息数量
消息传送速度
队列指标
单个队列指标获取
返回集群范围的指标
GET /api/overview
返回单个节点的状态
GET /api/nodes/{node}
返回所有集群成员节点的状态
GET /api/nodes
单个队列的指标
GET /api/queues/{vhost}/{qname}
本质都是通过RabbitMq提供的Http api接口获取
集群监控指标
监控的rabbitMq系统本身指标
应用程序跟踪的指标可以是特定于系统
客户端库和框架提供了注册指标收集器或收集现成指标的方法
RabbitMQ Java客户端和Spring AMQP就是两个例子。其它开发人员必须跟踪应用程序代码中的指标。
应用程序级指标
可以在MQ中专门创建一个监控的队列，定时的发送和消费队列中的消息，并且通过的如下的代码去监控队列是否已经堵塞，如果监听到队列已经堵塞，就立即发送告警的短信和邮件
监听堵塞消息
集群中是否有资源报警
rabbitMq是否正常运行
当前节点是否有报警
监控检测
监控指标
频率太高，容易对系统产生负面影响
生产系统建议收集间隔30秒-60秒
监控频率
Http接口
监控系统与被监控系统分离
降低服务开销
长期存储指标
方便关联聚合对比各个相关指标
更强大和可定制的用户界面
易于分享的指标数据
更健全的访问权限
针对不同节点的数据收集更具弹性
Prometheus & Grafana
RabbitMQ自带的（Management插件
监控工具
rabbitMq监控
监控系统不是很完善，目前主要依赖rokcetMq mqadmin命令行工具
rocketMq监控
本质依赖的是rokcetMq mqadmin命令行工具
1、官方提供的一个console web监控工具
将rockeMq的数据源导入到Prometheus上做相关监控
1、系统rocketMq服务
大体步骤
1、通过 RocketMQ Exporter 工具从rokcetMq 上获取到相关的指标数据；
2、配置Prometheus 从RocketMQ Exporter 获取到对应的指标数据
大致流程
2、Prometheus
Rocketmq监控
kafka官方也是提倡使用jmx并且提供了jmx的调用给用户以监控kafka.
jmx
监控实现原理
实例消息生产流量（bytes/s）
实例消息消费流量（bytes/s）
实例磁盘使用率（%）-实例各节点中磁盘使用率的最大值
实例监控
Topic 消息生产流量（bytes/s）
Topic 消息消费流量（bytes/s）
topic
Group 未消费消息总数（个）
group监控
资源类型监控
在运行正常集群中，同步副本（ISR）数量应等于副本总数。如果分区副本远远落后于 Leader，则从 ISR 池中删除这个 follower。如果代理不可用，则 UnderReplicatedPartitions 指标急剧增加。Tips：UnderReplicatedPartitions 较长时间内大于零，需要进行排查。
未复制的分区数
如果某副本在一段时间内未联系 Leader 或者 follower 的 offset 远远落后于 Leader，则将其从 ISR 池中删除。因此，需要关注 IsrShrinksPerSec / IsrExpandsPerSec 的相关波动。IsrShrinksPerSec 增加，不应该造成 IsrExpandsPerSec 增加。在扩展 Brokers 集群或删除分区等特殊情况以外，特定分区同步副本（ISR）数量应保持相对稳定。
同步副本（ISR）池缩小/扩展的速率
主要统计没有活跃 Leader 的分区数。Tips：由于所有读写操作仅在分区引导程序上执行，因此该指标出现非零值，就需要进行关注，防止服务中断。
离线分区数（仅控制器）
所有 brokers 中 ActiveControllerCount 总和始终等于 1，如出现波动应及时告警。Kafka 集群中启动的第一个节点将自动成为Controller且只有一个。Kafka 集群中的Controller负责维护分区 Leader 列表，并协调 Leader 变更（比如某分区 leader 不可用）。
集群中活动控制器的数量
在可用性和一致性之间，Kafka 默选了可用性。当 Kafka Brokers 的分区 Leader 不可用时，就会发生 unclean 的 leader 选举。当作为分区 Leader 的代理脱机时，将从该分区的 ISR 集中选举出新的 Leader。Tips：UncleanLeaderElectionsPerSec 代表着数据丢失，因此需要进行告警。
每秒 UncleanLeader 选举次数
TotalTimeMs 作为一个指标族，用来衡量服务请求（包括生产请求，获取消费者请求或获取跟随者请求）的用时，其中涵盖在请求队列中等待所花费的时间 Queue，处理所花费的时间 Local，等待消费者响应所花费的时间 Remote（仅当时requests.required.acks=-1）发送回复的时间 Response。
特定请求（生产/提取）用时
传入/传出字节率
每秒请求数
Kafka-emitted 指标
消耗磁盘空间消耗与可用磁盘空间
页面缓存读取与磁盘读取的比率
CPU 使用率
网络字节发送/接收
JVM 执行垃圾回收进程总数
JVM 执行垃圾收集进程用时
Host 基础指标 & JVM 垃圾收集指标
Broker 指标
每秒收到的平均响应数
每秒发送的平均请求数
平均请求等待时长
每秒平均传出/传入字节数
I / O 线程等待的平均时长
每个分区每个请求发送的平均字节数
Producer 指标
Consumer 在此分区上滞后于 Producer 的消息数
特定 Topic 每秒平均消耗的字节数
特定 Topic 每秒平均消耗的记录数
Consumer 每秒获取的请求数
Consumer 指标
Kafka Manager
Kafka Eagle
Logi-KafkaManager
kafka监控
消息中间件监控
log-bin=mysql-bin #[必须]启用二-进制日志server-id=100 #[必须]服务器唯一ID，如果是用于多台MySQL，ID不要重复就行binlog-format = ROW
1、修改配置
<dependency> <groupId>com.zendesk</groupId> <artifactId>mysql-binlog-connector-java</artifactId> <version>0.27.1</version> <!--2022.09.17版的--> </dependency>
2、引入依赖包
//为什么甚至路径都一样，还是com.github.shyiko.***，// 因为com.zendesk这个包，里面包了个com.github.shyiko.***这玩意，我怀疑是收购关系import com.github.shyiko.mysql.binlog.BinaryLogClient;import com.github.shyiko.mysql.binlog.event.*;import org.springframework.boot.ApplicationArguments;import org.springframework.boot.ApplicationRunner;import org.springframework.stereotype.Component;import lombok.extern.slf4j.Slf4j;import java.io.IOException;//此类可以监控MySQL库数据的增删改@Component@Slf4j //用于打印日志//在SpringBoot中，提供了一个接口：ApplicationRunner。//该接口中，只有一个run方法，他执行的时机是：spring容器启动完成之后，就会紧接着执行这个接口实现类的run方法。public class MysqlBinLogClient implements ApplicationRunner { @Override public void run(ApplicationArguments args) throws Exception { //项目启动完成连接bin-log new Thread(() -> { connectMysqlBinLog(); }).start(); } /** * 连接mysqlBinLog */ public void connectMysqlBinLog() { log.info(\"监控BinLog服务已启动\"); //自己MySQL的信息。host，port，username，password BinaryLogClient client = new BinaryLogClient(\"localhost\
3、具体代码demo
https://blog.csdn.net/qq_45821251/article/details/127490460
https://blog.csdn.net/chengsw1993/article/details/119328869
java监听Mysql数据变化
SigNoz
MySQL 企业版附带了 MySQL 企业级监视器
基于云的远程监控
查询分析可视化
支持 MySQL 集群监控
实时健康状态上报、可用性监控
易于配置
特性
MySQL Enterprise Monitor
Paessler PRTG Network Monitor
Sematext
Solarwinds
mysql监控
数据库监控
监控的实现
redis自带命令monitor的输出结果做分析的python脚本
redis-faina
RedisLive是一款用Python编写的Redis图形监控工具
监控脚本来利用Redis提供的MONITOR命令从被监控Redis实例中获取数据并存储到Redis的监控实例中来做数据分析
RedisLive以可视化的方式展示了Redis实例中的数据，分析查询模式和峰值
redis-live
Munin插件
nagios
监控插件
redis监控平台
连接失败检测
执行 info clients 命令获取 connected_clients 就是客户端连接数
客户端连接数
连接检测
此命令可以查询吞吐量相关的监控项
info stats
从 Redis 启动以来总计处理的命令数，可以通过前后两次监控组件获取的差值除以时间差，以得到 QPS
total_commands_processed
总执行命令数量
instantaneous_ops_per_sec
当前 Redis 实例的 OPS
total_net_input_bytes
网络总入量
total_net_output_bytes
网络总出量
instantaneous_input_kbps
每秒输入量，单位是kb/s
instantaneous_output_kbps
每秒输出量，单位是kb/s
具体指标
吞吐量监控
通过 info memory 获取，表示 Redis 真实使用的内存
used_memory
已使用内存大小
通过 config get maxmemory 获取。
maxmemory
最大内存大小
两个参数均通过 info memory 获取
计算方式：used_memory_rss/used_memory
大于 1 表示有内存碎片，越大表示越多；小于 1 表示正在使用虚拟内存，虚拟内存其实就是硬盘，性能会下降很多。一般内存碎片率在 1 - 1.5 之间比较健康。
内存碎片
内存监控
相关参数均为执行完 info Persistence 的结果
持久化可以防止数据丢失
rdb_last_bgsave_status
上一次 RDB 持久化状态
rdb_last_bgsave_time_sec
上一次 RDB 持久化的持续时间
aof_current_size
查看 AOF 文件大小
持久化监控
单个key对应的value值非常大
什么是大key
可以找出五种数据类型中各自最大的key；
不能帮助我们找到整个数据里的最大的key
一般不适用该种方式监控
redis自带的redis-cli --bigkeys
结果的准确性不高，集合类型的扫描只能扫描出集合的长度，而不是value的大小
还会阻塞redis正常的执行
通过脚本或者命令扫描所有的key
通过解析工具解析rdb文件，获取大key
很多第三方的解析工具
常用解析工具
解析rdb文件
通过代码aop的方式，异步每一次key的大小
大key
必须使用Least Frequently Used 最近最少使用的缓存淘汰策略
执行命令的途中肯定会阻塞正常的redis命令的执行
redis自带的redis-cli --hotkeys命令
每一个链接redis的客户端，都做相应的热key监控
客户端监控
监控示意图
代理端监控
利用monitor命令的结果就可以统计出一段时间内的热点key排行榜、命令排行榜、客户端分布
monitor命令的执行影响正常的reids命令的执行
只能统计单机的热key
服务端监控
机器
四种方式优缺点对比
自建对热key监控
热key
key监控
slowlog-log-slower-than
默认10000微妙
执行时间超过了多久，会被记录到慢查询日志中
当慢查询日志达到最大条数时，如果有新的慢查询，会移除最大的慢查询。
slowlog-max-len
慢日志的长度
慢查询涉及参数
查询所有慢查询
slowlog get
显示最新的一条慢查询
slowlog get 1
具体命令
慢查询监控
cluster_state
集群状态
cluster_slots_fail
hash槽状态
cluster_known_nodes
节点数量
cluster info 命令中可以获取集群的状态
集群监控
keyspace_hits 表示 Redis 请求键被命中的次数
keyspace_misses 表示 Redis 请求键未被命中的次数
HitRate = keyspace_hits / (keyspace_hits + keyspace_misses)
info stats 可以获取两个指标
命中率越低，导致越多的缓存穿透，对mysql容易造成影响
建议缓存命中率不要低于90%，越高越好
缓存命中率
redis监控指标
缓存监控
getActiveCount()
线程池中正在执行任务的线程数量
getCompletedTaskCount()
线程池已完成的任务数量，该值小于等于taskCount
getCorePoolSize()
线程池的核心线程数量
getLargestPoolSize
线程池曾经创建过的最大线程数量。通过这个数据可以知道线程池是否满过，也就是达到了maximumPoolSize
getMaximumPoolSize
线程池的最大线程数量
getPoolSize
线程池当前的线程数量
getTaskCount
线程池已经执行的和未执行的任务总数
线程池自带查询当前线程状态的方法
ThreadPoolExecutor的api setCorePoolSize(int corePoolSize)
核心线程数
ThreadPoolExecutor的api setMaximumPoolSize(int maximumPoolSize)
最大线程数
自定一个阻塞队列继承阻塞队类，然后在队列长度字段设置可以做修改。此队列作为线程池的阻塞队列
等待队列大小
？
是否自动扩容
具体可修改参数
都是需要在县城的运行期做相关的操作进行修改
线程池动态修改参数
执行任务前后全量统计任务排队时间和执行时间
定时任务，定时获取活跃线程数，队列中的任务数，核心线程数，最大线程数等数据
任务分类
监控任务
任务超时时间告警阈值
任务执行超时时间告警阈值
等待队列排队数量告警阈值
线程池定时监控时间间隔
告警指标
1、ThreadPoolExecutor线程池中beforeExecute和afterExecute方法是空实现
2、自定义线程池继承线程池类，实现beforeExecute和afterExecute方法
3、通过线程池的beforeExecute和afterExecute方法队线程池相关可查询参数进行监控
4、当相关的监控参数达到了告警阈值，那么就做出相关的告警操作；
告警实现
线程池告警
线程池监控
各种应用监控
监控系统
链路追踪监控诊断
0 条评论
回复 删除
下一页
