taoensso / roadmap

Taoensso open source roadmap
https://www.taoensso.com/roadmap
0 stars 0 forks source link

Telemere: additional handlers (please specify) #12

Open ptaoussanis opened 6 months ago

ptaoussanis commented 6 months ago

Task: Add additional signal handlers to Telemere.

Current handlers

What next?

What handler/s should be added next? It really helps to know what folks most need!

Click on the image below to vote: poll

Want something not on the list? Please add a comment below.

When relevant, it'd be helpful to please also mention which client libraries and/or API's you'd prefer be used. Links to relevant docs, etc. would also be much appreciated and help speed work! ๐Ÿ™

lsolbach commented 6 months ago

A Kafka producer would be useful, when Kafka is the medium of choice for dispatching messages in an enterprise. Jackdaw might be a good way to start.

bennyandresen commented 3 months ago

Maybe this is putting the cart before the horse due to the requirement on #16 but a zipkin compatible handler would be neat. (For Zipkin and/or Jaeger and others.)

ptaoussanis commented 3 months ago

@bennyandresen Hi Benjamin, just to clarify- a Zipkin handler would not block on #16. Telemere already includes its own tracing system. So there'd be 2 ways to get tracing data to Zipkin:

  1. Telemere -> OpenTelemetry -> Zipkin (needs #16 and an OpenTelemetry Zipkin exporter)
  2. Telemere -> Zipkin (needs a direct-to-Zipkin handler)

Edit to add: same would be true for Jaeger, etc.

velios commented 2 months ago

Something else. Prometeus expose data to endpoint for pulling and ability to push. Like mulog-prometeus .

avocade commented 2 months ago

Honeycomb.io, but probably fine using OT (for cljs please๐Ÿ™๐Ÿป).

mathiasp commented 2 months ago

I haven't been active in this area for some time, but wouldn't Riemann be a possible target?

From the Quickstart:

"""

Riemann is an event stream processor.

Every time something important happens in your system, submit an event to Riemann. Just handled an HTTP request? Send an event with the time it took. Caught an exception? Send an event with the stacktrace. Small daemons can watch your servers and send events about disk capacity, CPU use, and memory consumption. Every second. It's like top for hundreds of machines at once.

Riemann filters, combines, and acts on flows of events to understand your systems. """

"""

Powerful stream primitives

(where (or (service #"^api")
           (service #"^app"))
  (where (tagged "exception")
    (rollup 5 3600
      (email "dev@foo.com"))
    (else
      (changed-state
        (email "ops@foo.com")))))

Riemann streams are just functions which accept an event. Events are just structs with some common fields like :host and :service You can use dozens of built-in streams for filtering, altering, and combining events, or write your own.

Since Riemann's configuration is a Clojure program, its syntax is concise, regular, and extendable. Configuration-as-code minimizes boilerplate and gives you the flexibility to adapt to complex situations.

I wrote Riemann for operations staff trying to keep a large, dynamic infrastructure running with unreliable but fault-tolerant components. For engineers who need to understand the source of errors and performance bottlenecks in production. For everyone fed up with traditional approaches; who want something fast, expressive, and powerful. """