📊

AppDynamics

APPLICATION PERFORMANCE MANAGEMENT · 从入门到专家

📑 目录

APM 基础 — 为什么需要 AppD 以及核心架构
控制台与 Agent — Controller、Agent 部署实战
业务事务 (Business Transaction) — APM 核心概念
Flow Map 与拓扑发现 — 可视化服务依赖
Snapshot 与调用链诊断 — 深入代码级排查
健康规则 (Health Rules) — 智能告警体系
数据库监控 — Slow Query 与索引优化
高级实战 — Analytics、Business iQ、Dashboard

APM 基础 — 为什么需要 AppDynamics

什么是 APM？

应用性能管理（Application Performance Management）的核心问题是："我的应用跑得慢，到底卡在哪儿？"

传统监控工具只能告诉你"服务器 CPU 高了"或者"请求返回了 500"，但要定位根因——是哪个服务、哪个方法、哪条 SQL、哪个外部 API 调用导致的——传统工具就束手无策了。

APM 工具通过代码级插桩（instrumentation），在每个关键方法入口/出口埋点，自动追踪每次请求的完整调用链路，并且收集响应时间、错误、SQL 执行时间等指标。

AppDynamics 的核心理念

AppDynamics 将自己定位为 Business Observability Platform，而不只是技术 APM。其核心理念是：

地图 → 聚焦 → 诊断 三步法：
① 地图（Map）：Flow Map 自动发现你的服务拓扑，一目了然
② 聚焦（Focus）：通过 Health Rules 和 Business Transaction 指标快速发现异常
③ 诊断（Diagnose）：Snapshot 提供每条慢请求的完整方法级调用栈和 SQL 明细

AppD 架构总览

组件	角色	部署方式
Controller	大脑 — 接收 Agent 数据、Web UI、告警引擎	企业自行部署 (on-prem) 或 SaaS
Application Agent	代码级插桩 — 捕获方法调用、SQL、外部 HTTP 调用	嵌入到应用进程（Java: .jar agent, .NET: DLL 注入, Node.js: npm 包）
Machine Agent	基础设施监控 — CPU、内存、磁盘、网络	独立进程，每台服务器一个
Database Agent	数据库深度监控 — 慢 SQL、执行计划、锁等待	独立进程，连接数据库实例
EUM Server	终端用户体验 — 浏览器 RUM、移动 App 监控	可选组件，独立部署
Events Service	事件总线 — 聚合告警、变更事件、Analytics 数据	Controller 4.4+ 内置

💡 APM 选型参考

AppDynamics 的对手是 Datadog APM、Dynatrace、New Relic。AppD 的优势在于代码级诊断深度（快照包含完整调用栈 + SQL 参数）、Business Transaction 抽象（自动区分业务语义）、以及企业级权限和角色体系。

控制台与 Agent 部署实战

Controller 部署（Linux 环境）

Controller 是 AppD 的核心。企业版需要自行部署在 Linux + MySQL 上。SaaS 版（AppDynamics Pro）托管在 Cisco 云上，无需运维。

Controller 安装流程（On-Premises）

# 1. 系统要求：至少 8 CPU / 32GB RAM / SSD 磁盘
#    需要 MySQL 5.7+（AppD 用 MySQL 存配置和指标）

# 2. 下载 Controller 安装包（从 AppD 账号 → Downloads）
chmod +x controller_64bit_linux.sh

# 3. 静默安装（推荐用 response.var.file 预设参数）
./controller_64bit_linux.sh -q -DUSER_INSTALL_DIR=/opt/appdynamics \
  -DAPPD_CNTRL_ADMIN_PWD=MyAdminP@ss1 \
  -DDB_ROOT_PWD=MySqlRootP@ss1 \
  -varfile /path/to/response.var.file

# 4. 启动后访问 https://<host>:8090/controller
#    默认用户名 admin

# 5. 查看 Controller 状态
/opt/appdynamics/controller/bin/controller.sh status

Java Agent 部署 — 最重要的 Agent

Java Agent 是 AppD 的核心武器。它通过 JVM -javaagent 参数在类加载时动态注入字节码，完全不需要修改源代码。

Java Agent 部署

