Open ThorstenHans opened 11 months ago
Just to clarify things, you can explicitly pass the environment variable on the command line when running spin up
.
Is there a reason Spin would pass Rust-specific environment variables to guest components? Why not do it for other language ecosystems?
Good point. Obviously, It should be passed to the component as SPIN_DEBUG
or even SPIN_LOG_LEVEL
so. It's more the fact that there should be some "standard" where application developers can rely on.
I went with RUST_LOG
because its mentioned in the documentation to be the proper way for instructing spin
to do "verbose" logging.
In my case, I wanna do verbose logging if the host/runtime is instructed to do verbose logging. I don't want to add additional application state to detect if verbose logging is activated or not.
Ultimately, this would end at some point as an method in the language specific SDKs (Pseudo code ahead)
use spin_sdk::log;
fn foo() {
println!("{}", log::get_log_level());
}
While thinking about it.
A potential SDK capability such as spin_skd::log
(described in my comment above) could also provide simple the entire log capabilities required by application devs.
This would move things like "log level detection" completely out of the application developers responsibility.
+1 to a way for Spin app components to optionally log appropriate to a Spin-wide log level. SDK addition and/or env var (eg SPIN_LOG
) seem likely candidates. Combing through the backlog and I see there are a handful of semi-related issues eg https://github.com/fermyon/spin/issues/608 and https://github.com/fermyon/spin/issues/1349.
I've updated the title of the issue to reflect the conversation
I expect the spin CLI itself will still continue to use/support RUST_LOG, owing to its Rust codebase, but it seems to me that it would be natural for it to pass the value provided by eg RUST_LOG=spin=<log level>
down to components as SPIN_LOG=<log level>
. This has heavy overlap with https://github.com/fermyon/spin/issues/1349; I would imagine, if we liked this approach, this would satisfy the needs in this ticket and 1349.
@calebschoepp Is this superseded by the OpenTelemetry work?
@calebschoepp Is this superseded by the OpenTelemetry work?
Good question. I would say it's tangentially related but not superseded by the OpenTelemetry work.
I'm re-reading through this and I feel pretty weird about passing any RUST_LOG
value through as a SPIN_LOG
. From my perspective setting RUST_LOG
is purely about introspecting on the Spin runtime and I would find the behaviour confusing if this also affected the verbosity of my guest component. I would prefer a more explicit mechanism to make my guest verbose (whether spin_sdk::log
, a special spin flag, or a user defined env var).
Related I don't think we should follow through with #1349 and rename RUST_LOG
.
IMO, the runtime should pass the
RUST_LOG
environment variable to components.This would allow the component developer to take certain actions (write logs), if
RUST_LOG
is set tospin=debug
.