This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-04-10
Channels
- # aleph (3)
- # announcements (1)
- # architecture (16)
- # bangalore-clj (1)
- # beginners (65)
- # biff (5)
- # calva (23)
- # clj-kondo (6)
- # clj-otel (12)
- # clojure-austin (2)
- # clojure-europe (11)
- # clojure-norway (7)
- # clojure-uk (1)
- # clojuredesign-podcast (2)
- # clojurescript (18)
- # conjure (3)
- # datomic (1)
- # deps-new (18)
- # events (1)
- # hyperfiddle (14)
- # java (4)
- # malli (5)
- # off-topic (10)
- # pathom (13)
- # polylith (10)
- # practicalli (1)
- # re-frame (3)
- # reitit (16)
- # releases (1)
- # rum (5)
- # shadow-cljs (17)
📣 I am very pleased to announce clj-otel
release 0.2.0.
📈 This milestone release adds Metric API support to complement the existing support for the Traces API. Full details of changes can be seen in the https://cljdoc.org/d/com.github.steffan-westcott/clj-otel-api/0.2.0/doc/changelog.
⚠️ For those of you upgrading from a previous version of clj-otel
, please note there are a number of breaking changes, marked [BREAK] in the changelog. The most notable changes affect the middleware/interceptors and how they are applied. The documentation https://cljdoc.org/d/com.github.steffan-westcott/clj-otel-api/0.2.0/doc/guides#_work_with_http_client_and_server_spans and https://cljdoc.org/d/com.github.steffan-westcott/clj-otel-api/0.2.0/doc/examples have been updated accordingly. Please read the changelog, guides and examples carefully before upgrading clj-otel
.
https://github.com/steffan-westcott/clj-otel
clj-otel
0.2.0 introduces wrap-route
, a new Ring middleware that adds route data to the HTTP server spans of requests that match a route. This is designed to work with routers that inject route data into the request map, such as Reitit.
@steffan, I was venturing into the lib and would like to know if it is possible, following the latest updates, to get a full traceback of the information...
it would be to have the most detailed traces, in the same stack trace style, but not just for errors, but for all requests. I'll send a print of an example of how it is
like a dumpstack of the entire transaction
If you want information on every function evaluated during program execution, you should consider using a tool that offers (continuous) profiling or function-level instrumentation. Application profiling is working at a lower level than observability, generally speaking. A very good tool for instrumenting Clojure applications is https://github.com/jpmonettas/flow-storm-debugger.
More general Java application profilers are https://www.yourkit.com/, https://www.ej-technologies.com/products/jprofiler/overview.html and https://visualvm.github.io/. Some telemetry backends also have continuous profiling of Java applications e.g. https://www.datadoghq.com/dg/apm/profiler/java-continuous-profiler
ok ok, I'll take a look at these items... it's just that I wanted to do this all integrated with opentelemetry, just like your lib
It looks like OpenTelemetry is working on a proposal to add continuous profiling: https://github.com/open-telemetry/oteps/issues/139 2 other, OSS continuous profiling tools: https://grafana.com/blog/2023/03/15/pyroscope-grafana-phlare-join-for-oss-continuous-profiling
@UCHV4JZ7A Thank you for the links to continuous profiling initiatives 😄 If this makes its way into the OpenTelemetry standard, then I really hope vendors with existing JVM continuous profiling solutions move to support Otel with the same enthusiasm that they embraced the Traces API. Exciting times! 🔭