# 1. 下载 Java Agent zip，解压到应用服务器
unzip AppServerAgent-25.x.zip -d /opt/appdynamics/java-agent

# 2. 配置 controller-info.xml（Agent 怎么找到 Controller）
<controller-info>
  <controller-host>10.0.1.100</controller-host>
  <controller-port>8090</controller-port>
  <controller-ssl-enabled>true</controller-ssl-enabled>
  <account-name>customer1</account-name>
  <account-access-key>xxxxxxxxxxxx</account-access-key>
  <application-name>MyEcommerceApp</application-name>
  <tier-name>OrderService</tier-name>
  <node-name>OrderService-Node1</node-name>
</controller-info>

# 3. 启动应用时附加 Agent
java -javaagent:/opt/appdynamics/java-agent/javaagent.jar \
  -Dappdynamics.agent.nodeName=OrderService-Node1 \
  -jar myapp.jar

# Tomcat 场景：修改 setenv.sh
export CATALINA_OPTS="$CATALINA_OPTS \
  -javaagent:/opt/appdynamics/java-agent/javaagent.jar \
  -Dappdynamics.agent.applicationName=MyEcommerceApp \
  -Dappdynamics.agent.tierName=OrderService \
  -Dappdynamics.agent.nodeName=OrderService-Node1"

多语言 Agent 覆盖

语言	部署方式	覆盖能力
Java	JVM -javaagent	方法级、JDBC、HTTP、JMS、Kafka
.NET	IIS/Windows Service DLL 注入	方法级、ADO.NET、ASP.NET Pipeline
Node.js	npm require('appdynamics') 第一行加载	HTTP 出口/入口、Postgres/MySQL/MongoDB 调用
Python	pyagent run 或 wsgi middleware	Flask/Django 路由、HTTP、SQL 调用
PHP	安装 PHP 扩展	HTTP、MySQL/Postgres/MongoDB
Go	编译时注入 SDK	需手动 instrumentation

⚠️ Agent 部署注意事项

① Agent 会增加 ~5-10% CPU 开销，建议先在 Staging 环境测试
② 生产环境用 Rolling Restart 逐个加上 Agent，观察 30 分钟再全量
③ Tier 和 Node 的命名规则要提前约定（环境-服务-编号），否则 UI 里会很乱

Business Transaction（业务事务）

BT 是 AppD 的一等公民

Business Transaction（BT）是 AppD 最核心的概念。它代表一个有业务意义的用户操作——比如"用户登录"、"下单"、"搜索商品"。AppD 自动发现 BT，并为每个 BT 独立统计响应时间、调用量、错误率、慢/非常慢/停滞阈值。

自动发现 vs 自定义 BT

AppD Java Agent 会自动发现所有 Servlet/Spring Controller/JAX-RS 端点，按 URL 路径分组为 BT。例如 /api/orders/{id} 和 /api/orders/{id}/items 会被自动识别为两个 BT。

自定义 BT 规则（更精确的业务切分）

# Configuration → Instrumentation → Business Transactions → Add
# 类型：POJO（自定义类方法）

# 场景：把"支付"操作从通用 HTTP 入口中剥离
# Match Class: com.myapp.service.PaymentService
# Match Method: processPayment
# BT Name: Pay-{methodArg:paymentType}-{methodArg:amount}

# 场景：把 Kafka Consumer 消息处理注册为 BT
# Match Class: com.myapp.consumer.OrderConsumer
# Match Method: onMessage
# BT Name: Kafka-Order-{matchArg:topic}

BT 的四大核心指标

每个 BT 有四个核心能力指标：

Load（调用量）：每分钟请求数 → 发现流量突增或暴跌
Response Time：平均响应时间 → 定位变慢趋势
Error Rate：错误率（HTTP 5xx + 未捕获异常） → 问题第一时间暴漏
Slow/Very Slow/Stall：三档慢请求阈值 → 识别长尾问题

理解 Slow Threshold 三级划分

AppD 自动为每个 BT 计算基线，然后划分三级阈值：

阈值配置建议

# 默认配置
Slow Threshold:     50% above baseline    # 偏慢
Very Slow Threshold: 3x standard deviation # 明显慢
Stall Threshold:     5x standard deviation # 卡死

