Suggestion of an Observer Module for the Daml Code Base

I use Erlang/OTP in another capacity, for Network/Gaming type use cases … not brilliantly, but I do use it and in my opinion, one of it’s best features, is the Erlang Observer.

The Erlang Observer is a GUI that you can run at anytime once the BEAM is functional and it gives you total transparency on any of the processes; the children, the supervisors, the services etc.

Connect to it locally, or connect to it using the network, it is a great tool.

It allows you to see memory utilisation, kernel events, network load, I/O bottlenecks etc and I think it would be a great tool to be able to connect to and run against either a functional Daml application, a Daml-supporting ledger or both.

Generalised image here here and here.

1 Like

I’m not familiar with this tool.

To visually inspect a ledger during development we have Navigator, while for more in-depth information about the runtime you can use any off-the-shelf tool to connect to a running JVM process, like JConsole, which is shipped as part of the OpenJDK.

How would those tools compare with Observer?

2 Likes

Thank you for the reply. I will read the jConsole docs and run an instance tomorrow and get back to you about the specifics.

However Erlang Observer is lightweight, fast and abundantly helpful … I like it.

1 Like

You can also look at VisualVM (used to be part of Oracle JDK, but doesn’t seem to be shipped with OpenJDK) for generic JVM tooling.

Ledger-specific insights-yielding tools are difficult to design because they are fundamentally at odds with the basic privacy promises of the Daml platform.

2 Likes

Actually that looks like a pretty good tool, the biggest view I want to see is of Spawning & Killing processes; connect to the application? I want to see the process being created, named, allocated it’s memory etc. I’ll check it out :crossed_fingers:t2:

1 Like

You may be a little bit disappointed there: the JVM is not particularly good at creating and killing threads (its rough equivalent to Erlang processes, but much more clunky and heavy), so most applications use a thread pool instead of dynamic thread allocations.

So this movie is going to be a bit dull: you’ll see a bunch of threads being created at startup, and then nothing else will ever happen.

1 Like

I’ll try it and see what I think. In the meantime I’ll
leave my suggestion to the experts.

1 Like