即使系统构建完成并投入生产，您的工作也并未结束。事情偶尔会出错，您会遇到错误。代码也可能没有得到适当优化，您可能会消耗过多资源。如果您成功地实现了容错系统，它可能会恢复并应对错误和增加的负载。无论如何，您仍然需要深入了解任何问题并加以修复。

鉴于您的系统高度并发且分布式，发现和理解出现的问题可能并不明显。对这个主题的适当处理可以轻松填满一本单独的书——有一本优秀的免费书籍可供参考，名为《Stuff Goes Bad: Erlang in Anger》，作者是 Fred Hébert（https://www.erlang-in-anger.com/）。本章提供了一些分析复杂 BEAM 系统的标准技术的基本介绍，但如果您计划在生产中运行 Elixir 或 Erlang 代码，您应该在某个时候更详细地研究这个主题，而《Stuff Goes Bad》是一个很好的起点。

13.3.1 调试

尽管这与运行系统并不严格相关，但调试值得简要提及。标准的逐步调试在 Erlang 中并不是一种常用的方法，这可能会让人感到惊讶（Erlang 附带一个基于 GUI 的调试器；请参见 https://www.erlang.org/doc/apps/debugger/debugger_chapter.xhtml）。这是因为在高度并发的系统中进行经典调试是不可能的，许多事情是同时发生的。想象一下，你在一个进程中设置了一个断点。当遇到断点时，其他进程应该发生什么？它们应该继续运行，还是也应该暂停？一旦你跨过一行，所有其他进程是否应该向前移动一步？超时应该如何处理？如果你正在调试一个分布式系统，会发生什么？正如你所看到的，由于 BEAM 驱动系统的高度并发和分布式特性，经典调试存在许多问题。

与其依赖调试器，不如采用更合适的策略。理解高度并发系统的关键在于日志记录和追踪。一旦出现问题，您会希望拥有尽可能多的信息，这将帮助您找到问题的根源。

很不错的是，Elixir 的 logger 应用程序（https://hexdocs.pm/logger/Logger.xhtml）开箱即用地提供了一些日志记录功能。特别是，每当一个符合 OTP 的进程崩溃（例如， GenServer ），都会打印出错误信息以及堆栈跟踪。堆栈跟踪还包含文件和行号信息，因此这应该为调查错误提供一个良好的起点。

有时，失败的原因可能在堆栈跟踪中并不明显，您需要更多的数据。在开发时，一个原始的辅助工具是 IO.inspect 。请记住， IO.inspect 接受一个表达式，打印其结果并返回它。这意味着您可以用 IO.inspect 包围代码的任何部分（或通过 |> 管道传入），而不会影响程序的行为。这是一种简单的技术，可以帮助您快速确定问题的原因，当一段新代码出现问题时，我经常使用它。放置 IO.inspect 以查看值是如何传播到失败位置的，通常可以帮助我发现错误。一旦我修复了问题，就会移除 IO.inspect 调用。

