CAT 监控 3.1.0 介绍与选型指南

目标：面向正在为 Java 为主的分布式系统选型应用性能监控（APM）平台的架构师与运维工程师，系统介绍 CAT（Central Application Tracking，大众点评开源 APM）的定位、架构、消息模型、功能特性与部署形态，并给出与 Pinpoint、SkyWalking、Zipkin 的量化选型对比。本文为认知与选型篇，全部信息来自官方仓库（GitHub dianping/Cat）、官方 Wiki 与 shields.io 徽章数据的公开溯源，来源与查询日期在各节随文标注（统一查询日期：2026-10-23）；安装、配置、命令类实操内容见本专栏后续各篇。

一、环境信息

本篇为联网溯源的认知篇，不依赖本地实验环境；为保证信息可复核，先交代本文所有数据的来源与时效口径：

• 信息溯源对象：GitHub 开源仓库 dianping/Cat（主线分支 master、发布 tag 3.1.0）、项目官方 Wiki（github.com/dianping/cat/wiki）、Maven Central 官方坐标 com.dianping.cat。
• 数据取证方式：版本号取自 GitHub Releases 页面（github.com/dianping/Cat/releases）；星标数、最新发布版本取自 shields.io 仓库徽章（img.shields.io）——按团队取证规范不直连 api.github.com；各项目发布日期取自 GitHub Releases 页面 HTML 时间戳。
• 统一查询日期：2026-10-23。所有版本号、星标数、活跃度数据均为该日快照，读者复核时数据可能已变化。
• 官方披露的技术底座：服务端基于 Java 开发、以 WAR 形态部署于 Apache Tomcat；存储依赖 MySQL（必需）与 HDFS（可选，用于 LogView 大对象存储）；客户端支持 Java、C/C++、Node.js、Python、Go 多语言（来源：dianping/Cat 3.1.0 README.md，2026-10-23 查询）。

二、软件概述

2.1 项目定位

CAT（Central Application Tracking）是大众点评（现美团点评体系）开源的、基于 Java 开发的实时应用监控平台，为美团点评提供了全面的实时监控告警服务。它作为服务端项目的基础组件，已在美团点评的基础架构中间件框架（MVC 框架、RPC 框架、数据库框架、缓存框架、消息队列、配置系统等）中深度集成，为各业务线提供系统性能指标、健康状况、实时告警等能力（来源：dianping/Cat 3.1.0 README.md「CAT 简介」，2026-10-23 查询）。

⚠️ 命名澄清：本文所称 CAT 均指 Central Application Tracking 应用监控系统，与 Linux/Unix Shell 中的同名文件查看工具毫无关系。二者仅名称相同：前者是一个部署在应用服务器上的 Java Web 系统，后者是操作系统自带的基础命令。在命令行场景遇到 cat 时，它永远是 Shell 命令；在监控、APM、告警语境中提到的 CAT，才是本文讨论的应用监控平台。

2.2 产品价值与核心优势

官方 README 明确了三点产品价值：减少故障发现时间、降低故障定位成本、辅助应用程序优化（来源同上）。

官方概括的六项核心优势（来源：dianping/Cat 3.1.0 README.md「Cat 优势」，2026-10-23 查询）：

关于「实时」的量化口径，官方 README 给出了内部实测描述：CAT 大部分系统是分钟级统计，但从数据生成到服务端处理结束是秒级别——「秒级定义是 48 分钟 40 秒，基本上看到 48 分钟 38 秒数据」，即端到端延迟约 2 秒，整体报表统计粒度为分钟级；监控指标数据是全量统计（客户端预计算），链路数据是采样计算。这组数字是理解 CAT 与其他 APM「实时性差异」的关键：指标报表延迟极低，而调用链按采样率入库（来源：dianping/Cat 3.1.0 README.md，2026-10-23 查询）。

2.3 开源许可与社区基本面

• 许可协议：Apache License 2.0，可自由用于商业场景（来源：仓库 LICENSE 与 README「Copyright and License」，2026-10-23 查询）。
• 社区热度：GitHub 星标约 19k、维护方为美团点评（meituan/dianping 团队）（来源：shields.io 仓库徽章 img.shields.io/github/stars/dianping/CAT，2026-10-23 查询）。
• 版本节奏：最新发布 tag 为 3.1.0，发布于 2022-06-25（来源：GitHub Releases 页面时间戳，2026-10-23 查询）；仓库最近一次提交在 2025 年 1 月（来源：shields.io last-commit 徽章，2026-10-23 查询）。官方 README 同时提示「3.0 代码分支更新都发布在 master 上，最新文档以 master 分支为准」。
• 活跃度客观结论：项目迭代节奏缓慢，3.1.0 之后无新版本发布，属于「稳定但低频维护」的存量型开源项目——生产采用时需要自备二次排障与兼容性适配能力（例如 JDK/MySQL 新版本的兼容验证），这是选型时必须计入的工程成本。

