See below for config by topic-

A signal will be provided to a handler iff ALL of the following are true:

• 1. Signal call filters pass:
  • a. Compile time: sample rate, kind, ns, id, level, when form, rate limit
  • b. Runtime: sample rate, kind, ns, id, level, when form, rate limit
• 2. Signal handler filters pass:
  • a. Compile time: not applicable
  • b. Runtime: sample rate, kind, ns, id, level, when fn, rate limit
• 3. Call transform (fn [signal]) => ?modified-signal returns non-nil
• 4. Handler transform (fn [signal]) => ?modified-signal returns non-nil

👉 Transform fns provides a flexible way to modify and/or filter signals by arbitrary signal data/content conditions (return nil to skip handling).

👉 Call and handler filters are additive - so handlers can be more but not less restrictive than call filters allow. This makes sense: call filters decide if a signal can be created. Handler filters decide if a particular handler is allowed to handle a created signal.

See help:filters for more about filtering.

Telemere offers a lot of filtering control, so real systems can get quite complex. There's a lot of tools to help debug, including:

See section 4-Handlers.

tools.logging can use Telemere as its logging implementation (backend). This'll let tools.logging calls create Telemere signals.

To do this:

1. Ensure that you have the tools.logging dependency, and
2. Call tools-logging->telemere!, or set the relevant environmental config as described in its docstring.

Verify successful interop with check-interop:

(check-interop) ; =>
{:tools-logging {:sending->telemere? true, :telemere-receiving? true}}

SLF4Jv2 can use Telemere as its logging backend. This'll let SLF4J logging calls create Telemere signals.

To do this:

1. Ensure that you have the SLF4J dependency (v2+ only), and
2. Ensure that you have the Telemere SLF4J backend dependency

When com.taoensso/telemere-slf4j (2) is on your classpath AND no other SLF4J backends are, SLF4J will automatically direct all its logging calls to Telemere.

Verify successful interop with check-interop:

(check-interop) ; =>
{:slf4j {:sending->telemere? true, :telemere-receiving? true}}

Telemere needs SLF4J API version 2 or newer. If you're seeing Failed to load class "org.slf4j.impl.StaticLoggerBinder" it could be that your project is importing the older v1 API, check with lein deps :tree or equivalent.

For other (non-SLF4J) logging like Log4j, java.util.logging (JUL), and Apache Commons Logging (JCL), use an appropriate SLF4J bridge and the normal SLF4J config as above.

In this case logging will be forwarded:

1. From Log4j/JUL/JCL/etc. to SLF4J, and
2. From SLF4J to Telemere

The JVM's System/out and/or System/err streams can be set so that they'll create Telemere signals when flushed.

To do this, call streams->telemere!.

Note that Clojure's *out*, *err* are not necessarily automatically affected.

Verify successful interop with check-interop:

(check-interop) ; =>
{:system/out {:sending->telemere? true, :telemere-receiving? true}
 :system/err {:sending->telemere? true, :telemere-receiving? true}}

OpenTelemetry is a popular open-source observability framework that provides tools for collecting, processing, and exporting telemetry data like traces, metrics, and logs from software systems.

Telemere's OpenTelemetry interop is experimental - I'm looking for feedback on this feature please! 🙏

Telemere can send signals as LogRecords with correlated tracing data to configured OpenTelemetry Java exporters.

This allows output to go (via configured exporters) to a wide variety of targets like Jaeger, Zipkin, AWS X-Ray, AWS CloudWatch, etc.

To do this:

1. Ensure that you have the necessary OpenTelemetry Java dependency.
2. Ensure that the relevant exporters are appropriately configured (this is the trickiest part, but not at all specific to Telemere).
3. Create a Telemere signal handler using handler:open-telemetry, and register it using add-handler!.
4. Ensure that otel-tracing? is enabled if you want tracing interop.

Aside from configuring the exporters (2), Telemere's OpenTelemetry interop does not require any use of or familiarity with the OpenTelemetry Java API or concepts. Just use Telemere as you normally would, and the handler (3) will automatically emit detailed log and trace data to your configured exporters (2).

Verify successful interop with check-interop:

(check-interop) ; =>
{:open-telemetry {:present? true, :use-tracer? true, :viable-tracer? true}}

Tufte is a simple performance monitoring library for Clojure/Script by the author of Telemere.

Telemere can easily incorporate Tufte performance data in its signals, just like any other data:

(let [[_ perf-data] (tufte/profiled <opts> <form>)]
  (t/log! {:perf-data perf-data} "Performance data"))

Telemere and Tufte work great together:

• Their functionality is complementary.
• The upcoming Tufte v3 will share the same core as Telemere and offer an identical API for managing filters and handlers.

Truss is a micro toolkit for Clojure/Script errors by the author of Telemere.

Telemere can easily incorporate Truss assertion failure information in its signals, just like any other (error) data.

The catch->error! signal creator can be particularly convenient for this:

(t/catch->error! <form-with-truss-assertion/s>)

Telemere also uses Truss contextual exceptions when relevant.