# 实战调优：根据业务 SLO 调整
#   - 支付接口：slow=200ms, very_slow=500ms
#   - 搜索接口：slow=500ms, very_slow=2000ms

# 超过 Very Slow 的请求会被自动抓取 Snapshot（调用链详情）

Flow Map — 可视化服务拓扑

Flow Map 是什么？

Flow Map 是 AppD 的自动服务拓扑图。它不需要任何配置——Agent 插桩后，AppD 自动追踪应用之间的调用关系（HTTP、gRPC、消息队列），实时绘制出所有服务的依赖图。

Map 上的每个节点是一个 Tier（一个服务实例的逻辑分组），节点之间的连线代表调用关系，连线上的箭头粗细代表调用量，颜色代表健康状态（绿/黄/红）。

从 Flow Map 快速定位问题

典型排障流程

# 场景：用户反馈登录变慢

# Step 1：打开 Flow Map，看整体颜色
#   → Web-Frontend (绿), Auth-Service (黄), User-DB (绿)
#   → 锁定 Auth-Service 是瓶颈！

# Step 2：点击 Auth-Service → 看它的 Business Transactions
#   → /auth/login 平均 2.3s (基线 300ms)，明显异常

# Step 3：点进 /auth/login → 看 Snapshots
#   → 热门 Snapshot 显示 85% 时间花在 LDAP 认证调用上
#   → 排查后发现 LDAP 服务器在海外区域，网络延迟 200ms+

Tier & Node 命名最佳实践

良好的命名让 Flow Map 一目了然：

命名规范

# Tier Name == 服务名（跨所有环境相同）
prod-OrderService        # 生产环境的订单服务
stg-OrderService         # 预发环境的订单服务

# Node Name == 实例标识（唯一）
prod-OrderService-i-0a3b5c7d    # EC2 instance ID
prod-OrderService-pod-x7k2      # Kubernetes Pod ID

Snapshot — 代码级调用链诊断

Snapshot 包含什么？

当一条请求超过了 Very Slow 阈值或触发了错误，AppD 自动抓取这条请求的 Snapshot——一次完整的调用链记录，包含：

• 完整调用栈：从 HTTP 入口到最底层 JDBC 调用的每个方法，以及各自的耗时
• SQL 语句 + 绑参 + 执行耗时：完整 SQL（包括参数值！），不是像慢查询日志那样只是模板
• 外部 HTTP/RPC 调用：目标地址、耗时、返回码
• 线程信息：是否在等待锁、线程池是否耗尽
• 错误堆栈：异常类型、message、完整 stack trace

读 Snapshot 定位根因 — 实战案例

Snapshot 调用树分析

# BT: /api/orders (总耗时 3.2s, 基线 200ms)

# 调用树展开：
/api/orders                                          [3.2s]
  └─ OrderController.createOrder()                   [3.1s]
       └─ InventoryService.checkStock()               [0.4s]
       │   └─ JDBC: SELECT stock FROM ... WHERE sku=? [0.35s]  ✅ OK
       │
       └─ PaymentService.charge()                     [2.6s]  ← 瓶颈！
            └─ HTTP POST to payment-gateway/api/charge [2.5s]  ← 第三方慢了！
                 └─ JDBC: INSERT INTO payments ...     [0.05s]

# 根因：第三方支付网关响应慢（2.5s vs 正常 200ms）
# 行动：在支付网关前加超时 + 重试 / 异步化

SQL 诊断 — 参数化 vs 原始 SQL

AppD Snapshot 的一个重要优势：它显示的 SQL 是带实际参数的完整 SQL，不像 MySQL slow log 那样只显示模板。这让你可以直接在数据库里重现那条慢 SQL。

Snapshot 中的 SQL 示例

# 你能看到完整的 SQL 语句和绑定参数
SELECT o.id, o.total, c.name
FROM orders o JOIN customers c ON o.customer_id = c.id
WHERE o.created_at > '2025-01-01' AND c.region = 'CN-NORTH'
ORDER BY o.total DESC
LIMIT 1000

