java诊断与链路追踪监控

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、当相关的监控参数达到了告警阈值，那么就做出相关的告警操作；

告警实现

线程池告警

线程池监控

各种应用监控

监控系统

链路追踪监控诊断