通用剖析
Elastic Stack
Elastic 通用剖析是一种全系统、始终开启的持续剖析解决方案，无需代码检测、重新编译、主机调试符号和服务重启。通用剖析利用 eBPF 技术，在 Linux 内核空间内运行，仅捕获所需的数据，以最小的开销和不引人注意的方式运行。有关通用剖析的快速概述，请参见 通用剖析产品页面。
在本页中，您将找到有关以下内容的信息：
要打开 通用剖析，请在主菜单中找到 基础设施 或使用 全局搜索字段。
在 通用剖析 下，单击 堆栈追踪 打开 堆栈追踪视图 。
通用剖析目前仅支持通过堆栈采样进行 CPU 剖析。
从 堆栈追踪 视图中，您可以获得所有数据的概览。您还可以在搜索栏中使用筛选查询将您的数据切片成更详细的部分。基于时间的筛选器和属性筛选器允许您检查数据片段，并深入了解基础设施的各个部分随时间推移消耗了多少 CPU。
有关切片数据的更多信息，请参见 筛选，有关比较两个时间范围以检测性能改进或退化的更多信息，请参见 差异视图。
您的堆栈追踪可以是
- 已符号化，显示完整的源代码的文件名和行号
- 部分符号化
- 未符号化
在下面的屏幕截图中，您可以看到未符号化的帧不显示文件名和行号，而是十六进制数字，例如 0x80d2f4 或 <unsymbolized>。
添加未符号化帧的符号当前是一个手动操作。 请参见 为原生帧添加符号。
堆栈追踪视图显示按线程、追踪、主机、部署和容器分组的堆栈追踪图
堆栈追踪页面上的不同视图显示
- 线程： 按进程的线程名称分组的堆栈追踪
- 追踪： 未分组的堆栈追踪
- 主机： 按机器的主机名或 IP 地址分组的堆栈追踪
- 部署： 按容器编排设置的部署名称（例如，Kubernetes
ReplicaSet、DaemonSet或StatefulSet名称）分组的堆栈追踪 - 容器： 按主机代理发现的容器名称分组的堆栈追踪
堆栈追踪视图提供了有价值的信息，您可以使用这些信息来
- 发现哪个容器（部署在多台机器上）使用的 CPU 最多。
- 发现来自在您的机器上运行的第三方软件的相对开销有多大。
- 检测跨线程的意外 CPU 峰值，并深入研究更小的时间范围，以使用火焰图进一步调查。
堆栈追踪根据收集的堆栈追踪的来源进行分组。如果您的主机代理部署正在分析未运行任何容器或容器编排器的系统，您可能会在容器和部署中找到一个空视图。在通用剖析正确地从主机代理接收数据的部署中，您应该始终在线程、主机和追踪视图中看到一个图。
悬停并单击每个堆叠条形图部分以显示详细信息。您可以安排该图显示绝对值或相对百分比值。
在顶部图表下方，有单独的图表显示每个项目的单独趋势线
每个单独图表右上角显示的百分比是每次出现次数相对于该组中样本总数的相对数量。
显示的百分比与 CPU 使用率的百分比不同。通用剖析不是用来显示绝对监控数据的。相反，它允许对在您的基础设施中运行的软件进行相对比较（例如，哪个最昂贵？）
单独的图表按降序排列，从上到下，从左到右。
在 追踪 选项卡中，单击每个单独图表底部的 显示更多 会显示完整的堆栈追踪。
火焰图视图将分层数据（堆栈追踪）分组为堆叠在彼此之上或旁边的矩形。每个矩形的大小表示子级相对于其父级的相对权重。
火焰图可立即反馈应首先搜索哪些软件部分以寻找优化机会，从而突出显示整个基础设施中最热门的代码路径。
您可以使用火焰图来
- 检测对系统调用或链接到您自己的软件的本机库的意外使用情况：通用剖析能够将堆栈追踪从用户空间边界展开到内核空间
- 检查 CPU 密集型应用程序的调用堆栈，检测热代码路径并搜索优化机会
- 查找“深层”调用堆栈，通常暗示跨类或对象的许多间接引用所在的区域
您可以在水平轴和垂直轴上导航火焰图
- 水平轴：采样的每个进程在
root帧下至少有一个矩形。在通用剖析火焰图中，您可能会发现您不控制但正在消耗大量 CPU 资源的进程的存在。 - 垂直轴：遍历进程的调用堆栈允许您确定进程的哪些部分执行最频繁。这允许查明应该可以忽略不计但实际上是您的调用站点的很大一部分的函数或方法。
您可以向上、向下、向右或向左拖动图形来移动可见区域。
您可以通过单击单个帧或在彩色视图中向上滚动来放大和缩小堆栈追踪的子集。
该图左下角的摘要正方形可让您移动该图的可见区域。拖动火焰图时，右下角的摘要正方形的位置会调整，并且移动摘要正方形会调整较大面板中的可见区域。
将鼠标悬停在火焰图中的矩形上会在窗口中显示该帧的详细信息。 要查看更多帧信息，请在固定工具提示后单击 显示更多信息 图标。
在该图区域下方，您可以使用搜索栏在火焰图中查找特定文本；您可以在此处搜索二进制文件、函数或文件名，并在出现的地方移动。
函数视图显示通用剖析最常采样的函数的有序列表。 从此视图中，您可以发现跨整个基础设施运行最多的函数，应用筛选器以深入研究各个组件。
在所有 Universal Profiling 视图中，搜索栏接受 Kibana 查询语言 (Kibana Query Language, KQL) 格式的过滤器。
最值得注意的是，您可能需要按以下内容进行过滤：
profiling.project.id：project-idhost-agent 标志的对应值，已部署 host-agent 的逻辑组process.thread.name：进程的线程名称，例如python、java或kauditdorchestrator.resource.name：由 orchestrator 设置的容器化部署组的名称container.name：由容器引擎设置的单个容器实例的名称host.name或host.ip：机器的主机名或 IP 地址（用于调试单个虚拟机上的问题）
火焰图和函数视图可以转换为差异视图，用于比较两个不同时间范围或多个维度的数据。
从顶部的选项卡切换到 差异火焰图 (Differential flamegraph) 或 差异 TopN 函数 (Differential TopN functions) 时，您会看到两个独立的搜索栏和日期时间选择器。 最左侧的过滤器表示您要用作比较基准的数据，而最右侧的过滤器表示将与基准进行比较的数据。
单击每个数据过滤器上的刷新按钮会触发频率比较，从而突出显示 CPU 使用率的变化。
在差异函数中，函数最右侧的列具有绿色或橙色的分数计算器，表示相对于 CPU 密集型函数而言，位置的相对差异。
在差异火焰图中，与基准的差异用颜色和色调突出显示。 鲜艳的绿色矩形表示与基准相比，在较少样本中观察到某个帧，这意味着有所改进。 鲜艳的红色矩形表示在 CPU 上记录的更多样本中观察到某个帧，表明存在潜在的性能下降。
Universal Profiling 的主要目标之一是让用户获得净收益：分析和观察应用程序的成本不应高于优化产生的节省。
本着这种精神，host-agent 和存储都经过精心设计，尽可能减少资源使用。
Universal Profiling 存储预算在每个分析核心的基础上是可预测的。 我们以 20 Hz 的固定采样频率生成的数据将以大约每天每核心 40 MB 的速率存储在 Elasticsearch 中。
由于 Universal Profiling 提供全系统连续分析，因此 host-agent 的资源使用率与机器上运行的进程数量高度相关。
我们已记录到真实的生产环境中 host-agent 的部署消耗的 CPU 时间在 0.5% 到 1% 之间，进程的内存占用低至 50 MB，而在较繁忙的主机上高达 250 MB。