Proposal: Extend log crate with contextual, typed, and fatal-level logging #700

New issue

Open

opened 2025-09-25 03:44:30 -05:00 by Saumya-R · 3 comments

Saumya-R commented

2025-09-25 03:44:30 -05:00

(Migrated from github.com)

Motivation: Automotive Use Case

Contextual / Hierarchical Logging

Current target (module path) is too flat for complex automotive applications where multiple layers/modules may reuse common subsystems.
Developers need to distinguish who logged what not only by module but also by parent/ancestor context.
Add optional hierarchical context (e.g. ECU → Subsystem → Component).
Such context could be attached automatically (per logger instance) and optionally extended by the user.
Enables better traceability of log origins in safety-critical systems.

Type-Aware Logging

Today everything is stringified, discarding type info needed by automotive backends (e.g. DLT expects type fidelity: numeric vs string vs struct).
Proposal: allow passing typed values directly (info!(42), info!("user_id" = 43), info!(User { id: 7 })).
Preserves fidelity for DLT and similar tools, enables filtering/sorting, while staying backward-compatible and simple for developers.

Fatal Log Level

Current Error conflates recoverable and unrecoverable failures.
Add a Fatal level for logging critical, fail-stop conditions.
Essential for automotive where safety hazards must be identified and escalated distinctly.

Benefits

Improves interoperability with standards (e.g. DLT, AUTOSAR logging).
Strengthens suitability for safety-critical domains (ISO 26262 compliance).
Still lightweight: could be added as opt-in features, maintaining compatibility.

*Motivation:* Automotive Use Case 1. Contextual / Hierarchical Logging - Current target (module path) is too flat for complex automotive applications where multiple layers/modules may reuse common subsystems. - Developers need to distinguish who logged what not only by module but also by parent/ancestor context. - Add optional hierarchical context (e.g. ECU → Subsystem → Component). - Such context could be attached automatically (per logger instance) and optionally extended by the user. - Enables better traceability of log origins in safety-critical systems. 2. Type-Aware Logging - Today everything is stringified, discarding type info needed by automotive backends (e.g. DLT expects type fidelity: numeric vs string vs struct). - Proposal: allow passing typed values directly (info!(42), info!("user_id" = 43), info!(User { id: 7 })). - Preserves fidelity for DLT and similar tools, enables filtering/sorting, while staying backward-compatible and simple for developers. 3. Fatal Log Level - Current Error conflates recoverable and unrecoverable failures. - Add a Fatal level for logging critical, fail-stop conditions. - Essential for automotive where safety hazards must be identified and escalated distinctly. *Benefits* - Improves interoperability with standards (e.g. DLT, AUTOSAR logging). - Strengthens suitability for safety-critical domains (ISO 26262 compliance). - Still lightweight: could be added as opt-in features, maintaining compatibility.

Thomasdezeeuw commented

2025-09-25 04:37:11 -05:00

(Migrated from github.com)

Contextual / Hierarchical Logging

Note that target != module path, though it's the default. You can set the target yourself: info!(target: "my target"). I've personally used this for access log set a specific target which can then be used for filtering later.

Current target (module path) is too flat for complex automotive applications where multiple layers/modules may reuse common subsystems.

Developers need to distinguish who logged what not only by module but also by parent/ancestor context.

Add optional hierarchical context (e.g. ECU → Subsystem → Component).

Such context could be attached automatically (per logger instance) and optionally extended by the user.

Enables better traceability of log origins in safety-critical systems.

I think this will add quite a bit of overhead if this entire hierarchy needs to be kept in memory. What I do is add an id to each log so they can be grouped. My use case is handling requests so it's easy, an id per request, I don't know what an equivalent would be in automotive software though. Would something like this be possible for your use case?

Type-Aware Logging

Have you tried key-value logging: https://docs.rs/log/latest/log/kv/index.html, it's fully typed.

Fatal Log Level

Duplicate of #334, which discusses adding additional logging level.

> 1. Contextual / Hierarchical Logging Note that target != module path, though it's the default. You can set the target yourself: `info!(target: "my target")`. I've personally used this for access log set a specific `target` which can then be used for filtering later. > * Current target (module path) is too flat for complex automotive applications where multiple layers/modules may reuse common subsystems. > * Developers need to distinguish who logged what not only by module but also by parent/ancestor context. > * Add optional hierarchical context (e.g. ECU → Subsystem → Component). > * Such context could be attached automatically (per logger instance) and optionally extended by the user. > * Enables better traceability of log origins in safety-critical systems. I think this will add quite a bit of overhead if this entire hierarchy needs to be kept in memory. What I do is add an id to each log so they can be grouped. My use case is handling requests so it's easy, an id per request, I don't know what an equivalent would be in automotive software though. Would something like this be possible for your use case? > 2. Type-Aware Logging Have you tried key-value logging: https://docs.rs/log/latest/log/kv/index.html, it's fully typed. > 3. Fatal Log Level Duplicate of #334, which discusses adding additional logging level.

tisonkun commented

2025-09-28 09:14:54 -05:00

(Migrated from github.com)

Contextual / Hierarchical Logging

This seems to be an insatnce of Logforth's (thread-local) Diagnostic and needs not to be a feature in log.

> Contextual / Hierarchical Logging This seems to be an insatnce of Logforth's [(thread-local) Diagnostic](https://docs.rs/logforth/latest/logforth/diagnostic/struct.ThreadLocalDiagnostic.html) and needs not to be a feature in `log`.

tisonkun commented

2025-09-28 09:17:00 -05:00

(Migrated from github.com)

Fatal Log Level

From your description, this can be resolved either:

Move recoverable errors to the WARN level.
Tag fatal logs with a "fatal" target and specially handling it in the log impl.

> Fatal Log Level From your description, this can be resolved either: 1. Move recoverable errors to the WARN level. 2. Tag fatal logs with a "fatal" target and specially handling it in the log impl.