We are enjoying using your library at work.

I'm glad to hear you are enjoying clj-otel 😄 I should be releasing 0.2.7 within the next 7 days. I am working on adding Grafana dashboards to the microservices examples. They will feature traces and metrics. The JVM metrics provided by Java OpenTelemetry out-of-the-box are illuminating and deserve to be displayed clearly and coherently.

The following release may be 0.3.0, as that will introduce some long-planned work for the logs signal. There will be some small breakage (sorry!) as changes are made to clj-otel to make entire applications "bound context" aware for correct logging of context throughout, not just the Clojure parts.

Attributes need to be of low cardinality, as there is a limit of 2000 distinct sets per instrument. This is quite a generous limit. If you are getting anywhere close to this limit, you need to reconsider the attributes you are using.

Say you are attempting to count the number of events by event type across a number of application instances. The number of event types might be too high, but perhaps they can be grouped in some way that still give insight.

Alternatively, consider if raw metrics is an appropriate tool for the task at hand. You may want to consider deriving metrics from logs instead.

If you absolutely must have high cardinality, then Honeycomb might be a good telemetry backend to consider.

If you were using OTLP rather than Prometheus to export metrics, you could try setting system property otel.exporter.otlp.metrics.temporality.preference to LowMemory to make the OTLP exporter use delta temporality (i.e. send changes) rather than cumulative temporality (i.e. send all values since application start) See https://opentelemetry.io/docs/specs/otel/metrics/sdk_exporters/otlp/ I have no idea if this would help, so maybe not a sound idea.