# 执行耗时：2.1s
# 抓到的参数值：region = 'CN-NORTH', date = '2025-01-01'
# → 直接去数据库 EXPLAIN 这条 SQL，发现缺了 (region, created_at) 联合索引

Health Rules — 智能告警体系

什么是 Health Rule？

Health Rule（健康规则）是 AppD 的告警引擎。它定义了 "什么条件 + 什么范围 + 触发什么动作"。与传统的固定阈值告警不同，AppD 支持动态基线（Baseline）——自动学习正常运行模式，只有偏离基线时才告警。

构建有效的 Health Rule

Core Health Rule 清单

# Rule 1：Business Transaction 响应时间偏离基线
Type: Business Transaction Performance
Metric: Average Response Time
Condition: > 2 standard deviations of baseline
Scope: ALL_TIERS (or specific tier)
Action: Warning → Slack; Critical → PagerDuty + Email

# Rule 2：错误率突增
Type: Business Transaction Performance
Metric: Errors per Minute
Condition: > 10 errors/min for 5 consecutive minutes
Scope: Production applications only
Action: Critical → PagerDuty

# Rule 3：服务器 CPU 过高（Machine Agent）
Type: Hardware Resources
Metric: CPU % Used
Condition: > 90% for 10 minutes
Action: Warning → Slack

# Rule 4：特定 BT 调用量骤降（可能服务挂了）
Type: Business Transaction Performance
Metric: Calls per Minute
Condition: < 50% of baseline for 5 minutes
Action: Critical → PagerDuty

Policy — 告警的动作编排

Health Rule 触发后，通过 Policy 来决定做什么：

Policy 配置

# Policy: Production Critical Alert
Triggers:
  - Health Rule: All Production HRs with CRITICAL status

Actions:
  1. Send Email → oncall@company.com (含 Snapshot 链接)
  2. HTTP Request Template → PagerDuty API
  3. Diagnostic Session → 自动收集问题时间段的日志
  4. Remediation Script → 尝试重启异常服务（谨慎使用！）

Schedule: 24/7
Escalation: 15min 未确认 → 升级到二线 oncall

💡 告警设计原则

① 告警要有 actionable 信息（附带 Snapshot URL、Flow Map link）
② 用 Baseline 而非定死阈值，适应业务自然增长
③ 为不同环境配置不同策略（Staging 可以宽松，Production 要敏感）
④ 定期 Review：告警过度频繁？在下个 Sprint 优化 Health Rule

数据库监控 — Slow Query 与优化

两层数据库监控

AppD 提供两层数据库监控：

Layer 1：Application Agent 内嵌 — Java Agent 自动拦截 JDBC 调用，记录 SQL 文本 + 绑参 + 耗时。对 SQL 级别的调用方（哪个 BT? 哪个方法？）一目了然。免费，无需额外组件。
Layer 2：Database Agent（独立） — 部署一个独立进程连接数据库，监控数据库服务器的 CPU/IO/连接数/锁等待/表空间/执行计划变化。需要额外许可。

实战：从 Snapshot 找到慢 SQL → 优化 → 验证

完整的 SQL 优化闭环

# Step 1：找到慢 SQL
#   Application Dashboard → 某个 BT 慢了 → Snapshots → 按 SQL 耗时排序
#   → 发现：SELECT ... FROM user_sessions WHERE session_id = ? 耗时 1.8s

# Step 2：去数据库验证
EXPLAIN SELECT * FROM user_sessions WHERE session_id = 'abc123';
#   → 发现全表扫描，user_sessions 表有 5000 万行，缺索引

# Step 3：加索引
CREATE INDEX idx_session_id ON user_sessions(session_id);

# Step 4：回到 AppD 验证效果
#   Application Dashboard → 看 BT 的平均响应时间是否下降
#   → 从 Data → Database Calls 面板看该 SQL 的平均耗时变化

Database Agent 的独特能力

独立 Database Agent 提供了 Application Agent 不具备的视角：

执行计划变化检测：数据库优化器忽然换了执行计划（比如索引碎片化导致切回全表扫描）→ AppD 自动检测到执行计划变化并告警
锁等待分析：哪个 Session 在等锁？被谁阻塞了？阻塞了多久？
连接池监控：数据库连接是否耗尽？哪些应用占了最多的连接？
存储层监控：表空间使用率、磁盘 IOPS、Buffer Pool 命中率

