Autometrics List

列出所有带有 "autometrics" 注解的函数的命令。

目标是使用此二进制文件作为快速静态分析器，从代码库返回要自动量化的所有注释函数的完整列表。

分析由 Tree-sitter 提供，所有特定逻辑都包含在每个语言实现中特定的 Tree-sitter 查询 中。

快速入门

使用安装脚本直接从 Github 拉取最新版本（相应地更改 VERSION）

VERSION=0.2.0 curl --proto '=https' --tlsv1.2 -LsSf https://github.com/autometrics-dev/am_list/releases/download/v$VERSION/am_list-installer.sh | sh

然后运行二进制文件

# Make sure that `~/.cargo/bin` is in your `PATH`
am_list list -l rs /path/to/project/root

当前状态和已知问题

语言支持表

在以下表中，具有 "检测" 功能表示 am_list 返回与您在 PromQL 中查看指标所需相同的标签。简而言之，"Autometrics 兼容性"。

[^wrapper]: 对于 TypeScript（以及所有 Autometrics 是包装函数的语言），静态分析使得难以遍历导入以找到定义了已配置函数的模块，因此报告的模块是已配置函数的模块。

[^all-functions]: 支持列出所有自动量化的函数，但不限于所有函数

Typescript

模块跟踪

此工具无法“精确”跟踪模块（即“模块标签与autometrics报告的完全一致”），因为autometrics-ts使用JS编译包中的源路径来报告模块。编译和打包发生在am_list查看代码之后，因此无法精确。

这意味着TypeScript的模块报告将注定是“尽力而为”的尝试以有用。

在使用autometrics-ts的静态分析工具时遇到的另一个困难是，仪表化可以发生在任何地方，因为包装函数的调用可以使用导入的符号作为其参数

import { exec } from "child_process";
import { autometrics } from "@autometrics/autometrics";

const instrumentedExec = autometrics(exec);

// use instrumentedExec everywhere instead of exec

为了将函数定义的位置报告为模块，我们需要包括

• 一个完整的导入解析步骤，以确定仪表化函数的原始模块（例如，示例中的child_process），以及
• 一个依赖关系检查步骤，以确定仪表化函数定义在依赖关系中的路径（例如，在node源代码中的lib/child_process.js）

准确实现这些步骤是不切实际的且容易出错，因此我们只尝试检测在相同文件中显式导入的导入，并且我们只报告导入的模块作为函数模块（而不是定义它的文件路径）。实际上，这意味着对于这个例子

// in src/router/index.ts
import { exec } from "child_process";
import { origRoute as myRoute } from "../handlers";
import { autometrics } from "@autometrics/autometrics";

const instrumentedExec = autometrics(exec);
const instrumentedRoute = autometrics(myRoute);

// use instrumentedExec everywhere instead of exec

am_list将报告2个函数

• {"function": "exec", "module": "ext://child_process"}：使用ext://协议表示模块是非本地的
• {"function": "origRoute", "module": "handlers"}：即使myRoute从../handlers/my/routes/index.ts重新导出，我们也不会查看handlers做了什么来暴露origRoute；另外，别名已解析。