fermyon / spin

Spin is the open source developer tool for building and running serverless applications powered by WebAssembly.
https://developer.fermyon.com/spin
Apache License 2.0
5.14k stars 248 forks source link

Spin should pass the `SPIN_LOG` environment variable to component #1761

Open ThorstenHans opened 11 months ago

ThorstenHans commented 11 months ago

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 to spin=debug.

radu-matei commented 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?

ThorstenHans commented 11 months ago

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());
}
ThorstenHans commented 11 months ago

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.

vdice commented 11 months ago

+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.

ThorstenHans commented 11 months ago

I've updated the title of the issue to reflect the conversation

vdice commented 11 months ago

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.

itowlson commented 5 months ago

@calebschoepp Is this superseded by the OpenTelemetry work?

calebschoepp commented 5 months ago

@calebschoepp Is this superseded by the OpenTelemetry work?

Good question. I would say it's tangentially related but not superseded by the OpenTelemetry work.

calebschoepp commented 2 months ago

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.