高级实战 — Analytics、Business iQ、Dashboard

Analytics — 业务数据分析

Transaction Analytics 让 AppD 不仅能搜技术指标，还能搜业务数据。比如："过去 1 小时所有金额 > ¥1000 的支付请求，按城市分组看平均响应时间"。

Analytics 搜索语言（类 SQL）

# 搜索所有大额支付，按城市看平均耗时
SELECT count(*), avg(responseTime), city
FROM transactions
WHERE amount > 1000 AND application = "Ecommerce"
SINCE 1 hour ago
GROUP BY city
ORDER BY avg(responseTime) DESC

# 前提：在 Data Collector 中定义了 amount, city 等业务字段的提取规则

Business iQ — 从技术指标到业务指标

Business iQ 是 AppD 的数据分析引擎，让你把技术性能指标和业务指标关联起来。核心概念：

Journey（用户旅程）：用户在应用中的路径（浏览 → 搜索 → 加购 → 下单 → 支付）。AppD 可以追踪每个步骤的转化率和耗时，发现漏斗中哪里在掉人。
Experience Level Management：把用户分为不同等级（如按地区、设备、VIP 等级），分别追踪各组用户的体验差异。

Business iQ 实战查询

# 转化漏斗分析
SELECT funnel(user_id,
  "page == /products" AS Browse,
  "page == /cart/add" AS AddToCart,
  "page == /checkout"  AS Checkout,
  "event == purchase"  AS Purchase
) FROM journeys SINCE 1 day ago

# 按 VIP 等级分组的体验对比
SELECT avg(responseTime), userTier
FROM transactions WHERE businessTransaction = "/api/checkout"
SINCE 1 day ago GROUP BY userTier

Dashboard — 团队视角

AppD 的 Dashboard 和 Splunk 不同——它更侧重"看整体健康"，而不是搜索。每个角色都可以构建自己的视角：

开发团队：应用级的响应时间、错误率、SQL 耗时、发布前后对比
运维团队：节点 CPU/内存、连接池、GC 暂停、线程池利用率
业务团队：转化率、每笔订单处理时间、收入影响分析
SRE/值班：所有 Health Rule 状态一览、当前活跃事件

发布前后对比 — AppD 杀手级场景

在发布新版本时，AppD 的 Compare 功能让你对比发布前后同一时间窗口的所有指标：响应时间是否变慢了？错误率是否上升了？SQL 执行次数是否变了？一目了然。

发布验证流程

# 灰度发布流程
1. 10% 流量切到新版本 (canary)
2. 观察 15 分钟：
   - Compare: New Version vs Old Version 的 4 大指标
   - Health Rules 是否有新增告警
   - Snapshots 中是否有新增类型的异常
3. 如果指标正常 → 逐步扩展到 50% → 100%
4. 如果异常 → 回滚，同时保留 Snapshot 给开发诊断

# AppD 的 Compare 会自动生成对比报告

学习路径建议

📚 从小白到专家的推荐路线

Week 1-2：理解 APM 概念 → 部署 Controller + Java Agent → 可视化你的第一个应用
Week 3-4：理解 BT → 手动定义 BT → 看 Flow Map 和 Snapshot 做排障演练
Month 2：配置 Health Rules + Policies → 做一次发布前后对比 → 实践 SQL 优化闭环
Month 3：部署 Database Agent → 配置 Analytics + Business iQ → 设计团队 Dashboard
Advanced：自定义 Agent 扩展（BTSDK, MQ Monitoring, Custom Metrics）、跨应用关联（AppD + Splunk 联动）

AppDynamics 认证路径

Associate Administrator → 安装、配置、管理 Controller 和 Agents
Associate Performance Analyst → 性能分析、排障、APM 最佳实践
Associate Implementation → 规划和实施部署方案
Professional → 综合掌握，通常建议先拿 1-2 个 Associate 再考

Java AgentMachine Agent ControllerBTFlow Map SnapshotHealth RulesDB Agent AnalyticsBusiness iQJourney EUM

← 返回技能树