Feat: Added Tracing by ppmpreetham · Pull Request #265 · PostHog/posthog-rs

ppmpreetham · 2026-09-24T14:25:39Z

💡 Motivation and Context

Added tracing-subscriber (optional feature flag) integration that captures selected Rust tracing events as PostHog events.
This allows applications that already use tracing to send events to PostHog without implementing their own subscriber layer or field visitor.

This PR also Closes #205.

💚 How did you test it?

I've Added 4 integration tests covering:

Tracing field conversion and property preservation
Event filtering and event-name configuration
Distinct ID and shared property handling
SDK target exclusion and recursive capture prevention
E2E capture through the PostHog client transport

📝 Checklist

I reviewed the submitted code.
I added tests to verify the changes.
I updated the docs if needed.
No breaking change or entry added to the changelog.

If releasing new changes

Ran sampo add to generate a changeset file

marandaneto

Review findings from the validated snapshot. No approval submitted.

marandaneto · 2026-09-24T14:43:41Z

+        }
+
+        // for OOMs
+        let _guard = match CapturingGuard::try_acquire() {


blocking: Prevent background-worker capture feedback — the thread-local guard only covers synchronous enqueue. With a global subscriber, a before_send hook that logs an application-target event runs on the transport worker after this guard expires, enqueues another event, and repeats on subsequent flushes. Application-target filtering does not prevent this loop. Reproduction: reproduced — cargo test --features tracing-subscriber --test review_feedback (focused review regression) observed four captures from one original event with the hook artificially capped at three log emissions; temporary worker suppression made the same test pass.

marandaneto · 2026-09-24T14:43:41Z

+/// use std::sync::Arc;
+/// use tracing_subscriber::layer::SubscriberExt;
+///
+/// let layer = posthog_rs::PostHogLayer::new(Arc::new(client));


blocking: Make the documentation examples compile — all seven new no_run snippets are compiled by rustdoc, but lack client setup, imports, or an async context. This main example also needs SubscriberInitExt for .init(). Reproduction: reproduced — cargo test --features tracing-subscriber --doc failed all seven new doctests.

marandaneto · 2026-09-24T14:43:41Z

+
+    #[cfg(not(feature = "async-client"))]
+    {
+        posthog_rs::client(options)


blocking: Run blocking-client tests outside the async runtime — this branch constructs the blocking client directly inside #[tokio::test], causing reqwest runtime handling to panic before the tracing behavior is exercised. Use a runtime-free test context or a blocking thread for the blocking-client variant. Reproduction: reproduced — cargo test --no-default-features --features tracing-subscriber --test test_tracing failed all four tests with “Cannot drop a runtime in a context where blocking is not allowed.”

marandaneto · 2026-09-24T14:43:41Z

+Captures selected `tracing` events as PostHog events:
+
+```bash
+cargo run --example tracing --features tracing-subscriber


suggestion: Include the documented tracing example — the README points to an example target absent from this PR; add it or replace this command with an available quickstart. Reproduction: reproduced — cargo run --example tracing --features tracing-subscriber failed because no example target named tracing exists.

marandaneto

Additional non-blocking integration design and documentation suggestions.

marandaneto · 2026-09-24T14:45:49Z

+    S: Subscriber,
+{
+    fn on_event(&self, event: &TracingEvent<'_>, _ctx: Context<'_, S>) {
+        let metadata = event.metadata();


suggestion: Preserve tracing severity and source metadata — please consider recording the level, target, module, file, and line under agreed property names. Currently the target is used for naming, but severity and source location are omitted, so otherwise identical INFO and ERROR events cannot be distinguished after capture. Reproduction: reproduced — a focused captures_event_with_field_and_context_fidelity assertion for severity failed, and review_metadata_defaults_and_span_context confirmed the captured properties omit severity and source metadata.

marandaneto · 2026-09-24T14:45:49Z

+/// Tracing fields are stored as PostHog properties, while the existing
+/// PostHog client handles batching and delivery.
+///
+/// Use `tracing_subscriber` filters to control which events are captured.


suggestion: Document safe capture defaults with an allowlist — without a subscriber filter, this layer captures DEBUG/TRACE events and third-party targets as analytics events. Please show an application-target allowlist in the working quickstart and explain the volume/privacy implications of forwarding arbitrary tracing fields. Reproduction: reproduced — cargo test --features tracing-subscriber --test test_tracing review_metadata_defaults_and_span_context confirmed that an unfiltered layer captures both TRACE and DEBUG events from a third-party target.

marandaneto · 2026-09-24T14:45:49Z

+    /// `distinct_id` is read from the tracing fields.
+    pub fn new(client: Arc<Client>) -> Self {
+        Self {
+            client,


suggestion: Document that parent-span context is not inherited — fields on an enclosing info_span!("request", distinct_id = "user-123", request_id = "...") are not copied into its events; without another identity source, those events become anonymous. Please make this explicit and show the supported identity/context setup. Optional span-field enrichment can be a follow-up without introducing trace export. Reproduction: reproduced — review_metadata_defaults_and_span_context captured events inside such a span and confirmed a generated anonymous identity and no inherited request ID.

marandaneto · 2026-09-24T14:45:49Z

+    TargetAndName,
+    /// Derive the event name from the tracing metadata.
+    Custom(Arc<dyn Fn(&Metadata<'_>) -> String + Send + Sync>),
+}


suggestion: Clarify the boundary of custom event naming — EventNamer::Custom receives only metadata, so it cannot derive a name from an event field or inspect parent-span context. Please document that limitation and consider field-aware mapping only if a concrete use case requires it; prefer the existing before_send hook for transformations it already supports rather than adding an overlapping public callback. Reproduction: not reproduced — this is an API-design suggestion based on the callback signature, not a runtime defect.

dustinbyrne · 2026-09-24T14:46:45Z

hey @ppmpreetham, this is super cool! out of curiousity, have you seen our distributed tracing? some additional information here: https://posthog.com/docs/distributed-tracing/start-here

i wonder if this is a more natural direction to integrate with rust traces? cc @PostHog/team-apm

marandaneto · 2026-09-24T14:47:25Z

was your intention to add support for https://posthog.com/docs/ai-observability/traces or just capturing events with the tracing_layer subscriber? since we dont capture any traces right now in this PR

marandaneto · 2026-09-24T14:49:12Z

moving to draft until this and this is cleared up

ppmpreetham · 2026-09-24T14:54:50Z

hey @ppmpreetham, this is super cool! out of curiousity, have you seen our distributed tracing? some additional information here: https://posthog.com/docs/distributed-tracing/start-here

i wonder if this is a more natural direction to integrate with rust traces? cc @PostHog/team-apm

hey @dustinbyrne, thank you! I wasn't aware of the distributed tracing.
The intent of this PR is specifically the tracing_subscriber::Layer integration from #205 which is capturing tracing events/logs as PostHog events

I agree distributed tracing could be a more natural direction for Rust traces, but I think that would be a separate, broader piece of work

ppmpreetham · 2026-09-24T15:00:23Z

hey @marandaneto, This PR is just for capturing events proposed in #205. Trace/AI observability support isn't part of this PR, but could be added later if there's interest.

marandaneto · 2026-09-24T15:02:47Z

hey @marandaneto, This PR is just for capturing events proposed in #205. Trace/AI observability support isn't part of this PR, but could be added later if there's interest.

i wonder if this should be log events then? https://posthog.com/docs/logs
or do you really need product analytic events? https://posthog.com/docs/product-analytics

whats the problem you are trying to solve in your app? whats the visibility you need?

ppmpreetham · 2026-09-24T15:13:18Z

The main problem I'm trying to solve is avoiding a separate instrumentation path for applications that already use tracing. It was to let an app select specific tracing events and send them to PostHog with the existing client, rather than having to write its own Visit/Layer integration.

I wasn't solving a specific problem in my own app. I came across #205 and wanted to contribute. I don't have a strong preference between Logs and Product Analytics here, so I'm happy to align the implementation with whichever use case makes more sense for PostHog.

marandaneto · 2026-09-25T06:54:07Z

The main problem I'm trying to solve is avoiding a separate instrumentation path for applications that already use tracing. It was to let an app select specific tracing events and send them to PostHog with the existing client, rather than having to write its own Visit/Layer integration.

I wasn't solving a specific problem in my own app. I came across #205 and wanted to contribute. I don't have a strong preference between Logs and Product Analytics here, so I'm happy to align the implementation with whichever use case makes more sense for PostHog.

thx will check with APM team and come back to you

frankh · 2026-09-25T12:10:07Z

closing this as posthog now supports tracing, we don't want to be sending traces as posthog events

clients should use their existing tracing library to ship otel events, see https://posthog.com/docs/distributed-tracing

ppmpreetham · 2026-09-25T13:18:08Z

thanks!
i'll look into implementing other features at #29

ppmpreetham added 11 commits September 24, 2026 18:44

feat(guard): reentrancy

c86280e

feat(tracing): visitor parsing

6f02718

feat(tracing): eventnamer

ddacbfe

feat(tracing): structural data mappings

00ff694

feat(tracing): integration to runtime

bdf7a56

docs(tracing): add docstrings

6047772

feat(tracing): add tests

4770f50

Merge branch 'PostHog:main' into feat/tracing

99241d6

docs(tracing): update in examples

321cdde

chore(tracing): sampo

6c45928

chore(tracing): cargo fmt

2b1bc2a

ppmpreetham requested a review from a team as a code owner September 24, 2026 14:25

marandaneto reviewed Sep 24, 2026

View reviewed changes

marandaneto requested a review from a team September 24, 2026 14:44

marandaneto reviewed Sep 24, 2026

View reviewed changes

marandaneto requested a review from a team September 24, 2026 14:48

marandaneto marked this pull request as draft September 24, 2026 14:48

marandaneto requested a review from a team September 25, 2026 06:54

frankh closed this Sep 25, 2026

Conversation

ppmpreetham commented Sep 24, 2026

💡 Motivation and Context

💚 How did you test it?

📝 Checklist

If releasing new changes

Uh oh!

marandaneto left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

marandaneto left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dustinbyrne commented Sep 24, 2026

Uh oh!

marandaneto commented Sep 24, 2026

Uh oh!

marandaneto commented Sep 24, 2026

Uh oh!

ppmpreetham commented Sep 24, 2026

Uh oh!

ppmpreetham commented Sep 24, 2026

Uh oh!

marandaneto commented Sep 24, 2026

Uh oh!

ppmpreetham commented Sep 24, 2026

Uh oh!

marandaneto commented Sep 25, 2026

Uh oh!

frankh commented Sep 25, 2026

Uh oh!

ppmpreetham commented Sep 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants