You can also send metrics directly to an otel backend that can visualize them

Thank you, I don’t wish to send the metrics, I want to have them built in the same app, so it just exposes the metrics for pulling.

https://opentelemetry.io/img/otel-diagram.svg - perhaps you are looking for an in-memory time-series database of some sort?

yes yes exactly, but didn’t find an example of implementing with clj-otel

yeah I’m not sure otel is intended to be used in this scenario, it is about the observability of applications

@U028REEBHGF perhaps you can describe your need in #CQT1NFF4L?

thank you, I guess my only option would be with the java interop around the open-telemetry, a lot to figure out though ..

if you mean you just want to view the application traces and metrics locally you can run jeager locally pretty easily: https://cljdoc.org/d/com.github.steffan-westcott/clj-otel-api/0.2.6/doc/tutorial#_start_telemetry_backend

Yes, done the tutorial, however still fits as a separate collector and isn’t accepted

You can export metrics directly to a Prometheus instance without going via any Collector(s). The divisor-app is a small example that exports directly to Prometheus. https://github.com/steffan-westcott/clj-otel/tree/master/examples/divisor-app

`divisor-app` uses the OpenTelemetry agent at runtime. By default, the agent attempts to export metrics using OTLP, so the option otel.metrics.exporter=prometheus is required to use Prometheus instead. You'll see this option (and others) in the deps.edn of the example.

So it does a push exporting right? my task is to be a pull server, so I can add it as source in Prometheus or any other similar

divisor-app includes a Prometheus configuration, where the Prometheus instance scrapes (pulls) metrics from an HTTP endpoint provided by the instrumentation agent.

oh, yes, no instrumentation agent, all instrumenting will be internal..

The instrumentation agent runs as a Java agent, so it is in the same OS process as the main application.

no java agent, all metrics would be manually instrumented around the code

Manual instrumentation is the primary use case of clj-otel, so you are in the right place 😄 You have the option of using the Java agent or not when using clj-otel. Using the agent is useful, as you get lots of high-quality instrumentation with no effort. Please take a look at this https://cljdoc.org/d/com.github.steffan-westcott/clj-otel-api/0.2.6/doc/concepts#_instrumenting_libraries_and_applications.

In iopates package there was a reitit middleware that used io.prometheus.server to render the metrics .. I have to do something similar but with open-telemetrics .. my view is foggy, confusing aspects .. I understand clj-otel doesn’t have such a middlerware, and most probably I need some “in memory” thingy .. Or perhaps I could use jetty to render the registry metrics? 🤯

Perhaps to clear your view, might I suggest looking through the https://cljdoc.org/d/com.github.steffan-westcott/clj-otel-api/0.2.6/doc/concepts documentation? I think you may be confusing instrumentation (getting the telemetry data) with visualisation (analysis and display of telemetry data). Telemetry backends are responsible for visualisation.

Prometheus ships with a very basic display of metrics that it collects (scrapes). Telemetry backends (like Grafana and many others) integrate with your Prometheus instance to give a more comprehensive display and analysis.

Yes, that’s what I need, a basic display of metrics, not a collector or exporter to collector.

In the OpenTelemetry model, that display would be provided by a telemetry backend. clj-otel scope does not include making a telemetry backend, as it's focus is on the source of the telemetry data, not the visualisation.

Yess, but it exports right ? and instead of export it, can’t I store it in memory, and on request, display it? ..

The Prometheus exporter does not store metrics, as far as I know. It exports metrics in batches of a few seconds' worth of metrics at a time.

A Prometheus instance stores the metrics it scrapes, so I think you may be duplicating effort.

quoting - “Must not be specific to Prometheus, but to OpenTelemetry, in case tomorrow we switch to something else”

It sounds like you need to investigate the use cases for analysis and display of your metrics. You will need to develop queries against those metrics, which will likely involve PromQL or similar. OpenTelemetry and clj-otel is a standardisation effort around the capture and forwarding of telemetry data to compatible telemetry backends. I think it would be a lot of effort (but not impossible) to create your own telemetry backend, so you may need to look at the capabilities of existing backends and see if they fit your needs.

Correction: divisor-app in fact does not use the OpenTelemetry instrumentation agent. Instead, it uses the autoconfigure SDK extension. I'm sorry for any confusion caused. This https://cljdoc.org/d/com.github.steffan-westcott/clj-otel-api/0.2.6/doc/guides#_configure_and_run_an_application_with_telemetry explains the various options for configuring and running an application with telemetry.