Nice introduction to an underrated tool for languages that run on the BEAM :)
Erlang’s dbg module is extremely handy for debugging in the REPL during development. However, care should be taken when running dbg in production, especially if you have SLOs for low latency. Libraries like redbug and recon are handy because they can shut themselves off after a certain number of function calls or messages. They also provide a gentler syntax for matching than Erlang’s ‘match specifications’.
Another fabulous tool for debugging Erlang, particularly the interactions between various OTP processes, is the sys module. With sys, you can inspect the state of a gen_* process, and you can get printouts of messages passed between these processes. You can also start a GUI for inspecting the state of a running Erlang system with observer.
Nice introduction to an underrated tool for languages that run on the BEAM :)
Erlang’s
dbgmodule is extremely handy for debugging in the REPL during development. However, care should be taken when runningdbgin production, especially if you have SLOs for low latency. Libraries like redbug and recon are handy because they can shut themselves off after a certain number of function calls or messages. They also provide a gentler syntax for matching than Erlang’s ‘match specifications’.Another fabulous tool for debugging Erlang, particularly the interactions between various OTP processes, is the
sysmodule. Withsys, you can inspect the state of a gen_* process, and you can get printouts of messages passed between these processes. You can also start a GUI for inspecting the state of a running Erlang system withobserver.When doing something like this on a production system, are there any dangers or extra load it puts on the VM?
Yes. This is why libraries such as recon have been written. See Erlang in Anger for more content on debugging production systems.