tauri-apps
[feat] tracing support for rust webviews (leptos, yew etc.)
This is a feature offer rather than a feature request!
I have implemented a subscriber layer for passing tracing events created with the standard tracing macros (error!, warning! etc.) and instrumentation to either the tauri_plugin_log endpoint, a tracing specific endpoint and/or the web-console. If interested, I could offer a PR.
Motivation
I use tracing for it's spans, filtering and structured data. I have my own tracing formatters so would prefer not to use log as supported by tauri_plugin_log.
It's possible to integrate tracing and log with tracing-log but it means losing features/support and it has undesirable consequences like forcing execution of all event code even if disabled.
Options
-
If it's not wanted or already exists, you can just close this issue
-
As a feature of
tauri_plugin_logallowing a user to switch between tracing and log -
As it's own
tauri_plugin_tracinga) as an official tauri plug-in b) as an independent crate (is there a naming scheme for unofficial plugins?)
guest-rust
Some plug-ins have guest-js for client integration but I haven't seen the equivalent for rust webview integration i.e. guest-rust which is necessary in this case. This could be as a separate crate or as a feature on the plug-in crate e.g. webview or something. Ideally there is a standardised pattern for this.
It's possible to integrate tracing and log with tracing-log but it means losing features/support and it has undesirable consequences like forcing execution of all event code even if disabled.
Would we also lose features if the plugin is tracing-first but can also catch log logs? With the tracing crate becomming more of a standard i feel like it makes sense to make that the standard in tauri-plugin-log in v3 or to deprecate tauri-plugin-log in favor of tauri-plugin-tracing while keeping support for log logs.
Having a tracing subscriber and log subscriber in the same app feels weird if that's even possible.
Would we also lose features if the plugin is tracing-first but can also catch log logs?
From what I can see:
i) It looks like tracing_log conversion doesn't support log's 'kv' feature for structured data:
https://github.com/tokio-rs/tracing/issues/3355
ii) any custom adaptors and appenders based on log or use of log's global/compile-time settings. I doubt those will work as expected.
iii) those who choose log likely consider simplicity a feature. They might resent having to deal with configuring tracing after seeing trace from other crates in their logs or some such.
iv) I'm not aware of anything that would be truly lost for a log user as it's a subset of tracing features. Tracing is often a drop-in replacement but the 'kv' syntax is different. It looks a bit odd to me and I don't know how widely it's used.
iv) tracing criticisms:
a) performance - I don't know if it's relevant for log vs. tracing. When I see it discussed, the context is handling message flooding and different approaches for dropping messages and multi-threading to not block the main thread
b) internal apis - instrumentation is as easy log but I find the internal APIs pretty baffling making extensions more of a headache than they should be
c) initialisation - I dimly recall issues with things I could only configure once on first init which made dynamically changing settings and late-bound/lazy-loaded plug-ins difficult. It may have been my incomplete understanding at the time.
also catch log logs
Deciding whether to bridge logging frameworks with tracing-log is probably best left to the application developer.
If libraries make the decision there can be problems e.g. developers may already mix log and tracing for different purposes. If they already use tracing-log to convert tracing to log then you get message recursion by enabling the reverse flow too.
It wouldn't be a problem for Tauri to make this easy and configurable but probably not as an architectural decision to rely on and require.
thanks for the response :)
i'm also thinking about how/when to use tracing vs log in tauri and its plugins - currently we have a semi weird mix :/ that's the background for my question
i'm also thinking about how/when to use tracing vs log in tauri and its plugins - currently we have a semi weird mix :/ that's the background for my question
Hah! I have more rough thoughts along these lines I wasn't sure you'd want. Treat it as "thinking out loud" rather than a solid conclusion/recommendation.
Having a tracing subscriber and log subscriber in the same app feels weird
What might be missing is for Tauri to standardise how it handles logging and provide a stable interface as a core part of it's architecture.
It probably shouldn't all be left up to plug-ins. Tauri is a showcase of logging challenges: it's a distributed system with multiple process, plug-in ecosystem, multi-language, cross-platform, multiple instances can run at the same time, an install can be used by multiple users, it's customer facing and is deployed on customer devices so logs have security/privacy concerns for users and observability challenges for developers. Ugh!
I doubt Tauri needs/wants it's own custom logging system but it probably could just declare "the Tauri logging system is tracing" and provide API endpoints for structured events for integrating different languages/frameworks/components in a consistent way. Tauri would remain agnostic to how developers are instrumenting their code and log plug-ins would just be thin wrappers to connect a logging framework into Tauri's logging pipeline.
The goals/requirements for standardising include:
- Define how the logging pipeline / message-bus works:
- how log messages are collected/sent from multiple processes/contexts
- how events are integrated into a single unified application level log
- how to fan out to system logs, observability platforms, application ui etc.
- Unify semantics of structured data from different sources:
- integrating a log source shouldn't mean stringifying to a generic message but ensuring common fields can be mapped and retain their meaning e.g. component, code location, thread id etc.
- necessary for correctly filtering and transforming an integrated log for different destinations like system logs, ui views, observability platforms etc.
- Standardise log configuration
- single way to define how filtering by level, component or other structured data is declared
- a known format can be shared across languages and frameworks
- event-hooks for configuration changes
- Standardisation supports ecosystem
- set expectations for how Tauri ecosystem behaves:
- plug-ins integrate with the Tauri pipeline
- plug-ins honour logging configuration
- plug-ins respond to configuration changes
- can build dev tools and components on core logging interfaces
Most of that really is over my head but i really really appreciate the inputs!! Seems like this will require more thinking and work than i had hoped.
That's probably just my bad writing :) It's more of a big decision rather than a lot of work.
Adopting tracing as Tauri's core logging system would mean including tracing config where appropriate like tauri.conf/tauri::Builder, I can supply Tauri API end-points and refactoring any relevant plug-ins / documentation. One of those 'trivial' jobs... that's always more work than you expect... so I won't downplay it.
The big scary aspect is making a 3rd party dependency a core service, deferring to how it does configuration/event-schema/layers and saying "this is how we do things now". That deserves plenty of thought.