通过 dbg 宏 ( https://hexdocs.pm/elixir/Kernel.xhtml#dbg/2) 可以获得更丰富的体验。与 IO.inspect 类似，该宏生成返回其输入参数的代码。因此，只要不绑定任何变量，任何表达式都可以安全地包装在 dbg 中。 dbg 宏打印更详细的信息，例如管道链的中间结果。

另一个有用的功能是 pry，它允许您在 iex shell 中暂时停止执行并检查系统的状态，例如作用域内的变量。有关详细说明，请参阅 IEx.pry/0 文档 (https://hexdocs.pm/iex/IEx.xhtml#pry/0)。官方 Elixir 网站上也提供了典型调试技术的概述，网址为 https://elixir-lang.org/getting-started/debugging.xhtml。

不言而喻，自动化测试可以提供显著的帮助。单独测试各个部分可以帮助您快速发现和修复错误。

还值得提到几个有用的基准测试和性能分析工具。最原始的一个是 :timer.tc/1 函数 (https://erlang.org/doc/man/timer.xhtml#tc-1)，它接受一个 lambda，运行它，并返回其结果以及运行时间（以微秒为单位）。

此外，Erlang/OTP 附带了一些分析工具： cprof 、 eprof 和 fprof 。Elixir 包含 mix 任务来运行这些工具：

• mix profile.cprof (https://hexdocs.pm/mix/Mix.Tasks.Profile.Cprof.xhtml)
• mix profile.eprof (https://hexdocs.pm/mix/Mix.Tasks.Profile.Eprof.xhtml)
• mix profile.fprof (https://hexdocs.pm/mix/Mix.Tasks.Profile.Fprof.xhtml)

最后，有各种基准库可用，例如 Benchee (https://hexdocs.pm/benchee)。我不会详细解释这些，因此当您决定进行性能分析时，最好先阅读官方文档以及 Erlang 文档，网址为 https://www.erlang.org/doc/efficiency_guide/profiling.xhtml。

13.3.2 日志记录

一旦进入生产环境，您就不应该再依赖 IO.inspect 或 dbg 调用。相反，最好记录各种信息，以帮助您了解出了什么问题。为此，您可以依赖 Elixir 的 logger 应用程序。当您生成 Mix 项目时，此依赖项将自动包含，建议您使用 logger 来记录各种事件。如前所述， logger 会自动捕获各种 BEAM 报告，例如在进程中发生的崩溃错误。

日志信息默认输出到控制台。如果您以发布模式启动系统，标准输出将转发到发布根文件夹下的日志文件夹，您将能够稍后找到并分析这些错误。

当然，您可以编写一个自定义 logger 处理程序，例如一个将日志写入 syslog 或将日志报告发送到其他机器的处理程序。有关更多详细信息，请参见 logger 文档 ( https://hexdocs.pm/logger/Logger.xhtml)。 logger 应用程序主要是 Erlang 的 :logger 模块的包装，因此研究 Erlang 日志指南 ( https://www.erlang.org/doc/apps/kernel/logger_chapter.xhtml) 也是值得的。

13.3.3 与系统交互

Erlang 运行时的一个重要好处是您可以连接到正在运行的节点并以各种方式与之交互。您可以向进程发送消息，并停止或重启不同的进程（包括监督者）或 OTP 应用程序。甚至可以强制虚拟机重新加载模块的代码。

在此基础上，各种内置函数允许您收集有关系统和单个进程的数据。例如，您可以启动一个远程 shell，并使用 :erlang.system_info/1 和 :erlang.memory/0 等函数获取有关运行时的信息。

您还可以使用 Process.list/0 获取所有进程的列表，然后使用 Process.info/1 详细查询每个进程，返回的信息包括内存使用情况和进程已执行的指令总数（在 Erlang 中称为 reductions）。这样的服务为可以连接到运行系统并以 GUI 形式呈现 BEAM 系统信息的工具铺平了道路。

一个例子是 observer 应用程序，您在第 11 章中见过。由于是基于 GUI 的， observer 仅在主机操作系统中有窗口系统时才能工作。在生产服务器上，通常不是这种情况。但是您可以在本地启动 observer 并让它从远程节点收集数据。

让我们看看这个实际操作。您将把系统作为后台服务启动，然后在另一个节点上启动您将运行的 observer 应用程序。 observer 应用程序将连接到远程节点，从中收集数据，并在 GUI 中呈现。

生产系统不需要运行 observer 应用程序，但需要包含收集远程 observer 应用程序数据的模块。这些模块是您需要在发布中包含的 runtime_tools 应用程序的一部分。您可以通过 mix.exs 中的 :extra_applications 选项轻松做到这一点。

清单 13.4 在发布中包含 runtime_tools (todo_release/mix.exs)

defmodule Todo.MixProject do
  ...
 
  def application do
    [
      extra_applications: [:logger, :runtime_tools],   ?
      ...
    ]
  end
 
  ...
end

? 在 OTP 发布中包含 runtime_tools

:extra_applications 选项指定了您依赖的 Elixir 和 Erlang 的标准 OTP 应用程序。默认情况下，当您使用 mix 工具生成新项目时，Elixir 的 :logger OTP 应用程序会作为依赖项包含在内。

注意 :extra_applications 的作用与 mix.exs 文件中的 deps 函数不同。使用 deps 时，您列出必须获取和编译的第三方依赖项。相反，使用 :extra_applications 时，您列出已经在磁盘上编译的 Elixir 和 Erlang 库应用程序，这些是 Erlang 和 Elixir 安装的一部分。这些依赖项的代码不需要被获取，也不需要编译。但您仍然需要列出这些依赖项，以确保应用程序包含在 OTP 发布中。

通过此更改， runtime_tools 已包含在您的 OTP 发布中，现在您可以远程观察生产系统。让我们看看实际操作。首先，您需要在后台启动待办事项系统：

$ RELEASE_NODE="todo@localhost" \
  RELEASE_COOKIE="todo" \
  _build/prod/rel/todo/bin/todo daemon

请注意， RELEASE_COOKIE 操作系统环境变量已设置为配置秘密节点 cookie。

现在，以命名节点的方式启动交互式 shell，然后启动 observer 应用程序：

$ iex --hidden --sname observer@localhost --cookie todo
 
iex(observer@localhost)1> :observer.start()

注意您如何明确地将节点的 cookie 设置为与运行系统中使用的 cookie 匹配。此外，就像在第 13.1.1 节中的早期 remsh 示例一样，您将节点作为隐藏状态启动。一旦观察者启动，您需要从菜单中选择节点 > todo@localhost。此时， observer 正在展示有关生产节点的数据。

值得一提的是， observer 和 runtime_tools 是用普通的 Erlang 编写的，并依赖于低级函数来收集数据并以各种方式呈现。因此，您可以使用其他类型的前端，甚至编写自己的前端。一个例子是 observer_cli（https://github.com/zhongwencool/observer_cli），这是一个类似观察者的前端，具有文本界面，可以通过命令行界面使用。

13.3.4 跟踪

也可以开启与进程和函数调用相关的跟踪，依赖于 :sys (https://www.erlang.org/doc/man/sys.xhtml) 和 :dbg (https://www.erlang.org/doc/man/dbg.xhtml) 模块提供的服务。 :sys 模块允许您跟踪符合 OTP 标准的进程（例如， GenServer ）。跟踪是在标准输出上进行的，因此您需要连接到系统（而不是建立远程 shell）。然后，您可以借助 :sys.trace/2 为特定进程开启跟踪。

让我们看看它的实际效果。确保节点未在运行，然后在后台启动它，使用 iex 启动：

$ TODO_SERVER_EXPIRY=600 \
  RELEASE_NODE="todo@localhost" \
  RELEASE_COOKIE="todo" \
  _build/prod/rel/todo/bin/todo daemon_iex

为了本次演示，待办服务器的过期时间增加到 10 分钟。

现在，您可以附加到正在运行的节点并跟踪该过程：

$ _build/prod/rel/todo/erts-13.0/bin/to_erl _build/prod/rel/todo/tmp/pipe/
 
iex(todo@localhost)1> :sys.trace(Todo.Cache.server_process("bob"), true)

这将开启控制台跟踪。有关进程相关事件的信息，例如接收到的请求，将被打印到标准输出。

现在，发出一个 HTTP 请求以获取 Bob 的列表：

$ curl "http://localhost:5454/entries?list=bob&date=2023-12-19"

在附加的外壳中，您应该看到类似这样的内容：

*DBG* {todo_server,<<"bob">>} got call {entries,
  #{'__struct__' => 'Elixir.Date', calendar => 'Elixir.Calendar.ISO',
    day => 19,month => 12, year => 2023}} from <0.983.0>}
 
*DBG* {todo_server,<<"bob">>} sent [] to <0.322.0>,
  new state {<<"bob">>, #{'__struct__' => 'Elixir.Todo.List',
    next_id => 1, entries => #{}}}

输出可能看起来有些晦涩，但如果仔细观察，可以看到两个跟踪条目：一个是接收到的呼叫请求，另一个是您发送的响应。您还可以看到服务器进程的完整状态。请记住，所有术语都是以 Erlang 语法打印的。

追踪是一种强大的工具，因为它允许您分析运行系统的行为。但要小心，因为过度追踪可能会影响系统的性能。如果您正在追踪的服务器进程负载很重或状态庞大，BEAM 将花费大量时间进行追踪 I/O，这可能会减慢整个系统的速度。

无论如何，一旦你对这个过程有了一些了解，你应该停止追踪它：

iex(todo@localhost)1> :sys.trace(Todo.Cache.server_process("bob"), false)

来自 :sys 的其他有用服务允许您获取 OTP 过程状态（ :sys.get_state/1 ）甚至更改它（ :sys.replace_state/2 ）。这些功能仅用于调试或手动修复——您不应该在代码中调用它们。

另一个有用的追踪工具是 :erlang.trace/3 函数 (https://www.erlang.org/doc/man/erlang.xhtml#trace-3)，它允许您订阅系统中的事件，例如消息传递或函数调用。

此外，一个名为 :dbg 的模块 ( https://www.erlang.org/doc/man/dbg.xhtml) 简化了追踪。您可以直接在附加控制台上运行 :dbg ，但也可以启动另一个节点并让它追踪主系统。这是您在下一个示例中将采取的路线。

假设待办节点仍在运行，启动另一个节点：

$ iex --sname tracer@localhost --cookie todo --hidden

现在，在 tracer 节点上，开始跟踪主 todo 节点，然后指定您对来自 Todo.Server 模块的所有函数调用感兴趣：

iex(tracer@localhost)1> :dbg.tracer()                ?
iex(tracer@localhost)2> :dbg.n(:"todo@localhost")    ?
iex(tracer@localhost)3> :dbg.p(:all, [:call])        ?
iex(tracer@localhost)4> :dbg.tp(Todo.Server, [])     ?

? 启动跟踪器进程

仅订阅来自待办节点的事件

? 订阅所有进程中的函数调用

? 将跟踪模式设置为来自 Todo.Server 进程的所有功能

设置好跟踪后，您可以发出 HTTP 请求以检索 Bob 的条目。在 tracer 节点的 shell 中，您应该会看到如下内容：

(<12505.1106.0>) call 'Elixir.Todo.Server':whereis(<<"bob">>)
(<12505.1106.0>) call 'Elixir.Todo.Server':child_spec(<<"bob">>)
(<12505.1012.0>) call 'Elixir.Todo.Server':start_link(<<"bob">>)
(<12505.1107.0>) call 'Elixir.Todo.Server':init(<<"bob">>)
(<12505.1107.0>) call 'Elixir.Todo.Server':handle_continue(init, ...)
(<12505.1106.0>) call 'Elixir.Todo.Server':entries(<12505.1107.0>, ...)
(<12505.1107.0>) call 'Elixir.Todo.Server':handle_call({entries, ...})

每个输出行显示调用进程、被调用的函数和输入参数。

在生产环境中进行追踪时要小心，因为大量的追踪可能会淹没系统。一旦完成追踪，请调用 :dbg.stop_clear/0 以停止所有追踪。

这确实是一个简短的演示； :dbg 还有更多选项。如果您决定进行一些追踪，您应该查看 :dbg 文档。此外，您还应该查看名为 Recon 的库 (https://github.com/ferd/recon)，它提供了许多用于分析正在运行的 BEAM 节点的有用功能。

我们现在已经完成了对 Elixir、Erlang 和 OTP 的探索。本书涵盖了 Elixir 语言的主要方面、基本的函数式编程习惯、Erlang 并发模型以及最常用的 OTP 行为（ GenServer 、 Supervisor 和 Application ）。根据我的经验，这些是 Elixir 和 Erlang 系统中最常需要的构建块。

当然，许多主题尚未涉及，因此您的旅程并不会止步于此。您可能会想寻找其他知识资源，例如其他书籍、博客和播客。寻找进一步材料的一个好起点是官方 Elixir 网站上的“学习”页面（https://elixir-lang.org/learning.xhtml）。

摘要

• 要启动系统，所有代码必须被编译。然后，您必须启动一个正确设置加载路径的 BEAM 实例。最后，您需要启动所有 OTP 应用程序。
• 最简单的方法是依赖于 Elixir 工具，如 iex 和 Mix。
• OTP 发布是一个独立的系统，仅由运行时工件组成——编译后的 OTP 应用程序和（可选的）Erlang 运行时系统。
• OTP 发布可以通过 mix release 任务轻松构建。
• 一旦发布运行，您可以通过远程 shell 连接到它或附加到其控制台。然后，您可以以各种方式与系统交互，并找到有关虚拟机和单个进程的详细信息。