简介CAT实时应用监控平台 v3.1.0 是一套面向 IT 运维人员、后端开发者及计算机专业学生的分布式系统监控源码包可用于实时监测应用性能与稳定性也适合作为毕业设计或案例研究的实操素材。压缩包共约 2000 个文件整体 29.13MB以 1108 个 Java 源文件与 481 个 XML 配置为主辅以 JavaScript、C/C、Python、Go 等多语言实现以及 Markdown 文档、YAML 与 JSON 配置、数据库脚本等覆盖系统架构、模块划分、数据处理与异常处理等核心逻辑。包内附说明文档介绍部署、配置与 Web 界面操作便于快速上手。已有 113 人学习下载。通过研读源码与文档读者可掌握监控指标采集、日志聚合、报警通知与数据可视化等实现思路理解分布式监控的关键技术与最佳实践提升运维与开发技能。1. CAT 实时应用监控平台 v3.1.0从告警延迟到调用链定位的落地路径凌晨两点被告警电话叫醒打开监控面板只看到一条“接口成功率跌破 95%”的红线却不知道是哪个下游服务拖垮了整条链路——这是很多团队在微服务拆分到十几个节点后都会遇到的场景。CATCentral Application Tracking实时应用监控平台就是为解决这类问题而生的它把散落在各服务里的调用日志、耗时、异常、SQL 执行情况统一采集、聚合、可视化让你在分钟级内从“大盘异常”下钻到“具体哪台机器哪个方法哪条 SQL”。v3.1.0 这个版本号意味着它已经迭代到相对成熟的阶段消息树模型、跨语言客户端、实时报表这几块能力都趋于稳定。这篇文章面向的是准备自建或正在评估 CAT 的运维、后端和 SRE 同学我会按“它到底怎么工作 → 怎么搭起来 → 怎么接业务 → 坑在哪 → 怎么用得更深”的顺序讲清楚读完你应该能独立跑通一套可用的实时监控。2. CAT 的消息树模型与实时聚合链路为什么它能做到秒级定位2.1 消息树把一次请求的所有调用串成一棵树CAT 最核心的设计是消息树Message Tree。一次用户请求进入系统后会生成一个根 Transaction之后每一次 RPC 调用、数据库访问、缓存操作、本地方法调用都会作为子节点挂到这棵树上形成父子嵌套结构。每个节点记录类型Transaction / Event / Metric / Heartbeat、名称、耗时、状态成功/失败、以及自定义的业务数据。这种模型的价值在于当某个接口变慢时你不是看到一堆孤立的日志行而是能看到“这个接口耗时 800ms其中 600ms 花在调用 order-service 的 queryOrder 方法上而 queryOrder 内部又有 400ms 耗在一条慢 SQL 上”。定位路径是沿着树往下走的不需要靠时间戳去猜。消息树在客户端侧生成后会被序列化成二进制格式通过 TCP 长连接发给服务端。这里有个关键点CAT 客户端是异步发送的业务线程不会被网络 IO 阻塞但这也意味着如果服务端挂了客户端本地队列会堆积需要配置合理的队列上限和降级策略。2.2 服务端实时聚合分钟级报表是怎么算出来的服务端收到消息后不是简单存下来等查询而是走一条实时聚合链路。消息先进入内存队列由消费线程解析出消息树然后分发给不同的分析器Transaction 分析器按“应用 类型 名称”维度统计调用次数、失败次数、耗时分布包括 P95、P99Event 分析器统计异常和自定义事件Metric 分析器处理业务埋点指标。聚合结果按分钟粒度写入报表存储默认保留最近若干天的明细和更长时间的小时/天粒度汇总。这就是为什么 CAT 能做到“秒级写入、分钟级出报表”——它把计算前置到了写入路径上查询时直接读聚合结果而不是对原始日志做 OLAP。提示实时聚合的代价是写入放大。如果业务埋点过密比如每个循环都打 Event服务端 CPU 和内存会明显吃紧。生产环境建议对高频埋点做采样或合并。2.3 跨语言客户端与通信协议CAT 支持 Java、.NET、PHP、Python、Go、Node.js 等多种客户端。Java 客户端最成熟通过字节码增强基于 Spring AOP 或 JVM Agent自动埋点对业务代码侵入小。其他语言客户端通常需要手动埋点但核心 API 一致创建 Transaction、创建 Event、添加 Metric、设置状态。通信协议是自定义的二进制协议基于 Netty 做网络层。客户端和服务端之间维持长连接消息按批次发送。如果要做多机房部署常见做法是每个机房部署一组 CAT 服务端客户端就近上报然后通过跨机房同步或统一查询层做汇总。3. 从零搭一套 CAT v3.1.0部署拓扑与最小可用配置3.1 部署拓扑单机、集群与存储选型CAT 服务端有两种典型部署模式。单机模式适合测试或小规模团队一台机器跑 cat-consumer 和 cat-homeWeb 控制台数据存本地磁盘。集群模式适合生产多台 consumer 做水平扩展cat-home 独立部署后端存储通常选 HDFS 或 S3 兼容对象存储做历史归档实时报表数据放本地 SSD。我一般推荐的起步拓扑是2 台 consumer4C8G 起、1 台 cat-home2C4G、共享一个 MySQL 实例存配置和元数据。如果日均消息量在千万级以内这个配置够用。超过这个量级consumer 按每台承担 500 万条/天估算扩容。组件角色最低配置说明cat-consumer消息接收与聚合4C8G / SSD 200G可多实例cat-homeWeb 控制台与告警2C4G单实例即可MySQL配置与元数据2C4G可与业务共用对象存储历史归档按量可选3.2 服务端启动与关键配置项CAT 服务端启动前需要改几个配置文件。以 consumer 为例核心配置在data/appdatas/cat/目录下# 进入 CAT 服务端部署目录 cd /opt/cat # 编辑客户端路由配置告诉服务端自己属于哪个集群 vi data/appdatas/cat/client.xml!-- client.xml定义当前服务端的模式与集群 -- config modeclient xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance servers !-- 当前 consumer 所在集群用于路由和报表归属 -- server ip10.0.1.10 port2280 http-port8080/ /servers /config# 编辑数据库配置指向 MySQL vi data/appdatas/cat/datasources.xml!-- datasources.xmlCAT 元数据库连接 -- data-sources data-source idcat maximum-pool-size10/maximum-pool-size connection-timeout1000/connection-timeout idle-timeout60000/idle-timeout urljdbc:mysql://10.0.1.20:3306/cat?useUnicodetrueamp;characterEncodingutf8/url driver-classcom.mysql.jdbc.Driver/driver-class usercat_user/user passwordyour_password/password /data-source /data-sources配置完成后启动 consumer# 启动 consumer指定 JVM 参数 java -server -Xms4g -Xmx4g -XX:UseG1GC \ -Dcat.home/opt/cat \ -jar cat-consumer.jar逻辑说明client.xml里的 server 节点决定了当前实例向哪个集群汇报、报表数据归属哪个应用分组。datasources.xml是 CAT 自身元数据项目、告警规则、用户权限的存储不是业务监控数据。JVM 参数方面consumer 是内存敏感型堆大小建议设为物理内存的 50%60%G1 在消息量波动大时比 CMS 更稳。参数怎么改如果消息量突增导致 Full GC 频繁优先加堆而不是换 GC如果 CPU 打满但堆没满检查是不是聚合线程数不够可以通过cat.consumer.threads系统属性调整默认是 CPU 核数 × 2。3.3 cat-home 控制台与告警规则配置cat-home 是 Web 控制台启动方式和 consumer 类似但依赖 consumer 的报表数据。启动后访问http://cat-home-ip:8080/cat默认管理员账号在初始化 SQL 里。告警规则配置在控制台的“告警管理”页面核心字段包括告警类型Transaction / Event / Metric、匹配的应用和名称、阈值条件如失败率 5% 或 P99 1000ms、告警周期分钟级、通知方式邮件 / 短信 / Webhook。我一般会先配三条基线告警核心接口失败率、核心接口 P99 耗时、系统异常 Event 数量。这三条能覆盖 80% 的线上问题。注意告警规则不要一上来就配几十条否则告警风暴会让你直接忽略所有通知。先配核心链路跑一周后再根据实际误报和漏报调整阈值。4. 业务接入实战Java 客户端埋点与跨服务调用链还原4.1 Java 客户端接入依赖、配置与自动埋点Java 应用接入 CAT 客户端第一步是加依赖。如果项目用 Maven!-- pom.xmlCAT 客户端依赖 -- dependency groupIdcom.dianping.cat/groupId artifactIdcat-client/artifactId version3.1.0/version /dependency然后在resources/META-INF/下创建app.properties# app.properties声明当前应用名CAT 按此维度聚合 app.nameorder-service应用名是 CAT 里最重要的标识所有报表、告警、调用链都按它归类。命名建议用“业务域-服务名”格式比如trade-order-service、user-auth-service避免用app1、test这种无意义名字。如果要用自动埋点Spring AOP 方式在 Spring 配置里加// CatAopConfig.java启用 CAT 对 Spring Bean 的自动埋点 Configuration public class CatAopConfig { Bean public CatAnnotationAspect catAnnotationAspect() { return new CatAnnotationAspect(); } }自动埋点会拦截标注了CatTransaction的方法以及 Spring MVC 的 Controller 入口、MyBatis 的 SQL 执行、HTTP 客户端调用等。但自动埋点覆盖不到业务内部的关键分支所以核心逻辑还是需要手动埋点。4.2 手动埋点Transaction、Event 与 Metric 的正确用法手动埋点的核心 API 就三个Transaction、Event、Metric。看一段典型代码// OrderService.java手动埋点示例 public OrderResult queryOrder(Long orderId) { // 创建一个 Transaction名称用“业务域.方法名”格式 Transaction t Cat.newTransaction(OrderService, queryOrder); try { // 记录业务参数方便排查时还原现场 t.addData(orderId, orderId); // 调用下游服务这里会被自动埋点或手动包一层 UserInfo user userClient.getUser(orderId); t.addData(userId, user.getId()); // 记录一个业务事件比如缓存命中 Event event Cat.newEvent(OrderCache, hit); event.setStatus(0); event.complete(); // 记录一个业务指标比如订单金额 Cat.logMetricForCount(order.query.count); Cat.logMetricForSum(order.amount, 199.00); t.setStatus(Transaction.SUCCESS); return buildResult(user); } catch (Exception e) { // 异常必须记录否则调用链上看不到失败原因 t.setStatus(e); Cat.logError(e); throw e; } finally { // complete 必须放在 finally否则消息树不完整 t.complete(); } }逻辑说明Cat.newTransaction创建当前调用节点addData附加业务上下文setStatus标记成功或失败complete结束节点并触发上报。Cat.logError会把异常堆栈作为 Event 挂到当前 Transaction 下。logMetricForCount和logMetricForSum是轻量级指标不参与消息树直接进 Metric 聚合通道。参数怎么改Transaction 的名称不要用动态值比如把 orderId 拼进名称否则报表维度会爆炸。动态信息放addData。Event 的setStatus用 0 表示成功非 0 表示失败这个约定要统一。4.3 跨服务调用链还原HTTP 与 RPC 的上下文传递单机调用链好做跨服务就麻烦在上下文传递。CAT 的方案是在 HTTP Header 或 RPC 协议头里带上CAT_ROOT_ID、CAT_PARENT_ID、CAT_CHILD_ID三个 ID。服务端收到请求后客户端从 Header 里解析出父节点 ID把当前 Transaction 挂上去这样两个服务的消息树就能在服务端合并成一棵完整的调用链。以 HTTP 为例调用方在发请求前注入 Header// HttpClientInterceptor.java在 HTTP 请求头注入 CAT 上下文 public void beforeSend(HttpRequest request) { // 获取当前线程的 Transaction Transaction t Cat.getManager().getThreadLocalMessageTree().getMessageId(); if (t ! null) { request.setHeader(CAT_ROOT_ID, t.getRootMessageId()); request.setHeader(CAT_PARENT_ID, t.getMessageId()); } }服务端在收到请求后CAT 的 Servlet Filter 会自动读取这些 Header 并建立父子关系。如果用的是 Dubbo、gRPC 等 RPC 框架CAT 客户端通常提供了对应的 Filter 或 Interceptor直接注册即可。提示跨服务调用链还原的前提是各服务的时间大致同步。如果机器间时钟偏差超过 1 分钟调用链的时间轴会对不上排查时会很困惑。生产环境务必配 NTP。5. CAT 落地避坑从消息丢失到报表不准的排查记录5.1 现象客户端日志显示发送成功但控制台看不到数据原因最常见的是应用名配错或没配。CAT 客户端在app.properties里读app.name如果这个文件不在 classpath 下或者被其他配置覆盖客户端会用默认名unknown数据进了unknown应用你在自己的应用下自然看不到。另一个原因是客户端和服务端的时钟偏差导致消息被丢弃——CAT 服务端会拒绝时间戳偏差超过一定范围的消息。解决先确认app.properties在打包后的 jar 里存在且内容正确可以通过jar tf your-app.jar | grep app.properties检查。时钟问题用ntpdate或chronyd同步并在客户端配置里适当放宽时间容差。5.2 现象调用链断成两截跨服务后父节点丢失原因上下文 Header 没传过去。常见于自定义 HTTP 客户端、异步线程池、消息队列消费场景。比如在异步线程里发起的调用ThreadLocal 里的 Transaction 已经丢了自然拿不到父节点 ID。解决异步场景需要手动传递上下文。CAT 提供了Cat.getManager().getThreadLocalMessageTree()来获取当前上下文在提交任务前取出在任务执行时用Cat.getManager().setThreadLocalMessageTree()恢复。消息队列场景则在生产消息时把上下文 ID 放进消息头消费时恢复。5.3 现象报表 P99 耗时远高于实际或失败率虚高原因埋点粒度太细或重复埋点。比如一个循环里每次都newTransaction导致单次请求产生几千个节点聚合时耗时分布被拉偏。失败率虚高通常是setStatus用错——把业务上的“查询无结果”也标成了失败。解决Transaction 只埋关键路径循环内部用 Event 或 Metric。setStatus的语义要统一只有系统异常、超时、下游返回错误码才算失败业务空结果用addData记录即可。5.4 现象consumer 内存持续上涨频繁 Full GC原因消息堆积。当客户端发送速率超过 consumer 消费能力时消息在内存队列里堆积堆被撑满。常见触发场景是大促流量突增或者某个应用埋点量突然翻倍。解决短期加堆和加 consumer 实例长期要做埋点治理。CAT 支持在客户端配置采样率对高频 Event 按比例采样。另外检查是不是有应用在循环里打 Metric这种写法会让 Metric 通道也堵住。5.5 现象告警发了但没人收到或收到大量重复告警原因告警规则的通知方式没配全或者告警周期和恢复条件设置不合理。比如只配了邮件但邮件服务器没通或者失败率阈值设成 0.01% 导致每次抖动都触发。解决告警配置完后用“测试发送”功能验证通道。阈值设置参考历史基线一般取过去 7 天 P99 的 1.5 倍作为初始值。恢复条件要配否则告警会一直挂着。重复告警通常是告警周期太短改成 5 分钟或 10 分钟聚合一次。6. 用 CAT 做容量规划与根因分析两个我常用的进阶技巧第一个技巧是用 CAT 的 Metric 做容量水位监控。很多人只把 CAT 当故障排查工具其实它的 Metric 通道很适合做趋势分析。我习惯在核心接口里埋两个指标qps和avg_cost然后在 cat-home 里配一个自定义报表把这两个指标和机器 CPU、内存画在一起。当 QPS 上涨但 avg_cost 还没明显变化时说明系统还有余量当 avg_cost 开始抬头就是扩容的信号。这个比单纯看 CPU 阈值更准因为 CPU 高不一定代表瓶颈可能是 GC 或锁竞争。// CapacityMonitor.java在核心接口埋容量指标 public void doBusiness() { long start System.currentTimeMillis(); try { // 业务逻辑 } finally { // 每次调用都记录 QPS 和耗时 Cat.logMetricForCount(core.qps); Cat.logMetricForDuration(core.cost, System.currentTimeMillis() - start); } }第二个技巧是用调用链的“慢节点排序”做根因分析。CAT 控制台的 Transaction 报表支持按 P99 耗时排序点进去能看到该 Transaction 下所有子节点的耗时分布。我一般会先看 P99 最高的那个 Transaction然后看它的子节点里哪个耗时占比最大。如果某个子节点是 SQL 调用再结合 CAT 的 SQL 报表看具体是哪条 SQL 慢。这个路径比翻日志快得多尤其是在微服务调用层级很深的时候。分析目标看哪个报表关键字段接口整体健康度Transaction 报表失败率、P99慢调用根因调用链详情子节点耗时占比SQL 性能SQL 报表执行次数、平均耗时容量趋势自定义 Metric 报表QPS、avg_cost异常分布Event 报表异常类型、出现次数最后说一个我踩过的坑CAT 的报表默认按应用名聚合如果多个团队共用一个应用名报表会混在一起排查时互相干扰。所以从第一天起就要把应用名规范定好宁可多建几个应用也不要图省事共用。另一个习惯是每次上线新接口前先确认埋点已经生效——在 cat-home 里搜一下 Transaction 名称能看到数据再放量。这个动作花不了一分钟但能避免上线后监控盲区。希望帮到你。本文还有配套的精品资源点击获取 CAT实时应用监控平台v3.1.0：从告警延迟到调用链定位的落地路径
简介CAT实时应用监控平台 v3.1.0 是一套面向 IT 运维人员、后端开发者及计算机专业学生的分布式系统监控源码包可用于实时监测应用性能与稳定性也适合作为毕业设计或案例研究的实操素材。压缩包共约 2000 个文件整体 29.13MB以 1108 个 Java 源文件与 481 个 XML 配置为主辅以 JavaScript、C/C、Python、Go 等多语言实现以及 Markdown 文档、YAML 与 JSON 配置、数据库脚本等覆盖系统架构、模块划分、数据处理与异常处理等核心逻辑。包内附说明文档介绍部署、配置与 Web 界面操作便于快速上手。已有 113 人学习下载。通过研读源码与文档读者可掌握监控指标采集、日志聚合、报警通知与数据可视化等实现思路理解分布式监控的关键技术与最佳实践提升运维与开发技能。1. CAT 实时应用监控平台 v3.1.0从告警延迟到调用链定位的落地路径凌晨两点被告警电话叫醒打开监控面板只看到一条“接口成功率跌破 95%”的红线却不知道是哪个下游服务拖垮了整条链路——这是很多团队在微服务拆分到十几个节点后都会遇到的场景。CATCentral Application Tracking实时应用监控平台就是为解决这类问题而生的它把散落在各服务里的调用日志、耗时、异常、SQL 执行情况统一采集、聚合、可视化让你在分钟级内从“大盘异常”下钻到“具体哪台机器哪个方法哪条 SQL”。v3.1.0 这个版本号意味着它已经迭代到相对成熟的阶段消息树模型、跨语言客户端、实时报表这几块能力都趋于稳定。这篇文章面向的是准备自建或正在评估 CAT 的运维、后端和 SRE 同学我会按“它到底怎么工作 → 怎么搭起来 → 怎么接业务 → 坑在哪 → 怎么用得更深”的顺序讲清楚读完你应该能独立跑通一套可用的实时监控。2. CAT 的消息树模型与实时聚合链路为什么它能做到秒级定位2.1 消息树把一次请求的所有调用串成一棵树CAT 最核心的设计是消息树Message Tree。一次用户请求进入系统后会生成一个根 Transaction之后每一次 RPC 调用、数据库访问、缓存操作、本地方法调用都会作为子节点挂到这棵树上形成父子嵌套结构。每个节点记录类型Transaction / Event / Metric / Heartbeat、名称、耗时、状态成功/失败、以及自定义的业务数据。这种模型的价值在于当某个接口变慢时你不是看到一堆孤立的日志行而是能看到“这个接口耗时 800ms其中 600ms 花在调用 order-service 的 queryOrder 方法上而 queryOrder 内部又有 400ms 耗在一条慢 SQL 上”。定位路径是沿着树往下走的不需要靠时间戳去猜。消息树在客户端侧生成后会被序列化成二进制格式通过 TCP 长连接发给服务端。这里有个关键点CAT 客户端是异步发送的业务线程不会被网络 IO 阻塞但这也意味着如果服务端挂了客户端本地队列会堆积需要配置合理的队列上限和降级策略。2.2 服务端实时聚合分钟级报表是怎么算出来的服务端收到消息后不是简单存下来等查询而是走一条实时聚合链路。消息先进入内存队列由消费线程解析出消息树然后分发给不同的分析器Transaction 分析器按“应用 类型 名称”维度统计调用次数、失败次数、耗时分布包括 P95、P99Event 分析器统计异常和自定义事件Metric 分析器处理业务埋点指标。聚合结果按分钟粒度写入报表存储默认保留最近若干天的明细和更长时间的小时/天粒度汇总。这就是为什么 CAT 能做到“秒级写入、分钟级出报表”——它把计算前置到了写入路径上查询时直接读聚合结果而不是对原始日志做 OLAP。提示实时聚合的代价是写入放大。如果业务埋点过密比如每个循环都打 Event服务端 CPU 和内存会明显吃紧。生产环境建议对高频埋点做采样或合并。2.3 跨语言客户端与通信协议CAT 支持 Java、.NET、PHP、Python、Go、Node.js 等多种客户端。Java 客户端最成熟通过字节码增强基于 Spring AOP 或 JVM Agent自动埋点对业务代码侵入小。其他语言客户端通常需要手动埋点但核心 API 一致创建 Transaction、创建 Event、添加 Metric、设置状态。通信协议是自定义的二进制协议基于 Netty 做网络层。客户端和服务端之间维持长连接消息按批次发送。如果要做多机房部署常见做法是每个机房部署一组 CAT 服务端客户端就近上报然后通过跨机房同步或统一查询层做汇总。3. 从零搭一套 CAT v3.1.0部署拓扑与最小可用配置3.1 部署拓扑单机、集群与存储选型CAT 服务端有两种典型部署模式。单机模式适合测试或小规模团队一台机器跑 cat-consumer 和 cat-homeWeb 控制台数据存本地磁盘。集群模式适合生产多台 consumer 做水平扩展cat-home 独立部署后端存储通常选 HDFS 或 S3 兼容对象存储做历史归档实时报表数据放本地 SSD。我一般推荐的起步拓扑是2 台 consumer4C8G 起、1 台 cat-home2C4G、共享一个 MySQL 实例存配置和元数据。如果日均消息量在千万级以内这个配置够用。超过这个量级consumer 按每台承担 500 万条/天估算扩容。组件角色最低配置说明cat-consumer消息接收与聚合4C8G / SSD 200G可多实例cat-homeWeb 控制台与告警2C4G单实例即可MySQL配置与元数据2C4G可与业务共用对象存储历史归档按量可选3.2 服务端启动与关键配置项CAT 服务端启动前需要改几个配置文件。以 consumer 为例核心配置在data/appdatas/cat/目录下# 进入 CAT 服务端部署目录 cd /opt/cat # 编辑客户端路由配置告诉服务端自己属于哪个集群 vi data/appdatas/cat/client.xml!-- client.xml定义当前服务端的模式与集群 -- config modeclient xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance servers !-- 当前 consumer 所在集群用于路由和报表归属 -- server ip10.0.1.10 port2280 http-port8080/ /servers /config# 编辑数据库配置指向 MySQL vi data/appdatas/cat/datasources.xml!-- datasources.xmlCAT 元数据库连接 -- data-sources data-source idcat maximum-pool-size10/maximum-pool-size connection-timeout1000/connection-timeout idle-timeout60000/idle-timeout urljdbc:mysql://10.0.1.20:3306/cat?useUnicodetrueamp;characterEncodingutf8/url driver-classcom.mysql.jdbc.Driver/driver-class usercat_user/user passwordyour_password/password /data-source /data-sources配置完成后启动 consumer# 启动 consumer指定 JVM 参数 java -server -Xms4g -Xmx4g -XX:UseG1GC \ -Dcat.home/opt/cat \ -jar cat-consumer.jar逻辑说明client.xml里的 server 节点决定了当前实例向哪个集群汇报、报表数据归属哪个应用分组。datasources.xml是 CAT 自身元数据项目、告警规则、用户权限的存储不是业务监控数据。JVM 参数方面consumer 是内存敏感型堆大小建议设为物理内存的 50%60%G1 在消息量波动大时比 CMS 更稳。参数怎么改如果消息量突增导致 Full GC 频繁优先加堆而不是换 GC如果 CPU 打满但堆没满检查是不是聚合线程数不够可以通过cat.consumer.threads系统属性调整默认是 CPU 核数 × 2。3.3 cat-home 控制台与告警规则配置cat-home 是 Web 控制台启动方式和 consumer 类似但依赖 consumer 的报表数据。启动后访问http://cat-home-ip:8080/cat默认管理员账号在初始化 SQL 里。告警规则配置在控制台的“告警管理”页面核心字段包括告警类型Transaction / Event / Metric、匹配的应用和名称、阈值条件如失败率 5% 或 P99 1000ms、告警周期分钟级、通知方式邮件 / 短信 / Webhook。我一般会先配三条基线告警核心接口失败率、核心接口 P99 耗时、系统异常 Event 数量。这三条能覆盖 80% 的线上问题。注意告警规则不要一上来就配几十条否则告警风暴会让你直接忽略所有通知。先配核心链路跑一周后再根据实际误报和漏报调整阈值。4. 业务接入实战Java 客户端埋点与跨服务调用链还原4.1 Java 客户端接入依赖、配置与自动埋点Java 应用接入 CAT 客户端第一步是加依赖。如果项目用 Maven!-- pom.xmlCAT 客户端依赖 -- dependency groupIdcom.dianping.cat/groupId artifactIdcat-client/artifactId version3.1.0/version /dependency然后在resources/META-INF/下创建app.properties# app.properties声明当前应用名CAT 按此维度聚合 app.nameorder-service应用名是 CAT 里最重要的标识所有报表、告警、调用链都按它归类。命名建议用“业务域-服务名”格式比如trade-order-service、user-auth-service避免用app1、test这种无意义名字。如果要用自动埋点Spring AOP 方式在 Spring 配置里加// CatAopConfig.java启用 CAT 对 Spring Bean 的自动埋点 Configuration public class CatAopConfig { Bean public CatAnnotationAspect catAnnotationAspect() { return new CatAnnotationAspect(); } }自动埋点会拦截标注了CatTransaction的方法以及 Spring MVC 的 Controller 入口、MyBatis 的 SQL 执行、HTTP 客户端调用等。但自动埋点覆盖不到业务内部的关键分支所以核心逻辑还是需要手动埋点。4.2 手动埋点Transaction、Event 与 Metric 的正确用法手动埋点的核心 API 就三个Transaction、Event、Metric。看一段典型代码// OrderService.java手动埋点示例 public OrderResult queryOrder(Long orderId) { // 创建一个 Transaction名称用“业务域.方法名”格式 Transaction t Cat.newTransaction(OrderService, queryOrder); try { // 记录业务参数方便排查时还原现场 t.addData(orderId, orderId); // 调用下游服务这里会被自动埋点或手动包一层 UserInfo user userClient.getUser(orderId); t.addData(userId, user.getId()); // 记录一个业务事件比如缓存命中 Event event Cat.newEvent(OrderCache, hit); event.setStatus(0); event.complete(); // 记录一个业务指标比如订单金额 Cat.logMetricForCount(order.query.count); Cat.logMetricForSum(order.amount, 199.00); t.setStatus(Transaction.SUCCESS); return buildResult(user); } catch (Exception e) { // 异常必须记录否则调用链上看不到失败原因 t.setStatus(e); Cat.logError(e); throw e; } finally { // complete 必须放在 finally否则消息树不完整 t.complete(); } }逻辑说明Cat.newTransaction创建当前调用节点addData附加业务上下文setStatus标记成功或失败complete结束节点并触发上报。Cat.logError会把异常堆栈作为 Event 挂到当前 Transaction 下。logMetricForCount和logMetricForSum是轻量级指标不参与消息树直接进 Metric 聚合通道。参数怎么改Transaction 的名称不要用动态值比如把 orderId 拼进名称否则报表维度会爆炸。动态信息放addData。Event 的setStatus用 0 表示成功非 0 表示失败这个约定要统一。4.3 跨服务调用链还原HTTP 与 RPC 的上下文传递单机调用链好做跨服务就麻烦在上下文传递。CAT 的方案是在 HTTP Header 或 RPC 协议头里带上CAT_ROOT_ID、CAT_PARENT_ID、CAT_CHILD_ID三个 ID。服务端收到请求后客户端从 Header 里解析出父节点 ID把当前 Transaction 挂上去这样两个服务的消息树就能在服务端合并成一棵完整的调用链。以 HTTP 为例调用方在发请求前注入 Header// HttpClientInterceptor.java在 HTTP 请求头注入 CAT 上下文 public void beforeSend(HttpRequest request) { // 获取当前线程的 Transaction Transaction t Cat.getManager().getThreadLocalMessageTree().getMessageId(); if (t ! null) { request.setHeader(CAT_ROOT_ID, t.getRootMessageId()); request.setHeader(CAT_PARENT_ID, t.getMessageId()); } }服务端在收到请求后CAT 的 Servlet Filter 会自动读取这些 Header 并建立父子关系。如果用的是 Dubbo、gRPC 等 RPC 框架CAT 客户端通常提供了对应的 Filter 或 Interceptor直接注册即可。提示跨服务调用链还原的前提是各服务的时间大致同步。如果机器间时钟偏差超过 1 分钟调用链的时间轴会对不上排查时会很困惑。生产环境务必配 NTP。5. CAT 落地避坑从消息丢失到报表不准的排查记录5.1 现象客户端日志显示发送成功但控制台看不到数据原因最常见的是应用名配错或没配。CAT 客户端在app.properties里读app.name如果这个文件不在 classpath 下或者被其他配置覆盖客户端会用默认名unknown数据进了unknown应用你在自己的应用下自然看不到。另一个原因是客户端和服务端的时钟偏差导致消息被丢弃——CAT 服务端会拒绝时间戳偏差超过一定范围的消息。解决先确认app.properties在打包后的 jar 里存在且内容正确可以通过jar tf your-app.jar | grep app.properties检查。时钟问题用ntpdate或chronyd同步并在客户端配置里适当放宽时间容差。5.2 现象调用链断成两截跨服务后父节点丢失原因上下文 Header 没传过去。常见于自定义 HTTP 客户端、异步线程池、消息队列消费场景。比如在异步线程里发起的调用ThreadLocal 里的 Transaction 已经丢了自然拿不到父节点 ID。解决异步场景需要手动传递上下文。CAT 提供了Cat.getManager().getThreadLocalMessageTree()来获取当前上下文在提交任务前取出在任务执行时用Cat.getManager().setThreadLocalMessageTree()恢复。消息队列场景则在生产消息时把上下文 ID 放进消息头消费时恢复。5.3 现象报表 P99 耗时远高于实际或失败率虚高原因埋点粒度太细或重复埋点。比如一个循环里每次都newTransaction导致单次请求产生几千个节点聚合时耗时分布被拉偏。失败率虚高通常是setStatus用错——把业务上的“查询无结果”也标成了失败。解决Transaction 只埋关键路径循环内部用 Event 或 Metric。setStatus的语义要统一只有系统异常、超时、下游返回错误码才算失败业务空结果用addData记录即可。5.4 现象consumer 内存持续上涨频繁 Full GC原因消息堆积。当客户端发送速率超过 consumer 消费能力时消息在内存队列里堆积堆被撑满。常见触发场景是大促流量突增或者某个应用埋点量突然翻倍。解决短期加堆和加 consumer 实例长期要做埋点治理。CAT 支持在客户端配置采样率对高频 Event 按比例采样。另外检查是不是有应用在循环里打 Metric这种写法会让 Metric 通道也堵住。5.5 现象告警发了但没人收到或收到大量重复告警原因告警规则的通知方式没配全或者告警周期和恢复条件设置不合理。比如只配了邮件但邮件服务器没通或者失败率阈值设成 0.01% 导致每次抖动都触发。解决告警配置完后用“测试发送”功能验证通道。阈值设置参考历史基线一般取过去 7 天 P99 的 1.5 倍作为初始值。恢复条件要配否则告警会一直挂着。重复告警通常是告警周期太短改成 5 分钟或 10 分钟聚合一次。6. 用 CAT 做容量规划与根因分析两个我常用的进阶技巧第一个技巧是用 CAT 的 Metric 做容量水位监控。很多人只把 CAT 当故障排查工具其实它的 Metric 通道很适合做趋势分析。我习惯在核心接口里埋两个指标qps和avg_cost然后在 cat-home 里配一个自定义报表把这两个指标和机器 CPU、内存画在一起。当 QPS 上涨但 avg_cost 还没明显变化时说明系统还有余量当 avg_cost 开始抬头就是扩容的信号。这个比单纯看 CPU 阈值更准因为 CPU 高不一定代表瓶颈可能是 GC 或锁竞争。// CapacityMonitor.java在核心接口埋容量指标 public void doBusiness() { long start System.currentTimeMillis(); try { // 业务逻辑 } finally { // 每次调用都记录 QPS 和耗时 Cat.logMetricForCount(core.qps); Cat.logMetricForDuration(core.cost, System.currentTimeMillis() - start); } }第二个技巧是用调用链的“慢节点排序”做根因分析。CAT 控制台的 Transaction 报表支持按 P99 耗时排序点进去能看到该 Transaction 下所有子节点的耗时分布。我一般会先看 P99 最高的那个 Transaction然后看它的子节点里哪个耗时占比最大。如果某个子节点是 SQL 调用再结合 CAT 的 SQL 报表看具体是哪条 SQL 慢。这个路径比翻日志快得多尤其是在微服务调用层级很深的时候。分析目标看哪个报表关键字段接口整体健康度Transaction 报表失败率、P99慢调用根因调用链详情子节点耗时占比SQL 性能SQL 报表执行次数、平均耗时容量趋势自定义 Metric 报表QPS、avg_cost异常分布Event 报表异常类型、出现次数最后说一个我踩过的坑CAT 的报表默认按应用名聚合如果多个团队共用一个应用名报表会混在一起排查时互相干扰。所以从第一天起就要把应用名规范定好宁可多建几个应用也不要图省事共用。另一个习惯是每次上线新接口前先确认埋点已经生效——在 cat-home 里搜一下 Transaction 名称能看到数据再放量。这个动作花不了一分钟但能避免上线后监控盲区。希望帮到你。本文还有配套的精品资源点击获取