三、核心架构

3.1 组件模块划分

官方 README 将 CAT 划分为五个功能模块（来源：dianping/Cat 3.1.0 README.md「模块简介」，2026-10-23 查询）：

💡 说明：官方 README 明确「管理端、服务端、告警服务均使用 cat-home 模块部署即可」——即 cat-consumer/cat-alarm/cat-home 在 3.x 中已合并为同一个 WAR 包（cat-home 产物），按配置文件中的角色开关（job-machine/alarm-machine 等）决定单机承担的职责。因此部署上只需要一个 WAR + 一个配置目录，这是 CAT 部署面显著轻于 Pinpoint（HBase）的直接原因。

另据官方 README「根目录下 cat-client 模块以后不再维护，下个大版本更新计划移除，新版 Java 客户端参考 lib/java」——新建项目接入应使用 lib/java 中的新版客户端（Maven 坐标 com.dianping.cat:cat-client），不要再依赖仓库根目录的旧 client 模块。

3.2 消息模型（数据模型）

CAT 支持四种消息模型（来源：dianping/Cat 3.1.0 README.md「监控模型」与官方 Wiki model 页，2026-10-23 查询）：

四种模型组合起来覆盖了「调用链路（Transaction 树）+ 事件 + 异常 + 系统心跳 + 业务指标」五类可观测数据，这正是 CAT 优于纯 Trace 系统的地方：它不只是一条调用链，还自带报表化的统计视角。

3.3 数据流与部署形态

结合官方 Wiki（overall/client/server 设计页）与 3.1.0 README，CAT 的端到端数据流为：

1. 业务进程内嵌 cat-client 埋点，消息树在客户端预聚合（指标秒级聚合、Transaction 全量/链路采样）；
2. cat-client 通过 TCP 2280 端口将序列化消息上报到 CAT 服务端集群（客户端从 client.xml 拉取服务端路由表，服务端集群通过 MySQL 同步路由配置）；
3. cat-consumer 实时消费消息流，按「域名-类型-名称」维度做实时报表聚合，落本地文件存储 + MySQL 索引（3.x 全新文件存储引擎）；
4. cat-home 提供控制台（默认随 Tomcat 8080 暴露）展示各类实时报表；LogView 大对象可转发至 HDFS（可选 cat-hadoop）；
5. cat-alarm 按订阅规则对报表指标做实时告警（邮件等通道）。

💡 技术拓展：APM 数据上报协议不止 CAT 的一种自研 TCP 协议。业界常见对比——

上报方式	代表系统	特点	适用场景
自研二进制 TCP 协议	CAT（2280 端口）	客户端预聚合、吞吐高、协议紧凑	大体量指标全量统计
字节码增强 + gRPC/HTTP	SkyWalking、Pinpoint	自动埋点、Span 结构、对业务零侵入	调用链为主的自动追踪
通用 Span 库 + HTTP/Kafka	Zipkin（Brave、OTel）	协议开放、生态广	多语言、已有 Tracing 生态

CAT 走的是「自研协议 + 客户端预计算」路线，换来的是高吞吐与低服务端压力，代价是客户端需要少量代码埋点（Java 客户端提供自动集成的中间件插件，但覆盖面不及字节码增强方案）。本方案（CAT 3.1.0）实际采用自研 TCP 2280 上报。

四、功能特性

以下特性均来自官方 README 与官方 Wiki 的公开描述（2026-10-23 查询），部署与验证实操见专栏后续各篇：

1. 多语言客户端：官方提供 Java、C/C++、Node.js、Python、Go 客户端（仓库 lib/ 目录下分别维护），其中 Java 客户端（lib/java）支持 JDK 1.6+ 并以 Maven Central 坐标 com.dianping.cat:cat-client 发布。
2. 实时报表体系：Transaction（调用耗时统计）、Event（事件统计）、Problem（异常与慢请求问题列表）、Heartbeat（JVM/系统运行态心跳）、Metric（业务指标）五大报表分钟级刷新，从数据生成到服务端处理完成约 2 秒（官方口径见 2.2 节）。
3. 消息采样聚合与序列化协议：3.x 对消息采样聚合与序列化协议做了升级，配合全新文件存储引擎，支撑美团点评量级的全量指标吞吐（来源：README「更新日志」，2026-10-23 查询）。
4. 告警体系：cat-alarm 提供报表指标的实时监控告警，支持按 Metric/Exception/Transaction 等维度配置告警规则（官方 Wiki readme_server/readme_config）。
5. 分布式与跨 IDC 部署：服务端支持多节点集群、路由配置集中管理（客户端路由表服务端下发），支持跨 IDC 横向扩展（官方 Wiki 集群部署页）。
6. LogView 全链路消息查看：单次请求的消息树可完整落库（可选 HDFS），用于逐条排障（官方 Wiki server 设计）。
7. 中间件深度集成：在美团点评内部与 MVC/RPC/DB/缓存/MQ/配置中心等基础框架深度集成；开源侧 integration 目录收录了社区贡献的第三方集成示例。

