Clojurians Log v2

Das klingt spannend, ich kann mir vorstellen, dass die Versionierung bsp. bei Änderungen und Rolling Deployments zum Zug kommt?

@mroerni Schaue ich mir auch nachher mal an, danke für den Tipp

@ramart Danke für die Hilfe, die Idee mit with-redefs ist Spitze. Ich habe es noch einmal ein bisschen erweitert, um auch die ID des Parent Spans hinzuzufügen (und den Honeycomb Tracer an sich), und eigentlich ist es jetzt genau das, was ich haben möchte.

Das kommt dann als Trace bei Honeycomb selbst an

bzw mit Mock Timer sogar noch etwas schicker:

Na, das sieht doch schon vielversprechend aus! Die Idee mit den Meta-Informationen ist prima, solange man die Kontrolle über den Quellcode hat. Für das Verfolgen von Fremdfunktionen wäre wahrscheinlich noch eine API der Form (trace #'func-var)hilfreich. Oh, dann könnte man auch Trace-Szenarien vorkonfigurieren! Wenn ich das-und-das Verhalten genauer untersuchen möchte, sollte ich genau dieses Set an Funktionen tracen. :star-struck:

Ja, so ein bisschen was außenrum fehlt noch, z.B. auch um Ring Routes zu tracen usw usw

Sieht gut aus:+1:

Zu Code den ich nicht kontrolliere: Könnte ich da nicht mit alter-meta! auch Fremdcode ins Tracing holen, oder hat das noch andere Nebeneffekte die ich da nicht beachte?

Ich hab' noch nicht lange drüber nachgedacht, aber ich habe ein spontanes Störgefühl. Wieso an konkreten Funktionen, die ich ja benennen muss, per alter-meta! was dran kleben, damit später dann jemand anders das einsammeln kann? Da hab' ich ein von-hinten-durch-die-Brust-ins-Auge Störgefühl.

Es gäbe mir halt die Möglichkeit, einzelne Funktionen aus 3rd Party Libraries zu tracen, ohne dass ich Zugriff darauf habe… aber ja, es ist schon nicht sonderlich transparent, ein explizites (traced...) wäre wahrscheinlich sprechender