Simple BEAM/VM metrics collection for OpenTelemetry - what exists?

Questions / Help
, ,
1

Hi everyone,

I’m looking for a simple, out-of-the-box solution to collect basic BEAM/VM metrics (process count, atom count, memory usage, bins, schedulers utilisation, etc.) and send them via OpenTelemetry to my monitoring system.

I already have OpenTelemetry working for my application traces, but I’d like to add VM-level observability without writing custom collection code or complex bridges between different telemetry systems.

Does anyone know of:

  • An existing library that handles this cleanly?
  • A standard pattern the community uses?
  • Something that just works without extensive setup?

I’ve looked at various combinations of telemetry_poller, prometheus.erl, and opentelemetry_telemetry, but they all seem to require glue code or configuration complexity.

Ideally looking for something like “add this dependency, call this function in your app startup, and VM metrics start flowing to your OTEL collector.”

Any recommendations?

Thanks,

2

Following up on this - I’m surprised there isn’t more discussion around this topic given the OpenTelemetry ecosystem we have:

  • opentelemetry_bandit
  • opentelemetry_broadway
  • opentelemetry_cowboy
  • opentelemetry_dataloader
  • opentelemetry_ecto
  • opentelemetry_elli
  • opentelemetry_finch
  • opentelemetry_grpcbox
  • opentelemetry_httpoison
  • opentelemetry_nebulex
  • opentelemetry_oban
  • opentelemetry_phoenix
  • opentelemetry_redix
  • opentelemetry_req
  • opentelemetry_tesla
  • opentelemetry_xandra

All of these are actively maintained and provide great application-level observability, but there seems to be a gap when it comes to basic BEAM VM metrics export via OpenTelemetry.

Is this because:

  • Most people are using Prometheus/StatsD for VM metrics instead?
  • There’s a technical challenge I’m not seeing?
  • It’s just not been a priority for the community?

Anyone else finding this gap, or have thoughts on the best approach?

3

fwiw, we expose Prometheus metrics (we use an in-house prometheus library, but prometheus.erl would work – both expose BEAM metrics) and then use otel-collector to feed them into Tempo.

Except when deliberately working with OTel tracing and spans, we don’t use any of the opentelemetry_ libraries.

4

@rlipscombe Thanks for sharing!

Quick questions:

  • How’s the operational overhead of the otel-collector bridge?
  • Any particular BEAM metrics you find most valuable?

Starting to think the community naturally evolved toward “right tool for each job” rather than forcing everything through one system. Though still think there’s value in a simple opentelemetry_beam for those wanting pure OTel.

Anyone else?

5

Our observability team mostly looks after that, but it seems fairly lightweight from a scraping point of view.

Any particular BEAM metrics you find most valuable?

Memory stats (processes, binary, etc.), ETS usage (we use a lot of ETS).

naturally evolved toward “right tool for each job”

For us, it was more that we already had a solid Prometheus → Victoria Metrics → Grafana pipeline in place for several years before we started using OTel.