Instrumenting Erlang code

Vans S vans_163@REDACTED
Sun Jan 26 19:41:19 CET 2020

 On this topic, is there a way to attach instrumentation on the fly in a running system?  That can give you a callback onentry and onexit? To profile wall time and perhap do conditional matching / stack trace inspection. To see which calls trigger the slow path for example.
    On Sunday, January 26, 2020, 12:46:57 p.m. EST, Michael Truog <mjtruog@REDACTED> wrote:  
  On 1/26/20 4:58 AM, Frank Muller wrote:
Hi everyone
 I would like to implement a custom instrumentation module for my Erlang code.
 Let assume this function:
You are describing that you need aspects from aspect oriented programming (that should be the best concept for what you want, when thinking about the problem).  I implemented this in CloudI ( as a list of functions that are executed in order with separate lists for before and after a callback function.  My approach used the following to represent a function [1]:
{Module :: atom(), Function :: atom()}
to represent a function of the expected arity (call it arity N), and:
{{Module :: atom(), Function :: atom()}}
to represent a function of arity 0 that returns a function of arity N, or a normal Erlang function.  Representing the function as a tuple with atoms allows specifying the function before it is loaded.  Using the arity 0 function indirection allows execution of source code before the function is created, normally when a function retains variables created before the function is created (a closure).  Using this approach made it easy to add monitoring to CloudI services and other things like batch execution of CloudI services.
Using functions as data (configuration for the source code [2]) avoids source code that lacks transparency, like macros or parse transforms.
 Best Regards,
 [1] Example type specification
 [2] Example configuration of aspects
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the erlang-questions mailing list