五、快速开始（最小可用示例）

本节给出「应用侧接入 CAT 的最小代码形态」，代码取自官方仓库 lib/java/README.md 原文（Apache 2.0，查询日期 2026-10-23）；服务端从零安装、配置文件与建库的完整实测流程，见本专栏《CAT 监控 3.1.0 安装指南》与《CAT 监控 3.1.0 配置参数详解》。

5.1 引入客户端依赖（Java）

在业务工程的 pom.xml 中加入官方 Maven Central 坐标（来源：lib/java/README.md「Installation」，2026-10-23 查询）：

<dependency>
    <groupId>com.dianping.cat</groupId>
    <artifactId>cat-client</artifactId>
    <version>3.1.0</version>
</dependency>

5.2 声明应用名

在业务工程 src/main/resources/META-INF/app.properties 中写入应用标识（appkey 只允许英文字母、数字、下划线与连字符；来源：lib/java/README.md，2026-10-23 查询）：

app.name=my-app

5.3 配置服务端路由

在业务机器的 /data/appdatas/cat/client.xml 中声明 CAT 服务端地址（2280 为 CAT 服务端默认上报端口，官方注明不允许修改；http-port 为服务端 Tomcat 的 HTTP 端口，默认 8080。来源：lib/java/README.md，2026-10-23 查询）：

<?xml version="1.0" encoding="utf-8"?>
<config mode="client">
    <servers>
        <server ip="10.1.1.1" port="2280" http-port="8080"/>
        <server ip="10.1.1.2" port="2280" http-port="8080"/>
        <server ip="10.1.1.3" port="2280" http-port="8080"/>
    </servers>
</config>

5.4 埋点上报第一笔数据

Java 客户端为懒初始化，无需手动初始化；以下为官方 Quickstart 原文示例（来源：lib/java/README.md，2026-10-23 查询）：

Transaction t = Cat.newTransaction("URL", "pageName");

try {
    Cat.logEvent("URL.Server", "serverIp", Event.SUCCESS, "ip=${serverIp}");
    Cat.logMetricForCount("metric.key");
    Cat.logMetricForDuration("metric.key", 5);

    yourBusiness();

    t.setStatus(Transaction.SUCCESS);
} catch (Exception e) {
    t.setStatus(e);
    Cat.logError(e);
} finally {
    t.complete();
}

💡 说明：Cat.newTransaction(type, name) 开启一个计时事务，t.complete() 必须在 finally 中调用（官方明确：忘记 complete 会导致消息树损坏与内存泄漏）；Cat.logEvent 记录事件；Cat.logMetricForCount/logMetricForDuration 上报业务计数与耗时，客户端按秒聚合后一次上报。异常场景用 t.setStatus(e) + Cat.logError(e)，问题报表（Problem）中即可看到异常堆栈。

服务端侧的最小部署路径概览：准备 MySQL（执行 script/CatApplication.sql 建库）→ 准备 /data/appdatas/cat/ 配置目录（dataSources.xml/server.xml/client.xml/app.xml）→ 源码构建 mvn clean install -DskipTests 得到 cat-home WAR → 部署到 Tomcat → 浏览器打开 8080 控制台登录。上述每一步的命令与真实回显，见《CAT 监控 3.1.0 安装指南》。

六、适用场景与限制

6.1 适用场景

1. Java 为主、体量大的在线服务集群：CAT 的客户端预计算 + 高吞吐设计天然适合「接口多、QPS 高、需要分钟级全量指标」的业务形态，这也是它在大点评/美团体系内部大规模落地的场景。
2. 需要指标报表而非仅调用链的团队：Transaction/Heartbeat/Metric 报表把「每个接口的 QPS/耗时/错误率」「每台机器的 JVM/磁盘状态」做成实时大盘，偏运维与健康度视角。
3. 已有 MySQL 运维能力、希望部署轻量的团队：服务端只需 Tomcat + MySQL，无需 HBase/Kafka/ES 等重依赖（HDFS 仅在需要长期存 LogView 时引入）。
4. 多语言混合团队：官方提供 Java/C/C++/Node.js/Python/Go 客户端，非 JVM 服务也能接入指标与事件。

6.2 限制与风险（选型必读）

