Generate trace IDs as ULIDs by default

[adriangb]

The idea is to use a ULID to generate trace IDs.
This has the huge benefit of making trace IDs sortable and correlated with time.
For our backend this means much faster queries and much less data to index them.

This should not cause any issues with other backends, sampling or anything else.

This is already the default for logs and has been proposed to become the default for traces.

Why not use UUID v7 or set the bits for UUID v4 compatibility?

Mainly for safety of current implementations.
Existing implementations (including the OTEL Python SDK) should expect no more than 64 bits or randomness (see here).
Using a pure ULID (80 bits of randomness) ensures compatibility, using a UUID would leave us with only 7 (contiguous lower) bytes of randomness at most.
In the future if OTEL adopts https://www.w3.org/TR/trace-context-2/#random-trace-id-flag we can revisit.

[cloudflare-workers-and-pages]

Deploying logfire-docs with    Cloudflare Pages

Latest commit:	fec75d5
Status:	✅  Deploy successful!
Preview URL:	https://6b76750d.logfire-docs.pages.dev
Branch Preview URL:	https://uuid7.logfire-docs.pages.dev

View logs

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (488f399) to head (fec75d5).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##              main      #783   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files          137       138    +1     
  Lines        10985     11013   +28     
  Branches       780       781    +1     
=========================================
+ Hits         10985     11013   +28     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[adriangb]

@alexmojaki any idea why this test is failing only on 3.8? https://github.com/pydantic/logfire/actions/runs/12675633556/job/35327091346?pr=783

[alexmojaki]

The test was broken, it would always sort by the random part of the trace ID and never disambiguate by start time. Only 3.8 picked this up because f-string magic is disabled there. Otherwise the span name was always the f-string template.

[adriangb]

The test was broken, it would always sort by the random part of the trace ID and never disambiguate by start time. Only 3.8 picked this up because f-string magic is disabled there. Otherwise the span name was always the f-string template.

Ah good call. Should have used message!

[adriangb]

Thanks for your help Alex!