Dynatrace 5 层监控架构

在 Dynatrace 中，其核心的 5 层监控架构被称为 Smartscape 拓扑结构（Smartscape Topology）。

理解这 5 层的核心逻辑是：“自下而上提供支撑，自上而下逐层调用”。Dynatrace 通过 AI（Davis）自动将这 5 层垂直关联起来，只要任何一层出问题，AI 都能瞬间下钻并找出根本原因。

以下是这 5 层从底到顶的详细拆解：

1. 数据中心 / 基础设施层 (Data centers)

• 它是做什么的：整个系统的物理或云端边界。
• 具体指什么：AWS 的某个可用区（Region）、Azure 虚拟机集群、或者企业自己的物理机房（Data Center）。
• 监控重点：网络延迟、地域故障、云端可用性。
• 大白话理解：“你的服务器放在哪个具体的地理位置或云端机房里。”

2. 主机层 (Hosts)

• 它是做什么的：运行代码的硬件或虚拟化操作系统。
• 具体指什么：一台物理服务器、一个 VMware 虚拟机、或者是云端的一个 EC2 实例。
• 监控重点：CPU 使用率、内存占用、磁盘 I/O、网络吞吐量。
• 大白话理解：“承载业务的这台‘电脑’（操作系统）本身累不累、配置够不够。”

3. 进程层 (Processes)

• 它是做什么的：操作系统中运行的具体软件程序或容器。
• 具体指什么：一个 Java 虚拟机 (JVM)、一个 Tomcat 容器、一个 Docker 容器、或者 Nginx 进程。
• 监控重点：JVM 垃圾回收 (GC) 频率、进程崩溃、线程锁、容器资源限制。
• 大白话理解：“‘电脑’里运行的软件软件（比如 Java 环境）是不是健康的，有没有内存泄漏。”

4. 服务层 (Services)

• 它是做什么的：进程里运行的具体业务逻辑和代码组件（属于后台/服务端）。
• 具体指什么：一个具体的 REST API 接口（如 /login）、一个微服务（如订单服务）、或者数据库 SQL 查询。
• 监控重点：吞吐量（RPM）、响应时间、失败率（HTTP 500 错误）、代码级堆栈跟踪。
• 大白话理解：“程序员写的后台代码和数据库处理速度快不快，有没有报代码错误。”

5. 应用层 (Applications)

• 它是做什么的：最终用户直接接触和体验的前端界面（属于前台）。
• 具体指什么：一个官方网站（Web）、手机 App（iOS/Android）、或者微信小程序。
• 监控重点：真实用户体验（RUM）、页面加载时间（Apdex 指数）、JavaScript 错误、用户行为流。
• 大白话理解：“客户在手机或电脑上看你的界面卡不卡，点击按钮有没有反应。”

💡 核心价值：Dynatrace 是如何垂直联动这 5 层的？

假设一个真实场景：用户在手机 App 上点击“付款”按钮报错了。

如果没有 Dynatrace，前端、后端、运维和机房网络人员会互相推诿。但在 Dynatrace 的 5 层架构中，AI 会这样帮你秒级定位：

1. 应用层 发现：用户在手机 App（应用层）遇到了付款失败。
2. 自动下钻到 服务层 发现：App 调用的 /pay 订单接口（服务层）报了超时错误。
3. 自动下钻到 进程层 发现：运行该订单接口的 Tomcat（进程层）由于内存溢出，正在频繁进行垃圾回收（GC）。
4. 自动下钻到 主机层 发现：该服务器（主机层）的内存已经被占满（100%）。
5. 自动下钻到 数据中心层 发现：这是因为该 AWS 可用区（基础设施层）的其他机器挂了，导致流量全部涌入了这台主机。