1. 项目迭代缓慢：最新发布 3.1.0 停留在 2022-06-25，master 分支 2025 年 1 月后无提交（2026-10-23 查询口径）。安全补丁与依赖升级需自行负责，采用前应做 CVE 与依赖成分自查。
2. 新版本兼容性风险：官方 README 明确要求以 master 分支文档为准，第三方网站上大量老版本配置文档（含数据库结构）存在不兼容情况——照抄旧博客容易踩坑，应以仓库内 script/CatApplication.sql 与 docker/ 模板为配置基准。
3. 代码埋点成本：与字节码增强系（Pinpoint/SkyWalking Java agent）相比，CAT Java 客户端对业务代码有一定侵入（虽然提供了常用框架集成插件），历史遗留系统全量接入的人力成本更高。
4. 存储扩展依赖 Hadoop 生态：默认本地文件 + MySQL 即可运行，但 LogView 大规模长期留存需要 HDFS（cat-hadoop 模块），对没有 Hadoop 运维经验的团队是额外负担。
5. 社区文档老化：官方 Wiki 部分内容基于 2.x/3.0 时代，实践时应结合源码与仓库 docker/ 目录的最新模板交叉验证。

七、同类选型对比

7.1 对比对象与数据口径

对比对象选取社区最常与 CAT 同列的三个 APM/Tracing 系统：Pinpoint（Naver 开源）、Apache SkyWalking（吴晟主导进入 Apache 基金会）、Zipkin（Twitter 开源，Dapper 论文实现）。所有数值取自各项目官方 GitHub 仓库与 shields.io 徽章，查询日期统一为 2026-10-23；Pinpoint 的深入实测不在本文展开（本专栏另有专篇）。

表格解读（关键差异）：四个系统都是 Apache 2.0 的 JVM 系 APM，真正的分水岭有三条——①采集模型：CAT 是「指标报表 + 消息树」的监控系统，Zipkin 是纯调用链系统，Pinpoint/SkyWalking 介于两者之间且靠字节码增强实现自动埋点；②部署重量：Zipkin/SkyWalking 单 jar 即可起步，CAT 需要 Tomcat + MySQL，Pinpoint 需要服务端 JDK17 + HBase 最重；③维护活跃度：CAT 已进入低频维护期（2022 年后无新版本），其余三者保持活跃发版。

7.2 量化活跃度速览（2026-10-23）

（来源：img.shields.io 各仓库 stars/release 徽章与 GitHub Releases 页面，2026-10-23 查询。）

7.3 选型建议（如果…则…）

1. 如果团队以 Java 服务为主、需要分钟级实时指标大盘与内置告警、且能接受低频维护并自持排障——选 CAT。它的报表体系与 2 秒级处理延迟在指标监控上仍有独到价值，部署依赖（Tomcat + MySQL）也足够轻。
2. 如果要自动埋点、零代码侵入并持续跟进新版本——选 SkyWalking（生态最活跃、OTel 兼容、多存储后端）或 Pinpoint（调用链与拓扑可视化成熟，但需接受 HBase 运维成本）。
3. 如果只需要轻量调用链收集、或已有 OpenTelemetry/Brave 生态——选 Zipkin（单 jar、协议开放）。
4. 如果团队运维能力有限、没有专职中间件人力——优先 SkyWalking/Zipkin；CAT 虽部署面小，但版本停更意味着踩坑时基本依赖源码自读与社区 Issue。
5. 混合策略：指标监控用 CAT 的 Heartbeat/Metric 报表 + 调用链用 SkyWalking/Zipkin 的组合在企业中同样可行，两者按 appkey/domain 关联即可，但要注意双客户端的资源与上报通道隔离。

八、参考链接

1. GitHub 仓库（源码、README、Releases）：https://github.com/dianping/Cat
2. Releases 页面（版本 3.1.0，2022-06-25）：https://github.com/dianping/Cat/releases
3. 官方 Wiki（服务端部署/报表/配置手册/模型设计）：https://github.com/dianping/cat/wiki
4. lib/java 新版 Java 客户端文档（本文埋点示例出处）：https://github.com/dianping/cat/tree/master/lib/java
5. Apache License 2.0 全文：https://github.com/dianping/Cat/blob/master/LICENSE
6. 对比项目官方仓库：https://github.com/pinpoint-apm/pinpoint 、https://github.com/apache/skywalking 、https://github.com/openzipkin/zipkin
7. 星标/版本取证徽章服务（2026-10-23 快照）：https://img.shields.io
8. 本专栏姊妹篇：《CAT 监控 3.1.0 安装指南》、《CAT 监控 3.1.0 配置参数详解》、《CAT 监控 3.1.0 常用 CLI 命令与工具详解》