Rastreamento e depuração de sistemas distribuídos

Debugging a single Erlang process is already fun, but diagnosing issues across multiple interconnected Erlang nodes can be a real challenge! Why is it so hard?

• Concurrency: Many processes running in parallel.
• Distribution: Processes spread across different machines.
• Asynchrony: Messages sent, not always immediately received.

Erlang provides powerful built-in tools to help us peer into these complex systems.

The primary tool for in-depth debugging is the Erlang Debugger. It's a graphical interface that lets you inspect processes, set breakpoints, and trace code execution.

You start the debugger from the Erlang shell. Once open, you can connect to local or remote Erlang nodes to begin your investigation.

Once connected, the debugger allows you to select any running process on the chosen node. You can then:

• View its current state (process dictionary, stack trace).
• Examine its message queue (mailbox).
• Set breakpoints on functions it's executing.

This is crucial for understanding what a process is doing, or waiting for, at any given moment.

The debugger's tracing capabilities, often accessed via the dbg module, let you monitor function calls. You can trace specific functions and see their arguments and return values.

Let's trace a simple module. Compile it, then use dbg:tp/2 to trace its add/2 function.

One of Erlang's powerful features is the ability to trace across a distributed system. The dbg module can be instructed to trace events on other connected nodes, allowing you to follow the flow of execution and messages between them.

This is essential when a problem involves interaction between processes residing on different machines.

Imagine you have a 'worker' process on a remote node. You can instruct your local debugger to trace functions on that remote node. Here's a simple worker module.

If this module was running on worker@remotehost, you could trace its process_task/1 function from your local node using dbg:tp({'worker@remotehost', worker}, process_task, 1, []) after connecting the nodes.

For complex scenarios, viewing trace output directly in the shell or debugger GUI can be overwhelming. The Trace Tool Builder (TTB) helps by recording traces to a file for later, detailed analysis.

With TTB, you can visually replay and filter events, providing a clearer picture of system behavior over time. It's excellent for post-mortem debugging.

While dbg is powerful, it can have overhead. For quick, lightweight, on-the-fly tracing in a running system (even production), Redbug is often preferred.

Redbug lets you trace calls to specific functions and see their arguments and return values with minimal impact. It's perfect for quickly verifying assumptions or pinpointing recent activity.

Like dbg, Redbug can also trace functions on remote nodes. This makes it invaluable for quickly checking what's happening on a specific process or module on another server without bringing down the system or attaching a heavy debugger.

Here's a module we could trace on a remote node using Redbug.

Which of the following statements about Erlang's distributed debugging tools are true?

You've now explored key tools for tracing and debugging distributed Erlang systems:

• The Erlang Debugger (dbg) for in-depth inspection and tracing.
• TTB for recording and visualizing complex traces.
• Redbug for lightweight, on-the-fly tracing, even in production.

Mastering these tools is essential for building and maintaining robust, fault-tolerant distributed applications with Erlang.