[ANN] trace 0.1, tracy-client 0.1

Howdy fine people,

I’m quite giddy to announce the initial release of my library trace, and of tracy-client (sponsored by my employer, Imandra).

Trace is a lightweight library designed for instrumenting library and executable code with a low dependency cost. It provides abstractions for basic logging, traces (spans), and metrics, with a low footprint. The goal is that it’s ok to depend on it in libraries, and it costs almost nothing at runtime in the absence of a collector. The cost of a call in the absence of a collector is basically an atomic load and a comparison to None.

A collector is a backend that is typically registered at program startup. Only applications should ever specify a backend. There is a simple trace-tef library that provides a backend that writes into a .json file in the Catapult/TEF format (compatible with chrome://tracing in chrome, and with perfetto).

Which brings me to tracy-client. It is a library that provides direct bindings to the excellent Tracy project. It also comes with [tracy-client.trace], which provides a Trace backend that forwards events to Tracy over the network (while the program is running). It can be quite useful for interactive programs such as games, but also for CPU-oriented programs in general. The bindings work, but they don’t cover the full extent of Tracy yet (which notably include frames ­for graphic programs).

So far these are the two released backends for Trace, but I have a Opentelemetry backend in the works; it won’t cover the depth of options of OTEL but it will make it possible to reuse trace-based instrumentation with any OTEL collector. Another exciting possibility with OCaml 5.1 is to use the upcoming Runtime_events (and custom user events) to forward trace events to an external logger with low overhead.

Docs for Trace can be found here.
Trace is licensed under the MIT license, and tracy-client under BSD-3.

28 Likes

A simple usage-example from the perspective of a library-author would be a great addition to the README and/or this thread, heh.

In either case, I love what you’re doing here; an interoperable deep-transitive-dependency-friendly tracing standard would be a fantastic addition to our community and env. Keep it up.

I updated a bit the readme. What do you think?

Amazing work! :100:

Looking forward to the Opentelemetry backend, as this is something I really want.

Will it be substantially different from your existing ocaml-opentelemetry package? Or do you plan to rewrite ocaml-opentelemetry to use trace while maintaining full backwards compatibility?

There is already a sub library named opentelemetry.trace which uses an opentelemetry collector as the trace backend. It’s not used in prod yet but it worked locally.

It relies on thread local storage to remember the context and parent span for a given span; there are discussions on how this could be adapted/extended to work with lwt. If you’re interested in that we can open a github discussion.

1 Like

I swear i’ll get around to writing this up in public very soon. :weary:

It’s a nasty problem.